Hacker News Reader

Comment by ealexhudson | Hacker News Reader

Interesting definition of "semantic". In terms of the code, I'd take <button> over <div> every day of the week. Similarly lists, <nav>, and all that other lovely html5 stuff.

I really don't like stuff like <div class="right floated text"> - specifying the layout with class like that is pretty gruesome.

But then, I suppose "semantic" has a different meaning for this project than the one that I'm used to in the HTML/CSS/etc. world...

View on HN

"Article footer citation" is semantic in a language that describes structured content, while "big red button" is semantic in a language that describes design.

It does make perfect sense; for example, you may want to reuse the appearance of a nav bar button some place where a .nav-bar-button class would look strange, and the nested selectors that most popular frameworks use make this impossible (requiring .nav-bar-button to be a child element of .nav-bar). I went pretty far down this rabbit hole a few years ago before pulling back a bit recently. It's a very appealing concept, but in production you often run into corner cases where your basic display classes cause unwanted cascading (especially when wielded by users without a deep knowledge of CSS), requiring you to write a bunch of reset utilities with !important attributes. It's also ungodly messy, as a lot of people point out, and refactoring can be a nightmare when you have to grep for class names like "right" and "text" over dozens or hundreds of templates.

I've since settled into a pattern of using generalized module definitions (list-module, list-module--header, list-module--separator, etc), which is verbose but creates highly portable and maintainable classes. The few presentational classes that I do still use regularly are for white space (padding, margin, defined in short class names like .ptm for padding top medium, a convention borrowed from Nicole Sullivan's OOCSS libraries), and a contextual color palette (.box-warning, .text-danger, etc). The best of both worlds approach is to use a large library of presentational classes as sass placeholders (%color-scheme-inverse, %clearfix, etc) and @extend them where required. This does generate slightly larger CSS files but if you are properly modularizing your style definitions it shouldn't be an issue. The stuff that semanticUI is doing looks great and is a step in the right direction, but way-too-generic class names and lack of namespacing are a constant source of bugs (along the lines of putting all of your variables into a single global scope and using names like 'first' and 'finished').

EDIT: for clarity.

>Semantic in the sense that it uses display classes to describe the appearance of elements, not their content or structure, which is what people mean when they talk about semantic markup (<header><section><footer>, etc).

... on bizarro planet, where everything is the opposite of this reality.

edit: or is the grammar you used here just terribly ambiguous? confused. what does "which" refer to?

Sorry, tried to make that first paragraph more specific.

That was brought up a lot the first time this was posted, but I think it's a good description for how he uses CSS class names with inheritance to structure things.

I think its horrible an example of a decent semantic class would be div class=loud leave css inheritance up to less mixins.

the <button> issue is a valid feedback, I think it's a trivial enough issue that the author would happily accept the change

Reply on news.ycombinator.com