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

31–40 of 109 posts

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

#31

Post by morley »

ars wrote: post #26
bluetwo wrote: post #13

Earlier quoted context omitted.

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.

> I would still use .footer instead of #footer Why?

I think the preference against ids is covered over point #2 about specificity. id styles will always override class styles, so when you're trying to apply a class-based style guide to an element that's already been styled with an id, you end up having to use !important which just creates a similar specificity problem for someone else down the line.

Of course, you can still do this if you want to. To quote Chris Rock, "you can drive a car with your feet if you want to." But if you work on a large code base that lots of developers have touched, and lots of future developers will touch, you run into these issues all the time. And the bugs that come about can be tough to spot and to fix.

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

#32

Post by zdragnar »

soperj wrote: post #19

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

Nope. A variable is only global if you are in non-strict mode and leave off a `var` on the declaration, or explicitly assign to the global scope (aka window in the browser).

Object internal state is generally true, if you're using prototypal objects. Use function closures when you need to internalize something.

Speaking of which, anything hidden via closure is truly hidden and can't be overridden. Anything public can be overridden, excepting objects frozen via the ES5 spec's Object.freeze method.

I generally enjoy most aspects of JS, and generally detest working with CSS, in large part because I delegate interacting with many browser APIs to JS libraries, whereas there's no escaping the awfulness that is years of backwards compatibility with incompatible vendor specs and CSS implementations.

I suspect I'll be happier once CSS Grids are universally supported (properly) among all of the browsers I need to target, and use postcss for the rest.

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

#34

Post by Someone1234 »

peterchon wrote: post #20

In 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 right way is easier than doing it the wrong way.

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

#36

Post by talmand »

dsego wrote: post #29
RobertRoberts wrote: post #23

Earlier quoted context omitted.

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

I know C in CSS is cascading, that doesn't make it a good feature. I think it's one of the big reasons that the web is slow and bloated. CSS is needlessly complex, no wonder it takes herculean efforts from browser vendors to keep up with the exploding complexities [1]. [1] https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...

One reason for the cascading is to reduce bloat. If the CSS is bloated because of cascading and/or needlessly complex then the CSS and/or design is wrong, not the cascading.

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

#37

Post by pg_bot »

sebazzz wrote: post #22
pg_bot wrote: post #18

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

If we're going that way, you might as well include that particular file only on that page.

I would rather have one single request for a large static asset, than multiple small requests for per page based css. In my experience CSS files typically fall in the range 50-100KB. I'd rather not have to pay the perf penalty every time I load a new page considering the typical file size.

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

#38

Post by talmand »

RobertRoberts wrote: post #30
Risord wrote: post #8

Just wondering how much more complains and valid critique against css is still required to get real alternative. https://ishoudinireadyyet.com

I hope never enough, CSS is a fantastic language. Also, houdini won't replace CSS, it's actually the opening up of the CSS engine: https://developers.google.com/web/updates/2016/05/houdini

I agree since most of the complaints and critiques of the language that I've seen are from people who don't appear to know how to code it correctly. Especially the complaints along the lines of "this is how it works in language X, it doesn't work that way in CSS therefore CSS sucks!" and other similar notions.

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

#39

Post by LaGrange »

ars wrote: post #28
mkoryak wrote: post #7

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

> It can be reusable and yet unique on each page. And those should get id's, and are not rare at all.

I _think_ what's going on here is that, in the, excuse my French, _enterprise_ sector it's very common to have some sort of an end-user configurable, enormous form (or dashboard or whatever) full of widgets that are not in any way unique. In fact in many places it's so common, that for a certain section of developers it might be hard to imagine that the opposite is actually quite common.

This is _a lot_ of "web" development. Often done by developers who, to be honest, would rather be doing this in QT (eww) or something.

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

#40

Post by wvenable »

drinchev wrote: post #9

I'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.
Post reply on HN