4 ms·

> 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 he

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

paulojreis 11y ago
> 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...
- gotchange 11y ago
  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
  - paulojreis 11y ago
    > 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!
    - gotchange 11y ago
      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.
acjohnson55 11y ago
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-could-be-too-hot-for-humans-by-centurys-end_562e8d32e4b00aa54a4ac233 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.

paulojreis 11y ago

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

gotchange 11y ago
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
- paulojreis 11y ago
  > 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!
  - gotchange 11y ago
    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.

acjohnson55 11y ago

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-could-be-too-hot-for-humans-by-centurys-end_562e8d32e4b00aa54a4ac233 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.