W3C home > Mailing lists > Public > www-style@w3.org > August 2010

Re: [cssom] CSS Value API

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 17 Aug 2010 13:04:52 +0200
To: "Brad Kemper" <brad.kemper@gmail.com>
Cc: "Boris Zbarsky" <bzbarsky@mit.edu>, "Ojan Vafai" <ojan@chromium.org>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <op.vhkw2ekv64w2qv@anne-van-kesterens-macbook-pro.local>
Implementors: From potential implementors I would like to know how  
interested they are in seeing the CSSOM Value API happen soon. If I define  
this will this be experimented with in implementations or is this  
something that will take a very long time (if ever) before being adopted?

On Thu, 22 Apr 2010 19:25:42 +0200, Brad Kemper <brad.kemper@gmail.com>  
> On Apr 21, 2010, at 9:45 PM, Anne van Kesteren wrote:
>> Consider a property 'foo' that takes two values and is therefore  
>> represented by a map. Consider then that CSS changes over time. The CSS  
>> WG decides that 'foo' will now be a comma-separated list. To remain  
>> backwards compatible it will need to expose both a map and a list. That  
>> is the reason I gave it two different accessors. I am open to other  
>> solutions.
> So, as I understand the backwards compatibility story, 'foo.m' would  
> continue to provide a map array-like object in your example, even though  
> it was really coming from 'foo.l[0].m'. Is that correct, so far?


> It seems to me that this could be made simpler by getting rid of the m  
> attribute and just have that available on the property object. And spell  
> out "list" for clarity. So, for instance (assume also the first  
> component property is called "snork" and the second one is "width"):

The problem is here with a property that accepts a single value component  
as value and is then extended to accept several value components at once.  
At that point we might get clashes between the items represented by the  
map and the interface members of the CSSValue object the property returns.

E.g. 'color' returns a CSSValue object that also implements CSSColorValue  
and CSSColorValue has a member red. Now if we turn the 'color' property  
into something that accepts multiple component values of which it would  
make sense to name one red we have a problem. I am not sure how likely  
this is to occur, have not been able to find a historical example so far,  
and presumably we could name the item in the map slightly differently to  
avoid this at that point, but it would be slightly hackish. But then I  
suppose everything would be as extending interfaces in this way is rather  
fragile so maybe your suggestion of having map by default and list via a  
member is fine.

For what it's worth, I outlined the various transition scenarios we have  
to consider here: http://wiki.csswg.org/spec/cssom

Anne van Kesteren
Received on Tuesday, 17 August 2010 11:05:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:37 UTC