CSS: The bad bits and how to avoid them
21–30 of 109 posts
Re: CSS: The bad bits and how to avoid them
#22There is a different and IMO better way to solve the global scope problem in CSS. Adapted from the Paul Irish method of executing JS you can use data attributes to conditionally write CSS. For example a new user controller would output the controller and action names as data attributes on the body. I then have a separate css file under `assets/users/new.scss` which only contains css for that page. Your Sass code look…
Re: CSS: The bad bits and how to avoid them
#23One bad thing about CSS is cascading. Too bad that's the main thing. Some styles like colors and fonts move like a plague into every nook and cranny, all children elements get infected. Others like border get applied only onto the targeted element. Heavily nested selectors is another one, good luck overriding a style on a bootstrap element, their selectors strictly follow html nesting levels. You want to override a t…
This is an odd statement, considering that the C is CSS is "cascading". Maybe it's a perspective issue, because I really enjoy the cascading part of CSS. Don't you think it's better that we _don't_ have to set a color for each element/child element individually?
Re: CSS: The bad bits and how to avoid them
#24>If you told any back-end developer that they had to use a programming language that gave all variables global scope, made every object’s internal state visible, let any other developer override their code, they’d probably resign on the spot Isn't that the case with Javascript?
Re: CSS: The bad bits and how to avoid them
#25Stop using CSS and go with modular SCSS
Maybe I am stupid here, but doesn't SCSS just render out to CSS?
Re: CSS: The bad bits and how to avoid them
#26There'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…
Sure, the author is describing good practice, not best practice. If you have a choice, use class, then if you need to modify a specific use of the class, use id. I would still use .footer instead of #footer. Of course you should consider as well.
Why?
Re: CSS: The bad bits and how to avoid them
#27The 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…
Welcome to css-tricks.com [0], where you will learn all the current trends. I am a regular reader for things just like this. Where you just want to know what's new and where things are going. Plus they have an amazing stockpile of CSS examples.
Second only to Mozilla Developer Network. [1]
Re: CSS: The bad bits and how to avoid them
#28There'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
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 that are each unique. (They might appear on more than one page, but on any particular page, they are unique.)
Give them id's, that's what they are for.
Re: CSS: The bad bits and how to avoid them
#29One bad thing about CSS is cascading. Too bad that's the main thing. Some styles like colors and fonts move like a plague into every nook and cranny, all children elements get infected. Others like border get applied only onto the targeted element. Heavily nested selectors is another one, good luck overriding a style on a bootstrap element, their selectors strictly follow html nesting levels. You want to override a t…
> One bad thing about CSS is cascading. This is an odd statement, considering that the C is CSS is "cascading". Maybe it's a perspective issue, because I really enjoy the cascading part of CSS. Don't you think it's better that we _don't_ have to set a color for each element/child element individually?
[1]https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...
Re: CSS: The bad bits and how to avoid them
#30Just wondering how much more complains and valid critique against css is still required to get real alternative. https://ishoudinireadyyet.com