Re: Proposition to change the prefixing policy

There is one major difference. the prefixes we use now are changing their 
behaviour when the browsers update it to the newest spec, which will break 
older content. This is not the case for these new prefixes, since there will 
be a new prefix for the new draft. Old webpages won't break and new webpages 
can use the new draft to its full extent.

The problem with support for older drafts by browsers that didn't implement 
it isn't that great. Website developers at that time already knew that 
certain browsers won't support the feature and anticipated on that. Today 
the web developers arn't supposed to use the old drafts (it also isn't 
forbidden). They probably don't even want to use it (why else is the new 
draft introduced). So backwards supporting of previously non-supported 
properties isn't needed for browsers, while backwards supporting of 
properties that were supported in the past is a must.

There probably will be a website where you can find browser support for the 
properties and their drafts (W3schools already does for recommended 
properties, even though it isn't fully up to date). This new site could be 
part of W3C or a third party.

So I see a lot of advantages with these prefixes and not really any 
disadvantages.

-----Oorspronkelijk bericht----- 
From: Florian Rivoal
Sent: Monday, May 07, 2012 11:46 AM
To: www-style@w3.org
Subject: Re: Proposition to change the prefixing policy

On Sat, 05 May 2012 02:32:51 +0200, Rik Schaaf
<coolcat_the_best@hotmail.com> wrote:

> I agree on the problems the current prefixes have, but in stead of 
> browser prefixes, woulden't it be better to use draft prefixes 
> ike  -beta1-flexbox or maybe -23july2009-flexbox? (which I think is not as 
> good as beta1)

This idea has been floated around for a while, but I am not a fan of it.

Most importantly, it wouldn't be very different from what we have now
in some crucial aspects.

Even though the prefixes would be less branded than they are now,
you'd still have just the same problem with a lot of content accumulating
for the prefix that corresponds to the earliest implementation or the
most popular browser. The browser(s) supporting that particular prefix
would have the same difficulty about dropping support for then when they
get the unprefixed properties, and the browsers that don't support it
would be just as tempted to start supporting that old draft as they now
are to support the other vendor's prefix.

On top of that, early implementations often don't follow drafts that
closely, and authors don't read them much. So authors writing -draft1-foo
when only browser X implement it would be asking for browser X's behavior
regardless of whether it conforms to draft1 or not.

This means that draft prefixes would just be vendor prefixes in disguise.
Overall, I think this wouldn't really solve anything.

  - Florian

Received on Monday, 7 May 2012 12:33:56 UTC