re: An ode to the CSS owl selector VIEW POST

TOP OF THREAD FULL DISCUSSION
re: For me the biggest step forward (which was terribly long overdue) for CSS was the addition of flexbox and (more recently) grid layouts. I know, boo...

Solid examples you provided when components can make your life miserable when it comes to CSS. You are completely right when it comes to importing components from other libraries that ship a lot of their own CSS. Seen those sometimes, but I really try to avoid them, unless I really cannot do so anymore. In most cases I feel that those components are wrongly designed. Applying your styles properly should always be possible. In my case, I am there to have your feature set, not your styles, as they hardly ever match. The bare minimum that you can ship is CSS that is require to let the component function like it should (e.g. make a table side-scrollable, while looking ugly as hell).

Take for instance a table component. In most cases you can set a lot of Props in the React component to ensure that everything is working in various configurations (headers, pagination, multi-select etc. etc.). But when everything is shipped in one component, it is difficult to ensure you can apply styles correctly. It is far more beneficial if the library allows to build components like:

<Table>
  <TableHead />
  <TableBody />
  <Pagination />
</Table>

In this case you have the ability to apply your own styles on 4 different component (and wrap everything once yourself, creating your own styled tablewrapper component). Another example could be a Popup. It mainly consists of a click-area, and content that popups from an indicated direction. Instead of providing one <Popup /> component, provide something like shown below. This again allows to provide more or your own styling. The only styling you need to ship is to ensure that the content is positioned correctly, either on click or on hover. But the content itself can just be something with styles (e.g. background, spacing, drop-shadows).

<Popup>
  <PopupButton />
  <PopupContent />
</Popup>

So most of the issues we come across when using other people components, especially isolated (e.g. only a dropdown from material-ui), are components designed without other peoples CSS-needs in mind.

(This discussion inspired me for another blog-post I can write, thanks!)

Thanks for the in-depth answer!

The bare minimum that you can ship is CSS that is require to let the component function like it should (e.g. make a table side-scrollable, while looking ugly as hell).

Minimal CSS is good - I think we can all agree on that. But when exactly do you stop? After all, people will often download components based on screenshots. Your component may be good, and with carefully crafted minimal CSS, but will it receive any attention if it looks ugly? On a similar note, what if I would rather have a component which looks good by default and does not fit in as well, but is easy to just slap into an app? My point here is: I think that (just like "good API design") "minimal CSS" is a lot easier said than done.

The worst CSS experience I've ever had (which just happened to be my first contact with CSS ever) was with a big UI framework I had to deal with (I won't tell the name, it's still alive), which had a really complex SCSS theming going on, poorly documented of course, and to add insult to injury the HTML structure was generated dynamically at runtime, with DOM modifications galore on top. You had to (more or less blindfolded) guess the right selector to match the generated structure, and then pray that it happened to be more specific than any of the extensive theming which was already in place. No hot reloading by the way, a server restart was required for every change. It was a nightmare. I still clearly remember the 4 hours of work it took me just to change the font color of a tabsheet heading. So I'm a little biased when it comes to CSS, but I've also had some positive experiences with it later on.

I remember a similar experience. I learned CSS before the big frameworks existed. But at a certain point it got to work with a rapid development tool (kind of drag and drop). This tool did allow to create your own theme in scss. But it shipped its own scss framework as well, on top or one of the bigger css frameworks. I never apply some much selector nesting and !important to override the styles. This experience made sure I don't want to rely on css frameworks again. If you do, specificity does become a trouble.

Minimal CSS and good API is definitely easier said than done. We can definitely agree on that. I think it is almost human nature that we always try find one solution for our problems. In my previous table example, I have the separate components with minimal CSS, but I also have a fully styles wrapper (one component and one scss file). It's an ideal way to show how it can be styled.

This is a mental model issue for us as developers. We are keen so share our work and for others to use our work. But this is relatively new in front-end land. So we forget sometimes to think of potential use cases of others (styling wise, feature wise we do it quite alright). In back-end development it is already more matured (e.g. REST API design).

code of conduct - report abuse