Comment by thebouv | Hacker News Reader

Comment by thebouv | Hacker News Reader

Parent Full thread

"Considering it’s a point of professional pride to avoid nested structures as much as possible in other languages..."

Nested loops can be bad. Nesting logic deeply in other languages is bad.

Nesting style rules that belong together, well, together isn't nesting as much as it is putting like stuff together.

I may create section.myawesomesection {...} and everything to do with the stuff in there is in there, not leaking out. I don't accidentally use a class name used somewhere else and globally change it, I don't change all global UL tags to be flat, inline, no list-style. I change them in context of section.myawesomesection.

Not to mention allowing me to put my breakpoints together in context (particularly useful with a mixin like breakpoint(small) or something).

Yes you can really go nuts with the nesting and create a giant pile of crap. But then that's you being a bad planner (not even going to say coder here, as CSS/SASS is more about planning than coding).

I agree, nesting has been one of the most helpful parts in SASS to keep everything organised. Nestin is just harder to do right, you need some experience in organising files.

Even with the specifity I vastly prefer nesting to a bunch of files with flat selectors and a huge amount of globals where you need a lot of time just to understand which elements affect which.

The post is quite opinionated and puts every issue in a bucket, as if there is only one way to write CSS. A few examples would have been useful.

Not using Nesting is the worst offender in the list.

The trouble is that untangling nested selectors can be a real challenge, especially if you have inheritance between them, and the implications can be chronic. On a project I was working on recently, a colleague reported to the team that the addition of one line of code to a SCSS file resulted in an increase in size of the target CSS by 800KB. Looking at the spaghetti code that had been written, none of us could work out how many rules were being combined out of the deceptively clean looking SCSS.

A recommendation for that project was to lint for some ground rules forbidding certain behaviours, nesting being one of them. I've actually been considering avoiding SASS altogether in the future.

Couldn't agree more there. I tend to avoid nesting more than 3 levels deep, because I don't want someone else looking at my code and cry.

That approach - nesting everything inside section.myawesomesection- would hurt:

a) Performance (rule matching gets significantly harder as you nest);

b) Maintainability (did a change in the mark-up? Then check the CSS to see if it still matches);

c) Code reuse (obviously).

Using a nomenclature-based solution such as BEM, in the other hand, would avoid all these issues (complex, slow and over-specific selectors; DOM dependence; ease of reuse) while still avoiding style leaks. I'd argue BEM is even better at avoiding leaks: if you change all your global <ul> inside your section.myawesomesection, then it will - eventually, sooner or later - leak to a <ul> which you didn't want to style.

a) Granted. But we're talking about a specificity after compiling to CSS of: section.myawesomesection { h2{..} } to section.myawesomesection h2 {..}. Definitely not wanting to create nests that are so deep the specificity is insane.

Could I have just given a class to the h2? Yep. But performance difference between h2.myclass{..} vs section.awesomesection h2{..}? Worth worrying over?

Of course, if there really is a difference, it would add up I suppose over a mega-site. So thanks for the food for thought. I'll have to weigh it versus developer happiness I get from the tidy style rules.

b) Well, if the markup changes, that can just as well change your CSS too.

At some point, some change in the markup, you're going to reexamine the CSS for it. It's not like you write the perfect CSS and walk away because it will always work with the document and all its iterations.

Of course, like you said, maintainability is an issue but it isn't exclusive to SASS or my use of nesting via section.myawesomesection either.

c) Styles that are in many places get noted and placed so they can be reused. But that one special snowflake of a rule that applies only to this section of content because my designer wants to especially call it out? The rule can be specific.

I'm not creating 200 line section.myawesomesection definitions. Reusable items are resuable. Specific items are specific (most often to overwrite a global style say like font, color, this specific absolutely positioned icon, etc). Generally a dozen lines or so. If longer, just like a function getting too long, and I rethink/rewrite.

d) I absolutely 100% will check out BEM. I'm no slave to SASS, nesting, or anything like that. I have no idea about BEM will happily switch if it is better.

Bear in mind that BEM (CSS-wise) is just a nomenclature. What it addresses is exactly excessive nesting and dependence between mark-up and styling.

It roughly means that you imply structure via naming conventions instead of nesting (e.g. if you have a box inside a block, you'd style it via single class such as .my-block__my-box, instead of the traditional nesting approach .my-block .my-box). You can - and should - still use SASS (or other preprocessor) with BEM.

Some interesting resources regarding this:

http://philipwalton.com/articles/css-architecture/

http://philipwalton.com/articles/side-effects-in-css/

http://philipwalton.com/articles/extending-styles/

http://benfrain.com/the-ten-commandments-of-sane-style-sheet...

> you'd style it via single class such as .my-block__my-box, instead of the traditional nesting approach .my-block .my-box)

What you basically accomplished here is to transfer the problem of complexity from one domain (CSS) to another (HTML) not solving it.

Even if Sass provides a visual way to emulate hierarchy by using the & operator and breaking up the name at the significant points for instance:

  .myblock
    &-mybox
      color: black

It would be still a mess on the HTML side and there isn't really an equivalent workaround for it with tools like Jade or others.

In the end, if the penalty of using a shallow nesting architecture is to increase the specificity score by 1-2 points, I'm willing to take it in exchange of a more readable and maintainable codebase whether in CSS or HTML domain.

There are tools you can use to avoid this problem. BEM libraries for templating languages abound. When I worked at HuffPost on the current desktop rendering engine, I designed everything to be a system of nested components within a layout, and it was a pretty simple effort to make a helper that each component automatically got that was preinitialized with the component name as the BEM block and then within the template, all you had to do was provide the BEM element names and optional modifiers, and it spit out all the necessary classes. I just grabbed a link to the first article on the main page, throw it in dev tools to see what I mean: http://www.huffingtonpost.com/entry/parts-of-persian-gulf-co....

It's not completely free of pain points, particularly when it came to the JS, where we had to resort to some explicit usage of full BEM names. But that was very minor compared to the organizational benefits in the styles and markup.

> What you basically accomplished here is to transfer the problem of complexity from one domain (CSS) to another (HTML) not solving it.

Nop. I'm eventually polluting the mark-up with extra and uglier classes, but that's it. A small price to pay for less coupling - just use a class to bind styles to an element. No need to consider "what if this is a child element of X or a sibling of Y?".

> In the end, if the penalty of using a shallow nesting architecture is to increase the specificity score by 1-2 points,

It's not. It's style leaking, dependence between different system parts (content structure and styles), performance, less reuse...

HTML & CSS are like Siamese twins, you can't separate the one from the other and there will always be coupling between them no matter what and the solution you suggested is not optimal in my opinion as I said earlier that what you'd manage to achieve with this is just to shift the burden from CSS to HTML and to turn the organizational/hierarchical problem in CSS to a greater and unpleasant naming one in HTML that I personally try to avoid as much as possible

> HTML & CSS are like Siamese twins, you can't separate the one from the other and there will always be coupling between them no matter what

Yes, there will always be coupling. What I'm suggesting is minimizing the coupling, by using classes as simple "binders" and by stopping the use and implying of DOM structure in CSS files.

> I said earlier that what you'd manage to achieve with this is just to shift the burden from CSS to HTML

I think you're missing the big picture. You use classes anyway, I just suggest a) accepting them as needed to bind styles and content; and b) using more of them so that your CSS files don't reflect the HTML. In a way, some burden is in the HTML (more classes, naming convention) but you're missing the huge removal of HTML notions from CSS files!

Web devs have been using presentaional class names to style HTML elements ever since there was CSS around. So, this is not something new. What's new though is your recommendation to use class names as the exclusive method of binding between CSS and HTML, which in my opinion is not practical and moderately limiting for the aforementioned reasons I listed in a prior reply.

Also, it's worth mentioning that class naming and achieving consistency and predictability throughout a project is an extra work to do and from my experience it can be very daunting. I already suffer and I can barely cope with the organizational overhead that comes with naming files descriptively and consistently, and how to structure the project tree accordingly, and as you know a poor implementation is no better than having none.

So, I don't really need to map the original CSS problem to a naming one in HTML to make things worse for me. If it works for you, you should go for it but with the knowledge that there are other people out there who prefer another approach away from these "clerk" duties.

As with the other point you raised of the disadvantage of mirroring the HTML structure in your CSS, I'd like to get your feedback on some examples. Do you really think that having something like «ol > li» or «select > option» is excessive? Aren't these elements highly coupled by nature? You don't really expect a «div» or «section» to be a child of an «ol» element, do you?

I know that HTML parsers are forgiving by nature but expecting them to break the basic rules of the language is ridiculous.

Here's another example, I recently wrote a timeline module/widget that has a distinct style for both the start and finish points while another one for the other points. So, I opted for a tightly coupled solution for that using pseudo classes like «:first-child», «:last-child», «nth-child(odd):not(:first-child)» ...

Do you really think that this is unnecessary and difficult to reason about in the context of that the design is prescribed this way that the first and last elements share a certain style while the others share another one with slight modifications for odd and even elements?

Yeah you might it view this style as a bit verbose compared to going class-only but the styling of the module is very rational and predictable to the point that can be extended programmatically to other contexts with the help of mixins or other constructs.

In the end, the whole proposal of restricting styling to only class selectors is not enticing or compelling enough for me to make the switch, at least for now.

> Do you really think that having something like «ol > li» or «select > option» is excessive? Aren't these elements highly coupled by nature?

This is exactly your mistake: you seemingly can't conceive styles as something apart from content/structure/HTML.

Of course, a list item is coupled to a ordered/unordered list. A <li> as a descendant of a <ol> is the way to do it and they are effectively coupled by nature. But this is mark-up, only! The style you give to the list and the list items is a different subject. Imagine that, for some reason, you want to apply the exact same styles to a structure of anchors (<a>) inside a <nav>? Then your selectors (ol, ol > li) wouldn't apply anymore, you'd have to rework the selectors. If you just used classes for the list and the list items, reusing the styles would've been easier and trivial.

> In the end, the whole proposal of restricting styling to only class selectors is not enticing or compelling enough for me to make the switch, at least for now.

I can understand that, totally. I needed a few years of experience to come to the realization that the dumb and predictable "just use classes" was the way to go with CSS. I've been "smart" with selectors a thousand times; many of them came biting back - I just thought "why create an extra class if I can infer this via hierarchy and element relations?". Many, many times the structure changed and the selectors needed to be reworked; even more times, the styles "leaked" to elements I didn't want to style.

> This is exactly your mistake: you seemingly can't conceive styles as something apart from content/structure/HTML.

Like I told you before, people have been using class names as styling hooks since prehistoric times and what you have been proposing is not something new at all. As for me, I use classes EXTENSIVELY not EXCLUSIVELY and this is the main contention in this debate.

As with the example you cited, this is a pretty good example and use case for packaging the style module and slabbing a class name on it and pushing out the door but the problem with your approach is that you see EVERY and EACH CSS rule/ruleset as a viable candidate for potential reusability down the road when real world experience shows us that this is unnecessary and overkill. Not every CSS rule will end up as an independent module somewhere and in the eventuality that this happen for some of them, it's easy to remedy the situation with a few code lines and it's done without the need to invest upfront in a naming system that comes at a cost and has a considerable overhead at least from an organizational standpoint.

Regarding the last point, there's nothing smart-ass about my solution ( production-bound projects are not a suitable candidates for show-off or competitive coding contests and I guess you know that already ).

Again the problem is that you don't want to acknowledge that you don't solve the styling problem in CSS by simply passing the buck to HTML. Taking the earlier timeline as an example, if you'd go class-only in CSS and to throw away all the simple logic provided by those pseudo-classes, you'd still have to provide a similar solution in your HTML template files.

Please don't fool yourself that you wouldn't have to do this because there's no other way to supply those specific classes (one for the first and last item, one for the inner items and then extending it to even or odd item) other than programmatically. This logical problem needs to be solved and you'd have to come up with a scalable and reusable solution to meet the requirements. If you prefer to solve the problem in the HTML domain with the help of JS and you're capable of taking all the precautionary measures to avoid introducing errors in the template, it's your call but please note that there are other people who prefer to solve styling problems in CSS terms, if applicable, and not toss it around to other domains for the sake of just holding to a dogmatic position.

> Like I told you before, people have been using class names as styling hooks since prehistoric times and what you have been proposing is not something new at all.

No, not new at all. What I'm proposing is almost as old as the CSS spec, but still is at odds with what people typically do.

> As with the example you cited, this is a pretty good example and use case for packaging the style module and slabbing a class name on it and pushing out the door but the problem with your approach is that you see EVERY and EACH CSS rule/ruleset as a viable candidate for potential reusability down the road when real world experience shows us that this is unnecessary and overkill.

You're right; it's an "architect astronaut" kind of thing and I reckon you have your point - most CSS won't be reused and - quite honestly - most reuse I do is in the SASS/preprocessor domain, not in the CSS/packaged styles domain. Nevertheless, extensive experience and lazy coworkers solutions tell me that it's just a matter of time until:

a) the DOM-bound rules stop reflecting your DOM structure and you have to maintain both "structures"; b) the DOM-bound rules leak undesired styling to other elements; and c) people have to write even-more-specific selectors to override them.

> it's easy to remedy the situation with a few code lines and it's done without the need to invest upfront in a naming system that comes at a cost and has a considerable overhead at least from an organizational standpoint.

Come on... the overhead of writing BEM-like selectors? This gives you - besides the performance and IMO maintainability - predictability, a common standard for naming among the team members and a nomenclature which yields more meaning upon reading. I think this easily compensates the overhead.

Also, please notice, you said "remedy" the situation. Nothing particularly wrong with that, but that's not a solution - adding another CSS rules is just a "patch", and those patches will accumulate up until they're a "lot" of your CSS. Again, nothing wrong with that, but it's architecture vs. lack of architecture; what I'm proposing is a upfront solution to avoid this and to reframe style rules upon finding failures, which is different than "remediation".

> Again the problem is that you don't want to acknowledge that you don't solve the styling problem in CSS by simply passing the buck to HTML.

I really think you're seeing this wrong. Having more classes is not passing the buck to HTML.

> Taking the earlier timeline as an example, if you'd go class-only in CSS and to throw away all the simple logic provided by those pseudo-classes, you'd still have to provide a similar solution in your HTML template files.

First-child and last-child kind of stuff is usually where I open up exceptions. I tend to do the opposite if I'm using a JavaScript framework which I trust, to render modifiers in classes for first/last element (e.g. .timeline__element--first; .timeline__element--last), but I'm not against using CSS for this. Also, I don't propose adding a class via JS to do :hover. :)

Reply on news.ycombinator.com