4 ms·

The concept of 'semantic classnames', even if propagated by w3.org has caused as much grief as the concept of 'separation of concerns' between HTML & CSS fad. T

by jasim 10y ago

The concept of 'semantic classnames', even if propagated by w3.org has caused as much grief as the concept of 'separation of concerns' between HTML & CSS fad. The reason we need semantics in HTML is to make the markup accessible for screen-readers, and no screenreader considers the class name of an element when reading it out. What we instead need are semantic tags like article, section etc. and aria tags like role. CSS classnames are purely for the developer's benefit. Not the user's. And as developers, forcing ourselves to find semantic meaning for every element we write leads us to component-oriented CSS like BEM. Which is a fine thing, but we can also use purely visual classes - like `bg-red bold border-solid` if it helps (and it does. check out tachyons.io) The class names of elements in Google's homepage for example reads like 'tsf-p', `oq`, `gsb` etc. I suspect these are machine generated. Same with Facebook. One of the best libraries to do this currently is styled-components (https://github.com/styled-components/styled-components https://github.com/styled-components/styled-components). Consider reading http://nicolasgallagher.com/about-html-semantics-front-end-architecture/ http://nicolasgallagher.com/about-html-semantics-front-end-a..., http://mrmrs.io/writing/2016/03/24/scalable-css/ http://mrmrs.io/writing/2016/03/24/scalable-css/, and http://johnpolacek.com/2016/06/17/atomic-css-movement/ http://johnpolacek.com/2016/06/17/atomic-css-movement/ for reasoned perspectives.

jameslk 10y ago
I think this is missing the point. For me, semantic class names have lead to very maintainable websites/apps that I've been able to completely redesign without touching much of the HTML, which is usually much harder to change in larger dyanmic applications. It's also made it much easier on teams I've worked with because the designers could quickly dig into the styles to make tweaks in a central location (single source of truth) without rummaging through our entire codebase to modify appearances of things (separation of concerns). When I first discovered csszengarden.com, I realized the point of CSS and its power. HTML was made for hypertext and semantic content structure and CSS was made for appearances. Either one could be completely replaced partially or wholly, separate of each other. Classes are like interfaces[0] which allows for HTML to remain dumb and decoupled from presentation. When the HTML and CSS are hardcoded to specific design concepts themselves, then the usefulness of CSS as in "cascading style sheets" is nearly eliminated. These concepts aren't a fad, this is good software architecture brought to you by an international consortium who's been thinking about it for decades. 0. https://en.wikipedia.org/wiki/Dependency_inversion_principle https://en.wikipedia.org/wiki/Dependency_inversion_principle
- andrewingram 10y ago
  There's flaw in reasoning here, but I'm glad we're at least focusing on the maintainability arguments. Ultimately it comes down to how your CSS is authored, and how your teams works. If you develop in a heavily document-oriented way, and make big use of the cascade, you're most likely to benefit from semantic (rather than presentational) class names. This is because when you make full use of the cascade, markup changes tend to be more expensive (you can't just move a block of HTML from one place to another and not expect its appearance to change). These days though, we're increasingly building things in a UI-oriented way. What you see on the page is a composition of a number of components. If I move a component from one place to another, I expect it to look the same (with a caveat for responsive layouts) assuming it's still rendered with the same input properties. So now i'm authoring CSS that is bound to the structure of this component, naming becomes a lesser issues. The other thing worth pointing out is that it's not too difficult to built a document-UI (like say a magazine) using app-UI patterns, but it's rather challenging to do it the other way around. If the goal is maintainability, then there should be zero industry-wide dogma. Best practices are going to be coupled to the methodology of the maintaining team. Personally, I did document-oriented CSS for 15 years, now i'm doing component-oriented CSS, and the results are much better. Obviously this is just an anecdote, but i'm not alone in this. This idea that design is a "layer" on top of structure is somewhat offensive to the designer in me. Visual design is (and should forever be) coupled to structure and behaviour. Design is not a higher abstraction, it's something that pervades everything.
  - nailer 10y ago
    > If I move a component from one place to another, I expect it to look the same (with a caveat for responsive layouts) assuming it's still rendered with the same input properties. What's preventing you from doing this with your presentation login in your stylesheet, and what about this requires you to split your presentation logic between a stylesheet and HTML? We use components everywhere. We style in stylesheets. Handily we even keep the stylesheets in the same component as the module, thanks to npm-sass / sass-npm.
    - 10y ago
egeozcan 10y ago
> The reason we need semantics in HTML is to make the markup accessible for screen-readers Not sure about the screen-readers but when you add a class for, say, "small", it's a bit confusing because you can't guess how it is used when looking from the CSS side. One day, you decide to represent the unimportant text as grey (bad idea) and then you need to find all instances of .small that are used for the unimportant content and change them to .grey (then you discover there already is a class named gray, oh the horror) whereas if you used .unimportant as a class name, your change would be a single line of CSS. Also, "h1 .unimportant { color: something-not-grey }" is way clearer than ".bold.big .small { color: something-not-grey }".
rimliu 10y ago
Semantic names for CSS classes have the same utility as good variable/function/method names in code. They describe what is this for, not how should it look. I have seen enough .red12px where it was green and 10 px already. Cannot wait for the new web standards movement to start already.
- ryanbrunner 10y ago
  `.red12px` is for sure a bad example, but often-times "what is this for" in the context of a tag with a class on it is purely for styling. This div is here because I want padding here / a different font / whatever, and I can either be upfront about that (maybe with something a little more maintainable like `.padding-large` rather than `.padding-40px`), or I can do a little dance and invent some semantic name like `.widget-inner-details` that serves no purpose other than giving me a hook to say "I want larger padding here"
olavk 10y ago
There are really two different concerns which are often conflated: 1) Semantic markup for the sake of screen readers (and Google and so on) 2) Separation of concerns for the sake of maintainability I don't know how separation of concerns cause grief for developers, my experience is the opposite. Separation of concerns not a "fad", it is a fundamental principle of any kind of systems design. That said, it doesn't directly affect users, just as users don't care if you write incomprehensible spaghetti code.
- nailer 10y ago
  Getting both sides of this arg: basically 'sep of concerns' is viewed as being 'seperation of technology' rather than actual sep of concerns. Eg, put documents and styles and behaviour for a related component together, seperate that component from other components. It's a slightly silly argument because really we're arging between slicing something vertically (tech) vs horizontally (components) and the nicer thing is probably to do both - have lots of components with the documents, styles, and behaviour separated out within each component.

by jasim 10y ago

jameslk 10y ago

I think this is missing the point. For me, semantic class names have lead to very maintainable websites/apps that I've been able to completely redesign without touching much of the HTML, which is usually much harder to change in larger dyanmic applications. It's also made it much easier on teams I've worked with because the designers could quickly dig into the styles to make tweaks in a central location (single source of truth) without rummaging through our entire codebase to modify appearances of things (separation of concerns). When I first discovered csszengarden.com, I realized the point of CSS and its power. HTML was made for hypertext and semantic content structure and CSS was made for appearances. Either one could be completely replaced partially or wholly, separate of each other. Classes are like interfaces[0] which allows for HTML to remain dumb and decoupled from presentation. When the HTML and CSS are hardcoded to specific design concepts themselves, then the usefulness of CSS as in "cascading style sheets" is nearly eliminated. These concepts aren't a fad, this is good software architecture brought to you by an international consortium who's been thinking about it for decades. 0. https://en.wikipedia.org/wiki/Dependency_inversion_principle https://en.wikipedia.org/wiki/Dependency_inversion_principle

andrewingram 10y ago
There's flaw in reasoning here, but I'm glad we're at least focusing on the maintainability arguments. Ultimately it comes down to how your CSS is authored, and how your teams works. If you develop in a heavily document-oriented way, and make big use of the cascade, you're most likely to benefit from semantic (rather than presentational) class names. This is because when you make full use of the cascade, markup changes tend to be more expensive (you can't just move a block of HTML from one place to another and not expect its appearance to change). These days though, we're increasingly building things in a UI-oriented way. What you see on the page is a composition of a number of components. If I move a component from one place to another, I expect it to look the same (with a caveat for responsive layouts) assuming it's still rendered with the same input properties. So now i'm authoring CSS that is bound to the structure of this component, naming becomes a lesser issues. The other thing worth pointing out is that it's not too difficult to built a document-UI (like say a magazine) using app-UI patterns, but it's rather challenging to do it the other way around. If the goal is maintainability, then there should be zero industry-wide dogma. Best practices are going to be coupled to the methodology of the maintaining team. Personally, I did document-oriented CSS for 15 years, now i'm doing component-oriented CSS, and the results are much better. Obviously this is just an anecdote, but i'm not alone in this. This idea that design is a "layer" on top of structure is somewhat offensive to the designer in me. Visual design is (and should forever be) coupled to structure and behaviour. Design is not a higher abstraction, it's something that pervades everything.
- nailer 10y ago
  > If I move a component from one place to another, I expect it to look the same (with a caveat for responsive layouts) assuming it's still rendered with the same input properties. What's preventing you from doing this with your presentation login in your stylesheet, and what about this requires you to split your presentation logic between a stylesheet and HTML? We use components everywhere. We style in stylesheets. Handily we even keep the stylesheets in the same component as the module, thanks to npm-sass / sass-npm.
  - 10y ago

egeozcan 10y ago

> The reason we need semantics in HTML is to make the markup accessible for screen-readers Not sure about the screen-readers but when you add a class for, say, "small", it's a bit confusing because you can't guess how it is used when looking from the CSS side. One day, you decide to represent the unimportant text as grey (bad idea) and then you need to find all instances of .small that are used for the unimportant content and change them to .grey (then you discover there already is a class named gray, oh the horror) whereas if you used .unimportant as a class name, your change would be a single line of CSS. Also, "h1 .unimportant { color: something-not-grey }" is way clearer than ".bold.big .small { color: something-not-grey }".

rimliu 10y ago

Semantic names for CSS classes have the same utility as good variable/function/method names in code. They describe what is this for, not how should it look. I have seen enough .red12px where it was green and 10 px already. Cannot wait for the new web standards movement to start already.

ryanbrunner 10y ago
`.red12px` is for sure a bad example, but often-times "what is this for" in the context of a tag with a class on it is purely for styling. This div is here because I want padding here / a different font / whatever, and I can either be upfront about that (maybe with something a little more maintainable like `.padding-large` rather than `.padding-40px`), or I can do a little dance and invent some semantic name like `.widget-inner-details` that serves no purpose other than giving me a hook to say "I want larger padding here"

olavk 10y ago

There are really two different concerns which are often conflated: 1) Semantic markup for the sake of screen readers (and Google and so on) 2) Separation of concerns for the sake of maintainability I don't know how separation of concerns cause grief for developers, my experience is the opposite. Separation of concerns not a "fad", it is a fundamental principle of any kind of systems design. That said, it doesn't directly affect users, just as users don't care if you write incomprehensible spaghetti code.

nailer 10y ago
Getting both sides of this arg: basically 'sep of concerns' is viewed as being 'seperation of technology' rather than actual sep of concerns. Eg, put documents and styles and behaviour for a related component together, seperate that component from other components. It's a slightly silly argument because really we're arging between slicing something vertically (tech) vs horizontally (components) and the nicer thing is probably to do both - have lots of components with the documents, styles, and behaviour separated out within each component.