[russelluresti]

This is an argument I had with myself a few years ago, when OOCSS started becoming popular. Ultimately, what I determined is that there's a new definition of what "semantic" means in front-end architecture. Semantic doesn't just describe the content anymore, it describes the function as well. So using classes like "module-box" or whatever is perfectly fine. There's a bunch of articles out there on the new semantics, you can look them up as I can't be bothered to link to them.

Ultimately, though, the "separation of concerns" was a good principle to use when the web was a bunch of documents meant to provide content. It isn't that way anymore. The web has evolved in use to include web apps and other forms of media, so our principles must evolve as well. It seems silly to cling to past definitions as immutable when we work in a field that changes drastically nearly every year.

Also, anyone who advocates using a selector like "ul.members li a" and then complains about the maintainability issues of using non-semantic classes when an update needs to be made should really reconsider their hypocrisy. Using selectors like that (aside from being slow performing) completely tie the markup to the presentation. Hell, if all you did was update the list to an ordered list instead of an unordered one you'd have to update the CSS as well.

The reality is that any change in the UI big enough to warrant updating the markup is going to warrant updating the CSS, and vice versa. Worrying about making them completely separate is impractical and will just cause you to waste time in development.

If you're concerned about the discoverability of the code to a new developer, DOCUMENT IT. Do not create crappy selectors. Create a UI style guide that implements all of the major UI components and have the developer reference the style guide. Use something like KSS to link between the style guide and the CSS. There's no excuse for using bad selectors in the name of ease of on-boarding.

[Isofarro]

"Ultimately, though, the "separation of concerns" was a good principle to use when the web was a bunch of documents meant to provide content. It isn't that way anymore. The web has evolved in use to include web apps and other forms of media, so our principles must evolve as well."

The "webapps are not documents" position is hokum. Web apps are merely the application of HTML, CSS and JavaScript to create more functional/dynamic documents. But documents they still are.

"Also, anyone who advocates using a selector like "ul.members li a" and then complains about the maintainability issues of using non-semantic classes when an update needs to be made should really reconsider their hypocrisy."

That's a nice strawman you've propped up there.

"If you're concerned about the discoverability of the code to a new developer, DOCUMENT IT. Do not create crappy selectors. Create a UI style guide that implements all of the major UI components and have the developer reference the style guide."

Amen.

[nilliams]

> That's a nice strawman you've propped up there.

In his defence, that's not a "strawman he's propped up", it's taken from the article.

[kapowaz]

> what I determined is that there's a new definition of what "semantic" means in front-end architecture. Semantic doesn't just describe the content anymore, it describes the function as well. So using classes like "module-box" or whatever is perfectly fine.

Semantics describes a thing, but classes like ‘module-box’ don't convey any meaning beyond presentation. If you think that ‘module-box’ is semantic, then I have a whole bunch of classnames based on colours to sell you…

> the "separation of concerns" was a good principle to use when the web was a bunch of documents meant to provide content. It isn't that way anymore.

The virtues of this approach have very little to do with the web; it's a concept that pre-dates it, so it's hard to justify it having been invalidated simply by advances in web technology. Besides, a web ‘application’ is equally composed of semantic components just as much as a document is; part of the reason HTML5 came about was to reflect the kind of elements used in modern web pages.

> Using selectors like that (aside from being slow performing) completely tie the markup to the presentation. Hell, if all you did was update the list to an ordered list instead of an unordered one you'd have to update the CSS as well.

This suggests that your workflow starts with CSS and you then build markup to fit it, which his sounds completely backwards to how I approach things. You don't tie your markup to how it is presented: you declare how you want to present the markup your app is built upon. Also, if you change the markup to something with a completely different meaning (an ordered list is meant to have a different purpose than an unordered one) then of course it follows that you'd have to update the CSS, although there's no reason why those changes need be onerous or difficult.

The whole selector performance debate is old and dead, by the way: http://calendar.perfplanet.com/2011/css-selector-performance....

> If you're concerned about the discoverability of the code to a new developer, DOCUMENT IT. Create a UI style guide that implements all of the major UI components and have the developer reference the style guide.

A style guide is a fine starting point regardless of how you want to approach your CSS, but documentation isn't the only way to aid discoverability of code. Selectors that communicate context and purpose can be very helpful for this too.