When I first became involved with The Web Standards Project I was, like most of my peers, either building two completely different sites to support the version 4 behemoths – Internet Explorer and Netscape, or making a decision as to which browser people should use to view the site.

Internet Explorer 6, despite all of the well known issues, was a breath of fresh air. We could use a lot of CSS2, we could lay out our pages using CSS, and many people decided that Internet Explorer was the browser they were going to support. This led to a raft of “only works in Internet Explorer” sites and applications, the reason why we are still stuck with IE6 today.

Ten years later. In many ways we are in the place that we wanted to be, when we were campaigning for web standards adoption by developers and browser manufacturers. Our browsers do support W3C specifications. We don’t have rafts of crazy bugs in standard features or vendor specific implementations of those features that vary wildly. I can build a complex layout and load it up in Internet Explorer 9, the latest Firefox, Opera, Safari and Chrome and it all look pretty much the same. This is what we were asking for.

It could not be said however, that all browsers are equal in 2012. Some have moved more quickly to implement parts of the CSS3 specification even when they are just at Working Draft status. Browsers have implemented these new features using Vendor Prefixes, enabling them to implement a feature that might change as it goes through the W3C process. Vendor Prefixes to some extent have helped to prevent the situation arising again where we have a standard feature implemented in different ways by different browsers. Thinking back over our history I believe that to be a good thing.

Whether you like Vendor Prefixes or not, we have a problem. Due to the rise in mobile browser usage, and many of those mobile browsers being based on WebKit, many developers have decided to essentially only use the -webkit- prefix, even for properties that have been implemented by other browsers. Today Daniel Glazman, W3C CSS Working Group Co-chairman, wrote a blog post, Call for action: the open web needs you now!. He, and the W3C CSS Working Group is concerned that if this continues, other browser manufacturers will simply start implementing the -webkit prefix.

This approach seems very likely. If other browser manufacturers have implemented these features under their own prefix, yet web developers do not use those prefixes, then it makes their browsers look less capable than those based on WebKit. By simply implementing the -webkit prefix sites will look better in these browsers.

If this happens then we end up with a web once again controlled by one browser manufacturer. Once again we run the risk of having sites built only for one platform, and finding it very hard to get that platform to go away if things move on. Please read the above post. Please think about it every time you have to ensure your site works well in a browser that is over ten years old. Please do your bit to prevent -webkit becoming a de facto standard and hurting the Open Web.

How can you help?

1. Read the original post – Call for action: the open web needs you now!
2. If you have sites that test for WebKit browsers or only implement -webkit prefixes please take some time and update any -webkit-only property to use the other vendor-specific prefixes and non-prefixed versions.
3. Sign this petition & pledge telling browser makers not to implement the -webkit-* vendor prefix and promising to update the sites under your control.
4. Remove -webkit-only testing from repositories on GitHub – Pre-fix the web!

More commentary on the issue

• Remy Sharp: Vendor Prefixes about to go South
• Gilles Vandenoostende: On Vendor Prefixes
• Christian Heilmann: Now vendor prefixes have become a problem, want to help fix it?
• Bruce Lawson: On the Vendor Prefixes Problem
• Aaron Gustafson: This must not happen!
• Eric Meyer: Unfixed

Le monopole de fait d’un navigateur ou d’un moteur de rendu est nuisible au Web ouvert…

Il y a dix ans, les parts de marché d’Internet Explorer étaient écrasantes. Aujourd’hui, WebKit est un moteur de rendu particulièrement bien répandu….

Agreed, and like most of us designers/developers, I share your concern about a return to the browser-specific-web of years gone past.

Nevertheless, the heart of the problem is the slowness of the W3. We’re essentially chiding webkit for it’s fast turnaround of new design features, often faster than Mozilla and Opera can turn out their own CSS features (I’m talking CSS, not JavaScript, where the track record is different). These prefixes were needed because my industry needs are moving faster than the standards body implementation and approval.

I know most of us have little pull, if any, with the W3, but the root of the problem is them. What can we do to speed W3′s adoption of design principles? Do we need another WHATWG?

On top of that, Mozilla and Opera adopting -webkit prefixes seems a big tell. If people are adopting -webkit prefixes solely, are these browsers attempting to stem the bleeding of their user base? Is the adoption of -webkit prefixes a show of their lack progression?

My point is, understanding the root problem is important to theorize a more permanent solutions.

Glazou set me straight a little online – noting that WebKit specifically has not submitted to the W3. I’d be interested why this is – politics? Communication? Ego? Monopoly control? We maybe past that being helpful to the cause, but it’s certainly a factor in solving or preventing future issues.

Brady, for at least some of the properties involved the best guess anyone has is that Apple has patents covering the implementation and would have to disclose and license those if the property were to be standardized. And they don’t want to do that.

Odd thing is WebKit is one of the buggiest rendering engines one can use despite it’s otherwise high level of standards compliance.

I’ve seen lots of people post horrendously unprofessional comments on other Microsoft and Mozilla’s blogs telling them to drop their respective engines.

The main problem however is not these people though rapid releases that is encouraging this behavior. I have people visiting my site waiting for DOM based browser detection to be updated for nightly builds of Firefox and developer builds of Chrome even though there is absolutely no difference between Firefox Aurora/Nightly and Chrome Beta/Developer.

Normal people INCLUDING highly technical people like myself do not need five simultaneously developers versions of Firefox at a given time, nearly a dozen releases per year with barely enough committed changes to warrant a security update much less a full-fledged version number increment (every 42 days!). I understand Google’s initial approach with rapid release and I understand about the slow progress coming from the W3C though there needs to be some serious self-moderation. New versions of browsers simply have no justification for a new release more than once every half a year. If someone with a small mentality insists on testing the absolute latest and greatest then they can go mess with a nightly/developer build.

In fact rapid release schedule is the overwhelming factor of why people DON’T upgrade! Since Firefox 4 and Mozilla’s outrageous and very likely drug-induced decision to copy Microsoft’s anti-intuitive GUI they forced it on users by MANUALLY overriding USER-SET PREFERENCES! Then they brought their hand back to second face slap everyone by moving to the 42 day release cycle alienating EVERYONE. I have to maintain profiles for each version without allowing updates so I have to manually download/install/update to preserve older “irrelevant” versions. Don’t even get me started on Chrome, everyone sporting a Droid is using Chrome 5 and just try setting up two or more versions of Chrome to work side-by-side.

Don’t bother with the seeds if you can’t deal with the weeds. Rapid-release is THE root of the problem stopping short of the political agendas behind the current self-destructive move by most browser vendors. Anyone who says otherwise probably only cares about appealing to other technical people and at the end of the day that is the sort of mentality that warms up to self-destructive release policies.

[...] So far all sorts of odd solutions have been put forwards. [...]

Agree that the issue is a problem, but there are glaring differences. IE went ahead without any consultation with anyone, despite there being a good implementation or a reason not to do x. Webkit works on multiple platforms. W3C have been pondering these implementations for years, and still nothing to show for it.

Put out a standard that is adequate and most browsers will follow. Product always beats proposals. The problem is the reverse of the IE years; the standards are lagging the technology.

[...] folks in this this ain’t good crowd: Rachel Andrew, Bruce Lawson, and Gilles [...]

FWIW I’ve committed change proposals to the SVN repository that holds all the SPIP galaxy (CMS, plugins, templates).

http://zone.spip.org/trac/spip-zone/changeset/59092

Message in French reads:
+/*
+
+ ATTENTION
+ L’usage de proprietes -webkit-* sans leurs contreparties
+ (-o-*, -moz-*, etc.) est fortement deconseille !
+ cf. http://www.webstandards.org/2012/02/09/call-for-action-on-vendor-prefixes/
+
+ Prenez le temps de corriger s’il vous plait : les proprietes CSS prefixees ne sont en theorie
+ destinees qu’a des fins de test.
+
+*/

Which means: BEWARE: using -webkit-* properties without any counterpart is strongly not recommended. Take the time to correct please: prefixed CSS properties are only theoretically for testing purposes.

All in all the SPIP community is very respectful of diversity: out of several tens of thousands of files, I found only a dozen lonely -webkit-* rules. :)

[...] Andrew of the web standards project generally agrees with Glazman writing, “once again we run the risk of having sites built only for one platform, and [will] find it [...]

[...] Do You Exclusively Use webkit Prefixes? Now Vendor Prefixes Have Become a Problem Call For Action On Vendor Prefixes [...]

Whether you like Vendor Prefixes or not, we have a problem. Due to the rise in mobile browser usage, and many of those mobile browsers being based on WebKit, many developers have decided to essentially only use the -webkit- prefix, even for properties that have been implemented by other browsers. Today Daniel Glazman, W3C CSS Working Group Co-chairman, wrote a blog post

Really a informative post. I agreed that most of designers and developers are understanding the root problem is important to theorize a more permanent solutions.

No, that’s the wrong approach. Telling browser vendors to do the wrong thing because people are doing things they should not? If someone isn’t doing their job competently they either correct their actions or they should eventually get fired. Only using the WebKit prefix shows that the person generating the code is incompetent. Two wrongs don’t make a right.

I have implemented a change in our corporate website to supporting web standards browsers with graceful degradation for all others. We have removed the browsers and browser version we support and have replaced it with a comment that simply says we support web standards browsers.

It would be fantastic if you could provide a page with a list of browsers that are deemed by you to be compliant so that we can direct users to the list. I believe this would helpful to other large corporations as well.

Cheers

What kind of programmers is developing web browsers? When ever I do something I follow the standards. I know that the people that made the standards are probably smarter than me and that’s why they did something in a way that I think is insane.

Every programmer should have that as a rule of thumb: Follow the standards or make a standard your self.

I know most of us have little pull, if any, with the W3, but the root of the problem is them. What can we do to speed W3′s adoption of design principles? Do we need another WHATWG?