What's next for suitcss? #149
Comments
Sounds good. Maybe
If by this you mean use advanced/non-standard features to generate static, production ready code then yeah we could do that. We could ship a pre-built basic version eg. Another idea could be to let the preprocessor infer the component name from the main eg. /* @define Button */
.root { } // replaced with `.Button` can be configurable
.root--secondary {} // `.Button--secondary`
.child {} // .Button-childThis would make authoring also more pleasant.
I've been using modifiers for cases like On a side note, I agree with Nicolas that with JS e.g. React sometimes you'd rather render a different html structure rather than hacking with CSS to make it work on smaller/bigger screen.
Y not!
If we manage to extract preprocessor into a plugin that'd be great I think!
We can start it any time and see where it goes. Awesome ideas Tim, I think that most of them are actionable, in case we should just prioritize. |
|
I find myself rarely installing anything other than the Button component, the display utils, maybe the text utils, and perhaps the Grid. The official SUIT components and utilities can be a fantastic way to abstract quirky snippets of CSS (hiddenVisually is a good example) but most of them, are in my opinion, too specific and simple to make it worth installing, configure, and referencing the documentation. This, in combination with that I also strongly believe (based on long-term and large-scale experience) that SUIT got too excited about utils, makes me not care that much about many of the repositories. SUIT never solved working with viewport size. The Grid with media query prefixes was really cool and innovative when it was released but I think that extending that approach to other cases doesn't work long term. Agreeing with @necolas that new technology was/is needed. I think SUIT is the fanciest and cleanest of BEM like methodologies. Love the style guide and the newish tools around that. But, other than keeping it all alive and supposedly improving and cleaning up the documentation, I consider SUIT as finished ✅. |
|
Last time I used SUIT in a project I ended up building a handful of components and a lot of utility classes. As I see it right now most of the times it is hard to come up with the right abstraction for a component and a more utilities/atomic-css driven approach works very well https://medium.engineering/simple-style-sheets-c3b588867899 I don't like Atomic CSS (c) per se or libs like tachyons but writing inline styles using object literals in JS and let a tool compile them down to atomic classes is really nice. At this stage if I were to use CSS in AnotherLanguage I would write a library for that language similar to one of the CSS in JS' or use CSS Modules. That's why I proposed that we make SUIT, CSS Modules compatible: namespacing with the ComponentName can be automated, and authoring would be a slightly more pleasant experience. |
|
Hello everyone, I've been using SUIT CSS for years now, what a great project.
Great idea, it'd take away most of maintenance burden.
I think it makes sense, personally I use PostCSS plugins directly (not to introduce yet another dependency).
Please don't take me wrong, but I actually like that SUIT CSS uses only proposed CSS features (almost). It makes it lightweight and technology-agnostic. I also do agree with @AntonTrollback regarding the overall state of a project.
👍 I think, this could be done alongside with the monorepo transition. Going forward, personally, I'd like to see SUIT CSS putting more focus on tidying up documentation and improving SUIT CSS's website. That would make project more appealing for newcomers. Adding small things like logo or moving documentation to the website would definitely increase developer experience in my opinion. Thanks |
|
Finally got around to adding some thoughts MonorepoYes, I agree that we should make this a priority now. The biggest reason for lagging on maintenance for me these days is remembering to publish all the relevant modules. Initially I was worried about losing the issues and what not but I think it's worth the hit and just having a PostCSS ecosystemI'm not in agreement here. Whilst I see the logic I really like the idea of users being able to gradually drop parts of PostCSS out as browser support improves and one day not have a build step at all. I think this is a big win over a little bit of file duplication. A good example is Media prefixing for componentsI can see the value in this and whilst I too have seen great results with things like react-media I don't think there is any harm in permitting in SUIT if it helps users solve problems. npm Scoped packagesYes, would be nice to have our own namespace Deprecate preprocessorI'm inclined to agree. It's essentially a glorified wrapper around PostCSS anyway. If we formalised a plugin pack we could make it easier to use with the postcss webpack plugin too, or even add our own thin webpack plugin around it. suitcss-contribThis is a good idea as linking to them is one thing but if they're not managed or updated it's not great. We could move polished packages into the core org as well if they're good enough. I'd like to nominate my form field package which has been working well 😄 components-gridI feel like there could be value in moving from Flexbox to CSS Grid as seen in this example PriorityI feel like focusing on the monorepo first would be wise as it will make working on the other tasks far easier. I'll start looking at Lerna and seeing what is involved |
|
Sounds like monorepo is unanimous! The biggest decision is deciding if we want to do fixed/locked versioning or independent: https://github.com/lerna/lerna/#fixedlocked-mode-default Lets work here; #151 |
Yeah…I guess what I was envisioning was using it more for a development
Yep, I agree solutions like react-media are better, but I think assuming users are in a React/Vue/SPA environment excludes lots of people.
Yeah! How do you envision this working? Like would v4 grid be flexbox and v5 be grid? Wondering if we'll want to maintain both for a while until support is greener.
Hey that looks just like the one I never published! |
Ah I see. Well this might be easier to handle in a monorepo which I'm sure we've discussed previously. Perhaps using the suitcss postcss pack to generate the files that go into the npm packages? That could be quite nice.
Yes, not everyone has the luxury of swapping out branches of their component render tree so I'm all for this. SUIT still has a place in non SPA/JS app scenarios
Yes. We did the same with 2 > 3. |
Sorry I submitted that before finishing my thought…yes what you said :) So the end user would include the generated files, but a power-user might want to include the source, provided they're using the right postcss plugins. Would cut down on all this type of duplication and provide extensibility for users that wanted it. |
|
Sorry if I am resurrecting any zombies, but could somebody give an update on the current state of SUIT CSS?
Thanks! |
|
Hey @mlnmln I don't think there was much progress beyond this thread. I can't speak for the others but I've been busy with other things that stop me from dedicating much time to SUIT beyond answering questions and other small tasks Probably the biggest task is still the monorepo, so if you're experienced with Lerna then we could definitely use a hand! |
|
Since SUIT is effectively dormant, I'll comment. I've started what is essentially a fork (All repositories). Overview Blog: The main goal is to provide standards for a CSS ecosystem where anyone can publish a component or utilities and we will all be able to have interoperability because we share the same core packages and standards. Thus most of the work to date is to demo core packages and a few components that show that the concept / framework works well with NPM and PostCSS. Overview: CLI: Demo of applying the methodology, responsive queries to a component, and CSS dependency management, test methodology with nunjucks templating, etc.: There's a lot more coming down the line. For example I plan on turning Material and ngx-admin into pure CSS component skins: The first thing I need to do is add way for frameworks like Angular and React to generate all the templates using CSS utilities and classes into a single file, such that that file can be used to 'uncss' all css not used. Some of the modules are very large, such as the font, color, and layout utilities ... Demo / tests applying the framework to bootstrap buttons: |
|
@oleersoy The question was about SUIT progress and what areas need support, I don't think giving a full overview of your framework is appropriate with that topic |
|
@simonsmith My company has been using SUIT CSS for years, so we have incentives for an actively maintained package. I do have some personal experience with lerna.js, yes. I'll check start of 2019 what kind of resources we could offer for the project. |
|
@mlnmln Sounds good. I should have more time in 2019 to dedicate to OSS as well so perhaps we can work together on any pressing issues. Once everything is in a monorepo I'm expecting maintenance to be far easier and actually encourage us to get on with the various outstanding improvements We're tracking the work on the |
|
@simonsmith Great! I'll take a look. Did you use
edit: Will follow the discussion there. |
|
@simonsmith you said this (And keep in mind that this thread was started in 2017):
And that's essentially the state of SUIT. Since I'm at least pushing new material monthly with the intent of creating an ecosystem that we can all publish css modules too which are interoperable, responsive, and themeable, that is something that we can all benefit from. Might be helpful to take a "Glass is half full" view here. |
|
I agree that the first step would be to reorganize the org and make a monorepo but I also don't have time to do this right now. @mlnmln in case you have time and want to give this a stab it'd be nice to also evaluate Bolt https://github.com/boltpkg/bolt (see if it is maintained and if it is missing any important feature that lerna has). I'd be fine to go with lerna right away too though - in any case if you do this please add a tl;dr section to the README to explain how to manage the repo with that specific tool (the last thing I want is make it harder to contribute). Next I guess we can tackle the preprocessor deprecation, make a As for the media queries maybe we can go for: to match the utility classes convention: |
|
by the way are custom media queries still a standard or they abandoned the idea? |
Hey all,
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.
/cc @suitcss/contributors
MonorepoDone in #151This 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
fixedorindependentversioning mode.fixedis simpler and has less complications with interacting packages. (my preference for suit)components-grid@4.xbut a breaking change tocomponents-buttonbumps all packages to5.x. However, in that case a user could just simply stay oncomponents-grid@4.xwith 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..u-xlg-size1of4).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
@responivedirective for generating these.Spec changes/clarifications
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:
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
mdandlgonly:NPM Scoped packages
Would be nice to release things on npm with scoped packages (e.g.
@suitcss/components-grid)deprecate preprocessor?
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).
suitcss-contrib
Wondering if it would be a good idea to have a community-managed
suitcss-contriborg 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.
The text was updated successfully, but these errors were encountered: