empath: "I'm failing to see a problem here. If W3C and the other browser makers had their shit together, they'd have either gotten those features into the standard, or they'd have implemented them already."
You can say this about any of the features that IE offered that were half-assed implemented. See MS's Msxml2.XMLHTTP
I'm not convinced at all that standards bodies arguing in committees produces innovation in a way that is better in the long run than popular vendors putting out their own stuff and letting their competition copy them to stay compatible.
Standards for the web should be about codifying things that are already implemented and widely adopted, not for handcuffing browser developers and web developers so that they can't use anything that isn't already in the standard.
That "HTML5" has taken six years to become a "standard recommendation" (it is still not an approved, official W3C standard, and won't be until at least 2014) is a huge disservice to the evolution of the internet.
The fact that in 2012 people are still arguing about how to implement something as basic as embedding a video in a HTML page is a good example of how backwards it is to expect a standards committee to do a good job driving innovation.
"It’s never a good thing for there to be homogeneity in the experimentation phase. The explicit goal of the prefixes system is to enable diversity of early opinion and fast coalescing around the best answer, thereby enabling the writing of a standard which is likely to need less revising and iteration. Diversity provides some value, the market tests the alternatives, and we deliver the most value we can over time through the standard version. It has always been thus, but prefixes make it less risky…assuming we don’t start stepping on everyone else’s toes.
"...we have much bigger fish that need frying, and stat. Prefixes do work, they’re essential to delivering a future platform that can compete with native alternatives, and yes, they should be torn down at the same pace they’re erected."
The stupid thing about this whole debate is that it’s only really an issue because Mozilla is flustered about people selecting the Webkit-specific properties for their sites, and Mozilla is responding by making their browser respond to someone else’s vendor prefixes.
Daniel Glazman’s suggested approach is the right one and I think it’s being misunderstood in this thread: Mozilla’s response should be to ensure that every -webkit- property they want to support works as a -moz- property, and then target web developers with a search/replace campaign showing how easy it is to add the additional property, while at the same time working with the W3C to ensure that the prefixed properties are suitable for adoption as non-prefixed standards.
However, you can still (cautiously) use bleeding-edge features. Just don't depend on them, don't use vendor-specific prefixes in your raw CSS, and try to add them at runtime if possible. Use feature detection to selectively load polyfills and add vendor-specific prefixes to the CSS where necesary on a browser-by-browser basis so that new features are supported, and vendor-specific prefixes are added. If the bleeding-edge feature you're using has been standardized, and is supported (as a standard) in the user's browser, the feature detection script does nothing, and everyone is happy.
Ideally, you'd fetch these scripts from a reliable CDN so that they're continuously updated/maintained by developer, and also cached from site to site.
That's ridiculous. There's nothing wrong with implementing -webkit properties. Including multiple tags with the same data just wastes bytes. Maybe add an -draft-/-beta- prefix or something for experimental/nonstandard features.
Now, what about the related argument that Mozilla & Co. are only going to be doing this for properties which are “stable” (nevermind their actual standardization status)? The argument says that because something hasn’t changed in another vendor’s prefixed version in a while, it must be safe to squat on. Not only is this (again) incredibly short-sighted, it says that instead of forcing a standard over the line and clobbering both developers and other vendors with the dreaded label of “proprietary” (the usual and effective tactic in this situation), they’re instead willing to claim ownership and therefore blame for the spread of this soon-to-be-proprietary stuff, all the while punting on having an independent opinion about how the features should be structured and giving up on the standards process…and all for what?
If the reasoning behind prefixes is to set up and tear down large-scale experiments, iterate, and collect feedback then Lea’s -prefix-free approach and PPK’s -alpha-*/-beta-* proposals are equally counter-productive and should be avoided at all costs. Making prefixes less painful to use reduces the natural incentives for migrating to a standard while blindly assuming the same right-hand for a future standard version as we have for some prefixed versions is plainly idiotic. What were they thinking?
If the reasoning behind prefixes is to set up and tear down large-scale experiments, iterate, and collect feedback then Lea’s -prefix-free approach and PPK’s
That sounds good? Just reading that sentence exhausts me.
Also, why not just load the entire layout engine? Because then you’d be implementing Flash, and we all know how awesome that was.
« Older Errant Signal is one man's blog about games, where... | Who Will Run the Frog Hospital... Newer »
This thread has been archived and is closed to new comments
Buy a Shirt