Responsive design is not the end all solution to problems faced with mobile. Most people who do advocate it are dealing with fairly small sites. However, sites that have a purpose beyond delivering simple content almost always would best served with dedicated mobile work flow based on the context which the site is being used. There are actually a considerable amount of things in modern mobile webkit that can not be easily replicated in other browsers without significant performance issues. Especially, in regards to JavaScript.
Responsive design is not the end all solution to problems faced with mobile.
My point was, don’t think “oh yeah what about mobile?” and jump immediately to “oh, that means make an iSomething app and we’re done.”
I’ve heard too many developers at large media bureas say just that (the latter).
Plenty of others are weighing in on this discussion.
http://codepo8.github.com/prefix-the-web/
http://www.glazman.org/weblog/dotclear/index.php?
'Twill be very interesting to see where it all goes.
On the “plus” side … mozzila wants to drop their prefix ( or at least support webkit) . To me this kinda kills the one and only good reasons to have vendor prefixes… but hey.
I don’t understand why if there’s going to be a prefix, there should be one for every vendor. A single unified prefix like say “-development-do-not-use-in-production-sites” or something 
I still don’t understand why there has to be a goddam prefix at all. 
EDIT: I mean, yes, I get the idea that the final version of border-radius might end up different from -webkit-border-radius, but as far as I’m concerned, that’s just too bad for people who wanted to jump in early.
Hence my joke absurdly long prefix that says EXACTLY what all those other prefixes should actually mean.
Because you’re right – you jump the gun implementing something still in draft on a production site, you should get EXACTLY what’s coming to you when/if it breaks in the future… or breaks when someone doesn’t have the same magical combination of display, OS and software, or breaks on legacy, or ends up slower/more bloated for nothing compared to current recommendations.
But of course, nobody actually cares what “Beta” or “draft” mean anymore. New/shiney now! Now! NOW! who cares how bad it bends you over the table in the future. Of course, if we didn’t have this attitude there’d be no such thing as credit… Pay more later for something you can’t afford now – ABSOFRAGGINGLUTELY BRILLIANT!!!
I thought one of Remy’s suggestions was the best, that browsers should only have the prefixes available in nightly / beta builds.
That way, only those really interested in testing and giving feedback will use them, that was their intention.
That does make the most sense – if they exist just for testing (which is the entire point of the vendor prefixes) then they should only be available in ‘testing’ builds of the browser… like Opera Next, like IE developer previews… like… wait, do FF/Chrome/Saffy have equivalents other than the ‘build it yourself from source’? Never paid enough attention to those…
Or if you don’t want the dev channel of Chrome or Firefox, as they can sometimes be a little crash happy, there are the betas at http://www.google.com/landing/chrome/beta/ and http://www.mozilla.org/en-US/firefox/channel/#beta/beta-desktop.
(The good thing about being on a different release channel with Chrome and Firefox is that you’ll stay on that channel for automatic updates too, so latest beta/dev releases will get pushed out to you.)
Thanks – so yeah; if your going to have experimental elements, attributes and properties, what are they doing in the ‘stable’/public releases? That suggestion makes perfect sense in that light; it belongs in the above listed versions – beta/nightly/dev – and nowhere else.
Eric Meyer doesn’t think this vendor prefix thing will end well.
How depressing. When I got into web design 4 or 5 years ago, I discovered that this discipline was emerging from a dark age of browser wars and non-standardization. I’ve watched as browsers have improved—even IE—to the point where we can be pretty confident that a good design will hold up cross browser. And I was inspired by web standards, and progressive enhancement, and so on …
And then came HTML5, and the premature rush to use it, with sites drugged to the eyeballs with life-supporting JS. And now this crazy rush to befoul the web to satiate the gee-ain’t-it-cool brigade that is high on fanciful vendor prefixes. As if our world weren’t already choking on fads, fashions and tabloid noise.
Sigh. Well, there isn’t much I can do about it, but as an act of protest, I’m resolved never again to use vendor prefixes, but just use things like border-radius, and not worry if it’s not supported by a lot of browsers.
Aaaaand there we are. Opera confirms webkit prefix usage. Because they had no other choice.
Thanks, mobile web developers and large corporate clients who thought mobile==iPhone app! You’ve made the world a crappier place for the rest of us, and broken what use there was for browser prefixes.
Meh. That’s weak. And it’s even weaker that they choose to support only “some” of the widely used prefixes. That’s neither here nor there and will cause even more problems down the line. Either be consequent or don’t change anything at all.
The “some” was Tantek’s idea: support the essential-to-not-brokenness ones, not the gee-whiz-look-at-iDesign ones. Likely ideally ones that Opera already supports under the -o prefix or as non-prefixed properties, and possibly a few that might otherwise remain webkit-only.
… which is exactly why they blame site authors for the move – and it IS where it belongs. There are so many tutorials out there right now who claim to tell you about CSS3, but then only use the -webkit, or if you’re lucky both it and -moz…
WITHOUT EVEN LISTING THE PREFIXLESS VERSION!!! In which case, they aren’t even ABOUT CSS3… they’re about browser specific properties. You’ll constantly see text where it’s -webkit-this and -webkit-that, then at the end they MIGHT mention -moz or occasionally -o and -ms – again without mentioning adding the prefixless versions.
Developers, the majority are their own worse enemy – hardly surprising when the majority of people who call themselves ‘experts’ at making websites online don’t even seem to know how to use simple tags like LABEL, TH or numbered headings properly. When they can’t even get markup right and have their heads permanently wedged up 1998’s backside (hence HTML 5 - the new transitional) is it any shock we have browser prefixes being talked about BEFORE the prefixless actual CSS3 properties? Again, Welcome to your 1998 behavior much as Mallory had in her original post, “Best viewed in ____”.
Progress… that’s what it is. RIGHT.
Goes to show how much anyone who matters cares about opinions here no matter how rude they are. If you don’t embrace changes that you may not agree with you will become obsolete. I guess that doesn’t matter for some because they already are though…
Some of these prefixes are simply added to the webkit rendering engine without any mention to the Working Groups or anyone else, and sometimes without documentation. And webkit trying out a property without proposing it to the spec writers doesn’t mean everyone else should run out and try to reverse engineer it. What a waste of developer time. Those prefixes were there for a reason. Unfortunately they were released to the general developer public and then of course abused because that’s what the masses do to things. Makes me sound like an elitist but I’m so pissed right now…
Why am I hearing ol’ FrankenSteve screaming DEVELOPERS! DEVELOPERS! DEVELOPERS! DEVELOPERS! ?