W3C home > Mailing lists > Public > www-tag@w3.org > November 2011

RE: CSS vendor extension issues

From: Larry Masinter <masinter@adobe.com>
Date: Wed, 9 Nov 2011 12:55:38 -0800
To: Daniel Glazman <daniel@glazman.org>, "L. David Baron" <dbaron@dbaron.org>
CC: Karl Dubost <karld@opera.com>, Peter Linss <peter.linss@hp.com>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <C68CB012D9182D408CED7B884F441D4D0611DABBBD@nambxv01a.corp.adobe.com>
I'm trying to understand whether there is a difference between using "vendor" prefixes and prefixed values, compared to using URIs for XML namespaces and namespace prefixed values.
Both are extensibility mechanisms. In the vendor-prefix case, the name of the namespace requires some registry (maintained by whom?) to map between vendor prefixes and vendor identities.

Are there any other distinctions? Is one better than the other? Do the same sorts of problems occur?

Larry
 

-----Original Message-----
From: Daniel Glazman [mailto:daniel@glazman.org] 
Sent: Tuesday, November 08, 2011 10:26 PM
To: L. David Baron
Cc: Karl Dubost; Larry Masinter; www-archive; Peter Linss; www-tag@w3.org
Subject: Re: CSS vendor extension issues

Le 09/11/11 02:39, L. David Baron a écrit :

> They have the choice not to use the prefixed properties.  Given that 
> they've made that choice to do so *despite* their complaints about it, 
> I suspect they might not like a solution that takes away their ability 
> to make that choice.

No they don't. Prefixed properties offer features that are visible in apps like iTunes or proeminent web sites that adopt them as soon as they are shipped. Releasing a web site is not only releasing a webapp, it's also *almost always* about releasing a web site that is nicer and cooler than the other ones (just as a reminder, I used to be the CTO of a Web Agency).

Don't ask people working in Communication to avoid using cutting-edge tech...

The only way to solve the problem is to ship the feature but not enabled by default OR to ship the feature only in test builds.

Ignorants will say it slows the Web, others will say it prevents the border-radius/gradients mess from happening again. I'm sure we can explain this well to the masses.

> (I agree with the feedback that we need to be better about 
> standardizing high-demand features quickly.  I think we can do that by 
> keeping them limited in scope and not adding and stabilizing every 
> addition anybody asks for before moving to CR.  In both of the cases 
> you mention, the group resolved to advance quickly and the editor then 
> went through all the comments made on the spec and added a bunch of 
> requested features, delaying advancement to CR.  Those additions would 
> be better made by developing the next level in
> parallel.)

That is not enough. Gradients were shipped almost the day they were proposed to the CSS WG. Such a feature cannot not trigger a huge response from the Web Authors' community.
Gradients were shipped with a prefix, but as a 'production' thing, and *that* is the root of the problem.

</Daniel>
Received on Wednesday, 9 November 2011 20:56:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:40 GMT