W3C home > Mailing lists > Public > www-style@w3.org > March 2010

vendor prefixes considered harmful (was: vendor prefix properties diverging from official properties)

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Wed, 03 Mar 2010 10:14:04 +0100
Message-ID: <4B8E285C.9080606@disruptive-innovations.com>
To: Sylvain Galineau <sylvaing@microsoft.com>
Cc: Aryeh Gregor <Simetrical+w3c@gmail.com>, Zack Weinberg <zweinberg@mozilla.com>, "www-style@w3.org" <www-style@w3.org>
Le 26/02/10 04:15, Sylvain Galineau a écrit :

> This topic has come up before; see http://lists.w3.org/Archives/Public/www-style/2009May/0105.html.

I find rather hilarious - and a shame at the same time - that HTML5
elements and attributes are implemented as is w/o vendor prefix even
if the document is only a WD while we still require differenciated
vendor prefixes for CSS until CR that are a huge burden on web authors.
The last case is the placeholder attribute on html input fields,
recently implemented in Gecko and already implemented long ago as is in
Webkit.

I said it in the past and I maintain my opinion: the vendor prefixes
as we manage them in CSS don't make sense. We have
border-radius and border-image interoperable enough so web authors copy
precisely styles only changing the prefix. That gives stylesheets that
are a pain to maintain, and with my editor's implementor hat on, hell
to edit.
We've had @namespace implemented w/o vendor prefix eons before CR. The
vendor prefixes also pollute all the compatibility tests available on
the web (or in our test suites) because the day vendor prefixes are
removed, we have to update everything. The day vendor prefixes go away,
editing tools also have to be updated and that is not always easy to
do. Think *-border-radius: a modern editing tool CANNOT avoid it. So it
has _today_ to deal with at least 4 different versions of the property
for editing, for computed style, etc. Think CSS 3 transformations or
transitions, the new cool kids on the block. It's a mess...

I understand that nothing in a spec is really frozen until the spec is
released, but I don't see why there is a burden on CSS and not on other
Web standards here. Again, HTML5 is only a WD and implementations don't
use prefixes. I am officially requesting that a DRASTIC change of
the way we manage CSS vendor prefixes (and in particular when we remove
them) be discussed between browser vendors, for instance during the
forthcoming CSS WG face-to-face meeting. An idea could be to let the WG
decide when a given property can avoid vendor prefixes instead of
enforcing the CR status for the whole spec.

I would like the following to never happen again (example taken from a
real stylesheet on the web) if the properties are already interoperable
enough to avoid it:

   -moz-border-radius: 5px;
   -webkit-border-radius: 5px;
   -o-border-radius: 5px;
   -ms-border-radius: 5px;
   border-radius: 5px;

Counter-productivity at its best...

</Daniel>
Received on Wednesday, 3 March 2010 09:14:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:25 GMT