Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cargo Cult CSS

kapowaz.net

Post reply on HN
Print view View original

41–44 of 44 posts

Re: Cargo Cult CSS

#41

Post by hovertrain »

Consider the authors examples: The first example should really use extend or it will output the content of the news-item for each selector separately, and the news-item mixin contains many properties with static values that will be repeated. This example also couple the styles to the content, it should now only be used for news, this is not about premature optimization, but consistently working against code reuse, why cannot the authors beautiful blue box be used on something else then news. The alternative, the box-standard can be use multiple times and it is easy to understand and modify from the developer perspective and to anticipate the result (“what is breaking?”). Lastly why do author use the element (div) selector, the element selector is not necessary and it prevents author from writing it on section or article if that would semantically correct.

For the second example, yes, the example is extreme, and I do not see many people writing that many selectors, but the author is right that OOCSS will create multiple classes. Writing this box, I would probably have something like this: box box--special box--extra-padding. After the example the author argues that this is approach transfers the close coupling to the markup. Let us say we have a 100 pages and one style sheet, should the CSS really serve all those 100 pages or should each individual pages deal with one style sheet. With a 100 pages, it will be impossible to keep track of all the pages when you are writing your CSS.

From my perspective, the last example is legit, but element selectors with descendent selectors might cause performance issues, because every time the browser hits a link (a) it have to evaluate the hierarchy in the selector. Btw, the ul element selector is unnecessary.

Re: Cargo Cult CSS

#42

Post by Isofarro »

ahoge wrote: post #34
Cederfjard wrote: post #30

Earlier quoted context omitted.

> Basically, it's just a naming convention which tells you something about the purpose of this particular class. In languages like Java, C#, etc. you also use naming conventions to communicate something useful. In CSS, I do the same thing. There is UpperCaseCamelCase, lowerCaseCamelCase, _withLeadingUnderscore, and x-prefixed. All of these things mean something specific. What does those four styles mean then, respect…

Subtree root node, descendent, modifier, and not CSS. A modifier changes one or several aspects to make it more suitable for a different purpose. You can stick subtrees into the leafs of other substrees. There is no overlap or interweaving. So, if you look at some node, you just travel the tree up until you hit the first UpperCaseCamelCase class. That's the structure this node belongs to. It's also the name of the pa…

You have an accessibility issue in your example markup. Having links adjacent to each other without either non-linked readable characters, or an appropriate markup structure leads to screen readers reading out the numbers 1 2 3 4 in a "linked" tone, and it is impossible to distinguish that from a single link containing all four numbers.

That's why the web development best practice here is to mark up a list of links with a list. And before we had web standards people used to separate adjacent links with the | character, so at least screen readers would have the numbers read out in a link voice, and the 'bar' read out in a non-linked voice.

If your intention is to create reusable components, then it's essential that you're not introducing accessibility issues by default.

There's a second accessibility issue with the pagination. Why is the active page a link? What does it link to, considering that you are already in the view that should be that page. That feels like a link that does nothing. For a generic pagination, this feels like another accessibility issue to trip up developers.

Also, there's the obvious anti-pattern of using # as the href, instead of an actual URL. That leads to developers assuming that everything is handled with JavaScript. It's easy to fix in documentation, by putting in realistic looking URLs in there.

Good examples of documentation are ones that demonstrate good practice, and not encourage bad habits.

I know, good documentation is not easy. That's why we have to be careful of falling into these sorts of pitfalls. Especially when developers have no choice but to rely on documentation being correct.

Re: Cargo Cult CSS

#43

Post by ahoge »

Isofarro wrote: post #42
ahoge wrote: post #34

Earlier quoted context omitted.

Subtree root node, descendent, modifier, and not CSS. A modifier changes one or several aspects to make it more suitable for a different purpose. You can stick subtrees into the leafs of other substrees. There is no overlap or interweaving. So, if you look at some node, you just travel the tree up until you hit the first UpperCaseCamelCase class. That's the structure this node belongs to. It's also the name of the pa…

You have an accessibility issue in your example markup. Having links adjacent to each other without either non-linked readable characters, or an appropriate markup structure leads to screen readers reading out the numbers 1 2 3 4 in a "linked" tone, and it is impossible to distinguish that from a single link containing all four numbers. That's why the web development best practice here is to mark up a list of links w…

> If your intention is to create reusable components [...]

This isn't like Bootstrap, mind you. It's a set of building blocks for one particular website.

> Also, there's the obvious anti-pattern of using # as the href, instead of an actual URL.

It's about the structure of the markup. "#" is used as no-op href for dummy links. "data:," is used as no-op src for dummy images.

Re: Cargo Cult CSS

#44

Post by nilliams »

Isofarro wrote: post #38
russelluresti wrote: post #35

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,…

" 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 functi…

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

Post reply on HN