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

CSS: The bad bits and how to avoid them

joeforshaw.com

Post reply on HN
Print view View original

81–90 of 109 posts

Re: CSS: The bad bits and how to avoid them

#81

Post by jrobn »

jmsuth wrote: post #54
romaniv wrote: post #35

Never understood why people prefer verbose and repetitive BEM classes over custom properties and appropriate CSS selectors. becomes This solves for specificity, and uses built-in CSS features instead of a "manual" workaround.

This isn't a realistic example of how you should use BEM, you would never have a block, element, and modifier in one class. The "block" class would be used in a div that wraps the elements: I am an item I am a dangerous item Your simplification relies on an HTML hack and can potentially be more confusing when modifier names start colliding.

Yuck. I would follow the advise in this blog post [1].

https://www.smashingmagazine.com/2013/08/semantic-css-with-i...

Re: CSS: The bad bits and how to avoid them

#82

Post by breeny592 »

I think tooling is coming a long way to help with these - take for instance BEM. CSS modules is a great way to avoid needing BEM, as the bundler is handling the uniqueness of the classname for you (during minification etc.).

This is just the nature of web development - almost every tech in the stack is flawed, but tools and best practices make some sanity out of the chaos.

Re: CSS: The bad bits and how to avoid them

#83

Post by shardinator »

mattigames wrote: post #65
ars wrote: post #6

There's nothing wrong with styling on an id. You could put the style right in the HTML tag, or on the page where it's used, but with dynamic pages (and static stylesheets) both options will cost you bandwidth. And they split up your styles into separate places. So putting the style on the id is the right thing to do, and I don't understand why the author is against it. If I need my footer to look a certain way, then…

There is not a single time I had though to myself "This should have been an ID instead of a class"; but there are hundreds of times where I have though to myself "This should have been a class instead of an ID".

Interesting, I'm the other way around, I've defaulted to classes and then found that Ids would be more appropriate in many cases.

My simple rule for id vs class (as a non-expert) is if you say 'this is the x' e.g. 'this is the footer/header/navigation-panel' then it's an Id, if you would say 'this is a y' e.g. 'this the a product/list-item/image' then it's a class.

Re: CSS: The bad bits and how to avoid them

#84

Post by Retra »

talmand wrote: post #44
Someone1234 wrote: post #34

Earlier quoted context omitted.

> In my opinion, most CSS bad bits are a byproduct of bad use, not a problem of the language(?) itself. I've seen far too many bad languages come and go to believe that anymore. People used to say that about PHP and VB6 too. PHP eventually stopped with the "only bad programmers use me badly" and grew up, and VB6 died. A win in both cases. CSS could be far better; and bad practices won't disappear until doing it the r…

The ability for good practices is already there, just too many people would rather complain about their bad practices to bother learning the good practices and blame the language.

If the language were better, they would have learned the good practices while they learned the language, and they wouldn't even be able to express bad practices without extra effort.

Re: CSS: The bad bits and how to avoid them

#85

Post by enraged_camel »

mattigames wrote: post #65
ars wrote: post #6

There's nothing wrong with styling on an id. You could put the style right in the HTML tag, or on the page where it's used, but with dynamic pages (and static stylesheets) both options will cost you bandwidth. And they split up your styles into separate places. So putting the style on the id is the right thing to do, and I don't understand why the author is against it. If I need my footer to look a certain way, then…

There is not a single time I had though to myself "This should have been an ID instead of a class"; but there are hundreds of times where I have though to myself "This should have been a class instead of an ID".

In terms of pure CSS it doesn't matter, but for JavaScript that manipulates the DOM (e.g. jQuery), it does. Specifically, `getElementById` is more than 50% faster than `getElementsByClassName`.

https://jsperf.com/id-vs-class-hn/1

Re: CSS: The bad bits and how to avoid them

#86

Post by ravenstine »

mattigames wrote: post #65
ars wrote: post #6

There's nothing wrong with styling on an id. You could put the style right in the HTML tag, or on the page where it's used, but with dynamic pages (and static stylesheets) both options will cost you bandwidth. And they split up your styles into separate places. So putting the style on the id is the right thing to do, and I don't understand why the author is against it. If I need my footer to look a certain way, then…

There is not a single time I had though to myself "This should have been an ID instead of a class"; but there are hundreds of times where I have though to myself "This should have been a class instead of an ID".

I tend to reserve IDs for things that exist only once on the page at a given time, and the only properties I define under IDs are ones for layout. For example, if I have a page for an article, I would make the top-most element "#article" and things like the navbar and the body "#article__nav" and "#article_body". The only thing those IDs are concerned with is how the navbar and the body are sized and positioned when on the article page.

Shared stylistic properties for components use class names. The properties that make a navbar look like a navbar(color, font, and anything that applies to children) would be specified under ".nav" and the same would apply for the body under ".body". Anything that's stylistically-specific to

Shared variations of components are handled with modifiers. An example would be ".nav--dark".

Any one-off variations are handled with parent-scoped class names like ".article__nav", since I treat even that topmost element as a component. (or a block if you're thinking in BEM).

I've found that keeping "style" and "layout" CSS properties separate helps keep components flexible and untangled from a given page layout. The differentiation between IDs and class names makes this more convenient because it becomes obvious what parts of my CSS are intended for.

But what about the internal layout of components? If the children of a component are supposed to change their sizing and positioning at different breakpoints, then how are you supposed to achieve this while keeping components agnostic about the page layout?

It's a tricky problem, but I solve this with Sass mixins. If a component has different internal layouts for mobile and tablet screens, as an example, I write mixins to define those states using the same naming convention that I would use with class names and IDs. If I was using a grid system, I would define them as "@nav--lg", "@nav--md", "@nav--sm", "@nav--xs", etc. Then underneath the page layout, in this case "#article", I would include those mixins under the chosen breakpoints. That way, all layout can be handled by IDs in stylesheets dedicated to page layouts.

It just so happens that I have a Codepen that demonstrates this idea:

https://codepen.io/Ravenstine/pen/xpYoWv

The only part that is different is that I made the masthead and the footer not a part of "#article". If you don't plan on having components like that behave differently depending on the page they are on, that's probably appropriate.

Post reply on HN