WTF, HTML and CSS?
wtfhtmlcss.com
wtfhtmlcss.com
The reason for that is a rather cute implementation explained here:
http://blogs.msdn.com/b/ieinternals/archive/2011/05/14/10164...
(...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.
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.
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).
Open gmail, do this in the console:
document.styleSheets[2].cssRules.length
In any case, for large sites with site-wide stylesheets that have styles for everything on the site, it's easy to end up with thousands of rules. A simple example is github, which on the front page has this as of today:
<link href="https://github.global.ssl.fastly.net/assets/github-b836a3967c04ec8b8bfdd101d2226064cb18f45d.css" media="all" rel="stylesheet" type="text/css" />
<link href="https://github.global.ssl.fastly.net/assets/github2-91575e4b8f601c887ca6b13c6f78d06f03af775f.css" media="all" rel="stylesheet" type="text/css" />
The paragon of wondrous design that is the Huffington Post has a bit over 4k rules, spread over 5 stylesheets.
msnbc.com also has a bit over 4k rules, spread over 5 stylesheets.
It's pretty easy to find sites with 2-4k rules (Outlook Web Access, BBC front page, CNN front page, twitter, Google docs, whitehouse.gov, the Facebook login page, officedepot.com, washingtonpost.com, youtube, I'm sure I could find plenty more).
All of which is to say, your typical website has more CSS than most people think.
That it's common for all of these sites, who have massive surveillance and SEO structures built into them, to have gigantic stylesheet collections doesn't change the fact that they are bloated nightmares of code.
If I said, "filing taxes is a nightmare", and you said, "oh yeah, but what about all the other people who file taxes, some of them even more complex than yours?" That wouldn't change the fact that filing taxes is a convoluted, intentionally obfuscated, Lovecraftian construct, summoned forth from the depths of Hades itself.
They have to do with having a site with a wide variety of different-looking pages and wanting to have a single site-wide stylesheet, instead of having dozens or hundreds of smaller stylesheets. Whether that's a useful thing to do or not obviously depends on how your maintenance for the site is set up, how your CDN works, and probably other things I have no idea about; design of this sort of site is not my area of expertise.
And while I agree that all of these sites have a lot of complicated styles and scripts going on, I have a hard time believing that a site of the sort I just described can be created without ending up with a fairly complicated stylesheet.
If your position is that having such a site (variety of different kinds of pages) should be a non-goal, I can't agree with that: there are plenty of reasons to want a site like that. If the argument is that having a single stylesheet to rule them all in that situation is bad for maintainability, I don't have a good response: as I said I've never maintained such a site, so I don't have a good feel for what the maintenance tradeoffs are.
Fully agreed on the taxes. ;)
... especially since it'll be hard to fit more than that into the 640k of memory I have. ;)
http://en.wikipedia.org/wiki/Category:Web_browsers_for_DOS
(Whether they support CSS, and if so, what the limits are, I don't know.)
The solution was of course to simply join the CSS files where possible. But it definitely was a bit of a WTF moment.
Is there a reason for this? Why not just use 3 shorts?
It seems they didn't expand the limits to 64-bit, as that could vastly increase them: e.g. a (5x4):24 split, meaning 16M rules per sheet.... and if you have 16 million rules in a single CSS file, I think it's safe to say the CSS rule limit is the least of your problems. (But then whoever came up with the 4K limit probably thought the same thing...!)
Does anyone happen to know what WebKit/Gecko/Presto does? I've been thinking of writing my own HTML/CSS layout engine and these sorts of things make for interesting decisions on the algorithms to use.
There is always some level of arbitrariness when you represent data structures this way for performance reasons. It's all about what maximum values you think are good enough.
I don't recall any trouble applying styles to tr elements without having to do anything special to the parent table.
Setting the border-collapse to "collapse" explicitly just to test:
What am I missing here?
If you have a "CSS reset" that resets it to a non-initial value, that seems like a bug in that "CSS reset", no?
It would be nice to add a bit more of an explanation for some of these things. eg:
- There's a bold warning about float elements with display: block set - "Do not set both". Why is this so important?
- "Skipping the doctype can cause issues with malformed tables, inputs, and more" - some examples of what could go wrong would be really handy here. Or a link to a more in-depth explanation?
In general some more links would be great.
One small example that I've seen go wrong, elements don't center with CSS if you skip the doctype. Seems to ignore margin-left and margin-right.
Omitting the doctype basically sends the browser into "quirks mode" and then the page is rendered with old browser rendering bugs.
It's a bad scene. Avoid it at all costs.
If you do not want to show it to brother, more power to you and you got my respect for thinking about what language he picks up. Really. However, the resource has exactly two impolite words in it, so it is hardly huge amount.
Maybe the author feels obliged to curse a little bit, and mostly in jest / for its own sake because the domain name includes a simulacrum of obscenity (WTF) in it.
It's just too strong for me to feel comfortable sharing it with younger ones. I guess a more accurate way to describe the issue for me would be to say it's because of the "strength" of the swearing rather than the quantity.
However, I will be sharing this with co-workers! It's a good document for reference.
Isn't this the guy whose ego is so great he crapped all over Douglas Crockford when that man so generously spent time trying to help improve Twitter Bootstrap? The very same Douglas Crockford who has contributed so much to building the JS/frontend community to what it is today.
(Or perhaps they do and I'm just not running into them or they are buried underneath the W3Schools sewage?)
http://wisercoder.com/firefox-displaytable-cell-and-absolute...
Not even sure how to handle such problems.
http://philipwalton.com/articles/what-no-one-told-you-about-...
https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Under...
I wish those days were long passed. There are definitely still a lot of IE6 users. I recently worked on a project which services the Chinese market. http://www.modern.ie/ie6countdown
Leaving a few million users out of pixel perfection doesn't sound so bad. (And out of those millions, how many will actually stumble upon your web site anyway?)
These 4.4% more might still matter, but the cost-benefit tradeoff looks much different now.
I don't know if that's the whole story, but at least it's official.
I should start a blog about the horrors or C where mysteries are explained such as "You must declare variables before you use them!!" followed by appropriate horror music.
Then the next case comes along.
Seriously, there are many times when I miss the days of nested tables.
"The sort of twee person who thinks swearing is in any way a sign of a lack of education or a lack of verbal interest is just a fucking lunatic."
Profanity is an essential and rich part of the English language. It's really only prudes and people who need to feel morally superior have a problem with it, and they can fuck right off, frankly.
The whole idea of a swear word is that it's supposed to be strong, and, yes, offensive in some way. That means that there will be contexts in which profanity will be inappropriate, and there is nothing prudish about knowing this. Good writing means using the right word for the right purpose, and sprinkling swears inside a technical article usually comes off as cheap and lazy.
Your attitude changes when you have children. I used to use more colorful language more routinely. But there are various reasons you don't want to hear those words coming out of your little ones' mouths, yet.
> It's really only prudes and people who need to feel morally superior have a problem with it, and they can fuck right off, frankly.
Kinda like how you need to feel superior to them about this particular issue?
Can't blame him.
One example: sailors.