A little off topic, but at the end where it says browser compatibility is "everything but IE" got me wondering. Does Microsoft's IE team care about their product at all?

I thought with IE9 being so standard-compliant and 6 finally dead, tiresome browser-compatibility fixes were a thing of the past. I'm sure Microsoft's IE team reads about how much their browser sucks, right? Why does IE continue to suck?

EDIT: On the subject of vendor-specific extensions, it seems to me that a lot of new features of "the open web" such as WebGL, Native Client, and advanced CSS trickery all basically work best in Chrome, or maybe Firefox six months later (remember how long it took firefox to get text-overflow:elipsis?). These are all features that basically exist in a single browser at the moment. Here's some food for thought; we've had all of these in a single browser before, and that browser was IE6. ActiveX and a certificate system replaces Native Client and sandboxing, and it had it's own css filters for an awful lot of things just arriving in CSS3, as well as DirectX-accelerated transforms.

We've transitioned from having only one browser support the common features of the internet (IE6), though a brief period of openness, but it seems like we're heading down the single-browser path again. Just because Webkit is open source and the W3C publish a standard doesn't mean that everything is better this time - nobody thought IE would stagnate in its heyday.

Well it's better in one important way: the browser makers don't try to dictate behavior of other browsers. Instead of fighting, they put their own behavior in a namespace until they agree on an open standard. Then they can drop the prefixes.

I thought ... tiresome browser-compatibility fixes were a thing of the past

Not by a long shot. One thing to keep in mind are browser half-lives. IE's decay rate, in particular, is horrible. IE 6 is still a problem in some sectors, and IE 7 & 8 still linger just as much, if not more. IE 9 is a huge step in the right direction, but still, more advanced features such as support for local databases, ES 5 strict, web sockets, and web workers, won't land until IE 10. The same is even true for lesser features that other browsers have had for years, like text shadow.

    background:      -o-linear-gradient(top, #ECECEC 50%, #D1D1D1 100%);
    background:     -ms-linear-gradient(top, #ECECEC 50%, #D1D1D1 100%);
    background:    -moz-linear-gradient(top, #ECECEC 50%, #D1D1D1 100%);
    background: -webkit-linear-gradient(top, #ECECEC 50%, #D1D1D1 100%);
    background: linear-gradient(top, #ECECEC 50%, #D1D1D1 100%);

If you want to use standards, you need to select what's available to you by your target audience, and ignore the non-standard-compliant cases. If you want to do things, and keep as large a target audience as possible, you need to either hack them together with old tech or jump through hoops to do it with new tech. Especially given the web's rocky past, many developers would prefer to use the new stuff. And there are tools to help - Less or Scss, for instance, make those prefixes essentially free.

But that's just a fact of programming in general - you could write a web-app and get it on any computer with a modern browser. Or you could write it in Ruby, and get it on any computer with a Ruby interpreter, and include an installer / instructions for those that don't. Or you could write it in C, and get it on any computer with a C compiler, and you may have to write your own library code / preprocessor controls to handle strange architectures, and change things based on your target OS. Or you could write it in assembly, and have it run on almost anything, but have to handle multiple flavors and an endless variety of available memory, and input and output devices.

Or do any of the above, pick a subset of the devices that are technically capable of reading your code, and screw the rest. Porting Doom 3 to Commodore 64 probably isn't going to work, despite the code being written to the standard of whatever language it was written in (probably C, which I will assume for now), and compilers adhering to the same standard for targeting the C64. That you can't run Doom 3 on your C64 doesn't mean the standard is broken or useless.

--

The nice thing about those prefixes is that, in general, it means you can use new features and know they'll work as you designed for years to come. If a re-design every year or so is cheaper than vendor prefixes, then yes, they're a pain - wait until the standard comes out. If not, they're a time saver to get handy new features a couple years early, and free switch-over to the standard when and where it's implemented.

1. Basically now we're stuck with +five lines to specify one thing. When can we switch to just one line, and drop the prefix versions? I doubt any time soon. We're only now dropping support for IE6.

2. how useful is it to be able to build stuff that only works in some browsers? I get that it helps push stuff forward, but you get myriad posts on HN that are like "look at this sweet thing I built (only works on chrome)" or something similar. Good for you, you built something cool, but you might as well have done it as a native app because I can't run it without downloading a different browser.

Interoperability is one of the basic premises of the web.

Many of the older CSS3 specs are now supported in modern browsers, so I'd say we're pretty close, really. Or now, if you only support the most recent version (which accounts for what, >50%?). A stupendously far cry from where we used to be not too long ago.

There has to be a way for browsers to test new features in the wild. That's how it's always been and will always be, which also has the nice side effect that the standards body (or single vendors inside the body) cannot slow everyone down. If everyone could only implement features when they are really done and part of the standard the world would be a dreary place indeed.

The problem with this is that when two browsers implement a feature with either a different syntax or different results you would be forced to do browser detection and have two stylesheets or use hacks. That reallx used to happen and it sucked. The prefixes avoid this problem altogether. When everyone agrees about a feature the prefixes can be dropped – in this case (if the syntax doesn't change) nobody even has to change anything. All the designer has to do is delete lines as more browsers adopt the standard.

What you are seeing is the necessary result of a standards process with many vendors.

http://leaverou.github.com/prefixfree/

Not a perfect solution, but it's interesting.

Many a year has gone by where I've seen cool things appear that I'd love to use but just couldn't write off ~ 70% of browsers. Those days are numbered, more or less, and it makes me unsad.

edit: I feel so stupid not knowing about this even after years of CSSing. Apparently it's CSS2 but doesn't work well if you don't have IE8+

http://www.wittenburg.co.uk/mobile

Click "Handsets" on the top menu.

Select any phone on the left.

Tabs are shown on the right.

[Edit] Not saying joshuacc's CSS version is trivial. It's not. And it IS impressive!

The use of jQuery was to provide the functionality so you can see it in action. If I felt the need I could easily recreate the tabs on a series of pages that do not require javascript at all.

The only reason this might need javascript involved is if the tabs are changing content on the page without loading a new page, such as swapping out divs in a container.

I believe you are confused about design versus function.

... except it doesn't appear to be intentional, or in line with what I just visited. On the example page, click the last, then second, then third to last tabs. Even though you're in the second tab and were just on the third, the last tab appears to be resting on top.

It looks awkward to me. Sorry, that was a lot of criticism for a well written iterative CSS guide which I appreciate!