Thanks for the detailed overview @uxamanda. We're roughly on the same page on how to make styling easier, and some of these issues we can look at over time, in particular how to make it easier to build themes.
I think using the styled-component was a mistake since it makes customisation harder and it's a bit cumbersome in terms of development too, so for new components I'll go for a simple stylesheet approach, so that part of the codebase start moving to this.
I've tried that earlier but I've just realised that the first step is to move the theme colors to CSS variables, because then it's possible to use them in stylesheets. I've also looked at naming convention and I'm thinking of using RSCSS as it matches more or less the convention we already use, which is "name-type" (eg, "sync-button", "title-input", etc.). I'll experiment with all that on a simple component to see how it can work out.
2 Likes
RSCSS seems like a good approach for class names.
It seems there are 2 things in play:
- class names – as you mentioned, these make sense to describe where they are used, and will likely be unique. i.e. there is only one "notes-list" or whatnot.
- css variables - these are a set of common "roots" for the styles so that a user / theme maker can quickly change a color or font and it will affect the entire design.
There seems to be missing the 3rd piece, which ends up being helpful in consistent in design, which is common classes. I.e. a "panel" might have a set margin / padding + background color + border. Or a "headline" which is specific color + font + size.
These "rolled up" styles can be defined in (at least) 2 places - they can either be defined as classes, so a specific element might be .notes-list.panel in the HTML (or even #notes-list.panel since the first is unique). Or, it can be .notes-list in the html and then the rolled-up styles are included in the stylesheet. (If something like SASS is used, this can be "extends").
My preferences is on the former where the common classes are included in the HTML and we maintain a small design system style guide that defines and shows these so developers can easily include cut / paste.
Even better – in another project we actually make all of these sub-elements into their own components, so the developer includes a "headline" component and just provides the string as an attribute. In practice this means that the designer creates all the components in code, and the developer just connects "lego blocks" for layout. This is the https://storybook.js.org approach.
And, since the component will have a name "notes-list", even if it includes common things like a panel and headline, it can easily be overwritten since when it is compiled, the sub-components expose their HTML classes in a predictable way.
1 Like
I had never hard of rscss and don't really have an opinion about the naming conventions that are used. I do have an opinion about the way rscss promotes nesting. This increases the specificity of the CSS rules and can make simple things incredibly hard.
In my opinion CSS specificity should be kept as low as possible at all times. This is what BEM promote for very good reasons.
1 Like