Bad bits? More like code correctly, use already existing CSS features to your advantage, and use common sense when naming things. Then the so-called "bad bits" tend not to happen.
CSS: The bad bits and how to avoid them
41–50 of 109 posts
Re: CSS: The bad bits and how to avoid them
#42Never 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.
Because "my-block" is not a valid attribute for div. You are breaking one language in your attempt to fix your problem in another language.
Re: CSS: The bad bits and how to avoid them
#43I'm a huge fan of 1 & 2, so I end up using CSS with only class names. This helped me deliver maintainable and reliable stylesheets that other devs like. Most importantly using only class names you will gain : 1. Your HTML / CSS is easier to maintain. 2. Is faster to develop. 3. Is faster to refactor. 4. Is more portable. 5. Is faster for the browser. I even wrote a blog post about it [1]. http://www.drinchev.com/blog…
But your HTML is uglier.
So? The only people looking at your html classes are you and your team. Bots don't process css, and most people don't look at html.
Re: CSS: The bad bits and how to avoid them
#44In my opinion, most CSS bad bits are a byproduct of bad use, not a problem of the language(?) itself. SASS, BAM, OOCSS, etc are all good practices. You can/will abuse those as well without proper understanding and planning.
> 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.
Re: CSS: The bad bits and how to avoid them
#45Just like WASM allows us to implement new languages as alternative to JavaScript, could it one day become practical to implement an alternative to CSS?
EDIT: Perhaps by implementing the whole browser in WASM? Would that even make sense?
Re: CSS: The bad bits and how to avoid them
#46Re: CSS: The bad bits and how to avoid them
#47Never 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.
Because "my-block" is not a valid attribute for div. You are breaking one language in your attempt to fix your problem in another language.
This argument doesn't stop a myriad of widely used JavaScript frameworks that rely on custom attributes. Besides, if you really care about validity, you can use
Re: CSS: The bad bits and how to avoid them
#48Earlier quoted context omitted.
Because "my-block" is not a valid attribute for div. You are breaking one language in your attempt to fix your problem in another language.
This argument doesn't stop a myriad of widely used JavaScript frameworks that rely on custom attributes. Besides, if you really care about validity, you can use It's still shorter, more readable and avoids repetitions. The difference becomes even more pronounced as the complexity of your styling goes up.
My argument about the attribute is not invalid because they are doing it the wrong way. Custom attributes for HTML should make use of the data attribute, as you point out. One could use data attributes in such a way, I have, but in the past it was something to avoid due to performance issues.
To be fair, I don't know the latest performance figures on attribute selection.
Re: CSS: The bad bits and how to avoid them
#49Earlier quoted context omitted.
I think the author probably agrees with you. What you pointed out is the exception to the rule though. The percentage of things on a page that are "singletons" is very small compared to reusable widgets. If you don't have much resuable stuff on your site, that's a code smell in itself
> If you don't have much resuable stuff on your site, that's a code smell in itself It can be reusable and yet unique on each page. And those should get id's, and are not rare at all. > The percentage of things on a page that are "singletons" is very small compared to reusable widgets. That isn't necessarily true. Obviously there are different types of pages, but a typical page will have a number of elements on it th…
Elements can often be unique today but not tomorrow as pages grow in complexity and start sharing features. Ids are fine (even necessary) for things that are unique in their very essence, like a label's for="", the target for a URL fragment, or things that need special individualized treatment in JavaScript. In the common "unique today" case, ids provide no benefit over classes as simple styling hooks and quickly become a PITA when they start colliding.
Re: CSS: The bad bits and how to avoid them
#50Best workaround: Quit front end web development. If that’s not an option, tough, you’ve got to use CSS.
Instead of quitting front-end dev, you might also consider using https://www.styled-components.com/
Styled-components solves all of the issues the author highlights in his writeup.
Bonus: styled-components works both on web and on React Native! So you don't have to throw out all your stuff to participate in the post-browser future...