Reasonable System for CSS Stylesheet Structure | Hacker News Reader

Reasonable System for CSS Stylesheet Structure

github.com

56 pointsdhruvbhatia24 comments

These are all great ideas. The only thing I don't like about these types of projects/guidelines is the almost religious, strict adherence to them that some people who pick them up like to rant about.

The examples are great and realistic but they will inevitably break down in any project with just a moderate amount of complexity. When this happens I see people decide that they've done something wrong and think they either need to restructure the UI to fit the guidelines or find a different set of guidelines to fit their project. Both are wrong.

After years of studying these guidelines and trying to perfect the perfect, most efficient, small, and understandable set of CSS styles I've come to the realization that we need to simply accept that there are going to be exceptions and that's okay. Yes, think in components, give classes sane names, don't use ID attributes, etc. but also know that at some point you're probably going to have to break a rule and it's not the end of the world. Think about the problem for a few minutes but don't waste your time trying to shoehorn your front end code to fit a set of guidelines so you can feel superior because of your strict adherence to RCSS or SUITCSS or whatever. There are more pressing issues than a few unused or single use classes. If you can follow the rules more than 80% of the time then I say you're as close to perfect as you'll ever be. Anything else is reaching for an impossible standard.

It's funny that the stricter you adhere to some of these guidelines the less productive you become as you spend more time thinking about how to create components so they fit the rules rather than getting the damn styles to look however you want.

My point being this: I love all the different philosophies and think they're all worth studying but let's be realistic when it comes time to implement stuff.

Naming conventions seems to be old school now that virtually everything is being done with JS.

Using webpack's css-loader changes the game completely as pointed out by Mark Dalgleish here:

https://medium.com/seek-ui-engineering/the-end-of-global-css...

Writing maintainable CSS is now encouraged, not by careful adherence to a naming convention, but by style encapsulation during development.

I'm sure there will continue to be more JS solutions to getting rid of CSS naming conventions, since it seems everything is being done with JS these days.

At which point you no longer have graceful degradation when JS is disabled. Web "designers" need to stop breaking the web with their code spew everywhere ruining the basic functionality of HTML and CSS.

Sure you can... there is no reason why those JavaScript styles can't be outputted to a css file in your preprocessing step.

I always feel like these naming conventions are just one big workaround for the pain of a global namespace. We should tackle it with tools like CSS Modules[0], not with something as flimsy and error-prone as a naming convention.

[0] https://github.com/css-modules/css-modules

CSS is not a programming language. You can't think about it the same way you'd think about your backend code or even client side JS. The global namespace is by design. It's a feature, not a bug. The whole point is to think about the Cascade. You go from vague to specific and that way you have entire classes of elements with base styles and specific components have additional styles attached.

CSS modules is a cool idea but I don't think there's anything wrong with CSS as it stands today. When you work in any language you need to understand and work with the language you have and I think that a lot of criticism of CSS boils down to "CSS doesn't work like this other language/paradigm I know and like".

I humbly disagree.

No, CSS isn't a programming language, but that doesn't mean it can't use functionalities that are typical of programming languages - just look at variables, functions, arrays, maps and other features that preprocessors like SASS have brought us.

While some approaches are a matter of taste/habit, I think there's an extremely wide consensus that having everything available in global scope is bad.

If the global namespace really is by design, then why are we adopting conventions (such as the one in this very topic) that mostly aim to defeat it? Prefixing class names to apply them only to a specific component is nothing but a primitive way of limiting scope.

Shadow DOM[0] is a big step in the right direction, as well.

[0] https://w3c.github.io/webcomponents/spec/shadow/

In another comment[0] I also mentioned using Shadow DOM for modularizing CSS. However I got a comment "Shadow DOM is not the solution for CSS isolation for components." and the commenter referred me to css-modules.

I'm wondering what's the merit/advantages of using css-modules over using Shadow DOM to limit the scope of CSS rules.

[0]: https://news.ycombinator.com/item?id=10453076

Shadow DOM enforces CSS isolation incidentally, but is also part of the larger "web components" plan, which would also incorporate CSS modules.

In these cases you would fully encapsulate CSS, HTML, and JS on a per-component basis.

Hasn't this already been solved with SUITCSS?

https://github.com/suitcss/suit/blob/master/doc/naming-conve...

Yea SUITCSS is a great solution and it's completely cleared up so many CSS issues my team has had in the past. Looking at rscss I kind of cringe because it doesn't make it easy to reason about where classes are in the markup. Like .search-form is affecting .submit, but looking at the template I have no idea, and I also don't even know which file to look in.

I was under the impression that child selectors are specific in nature, and they should be used later in the sheet, when declarations become increasingly specific.

In a general sense, the child combinator is "more specific", i.e. there are fewer elements that can match it. Combinators do not affect specificity though.

See https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity...

Another alternative to BEM http://getkickstart.com/amadeus/

Or more precisely: http://getkickstart.com/amadeus/#selectors

I like how readable it is, but nesting selectors:

  .parent .child .element {

is bad for performance — thus BEM's:

  .parent--child__element {

It's not as bad because of decreased performance (which is negligible) as it is because of increased specificity, which has bigger day-to-day implications in large apps.

That information is outdated. CSS speed optimisation is a complete waste of time for at least 5 years now.

If your CSS performance is slow then you certainly have some terrible UX problems as well. You can't fill up the DOM to the extent that the browser slows down when it's rendering things and still have a usable website.

Fix the UX and the CSS performance will magically fix itself.

But that would require you to modify the markup.

It would also stops you from having general styles declarations.

You couldn't do .button{color:red;border: 1px solid white;} and then .box>.button{width:100%;} unless you make your markup <span class="button pricebox--box__button"> and that would be pretty ugly, wouldn't it?

Correct me if I am wrong.

In this case it's

    .parent>.child>.element.

Don't you mean

    .parent__child-element {

?

Very interesting project, although I believe the name suffers from RAS syndrome: Reasonable System for [Cascading Style Sheets] Stylesheet Structure.

Reply on news.ycombinator.com