3 ms·

> (...and IMHO 4K selectors is a lot more than any sane page should use...) I don't think this is a problem with hand-coded CSS files. But since the trend nowa

by kijin 13y ago

> (...and IMHO 4K selectors is a lot more than any sane page should use...) I don't think this is a problem with hand-coded CSS files. But since the trend nowadays is to generate CSS from a bunch of LESS or SASS files, minify the whole thing, and stuff it into a single HTTP request, it's not impossible for large and complicated apps to end up with over 4K selectors. When you're living in SASS fairyland you don't always remember that your beautifully nested rules and mixins will compile into dozens of CSS selectors.

thejosh 13y ago
Ran into this problem when doing some crazy silly CSS, ended up using bless[1] to fix this issue. [1] http://blesscss.com/ http://blesscss.com/
- STRML 13y ago
  I've run into this before with a large app: bootstrap + font awesome + plugins + custom css in a single blob put me well over 4096 selectors. Fortunately, bless (via grunt-bless) and a simple IE conditional comment fixed it for good. Bless is a great project.
- Already__Taken 13y ago
  Isn't @Import a bad idea? At least if you write multiple <link>s for css they can download in parallel. @Import will always have to wait for the first sheet to download AND Execute. Which isn't so bad with CSS but still.
  - thejosh 13y ago
    You should be using a IE conditional just for bless. :)
userbinator 13y ago
it's not impossible for large and complicated apps to end up with over 4K selectors Is that 4K of selectors that are all actually used, or are most of them just taking up space? If it's the former, then I can see the concern, but if it's the latter, then maybe the 4K limit is perfectly reasonable after all, and instead we should be rethinking how we generate our CSS (a quick search shows plenty of tools that will find and remove unused selectors.) Or put another way, it's the difference between complaining about some system not having enough RAM instead of trying to rewrite your application to be more efficient so it can stay within the limits; and I think most recently there's been far too much of the former and not enough of the latter.
- kijin 13y ago
  Sure, you could remove unused selectors, but then you'll end up with different CSS files for different pages. That's a lot of extra HTTP requests for a first-time visitor who wants to look around your website. Whether or not the extra HTTP requests are worth the time and RAM saved by removing unused selectors will probably depend on your specific needs and priorities. For the time being, though, I suspect that modern computers take less time parsing a few thousand unused CSS selectors than the time it takes to fetch an uncached HTTP resource from a few thousand miles away. Moreover, devices with less RAM and computing power tend to be connected to even slower networks (e.g. 3-year-old phone on a 3G network).

by kijin 13y ago

thejosh 13y ago

Ran into this problem when doing some crazy silly CSS, ended up using bless[1] to fix this issue. [1] http://blesscss.com/ http://blesscss.com/

STRML 13y ago
I've run into this before with a large app: bootstrap + font awesome + plugins + custom css in a single blob put me well over 4096 selectors. Fortunately, bless (via grunt-bless) and a simple IE conditional comment fixed it for good. Bless is a great project.
Already__Taken 13y ago
Isn't @Import a bad idea? At least if you write multiple <link>s for css they can download in parallel. @Import will always have to wait for the first sheet to download AND Execute. Which isn't so bad with CSS but still.
- thejosh 13y ago
  You should be using a IE conditional just for bless. :)

userbinator 13y ago

it's not impossible for large and complicated apps to end up with over 4K selectors Is that 4K of selectors that are all actually used, or are most of them just taking up space? If it's the former, then I can see the concern, but if it's the latter, then maybe the 4K limit is perfectly reasonable after all, and instead we should be rethinking how we generate our CSS (a quick search shows plenty of tools that will find and remove unused selectors.) Or put another way, it's the difference between complaining about some system not having enough RAM instead of trying to rewrite your application to be more efficient so it can stay within the limits; and I think most recently there's been far too much of the former and not enough of the latter.

kijin 13y ago
Sure, you could remove unused selectors, but then you'll end up with different CSS files for different pages. That's a lot of extra HTTP requests for a first-time visitor who wants to look around your website. Whether or not the extra HTTP requests are worth the time and RAM saved by removing unused selectors will probably depend on your specific needs and priorities. For the time being, though, I suspect that modern computers take less time parsing a few thousand unused CSS selectors than the time it takes to fetch an uncached HTTP resource from a few thousand miles away. Moreover, devices with less RAM and computing power tend to be connected to even slower networks (e.g. 3-year-old phone on a 3G network).