

The open web needs you *now* (Webkit the new IE6?) - sunnysideup
http://www.glazman.org/weblog/dotclear/index.php?post%2F2012%2F02%2F09%2FCALL-FOR-ACTION%3A-THE-OPEN-WEB-NEEDS-YOU-NOW

======
zacharyvoase
> “…the proprietary CSS-like properties they have let the whole world use in
> iOS and Android devices, harming the Open Web.”

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.

~~~
Dinoguy1000
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.

------
endeavor
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.

------
jinushaun
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.

------
Geenkaas
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.

------
DanBC
(<http://news.ycombinator.com/item?id=3570353>)

