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. See webkit's original proprietary implementation of gradients: it was a bit of a cock-up and turned out to be very hard to use correctly. Look at the early webfont implementations that still hang around.
You can say this about any of the features that IE offered that were half-assed implemented. See MS's Msxml2.XMLHTTPMicrosoft's features were implemented using MS-centric technologies whereas WebKit's CSS features are created to be a cross-platform and cross-browser standard. I.e. the W3C could never take MS's features and make them a standard, but they can easily take the WebKit syntax as the new standard.
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.Generally speaking, innovation is not what standards are for.
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.The question here is what “widely adopted” means. Vendor prefixes are intended to address this by making it possible for different developers to approach problems in their own ways before nagging the standards committees. Border-radius is an excellent example, where the -moz-, -webkit- and -o- versions all converged on a shared syntax that was adopted as a single “border-radius” property.
lynx.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.See also WHATWG, the original group that formed in 2004 to work around the completely useless W3C organization. Without them there'd be no HTML5.
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.Much of the argument is focused on encodings and software patents. This is not a herp-derp-what-do-we-do ivory tower debate, it’s a real legitimate argument among competing businesses bristling with patent portfolios and still trying to meet someplace in the middle. If all you want to do is throw video in a browser, Macromedia had an answer for you a decade ago and Youtube took it all the way to the bank. If you want to do it in a way that’s usable by new technologies outside of cumbersome licensing deals, you get the debate that W3C is having now.
border-radius: 2px;-webkit-border-radius: 2px;
-moz-border-radius: 2px;
border-radius: 2px;"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.posted by weston at 8:54 PM on February 15 [1 favorite]
"...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.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.
...
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.
gradient: ... and have it translated to an appropriate tag
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.I've mentioned it before, but why not just load the entire layout engine? I mean google has Chrome Frame which lets you use webkit in IE6. It's a separate download and works as a plugin. But if a browser supports canvas, you could in theory do all the layout in javascript. Store it a central location, like jquery is today and it will sit in people's caches. And you'll be able to write your own extensions for whatever you want. Dynamic shadows? Blur? 3d transformations? multiplication and addition of images rather then just alpha blending? Hexagonal boxes instead of square ones? Go nuts!
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.He’s plainly biased, but I agree with Alex Russell’s opinion on why Mozilla should avoid implementing the -webkit properties:
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?In a world where it costs more than two megabytes of data transfer to view a single tweet on Twitter.com, the wasted bytes of extra selectors seem immaterial. More to the point, it only makes sense for Mozilla to borrow prefixes from Webkit if Mozilla agrees that Webkit has done “the right-hand side” correctly (e.g the actual syntax for describing a gradient), and once you agree to that you’re two steps away from getting the dumb thing through committee and into a standard.
…
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’sLook, obviously developers can make their pages work in mozilla and webkit both, simply by adding -moz- versions of the tags. but they're not going to If they were going to develop the right way, they would have done it. The problem with the idea that you can just "educate developers" is that it just won't work
That sounds good? Just reading that sentence exhausts me.It was less exhausting then reading all of this - If you added all those 'polyfills' to a page you'd probably just be better off just using pure canvas.
Also, why not just load the entire layout engine? Because then you’d be implementing Flash, and we all know how awesome that was.Yes, except without the compatibility problems, lack of platform support, privacy issues, or security vulnerabilities.
« 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
I guess this shouldn't be unexpected, but it certainly is disappointing.
posted by mcstayinskool at 11:06 AM on February 15 [2 favorites]