4 ms·

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 y

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

paulojreis 11y ago

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

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