W3C home > Mailing lists > Public > www-style@w3.org > November 2009

Re: [cssom] Property Value API Ideas

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 30 Nov 2009 11:13:52 -0800
Message-ID: <4B141970.10702@inkedblade.net>
To: Anne van Kesteren <annevk@opera.com>
CC: CSS WG <www-style@w3.org>
Anne van Kesteren wrote:
> During TPAC some members of the CSS WG and people outside the CSS WG 
> discussed the idea of a potential replacement for CSSValue. Inspiration 
> came from a very old proposal by Ian Hickson which was originally 
> Member-only but I've since made available publicly here:
>   http://lists.w3.org/Archives/Public/www-archive/2009Nov/0007.html
> The idea is to make the members of CSSStyleDeclaration return a mix 
> between DOMString and a real Object. This would mean that e.g. 
> triple-equality checks would no longer work and hopefully nobody relies 
> on those specifics but if they do we have to think of something else. 
> (Suggestions for "else" that floated around were having a new member on 
> CSSStyleDeclaration that gives a CSSImprovedStyleDeclaration, having a 
> new member for each CSS property, etc.)
> I think that if we go in this direction we should start out small. Every 
> member (width, cssFloat, etc.) of CSSStyleDeclaration would start 
> returning the new DOMString/Object construct but only a few of them 
> would return specialized constructs. Obvious candidates are properties 
> that return some variant of <length> and properties that return some 
> variant of <color>. Personally I'd also like one for <uri> that gives 
> you the value without "url(" and ")" around it.

So, I don't have any DOM scripting background, but this all sounds good to me.

> The problems with exposing a better API like this is that the syntax of 
> CSS is very dynamic. So to preserve backwards compatibility at the 
> API-level we might have to sacrifice some of the flexibility we have at 
> the syntax-level or we have to get very creative (and potentially ugly) 
> at the API-level. For instance, background-image was a single value at 
> one point, but now it is a comma-separated list. E.g. if we define that 
> list-style-image returns a CSSUrlConstruct and later decide that it gets 
> a comma-separated list as well there is a small issue there. In that 
> obj.style.listStyleImage.url still has to function properly.

I think we should take the "get creative at the API-level" route. Tying
ourselves down at the DOM level like that is going to be very restrictive.

For lists, could you have it be /either/ a CSSUrlConstruct (if there's
just one value) /or/ a list (if there's more)? Then old pages would
continue to function, you just have to remember to upgrade your scripts
when you start using the new style features.

> The other problem I see is with properties that become a shorthand later 
> on. E.g. if we turn background-position in a shorthand we might get some 
> API breakage as well. Though this is probably already an issue given 
> that in most implementations shorthand properties will always return the 
> empty string.

In that case, I guess you'd want canonical representations defined for
what the shorthand should return when accessed.

What do we do with system fonts? They don't have longhand equivalents.

Received on Monday, 30 November 2009 19:14:36 UTC

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