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

Re: [cssom] CSS Value API

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 17 Aug 2010 14:38:35 -0700
Message-ID: <AANLkTi=1SUWpc2c+ZiPue5mP-edAeiBQz4bCDNW46ZVb@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Brad Kemper <brad.kemper@gmail.com>, Boris Zbarsky <bzbarsky@mit.edu>, Ojan Vafai <ojan@chromium.org>, "www-style@w3.org" <www-style@w3.org>
On Tue, Aug 17, 2010 at 4:04 AM, Anne van Kesteren <annevk@opera.com> 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 <brad.kemper@gmail.com>
> 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: http://wiki.csswg.org/spec/cssom

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 e.style.borderTop.m.style.value
but I can just do e.style.color.red - that is, that interfaces expose
their members directly while subvalues have to be accessed through a
map.

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.

~TJ
Received on Tuesday, 17 August 2010 21:39:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:30 GMT