Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What's next for suitcss? #149

Open
timkelty opened this issue Dec 14, 2017 · 19 comments
Open

What's next for suitcss? #149

timkelty opened this issue Dec 14, 2017 · 19 comments
Assignees

Comments

@timkelty
Copy link
Member

timkelty commented Dec 14, 2017

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

Monorepo Done in #151

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 fixed or 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 protected] but a breaking change to components-button bumps all packages to 5.x. However, in that case a user could just simply stay on [email protected] 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. .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 @responive directive 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:

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 md and lg only:

<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. @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-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.

@giuseppeg
Copy link
Member

giuseppeg commented Dec 15, 2017

Monorepo

Sounds good. Maybe independent versioning is the best way to go with the contingency that for example it allows us to bump a dependency and release (eg. npm version patch && release) every package at once.

Leverage postcss ecosystem

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. .u-size1of4 and the file to generate custom ones.

Another idea could be to let the preprocessor infer the component name from the main @define comment and automatically add it to the class selectors. This would also make the styles CSS Modules-compatible.

eg.

/* @define Button */

.root { } // replaced with `.Button` can be configurable
.root--secondary {} // `.Button--secondary`

.child {} // .Button-child

This would make authoring also more pleasant.

Spec changes/clarifications

I've been using modifiers for cases like md-Grid--withGutter: Grid--withGutterMd or utility classes to tweak the gutter. But either ways work for me.

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.

NPM Scoped packages

Y not!

deprecate preprocessor?

If we manage to extract preprocessor into a plugin that'd be great I think!

suitcss-contrib

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.
Unfortunately I won't have time to work on any of this (with exceptions but I cannot guarantee anything).

@AntonTrollback
Copy link
Contributor

AntonTrollback commented Dec 15, 2017

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 ✅.

@giuseppeg
Copy link
Member

giuseppeg commented Dec 15, 2017

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.

@kristoforsalmin
Copy link
Contributor

Hello everyone,

I've been using SUIT CSS for years now, what a great project.

Monorepo

Great idea, it'd take away most of maintenance burden.

deprecate preprocessor?

I think it makes sense, personally I use PostCSS plugins directly (not to introduce yet another dependency).

Leverage postcss ecosystem

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.

NPM Scoped packages

👍 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

@simonsmith
Copy link
Member

Finally got around to adding some thoughts

Monorepo

Yes, 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 suit repo with everything in there.

PostCSS ecosystem

I'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 calc and custom-properties.

Media prefixing for components

I 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 packages

Yes, would be nice to have our own namespace

Deprecate preprocessor

I'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-contrib

This 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-grid

I feel like there could be value in moving from Flexbox to CSS Grid as seen in this example

Priority

I 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

@timkelty timkelty mentioned this issue Mar 29, 2018
@timkelty
Copy link
Member Author

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

@timkelty
Copy link
Member Author

@simonsmith:

PostCSS ecosystem

Yeah…I guess what I was envisioning was using it more for a development

Media prefixing for components

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.

components-grid

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.

suitcss-contrib

Hey that looks just like the one I never published!

@simonsmith
Copy link
Member

Yeah…I guess what I was envisioning was using it more for a development

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.

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.

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

Yeah! How do you envision this working? Like would v4 grid be flexbox and v5 be grid?

Yes. We did the same with 2 > 3.

@timkelty
Copy link
Member Author

Yeah…I guess what I was envisioning was using it more for a development

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.

@mlnmln
Copy link
Contributor

mlnmln commented Dec 17, 2018

Sorry if I am resurrecting any zombies, but could somebody give an update on the current state of SUIT CSS?

  • How far did you progress 2018?
  • Are there any specific areas where you would need support in 2019?

Thanks!

@simonsmith
Copy link
Member

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!

@oleersoy
Copy link
Contributor

Since SUIT is effectively dormant, I'll comment. I've started what is essentially a fork (All repositories).
https://github.com/superflycss/

Overview Blog:
https://medium.com/@ole.ersoy/superflycss-the-wait-is-over-f0601fdb62f2
https://medium.com/@ole.ersoy/hacking-the-superflycss-cli-postcss-plugin-configuration-b5157ff5f2e3

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:
https://github.com/superflycss/superflycss

CLI:
https://www.npmjs.com/package/@superflycss/cli

Demo of applying the methodology, responsive queries to a component, and CSS dependency management, test methodology with nunjucks templating, etc.:
https://www.npmjs.com/package/@superflycss/component-navbox
https://superflycss.github.io/component-navbox/target/test/html/

There's a lot more coming down the line. For example I plan on turning Material and ngx-admin into pure CSS component skins:
http://akveo.com/ngx-admin/#/pages/dashboard

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:
https://superflycss.github.io/component-button/target/test/html/bootstrap/

@simonsmith
Copy link
Member

@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

@mlnmln
Copy link
Contributor

mlnmln commented Dec 20, 2018

@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.

@simonsmith
Copy link
Member

simonsmith commented Dec 20, 2018

@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 lerna branch in #151

@mlnmln
Copy link
Contributor

mlnmln commented Dec 20, 2018

@simonsmith Great! I'll take a look.

Did you use lerna import?

We're tracking the work on the lerna branch in #151

edit: Will follow the discussion there.

@oleersoy
Copy link
Contributor

@simonsmith you said this (And keep in mind that this thread was started in 2017):

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

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.

@giuseppeg
Copy link
Member

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 suitcss-preset and recommend to use postcss-preset-env for the rest.

As for the media queries maybe we can go for:

--media-[sm-|md-|lg-]<mediaQueryName>

to match the utility classes convention:

u-[sm-|md-|lg-]<utilityName>

@giuseppeg
Copy link
Member

giuseppeg commented Dec 22, 2018

by the way are custom media queries still a standard or they abandoned the idea?

@simonsmith simonsmith reopened this Jan 16, 2019
@simonsmith simonsmith added suit and removed suit labels Feb 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants