W3C home > Mailing lists > Public > www-style@w3.org > May 2012

Re: Proposition to change the prefixing policy

From: Rik <coolcat_the_best@hotmail.com>
Date: Tue, 8 May 2012 13:45:33 +0200
Message-ID: <SNT132-ds13D189E22AD1449578DE6DCF100@phx.gbl>
To: Fran├žois REMY <fremycompany_pub@yahoo.fr>, "Sylvain Galineau" <sylvaing@microsoft.com>, "Florian Rivoal" <florianr@opera.com>, <www-style@w3.org>
Now I think of it, this will only be needed for any properties which 
currently aren't in the CR phase yet. Why supporting this feature for old 
drafts, if it isn't used yet.

If applied only to the current WDs, this wouldn't cause such a dramatic 
performance issue.

Would the performance improve if it was used as a suffix?

-----Oorspronkelijk bericht----- 
From: Fran├žois REMY
Sent: Tuesday, May 08, 2012 1:30 PM
To: Rik ; Sylvain Galineau ; Florian Rivoal ; www-style@w3.org
Subject: Re: Proposition to change the prefixing policy

> Again, I state that authors should use the newest draft (or the unprefixed
> version once it is a CR). The older drafts only should be supported to
> prevent older websites from breaking. Older drafts can be used if the 
> newer
> draft is not fully supported by all browsers. Everyone can look on a still
> to be made website to see which draft is supported.
>
> it should look a bit like http://caniuse.com/, but then with each draft 
> vertically and the browsers horizontally.
>
> This way of prefixing could probably not be implemented until the next 
> browserversion comes out. When it does it supports the older drafts, so it 
> isn't needed to show at which browserversion it is supported, because all 
> drafts would be supported by the newest browser.

The main issue remains: blog posts, printed books and similar resources are
static snapshots of a moment in the spec history. Most people use them, but
few will "live update" to reflect changes in support, modify recommanded
prefix. That means the code "copy-pasted" from those sources will not
necessarily be in sync with what you would like to; old prefixes won't die
easily. Also, this solution would lead to an important amount of
per-property prefixes. It'll hurt parser performance, at some point.

I'm pretty sure an intermediary approach exists between "all vendor-based"
and "all version-based".

Anyway, the best solution remains no prefix at all, as soon as possible.
Received on Tuesday, 8 May 2012 11:46:03 GMT

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