The open web needs you *now* (Webkit the new IE6?)(glazman.org)
glazman.org
The open web needs you *now* (Webkit the new IE6?)
http://www.glazman.org/weblog/dotclear/index.php?post%2F2012%2F02%2F09%2FCALL-FOR-ACTION%3A-THE-OPEN-WEB-NEEDS-YOU-NOW
6 comments
We had decentralized web standards in the past, with browser vendors implementing new markup features on their (and, to a lesser extent, their users') whims rather than marching in lockstep with some "central governance" - the First Browser War, where Microsoft and Netscape were slinging it out for market dominance, adding new features as quickly as possible to gain more users and simultaneously create a captive market by way of incompatible markup. Yes, this gave us Javascript (if I understand my history correctly), but it also gave us such abominations as the "marquee" and "blink" tags, and no one who worked through those times as a web developer looks back on them fondly.
I am not saying the current situation is ideal, but it is better by leaps and bounds than what it used to be, and what you are proposing.
I am not saying the current situation is ideal, but it is better by leaps and bounds than what it used to be, and what you are proposing.
Browser prefixes are a great way for browser vendors and designers to experiment with new graphical elements. They're a good thing. But us hackers haven't caught up. It's been said before but I'll say it again: jQuery saves us from browser specific quirks in the DOM; we need an equivalent for CSS.
Last night I added Compass (http://compass-style.org/) to a Rails project I'm working on. It's a CSS pre-processor that takes care of generating browser specific style for you.
"@include border-radius(10px)" and you're done. All of the -webkit, -moz, -ms and -khtml prefixes are automatically generated. (Who knew there was a KDE prefix?) Same with gradients, inline-block, etc.
Last night I added Compass (http://compass-style.org/) to a Rails project I'm working on. It's a CSS pre-processor that takes care of generating browser specific style for you.
"@include border-radius(10px)" and you're done. All of the -webkit, -moz, -ms and -khtml prefixes are automatically generated. (Who knew there was a KDE prefix?) Same with gradients, inline-block, etc.
Life would be a lot easier if everyone just adopted WebKit for rendering HTML and CSS and just focus on the UI and features. Lack of a reference implementation and forcing everyone to implement their own version of HTML 5 + CSS 3 at their leisure is counter-productive and stalls adoption.
Chrome is my preferred browser because of the user experience, not because of its HTML rendering abilities. IE 9 has really good standards support, but the UI is the sole reason I don't use it. I couldn't care less about HTML 5 and CSS 3 support. Let's just stop fooling ourselves and standardise on WebKit for core HTML and CSS rendering.
Chrome is my preferred browser because of the user experience, not because of its HTML rendering abilities. IE 9 has really good standards support, but the UI is the sole reason I don't use it. I couldn't care less about HTML 5 and CSS 3 support. Let's just stop fooling ourselves and standardise on WebKit for core HTML and CSS rendering.
This is just plain silly:
-webkit-border-radius: 1px;
-moz-border-radius: 1px;
-ms-border-radius: 1px;
-o-border-radius: 1px;
border-radius: 1px;
If one vendor has something that is useful, let the others ask that vendor to make it default, let all vendors strip the vendor tag and get it over with. if you do not want to implement the rule, ignore it but do not cry when people leave your vendor prefix alone.
I can't be bothered with ever changing browser prefixes.
If one vendor has something that is useful, let the others ask that vendor to make it default, let all vendors strip the vendor tag and get it over with. if you do not want to implement the rule, ignore it but do not cry when people leave your vendor prefix alone.
I can't be bothered with ever changing browser prefixes.
[deleted]
It seems the W3C is opposed to grassroots innovation from browser vendors without having every feature pass through their committees first. I don't buy the arguments about monopolization, and if most of your user base is on iOS or Android then it makes perfect business sense to prioritize those platforms when building out your design. Graceful degradation and progressive enhancement are widely recognised good practices, but by no means are they mandatory for the success of the 'Open Web'. The benefit Apple has brought by not bundling Flash with their iOS devices (suddenly that 'monopolization' doesn't look so bad, does it?) far outweighs any drawbacks caused by the implementation of non-standard features in WebKit.
In fact, you know what the real enemy of the 'Open Web' is? The use of terms like ‘de jure’. In the real Open Web, there's no room for central governance, and no tolerance of the assertion by any organization that they represent the sole font of truth.