The Open Web Needs You Now
glazman.org
glazman.org
And it is often the case that you're using an experimental style that's only available on one browser family which is then adopted at a later date by other browsers. This method would mean that as soon as other browsers adopted the style it would render without any changes or additions required on the web site.
I think it is instructive to examine how the incentives line up for various players here.
* For high-marketshare browser engines:
Prefixes are great. It allows them to release whatever new stuff they like whilst avoiding the bad rap that Microsoft got for releasing proprietary things like XMLHttpRequest. This makes them look innovative, which gets them lots of press. It also makes it impossible (thorugh the "you won't implement other people's prefixed stuff" social contract) for their competitors to implement the new things and, even once the others do implement, the existing content won't work, helping protect their marketshare. Of course you can't ever drop the prefixed property, but there is no social stigma for this, so it isn't a big deal.
* For leading-edge web designers:
Using prefixed properties in demos is a no-brainer. They allow you to create novel effects which you can then discuss in your blog, so improving your reputation and social standing in a competitive market. The fact that the sites won't work in multiple browsers is irrelevant to you because you are mainly targeting other designers who will have a full set of browsers installed.
* For web designers working on client projects
Using prefixed properties is attractive, particularly on platforms where there is an unhealthy balance of rendering engines. It allows you to make designs that look like the leading edge demos — indeed your clients may be demanding this. You can rely on vendors never dropping prefixes and by the time the next major shift in browser marketshare occurs you probably won't have to maintian the site anyway.
* For the CSS WG:
Well obviously this is composed mainly of people from the other groups. But the main argument they use in favour of prefixing is that it allows them an unbounded amount of time to tinker with new proposals whilst providing a convenient excuse to ignore the legacy content that has built up in the meantime. This means that in the future there might be fewer people who have WTF-why-is-it-like-this moments when using CSS and decide to blame the working group. Therefore they think that prefixes are good.
* For non-dominant-marketshare engines:
Prefixes suck. You put a huge effort into implementing some new feature that someone else released under a prefix, release it, and it probably doesn't cause a single site to work better. You have to hope that authors start to include your prefix (even though there are probably legacy tutorials that don't mention it) or already included it by adopting the scattergun "add all the prefixes I can think of and hope the syntax doesn't change" methodology. This affects your ability to attract new users.
* For new entrants to the market:
This is an extreme case of the above. Prefixes are an enormous barrier to entry.
* For end users:
Prefixes suck. They increase the difficulty of changing browsers because they increase the chance that sites will break. This makes it harder to choose your browser on the basis of features like UI, privacy controls, security performance, etc.
So we have a solution that is good for vendors with dominant market positions and bad for users. That seems pretty anti-open-web to me. In the long term, I think the solution is to get over the idea that it is OK to keep fiddling with features once there is content that depends on the existing implementation; i.e. you have two options: "don't ship" or "ship and accept the legacy you create". That means no prefixes in CSS, just like we don't have them in HTML.
In the short term, the situation for non-WebKit browsers on mobile has become critical. If a decade ago browsers hadn't decided to implement the Microsoft-proprietary features in a way that was compatible with the legacy, we might all be stuck with IE6 today. If Safari hadn't added "like Gecko" to their UA string they might found it much harder to gain traction. History suggests that when browsers feel the need to take some action to improve competition, it is good for the long term health of the web. So it is here.
Of my biased selection of wife, father, mother, brother, I will frequently see them browsing in IE or FireFox and seeing terrible, terrible pages and not really caring or even noticing. They don't think, "huh, I bet this site would look better with a border-radius... didn't it have one in chrome?"
Edit: To clarify. I think I'm just questioning whether this is bad for these users. I mean, if they don't perceive the issue, is it bad? They are getting a lesser experience, but does that matter?
This may be related to why I don't really care about the few users who use Opera -- it is just not worth it.
Case and point: Border radius and linear gradients made things better for EVERYONE. Developers didn't have to create the html/js/css/image mess just to create rounded corners. This meant less code, less images, less css, which also translates to snappier websites. (and users like that.. there are studies that prove that) This also meant that, as a company, we decided that IE had to live with a degraded experience until they made their browsers competitive with all the others. (and users had access to said browsers)
As a Front End Engineer, I find it insulting that you suggest we are doing it for "fun" or to make our resume look better. This makes our lives better, and we have to consciously decide who gets a degraded experience and who gets the better experience. I think we call that "graceful degradation" or "progressive enhancement". You stated: "They allow you to create novel effects which you can then discuss in your blog", if these are novel effects then why do...
You state that websites are "broken" for non-webkit browsers on mobile. Well then maybe my definition of broken and yours differ. I say a "broken website" is one where the content CANNOT be consumed by the end users. Also if the end users have functionality that is broken, and therefore prevents them from accessing / modifying content.
I DO NOT think broken means, degraded visual experience. When we decided that IE would get square corners, and flat background (instead of rounded corners and linear gradient backgrounds), we knew that IE would still be consuming the content just the same.
Therefore, please inform me which -webkit prefixed css is causing the breakage I define. (where consumers are blocked from the content)
"This looks bad", doesn't count.
Now granted, I'll give you that as developers, we should be using all prefixes that are supported. It might be a pain in the ass, but that's our job. I'm with you there, and I'm going through my current css to find if any are missing -ms, -o, -moz and the default fallback css. Considering I use a preprocessor for my css, I'm pretty safe, except on my blog, (which has no preprocessor yet). I suggest all of us developers do the same. But this is a "nice to have" not the "the mobile web is broken!" as browser vendors are rallying.
Again, if you can prove to me, that the web is broken under my definition, I will take my words back for those specific css rules according to their proliferation on the web.
glazou: A long time ago, Mozilla had an Evangelism team that would call up the website owners and ask them to change.
Florian: Opera has a large and active one, but it does not scale. ...
Florian, Sylvain: Evangelism has failed.
glazou: Have you tried pinging the WASP about that? Other activists of web standards?
sylvaing: If MS can't scale to handle this, you think WASP can?
tantek: Opposite is happening right now. Web standards activists are teaching people to use -webkit-
When the spec changes, the updated feature could be implemented as '-dev-2-', '-dev-3-' and so on. W3C would just need to introduce consistent numbering scheme that could be followed by all vendors.
Vendor prefixes should be reserved only for features that are not standardized in any way.
I can't remember any specific examples off the top of my head but I do remember that some of the -webkit and -moz prefixes were ever so slightly different.
I think once it made it into the draft most browsers start supporting it using the standard css without any prefix.
Luckily nice tools exist to automatize the boring prefixing (even for us who don't use LESS/SASS style preprocessors):
$ pip install cssprefixer
Although IE9 supports standards well on paper, it's shocking how many sites aimed at "webby" sorts of people don't work on IE9.
edit: Why not move to another browser with better standards support like firefox or opera?
So if you use IE when you are not forced to, you drag the rest of us down. And that frankly isn't cool.
But only for people on Win7. Which does nothing at all for those who still use xp.
http://lea.verou.me/2011/11/vendor-prefixes-have-failed-what...
1. https://news.ycombinator.com/item?id=3566329
2. search by image, search background, google plus notifications, ...
That is a terrible, terrible idea and will never (and should never) happen. Sure, add support for the un-prefixed property. But don't break existing sites.
That mentality is what gave us XHTML, and we all know how that went. I guess it is the IE6 days all over again after all...
Don't forget that those sites are already, by design of the owners, broken for any non-webkit browser.
The only way for this to change, is to build into the spec that once a feature is no longer experimental its vendor specific tag name gets deprecated and then removed and the deprecation warning needs to show up in the web inspector / firebug. Otherwise devs will literally think if it ain't broke don't fix it.
This is a job for the W3C. They have the task now of convincing browser manufacturers to implement this and to really start picking up the pace standardizing the web. There is never going to be enough public outcry to get people to stop using the webkit only prefixes unless other browser install numbers pick up.
I understood the outcry from W3C being caused by Opera and Mozilla declaring that this is exactly what they will be doing. The situation is particularly bleak in mobile devices due to Android + iPhone + iPad WebKit monopolies.
It'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.
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.
I'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.
It'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.
Here, the problem isn't one of capability. The other browsers can (and have indicated that they will) implement the webkit syntax and feature set.
The W3C is simply clinging to a failed spec "because its the spec". As was made clear in the OP's plea, the W3C needs browsers to observe their specs to remain relevant and avoid circumvention.
If the webkit extensions aren't technically or legally barred from implementation, there's no reason that other browsers shouldn't simply adapt. Aside from the W3C's own self-interest, the only "problem" here is that the market is dictating the solution, instead of a panel of self-professed governors.
And I am all for letting MS back in, at such time that they:
1) Decouple their browser updates from their OS. 2) Make it automatically update to the latest version, just like Firefox and Chrome. It should be possible to turn this of, just like Chrome, but not on a group basis.
Because we really, really need ms to decouple their browser from their OS and institute forced upgrades ala Chrome so that we never again have to deal with outdated shit.
Seems fair that we ban their browser until they play along.
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.
In terms of what is delivered in each update, Chrome is ahead. For instance, IndexedDB in Firefox at one stage was an order of magnitude slower than Chrome for several months and this may still be the case, Mozilla's implementation being based on SQLite, with Chrome on LevelDB. There is the dubious history of WebSQL, and the FileSystem API. Many of the new useful CSS features have taken far longer in Firefox. And then there is the similar rendering across WebKit browsers. Firefox renders some things like line-height completely differently.