For the current webkit- mess, it's probably best to just have the vendors implement each others prefixes on a case-by-case basis (when you know the semantics are the same). There are way fewer browser vendors than there are website developers, and it's much easier to get them all in a room to agree on something.
The Open Web Needs You Now
21–30 of 61 posts
Re: The Open Web Needs You Now
#22Re: The Open Web Needs You Now
#23What's the reason they even have to add a prefix? If all we end up doing is prefix the feature with 4 different ones, and then the actual feature name in case all else fail, it's pretty pointless. The browser should just implement the feature as it is spec'd and when it's finalized they can do the work to match the specs again. If we did that then nothing would break other than possibly some behavioral differences.
Re: The Open Web Needs You Now
#24It's bad enough that -webkit prefixes are putting Mozilla, Opera, and Microsoft in this position, but imagine what this situation could be doing now, or could do down the road, to innovation in this space? If history repeats itself and we end up with a browser monoculture again, how can a new contender enter the browser space if pages are full of badly documented, unspecified vendor prefixes?
From the outside, vendor prefixes look like they originated as a passive response to the slowness of W3C standardization and the behavior of W3C participants. When you look at some of the W3C minutes - http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.h... as an example - they are full of examples of participants who either do not realize their lack of knowledge or are actively attempting to hinder discussion. If it takes months or years to standardize a basic feature, should it be a surprise that frustrated browser developers roll a feature out behind a vendor prefix and the entire web adopts it as a de-facto standard? The presence of these vendor prefixes should have sounded alarm bells for everyone involved in web standardization, and action should have been taken to address it then and there. At this point, I'm not sure anything can be done except to attempt to reduce the damage.
As a web author, dealing with prefixes is miserable. Each vendor version of the prefix might have different accepted values or even have a slightly different name, and I have to go through and manually test in each browser. If I make changes to my CSS rules, I need to ensure that I update them all to match and deal with differences in syntax. The documentation for how to do this is spotty and it introduces a ton of room for mistakes in what should have been a simple part of the web development process.
As a user, prefixes are a disaster. I've got a fairly recent Android phone, and because Android is a fragmentation trainwreck, the stock browser on my phone is outdated and buggy and doesn't support lots of modern web content. To deal with this, I installed a third party browser from the Market, and I can use it to view modern web content successfully. Unfortunately, a large number of the sites I visit mess up useragent sniffing and serve me webkit-only CSS or even webkit-only JS. I don't have any options here; I can't surf the Real Internet on this phone.
Re: The Open Web Needs You Now
#25It's ridiculous at the moment when you have -o-feature, -moz-feature, -webkit-feature, -ms-feature, and feature, which take 2, 3, 4, or even 5 different syntaxes. W3C considers two implementations sufficient for standardisation, which this process gives.
I'd also have an automatic process for moving any vendor prefixed feature into being the standard after they have had it stable for 6 months, other implementations or no. A more predictable timescale would make these "experimental" features more realistically experimental and encourage standardisation.
Re: The Open Web Needs You Now
#26I'm huge WebKit fan (been since KDE 2), but I agree with the author that the current situation is problematic. (Although the case with IE6 was orders of magnitude worse and largely different in nature.) Luckily nice tools exist to automatize the boring prefixing (even for us who don't use LESS/SASS style preprocessors): $ pip install cssprefixer There is also a client-side solution, which I find suboptimal as a techn…
I was about to comment mentioning cssprefixer. Now I am thinking it might make sense to go around looking for sites that don't prefix properly and emailing the operators with the prefixed version. It might even be possible to do this in an automated fashion.
Re: The Open Web Needs You Now
#27I'd love to see a newsletter where the W3C announces feature support and even demos new techniques/tools. They're a standards org, sure, but their blowing it as far as getting this info out to the public is concerned.
Re: The Open Web Needs You Now
#28The other browsers have been moving too slowly in their update cycles and it is starting to show. The difference this time is that WebKit is open source.
Have you even read the linked article? using -webkit- prefixes but not the -o- and -moz- counterparts is just very bad CSS and has nothing to do with slow update circles anywhere.