CSS: The bad bits and how to avoid them
joeforshaw.com
CSS: The bad bits and how to avoid them
1–10 of 109 posts
Re: CSS: The bad bits and how to avoid them
#2The world really doesn't need another "What to Avoid with CSS" list.
This list also assumes the use of a CSS pre-processor.
Re: CSS: The bad bits and how to avoid them
#3The world really doesn't need another "What to Avoid with CSS" list. This list also assumes the use of a CSS pre-processor.
Maybe you've learned everything there is to know about CSS, but I haven't, and I prefer to learn from the mistakes of others rather than my own (not that I don't make plenty of my own).
Re: CSS: The bad bits and how to avoid them
#4The world really doesn't need another "What to Avoid with CSS" list. This list also assumes the use of a CSS pre-processor.
I enjoyed reading it. I liked that fact that it wasn't a huge list, just 6 points. Well described, good examples, and well structured with the "Best workaround" sections. To me it felt big enough to hold real value but small enough to easily consume. It's something I'd probably share with juniors on my team.
Re: CSS: The bad bits and how to avoid them
#5The advice to use CSS variables to handle Z-index confusion is a good first step, but IME that's only the right way to handle global z-indexes like modal lightboxes and menus. For local z-indexes, you should also know how and when to create a new stacking context with position: relative.
This is the go-to article I send to newbies struggling with z-index. https://hackernoon.com/my-approach-to-using-z-index-eca67feb...
Re: CSS: The bad bits and how to avoid them
#6There'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 #footer {} is exactly what you should do.
Not add some bogus class based style just in case someone decides we need two footers on one page.
Re: CSS: The bad bits and how to avoid them
#7There'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…
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
Re: CSS: The bad bits and how to avoid them
#8Just wondering how much more complains and valid critique against css is still required to get real alternative.
Re: CSS: The bad bits and how to avoid them
#9I'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].
Re: CSS: The bad bits and how to avoid them
#10The world really doesn't need another "What to Avoid with CSS" list. This list also assumes the use of a CSS pre-processor.
Well, I liked it. I had never heard of BEM before, either, so I'll definitely take a look at that. What gets me about CSS is that, in spite of having used it now for about 20 years, I still don't have an intuitive feel for it. With everything else I work with, I start out with an experimental approach: if I change this, I see this, if I change that, I see this other thing; after usually a few weeks of experimentation, I develop an intuition for it so that I can usually predict what it's going to do before I have to see it do it (admittedly it took more than a few weeks to get to that point with Lisp and assembler). CSS, though, just seems to deny intuition; even after reading the O'Reilly "CSS: The Definitive Guide" book, I don't have the faintest clue what my CSS is going to do until I try it out.