RE: DOMString-like objects for the CSSOM

Anne, I know you discussed this with me at TPAC. Have you written this down somewhere? Perhaps I missed it in the thread?

I definitely see the value of this proposal to the script author. It is simple to understand and simple to use (it just might be harder to spec :)

If I understood correctly, the implementation would simply be that the string instances returned by the properties of the CSSStyleDeclaration, would not all have String.prototype as their private [[prototype]] reference. Rather the affected properties would return string instances whose [[prototype]] referred to some intermediate prototype (something like CSSColorPropertyExtensions.prototype -- I'm just making this up, of course) whose internal [[prototype]] then referenced String.prototype for compatibility. 

I find this to be most interesting, and I don't wish to throw the idea away without some consideration.

The more I learn about ES language design principles, the more this type of manipulation might seem odd. For instance, string instances, as well as the String.prototype object are both string instances. Putting an intermediate DOM object in-between a string instance and it's default [[prototype]] could throw a wrench into the algorithms defined in the ES spec.

On the other hand, creating [several] new kinds of String extensions just for this purpose, which have to mirror the support of the ES String type and its members also seems like the wrong approach, and too much overhead.

-Travis

-----Original Message-----
From: public-script-coord-request@w3.org [mailto:public-script-coord-request@w3.org] On Behalf Of Anne van Kesteren
Sent: Friday, February 19, 2010 7:46 AM
To: Mark S. Miller
Cc: public-script-coord@w3.org
Subject: Re: DOMString-like objects for the CSSOM

On Fri, 19 Feb 2010 16:42:11 +0100, Anne van Kesteren <annevk@opera.com>
wrote:
> On Fri, 19 Feb 2010 16:25:44 +0100, Mark S. Miller 
> <erights@google.com>
> wrote:
>> This is yet another example of why WebIDL is a bad language for 
>> designing JavaScript APIs. The choices encouraged by WebIDL, and that 
>> seem natural in WebIDL, often result in bad JavaScript API designs.
>
> I'm not sure what you mean. We're not starting to reason based on Web 
> IDL. We're simply trying to extend a legacy API and I'm wondering how 
> to express that in Web IDL.

And to be clear, we realize strict-equality and typeof will very likely (unless we'd break with ECMAScript) no longer return the same result.  
We've yet to evaluate whether that is feasible in practice. Having string members present is a minimum requirement for compatibility.


--
Anne van Kesteren
http://annevankesteren.nl/

Received on Monday, 22 February 2010 23:23:45 UTC