5 ms·

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

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

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