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

Re: [cssom-values] Possibility of patching existing CSS strings into Values objects?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 8 Aug 2013 17:10:50 -0700
Message-ID: <CAAWBYDDbk6xVjdACW1e_BHjwmPf-bsd_jeDCH0RW1yQWj-v6zA@mail.gmail.com>
To: www-style list <www-style@w3.org>
On Thu, Aug 8, 2013 at 4:18 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> I've been thinking about the CSSOM Values API today, since SVG is
> wanting to do essentially the same thing for its attributes.  One of
> the downsides of it is that we need to expose the Value objects as
> something separate, because we currently always return strings.
> How realistic is it to change the type of attributes like
> el.style.color from DOMString to a CSSValue, where CSSValue has a
> stringifier and the attribute has a [PutForwards] on it?

Since we need value objects from TC39 to make this work properly,
ignore this for now.

The previous thread about this from 2010
concluded with the suggestion to just add a new accessor to .style
that returned the same object, but with the fancy new values rather
than strings.

The reason I'm bringing this up is in reference to SVG discussing a
new DOM, where properties like rectElement.x no longer return
AnimatedLength.  They want to return a string, for consistency with
HTML, but also want the same abilities as we've discussed for CSSOM
Values.  A different possibility here is just to take the same tack as
the old thread decided on - have the reflected attributes return plain
strings, but have a .values property on SVG elements that instead
returns a map of attribute names to the new value objects.

You'd do "rectElement.values.x.px = 5", etc.  This might work well,
and it has the benefit of being consistent between the two APIs.  We
could even push this into plain HTML eventually as well.

Received on Friday, 9 August 2013 00:11:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:13 UTC