Re: [cssom] Property Value API Ideas

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.

~fantasai

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