W3C home > Mailing lists > Public > www-tag@w3.org > April 2012

RE: CSS vendor extension issues

From: Larry Masinter <masinter@adobe.com>
Date: Mon, 23 Apr 2012 17:28:22 -0700
To: "L. David Baron" <dbaron@dbaron.org>, Daniel Glazman <daniel@glazman.org>
CC: Karl Dubost <karld@opera.com>, www-archive <www-archive@w3.org>, Peter Linss <peter.linss@hp.com>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <C68CB012D9182D408CED7B884F441D4D194AB19DE0@nambxv01a.corp.adobe.com>
I tried to lay out the choices for identifiers in the previous work on web evolution, which I've moved to http://www.w3.org/wiki/Evolution ; see http://www.w3.org/wiki/Evolution/Identifiers Including the use a "vendor prefix" case. 

I'd like to at least get to the point where we've identified the issues and use cases in the wiki for the various methods of distributed extensibility, the costs and benefits, failure modes.  Ambitious, I suppose, but perhaps the Wiki Way will help?

Larry


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

On Tuesday 2011-11-08 21:53 +0100, Daniel Glazman wrote:
> The only thing I know is the following one : what happened with
> -*-border-radius was lame and we decided to implement new processes
> to avoid a fiasco of same magnitude. Then CSS Gradients arrived
> and browser vendors did the very same mistake. I think it's good to
> have the TAG in the loop here. Feedback #1 from Web Agencies at this
> time is the pain it is to deal with multiple prefixed versions of the
> same property...

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.

(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.)

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Tuesday, 24 April 2012 00:29:12 GMT

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