
The Open Web Needs You Now - tbassetto
http://www.glazman.org/weblog/dotclear/index.php?post/2012/02/09/CALL-FOR-ACTION%3A-THE-OPEN-WEB-NEEDS-YOU-NOW
======
gazrogers
It'd be nice if the browsers could adopt a standard prefix for experimental
styles ( _-exp-_ maybe) which is then replaced by the browser prefix before
being used - so in Chrome _-exp-text-size-adjust_ would become _-webkit-text-
size-adjust_ and in Firefox it would become _-moz-text-size-adjust_. That way
we can escape the necessity of doing one rule for each prefix ( _-webkit-_
_-moz-_ _-o-_ _-ms-_ etc.) and just have one. Browsers could just ignore the
rules which they haven't implemented yet and web devs would not be able to
cause problems by targeting just one family of browsers. It could probably be
implemented by a quick text replace before parsing (the c++ equivalent of
s/-exp-/-webkit-/g) and would shrink the size of some stylesheets
considerably.

~~~
padenot
This could work if and only if there weren't different syntaxes and
implementations differences between prefixed properties with the same name.

~~~
gazrogers
I agree it's certainly not a panacea for all the ills of the current system,
but as the syntaxes converge it could provide a way for web devs to use one
prefix without breaking the web or forcing minority browsers to adopt the
prefixes of the majority browser.

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.

------
alexchamberlain
I completely agree that Firefox must not accept -webkit-* prefixes. A better
approach would be to contact the sites in question and socially bombard them
into changing.

~~~
hoppipolla
Long experience of contacting sites suggests that it is, at best, of limited
effectiveness. At Opera we have a not-insubstantial team dedicated to
developer outreach who frequently contact sites that are broken in Opera and
give them help to get stuff working again. But the approach doesn't scale; we
can only contact so many broken sites and we can only get so much traction
being proactive and asking people not to depend on new, shiny, but single
browser, stuff.

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.

~~~
tomjen3
Honestly I don't really get the existence of Opera. Not when both Firefox and
Chrome are free and don't suffer from the issues you mentioned.

This may be related to why I don't really care about the few users who use
Opera -- it is just not worth it.

~~~
ysbreker
You do know that Opera is the most used browser on mobile devices, right? And
that they invented quite a lot of features you take for granted in your
current browser of choice, right?

------
jarek-foksa
Why can't we just have '-dev-' prefix which would mean "a feature implemented
according to dev or working draft spec"?

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.

~~~
andrewmccall
A lot of the time it's because the implementations haven't even been agreed
between the different browsers.

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.

------
fufulabs
Agreed but in turn you standards body should act a LOT more quickly in
updating web standards.

------
Yaggo
I'm huge WebKit fan (been since KDE 2), but I agree with the author that the
current situation is problematic. (Although the case with IE6 was orders of
magnitude worse and largely different in nature.)

Luckily nice tools exist to automatize the boring prefixing (even for us who
don't use LESS/SASS style preprocessors):

    
    
      $ pip install cssprefixer
    

There is also a client-side solution, which I find suboptimal as a technique,
but YMMV: <http://leaverou.github.com/prefixfree/>

~~~
phreeza
I was about to comment mentioning cssprefixer. Now I am thinking it might make
sense to go around looking for sites that don't prefix properly and emailing
the operators with the prefixed version. It might even be possible to do this
in an automated fashion.

~~~
dave1010uk
The initiative "Pre-fix the web" <http://codepo8.github.com/prefix-the-web/>
is about doing this with GitHub projects. Probably a good place to start.

------
PaulHoule
Funny, for my own reasons I uninstalled Chrome and switched to IE9 on my main
computer.

Although IE9 supports standards well on paper, it's shocking how many sites
aimed at "webby" sorts of people don't work on IE9.

~~~
emehrkay
Why would you choose to use ie9 over something like chrome?

edit: Why not move to another browser with better standards support like
firefox or opera?

~~~
khuey
IE's standards support is pretty decent these days. There are other reasons to
choose a browser besides support for standards too.

~~~
xtian
Decent, but still worse than everything else.

------
emehrkay
I read this post by Lea Verou last night and I feel that it could be a good
solution to the problem

[http://lea.verou.me/2011/11/vendor-prefixes-have-failed-
what...](http://lea.verou.me/2011/11/vendor-prefixes-have-failed-whats-next/)

------
rplnt
Just yesterday I had similar comment(s) here on HN[1]. And blogging probably
won't help. Just don't do it on your production sites and apps. If you don't
have the capacity to support other than major two browsers then just don't.
But blocking them is not a solution. And blocking features even though they
work when you change user agent (hello google[2]) is complete nonsense.

1\. <https://news.ycombinator.com/item?id=3566329>

2\. search by image, search background, google plus notifications, ...

------
anon1385
For those who missed it: discussion of the minutes of the recent W3C meeting:
<http://news.ycombinator.com/item?id=3561950>

------
methodin
What's the reason they even have to add a prefix? If all we end up doing is
prefix the feature with 4 different ones, and then the actual feature name in
case all else fail, it's pretty pointless. The browser should just implement
the feature as it is spec'd and when it's finalized they can do the work to
match the specs again. If we did that then nothing would break other than
possibly some behavioral differences.

~~~
spooneybarger
So browser makes can push forward innovation by adding support for
experimental procedures.

~~~
el_presidente
Something that is available on hundreds of millions of phones is not
experimental.

~~~
dmethvin
Exactly the problem. There was a proposal to make vendor-prefixed features
_only_ available on experimental builds, but as long as they escape to the
wild and do cool things developers will use them

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

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

~~~
DanBC
People using experimental features should be prepared for those features to
break. Hopefully this allows people to be creative and inventive on their
personal sites, without pushing experimental features through to big
production websites.

Don't forget that those sites are already, by design of the owners, broken for
any non-webkit browser.

~~~
tomjen3
Experimental? Gradients are almost certainly not experimental -- they are even
supported in IE 8 (though through a non-standard way, thanks MS) -- nor should
scaling be experimental (there is nothing experimental about it).

------
gerggerg
I think the doom and gloom is a bit over-hyped, and the other browser authors
probably have no choice but to implement the webkit prefixes. They just don't
have the install numbers to do otherwise. I don't like the situation but I see
it as inevitable and not that big of a deal.

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.

~~~
gcp
_I think the doom and gloom is a bit over-hyped, and the other browser authors
probably have no choice but to implement the webkit prefixes._

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.

------
Robin_Message
How about an agreement that only one vendor should create a prefix on a
feature? So, they create say "-webkit-feature", and can innovate there. Once
another vendor wants to implement it, they co-operate with the original vendor
and interested parties and get a standard together, which everyone can then
implement as "feature".

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.

------
cmorrisrsg
A viable solution going forward is to have browsers implement both the vendor-
prefixed and non-vendor-prefixed versions of a property, but use the vendor-
prefixed one preferentially. That would allow developers to use one non-
prefixed rule in the common case where all supporting browsers implement the
rule in the same way, but developers can target particular browsers if they
deviate. Or if you're worried about the standard deviating, support vendor-
rule and x-rule at the same time.

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.

------
rglover
The W3C needs to become more vocal about experimental features, which browsers
support them, and their implementation. They may do this in their "spec"
documents, but I like to read those as much as I like to do taxes. Make the
information more accessible and friendly to those using it. I bet a lot of the
people using only "-webkit" don't even realize it's wrong. If they do, then
it's probably because rewriting the same rule 4-5 times is pretty cumbersome
(especially when doing front-end for apps!).

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.

------
kevingadd
This problem seems to indicate a tremendous failure on the W3C's part to
anticipate the actual consequences of vendor prefixes, or if they actually
anticipated them, a failure to act. Despite the fact that Quirks Mode is not
identical, it is a similar enough case (And one that should be familiar to
every browser vendor) that ignoring its example when considering vendor
prefixes suggests either willful ignorance or an extreme desire to hope for
the best and ignore the consequences.

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...](http://lists.w3.org/Archives/Public/www-
style/2012Feb/0313.html) 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.

~~~
nroach
I agree to an extent. But, the webkit prefix situation is not the same as the
IE problem. During IE's heyday, sites were tailored specifically to that
browser, but due to IP and technical lock-in, other browsers were unable to
implement the IE-specific features. (See ActiveX).

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.

------
Flenser
Surely once the feature is standardised webkit stops supporting the feature
with the -webkit- prefix so sites will be forced to update their css. Or does
webkit continue to support the features with the -webkit- prefix even when
they'll work without it? If it's that latter then surely all that's needed is
for webkit—or projects using webkit—to agree to drop support for the -webkit-
prefix once it's been standardised and this will stop being a problem.

------
Toshio
I agree with helping Mozilla and Opera, because they are good citizens of the
open web community. But I disagree with helping Microsoft. We should make sure
the IE-nazism episode never happens again by forcing them to implement one of
-webkit- -moz- -o-.

~~~
gcp
Either the web is open for everyone (including Microsoft), or it's closed.
There is no middle ground here.

~~~
tomjen3
Then it is closed. Whatever.

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.

------
tomjen3
Can we excempt -ms prefixes from this?

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.

------
jorangreef
The other browsers have been moving too slowly in their update cycles and it
is starting to show. The difference this time is that WebKit is open source.

~~~
exterm
Have you even read the linked article?

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.

~~~
jorangreef
I have read the linked article. There is a root cause that is deeper than
"just very bad CSS".

