Re: [cssom] CSS Value API

On Tue, Aug 17, 2010 at 4:04 AM, Anne van Kesteren <> wrote:
> 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?

I know that Chrome is generally very interested in it, and further
improvements to CSSOM in general that make it easier and saner for
authors.  I believe this is something we'd implement in the relatively
near future.

> On Thu, 22 Apr 2010 19:25:42 +0200, Brad Kemper <>
> wrote:
>> On Apr 21, 2010, at 9:45 PM, Anne van Kesteren wrote:
>> 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:

I can't decide which one I like better.  I do think it somewhat
unlikely that we'll end up introducing a sub-value with the same name
as an interface field from the original value.  I also find it
slightly confusing that I have to use
but I can just do - that is, that interfaces expose
their members directly while subvalues have to be accessed through a

That said, I don't think that the .m is a horrible burden.  I'd have
to actually use it a bit to determine whether my initial feeling that
it's slightly clumsy turns out to be true or not.


Received on Tuesday, 17 August 2010 21:39:29 UTC