Wanted to start up a discussion to share some ideas & concerns I have about what might be next for suitcss. Would love to get everyone’s input.
This came up quite a while ago, and we decided not to pursue it. Lerna makes this pretty damn easy. I think the benefit to development efficiency would be more than worth it.
If we proceed, we would have to decide if we wanted to release packages in a
independent versioning mode.
fixed is simpler and has less complications with interacting packages. (my preference for suit)
- The drawback is unexpected major version bumps for end-users (e.g. user is only using
email@example.com but a breaking change to
components-button bumps all packages to
5.x. However, in that case a user could just simply stay on
firstname.lastname@example.org with no harm.
Here’s an example of what the conversion process might look like: https://github.com/babel/babel-preset-env
Leverage postcss ecosystem
Now that our build is fully postcss, there is a lot we could do to streamline development, and also provide a level of extensibility for our users. For example, currently whenever we have a responsive variant of a utility, we just duplicate the code and change selectors. If a user wants to add a new viewport def (e.g.
--xlg-viewport), they’re stuck recreating all the code if they want to use it with responsive utilities (e.g.
We should be able to leverage postcss more into our build process to make things like this more configurable. Tailwind CSS, for example, has an
@responive directive for generating these.
media prefixing for components
Whether or not it is a common or “suggested” practice, I still feel that we should have media-prefixing for components written into the spec. Previous discussions here and here.
Long ago @necolas stated:
For components, you can use media queries directly in your component CSS instead. And in general, I’m not really sure that viewport-width should be the concern of UI components. Certain frameworks will allow you to efficiently re-render the component HTML, and I think swapping out HTML is often simpler and more robust.
While I agree, I think there are still simple situations where media prefixing for components can make a lot of sense. Consider something like this, where you might want to render a gutter on
<div class="Grid md-Grid--withGutter lg-Grid--withGutter">…</div>
NPM Scoped packages
Would be nice to release things on npm with scoped packages (e.g.
I’m wondering if we should deprecate the preprocessor in favor or using just a postcss and a suitcss-postcss plugin directly. It seems like it’s really only used internally anyway (correct me if I’m wrong).
Wondering if it would be a good idea to have a community-managed
suitcss-contrib org for people to source “vetted” community components and utils.
Along these lines, I think it would be nice to somehow provide more guidance to the community for common problems everyone needs to solve. Currently , I think everyone kind of figures out how to manage things like typography components, forms, spacing, etc. on their own. While I don’t want to provide a kitchen-sink, many of these seem so common that guidance would be helpful.