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

Re: CSS vendor extension issues

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 23 Apr 2012 20:54:57 -0400
Message-ID: <4F95F9E1.5030604@openlinksw.com>
To: www-tag@w3.org
On 4/23/12 8:28 PM, Larry Masinter wrote:
> 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.

Very good read!
>
> 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

+1

Especially if existing work (in related Wikis) is meshed and cross 
referenced.

Kingsley


>
>
> -----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
>


-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen







Received on Tuesday, 24 April 2012 00:55:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:44 UTC