You make it sound as if Developers are solely to blame for this "mess", and they did it for superflous reasons. I call BS on that.
Case and point: Border radius and linear gradients made things better for EVERYONE. Developers didn't have to create the html/js/css/image mess just to create rounded corners. This meant less code, less images, less css, which also translates to snappier websites. (and users like that.. there are studies that prove that) This also meant that, as a company, we decided that IE had to live with a degraded experience until they made their browsers competitive with all the others. (and users had access to said browsers)
As a Front End Engineer, I find it insulting that you suggest we are doing it for "fun" or to make our resume look better. This makes our lives better, and we have to consciously decide who gets a degraded experience and who gets the better experience. I think we call that "graceful degradation" or "progressive enhancement". You stated: "They allow you to create novel effects which you can then discuss in your blog", if these are novel effects then why do...
You state that websites are "broken" for non-webkit browsers on mobile. Well then maybe my definition of broken and yours differ. I say a "broken website" is one where the content CANNOT be consumed by the end users. Also if the end users have functionality that is broken, and therefore prevents them from accessing / modifying content.
I DO NOT think broken means, degraded visual experience. When we decided that IE would get square corners, and flat background (instead of rounded corners and linear gradient backgrounds), we knew that IE would still be consuming the content just the same.
Therefore, please inform me which -webkit prefixed css is causing the breakage I define. (where consumers are blocked from the content)
"This looks bad", doesn't count.
Now granted, I'll give you that as developers, we should be using all prefixes that are supported. It might be a pain in the ass, but that's our job. I'm with you there, and I'm going through my current css to find if any are missing -ms, -o, -moz and the default fallback css. Considering I use a preprocessor for my css, I'm pretty safe, except on my blog, (which has no preprocessor yet). I suggest all of us developers do the same. But this is a "nice to have" not the "the mobile web is broken!" as browser vendors are rallying.
Again, if you can prove to me, that the web is broken under my definition, I will take my words back for those specific css rules according to their proliferation on the web.
RE: low hanging fruit.
It's assumed that you have already done that. Just one more piece of the puzzle. As the test suggests.. it would be good to code in a way that's less bloated, however it's not always going to make a huge difference.
re: zero-impact if cached: I assume you mean visitors that have already downloaded your css from a previous visit? That's been shown to be inaccurate. I also would assume that you have css with far future expires and is zipped, (possibly URI'zed), and on a fast CDN. (not all CDN's are fast).
Yet there is no such thing as zero impact. The css still has to be painted on the page and even when cached. If your CSS is 500kb, that could take a long time for a browser to parse CSS.
re: non-semantic class names.. it's a test.. nuf said
re: your ideal site: There't lots I could say here.. besides the fact that IE is still to simpleton to understand most selectors I assume you are speaking of. Also, if you are talking about decendent selectors like I am thinking.. check the Link to Steve Souder's site.. they talk on that. (hint: they're faster)
again, this is assuming you have done all of the other things.. and then some. There is much more you can do before optimizing your css.. but some are at that point. Just because it doesn't apply to you, doesn't mean it isn't an issue to others.. Nor does it mean we should assume there is no issue, without testing and measuring (in order to make sure.)
Yes, I do. I come from large corporations, where studies have shown that when a site is slower, even by 50-100 milliseconds, your traffic WILL decrease.
When your site gets a million views a day, 2 percent is large.
Thats when you start to nitpick each and every part of your site that slows things down.
I use SASS/Compass because it's an awesome tool to maintain your CSS, however it's very easy to add alot of extra CSS (mixins and whatnot).
The reason I created this, was to find out if using @extend would perform similarly to the OOCSS methods, which are proven to perform fast.
I think it accomplishes exactly that.
Yikes! You are right.. what was I thinking adding the @font-face.
However, the rest of the css is used in all the tests as a base. I don't see how that would affect the test considering it's on all scenarios (except the no css scenario)
I use the javascript-based date as I found it to be quite accurate at in giving me the time difference from the time css is loaded until it's done. Thanks for the reminder.. I need to credit the testing JS to Steve Souders.. found in his article here:
http://www.stevesouders.com/blog/2009/03/10/performance-impa...