Dustin Curtis writes in his article Web Standards:
Several years ago, WebKit began including experimental CSS features in the open source project. Because the features were not officially part of the CSS standard, the developers of WebKit added the prefix -webkit to the experimental stylesheet declarations. This ensured that they did not affect existing or future declarations, but also meant that they worked only in WebKit. Now, years later, the CSS Working Group is trying to reverse the “damage” done to the web by sites that use WebKit-specific features, suggesting that if it does not happen, “it will kill our standardization process.”
I hope it does kill the W3C and CSS Working Group standardization process.
He then continues to quote the previously linked Call for action.
I repeat:
Now, years later, the CSS Working Group is trying to reverse the “damage” done to the web by sites that use WebKit-specific features, suggesting that if it does not happen, “it will kill our standardization process.”
This is fundamentally wrong! The whole issue is not about sites using -webkit-*, but sites that sniff out the user agent and blog sites that are not (Mobile)Safari, Opera Mini (which I personally don’t like, but of cause support) for example.
Basically: the damage was not done by the webkit team directly, but by “designers” and “coders” that have previously made “Internet Explorer” only sites, after receiving an iPad for christmas 2010… Of cause Apple has helped too… (Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies).
Curtis continues:
The co-chairman of the CSS Working Group, Daniel Glazman, posted an appeal to his website, titled, “CALL FOR ACTION: THE OPEN WEB NEEDS YOU NOW”:
WebKit, the rendering engine at the heart of Safari and Chrome, living in iPhones, iPads and Android devices, is now the over-dominant browser on the mobile Web and technically, the mobile Web is full of works-only-in-WebKit web sites while other browsers and their users are crying. […]
Without your help, without a strong reaction, this can lead to one thing only and we’re dangerously not far from there: other browsers will start supporting/implementing themselves the -webkit-* prefix, turning one single implementation into a new world-wide standard. It will turn a market share into a de facto standard, a single implementation into a world-wide monopoly. Again. It will kill our standardization process. That’s not a question of if, that’s a question of when. […]
I am also asking the browser vendors behind WebKit, namely Apple and Google, to submit as soon as possible to the CSS Working Group complete technical proposals for the proprietary CSS-like properties they have let the whole world use in iOS and Android devices, harming the Open Web.
The reason the -webkit prefix was necessary is simple: the W3C and the CSS Working Group are ineffective, failed organizations. The web is an evolving, living platform, and it is impossible to effectively define versioned standards separated by 8-10 years of political discussion. 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. If the web is going to evolve on par with the rest of the technology industry, the standardization process has to change.
Well, actually:
I won’t cover anything approaching all of the features found in CSS3, as, well, I’d be here until Christmas and miss Coronation Street. For now, I will get down to business and look at some of the basic CSS3 yumminess we all know and love, and how to make it as cross-browser as possible:
Linear gradients
Drop shadows
Opacity
Rounded corners
Web fonts
[…]
LINEAR GRADIENTS
Linear gradients are currently supported across all of the newest browsers with vendor prefixes. We therefore need to add a few lines to get them working cross browser. For my blingtastic example, I have added a white gradient going diagonally across the box at 60 degrees to give the box a nice bit of texture:
background-image: -ms-linear-gradient(60deg, rgba(255,255,255,0), rgba(255,255,255,0.2) 50%, rgba(255,255,255,0));
background-image: -moz-linear-gradient(60deg, rgba(255,255,255,0), rgba(255,255,255,0.2) 50%, rgba(255,255,255,0));
background-image: -o-linear-gradient(60deg, rgba(255,255,255,0), rgba(255,255,255,0.2) 50%, rgba(255,255,255,0));
background-image: -webkit-linear-gradient(60deg, rgba(255,255,255,0), rgba(255,255,255,0.2) 50%, rgba(255,255,255,0));
background-image: linear-gradient(60deg, rgba(255,255,255,0), rgba(255,255,255,0.2) 50%, rgba(255,255,255,0));
[emphases are mine.]
from CSS3 Bling in the Real World, A List Apart, Issue 311, JULY 26, 2011.
I feel this is a prime example, which shows how
- all vendors can work on a standard, each with their own prefex and maybe even own syntax.
- it show’s how to do it right: target everybody, not just 1 browser.
and curtis:
The features WebKit has recently implemented with the -webkit prefix are the biggest enhancements to CSS in a decade, yet the co-chair of the Working Group condescendingly calls them “CSS-like properties”. If the developers of WebKit had waited to define and approve another version of the official CSS standard, it would have taken yet another decade. Without the experimental features in WebKit, the web would be a markedly worse place. I use many WebKit specific css properties on this site, and the Kudos button (to the right of each article title) is constructed almost entirely with CSS animations first defined and built for WebKit.
Most people on the web can surly agree that experimental features with prefixes are great! For me it’s even on of the reasons to stay in the industry, because suddenly it’s fun again to make websites!
And no one (as far as I know, I am open to corrections!) has ever asked to wait and not implement a new feature with prefixes to see how it works!
Sure, many things have come up first in Webkit, but not all. Other vendors have crafted great things like @font-face (first in IE4!!) or implemented them quicker then others.
Despide his statement that he uses many Webkit specific features, he still uses cross browser (vendor prefixed) code. Good.
Glazman’s blog post is a sad side effect of an ineffective, closed organization. It is an admission of failure. Despite having representatives from all of the major browser developers, the Working Group has not been able come up with a solution. What does that say about the organization?
If the CSS working group would be as closed as many say, it would not work with the browser vendors! It would just hit the wall, as the W3C did with XHTML 2. It’s not, it’s working with vendors! And Curtis left it out, but Glazman also writes in that very same post:
I am also asking the browser vendors behind WebKit, namely Apple and Google, to submit as soon as possible to the CSS Working Group complete technical proposals for the proprietary CSS-like properties they have let the whole world use in iOS and Android devices, harming the Open Web. An example of such a property is -webkit-text-size-adjust. Please note the Apple representative to the CSS WG said he’ll look at the possibility to have proposals submitted for a list of such properties. If these properties are so well implemented and so useful to the mobile Web, they became de facto standards ; let’s turn them as soon as possible into de jure standards through W3C standardization. I am also calling Apple and Google to remove support for the “experimental” versions of a property when the final one is implemented and shipped. We, and that we represents the whole Web Industry, cannot let the architecture of the Web become unsafe and unreliable keeping forever vendor prefixes that should be gone. That is harmful and this is your responsibility, because you could provide mandatory software updates to your users. The Open Web does not have to suffer of such a decision.
He asks the Webkit team to open webkit-only properties for the standard process! Closed??
Curtis:
The Future
At some point, and I hope very soon, the way web standards are defined is going to have to change. The ten year gap of bickering and bureaucracy between each official W3C standard is not sustainable. Browser manufacturers, hindered by the lack of progress on standards, are going to progress independently. It will become a serious problem.
This is simply not true: the problem are the users and makers! If a browser maker produces a widely used feature, but does not open it to he CSS WG, it’s not the W3C’s flaw, but a problem with users and producers!
The web is not finished. It needs rapid evolution to find itself. The first step is to create a standards body that encourages the rapid innovation that we need.
This standards body does already exist: the W3C CSS WG!
I am sad that this quite flawed rant had been republished (I got the link from the .net magazine news letter…). So far, I have not seen a follow up on curtis blog that would address the issues.
To sum up:
Dear Curtis-san, the issue is not the W3C CSS WG, but users who actively hinder an open web, with open standards. If things would move in the direction you suggest, we would end up with a world where everybody either uses webkit as render engine or use -webkit-* to complete uselessness.
Please read the articles I have linked here, or simply read the current issue of a list apart.
Cheers,
taotsu
