- From: Yves Lafon <ylafon@w3.org>
- Date: Thu, 10 Nov 2011 14:00:08 -0500 (EST)
- To: Chris Lilley <chris@w3.org>
- cc: Larry Masinter <masinter@adobe.com>, Daniel Glazman <daniel@glazman.org>, "L. David Baron" <dbaron@dbaron.org>, Karl Dubost <karld@opera.com>, Peter Linss <peter.linss@hp.com>, "www-tag@w3.org" <www-tag@w3.org>
On Thu, 10 Nov 2011, Chris Lilley wrote: > One problem that can occur is that the amount of stylesheets that use a > particular vendor prefix for a commonly used feature (which is not yet > standardised and does not have an unprefixed version) can reach > somecritical mass such that other vendors start supporting that vendor > prefix in their own implementations (possibly with different levels of > support or different bugs). Thus, the simple 1:1 mapping between prefix > and implementation is broken. > > Another difference between vendor prefixes and xml namespaces is that > the vendor prefixes are *intended* to be temporary - once there is a > standardized version, stylesheets should use the unprefixed version. > Although in practice with the wide range of browser versions in use at a > given time, the prefixes stick (same problem as x- MIME types). Yes, and same problem with X- HTTP headers, like X-Forwarded-For. The issue is that people want to use a specific feature to solve specific problem, so 'experimental' things are used. It is very unlikely that vendors will stop producing new things that needs a new css property, a new media type or a new HTTP header. As of today, it is unlikely that product vendor will remove what was useful for their customers, because they rely on that behaviour. So unless you tie the extension with a particular version of the software that implements it (basically forcing obsolescence), there is no clean solutions as it is not a technical issue but a social issue. -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Received on Thursday, 10 November 2011 19:00:32 UTC