W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2010

Re: DOMString-like objects for the CSSOM

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 19 Feb 2010 18:06:20 -0800
Cc: Simon Pieters <simonp@opera.com>, Boris Zbarsky <bzbarsky@mit.edu>, "Mark S. Miller" <erights@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-id: <736D8EE1-FDB8-4429-9403-BEAD71578B76@apple.com>
To: Brendan Eich <brendan@mozilla.org>

On Feb 19, 2010, at 5:33 PM, Brendan Eich wrote:

> On Feb 19, 2010, at 5:27 PM, Maciej Stachowiak wrote:
>
>> We definitely do need an API that works with numbers. Conversion,  
>> no matter how optimized, is a waste. Furthermore, it's not just a  
>> simple conversion, the units part of the string must be removed and  
>> then re-added. I don't think there is any question that we need to  
>> bypass all that and enable direct use of numeric values.
>
> Ok, sure -- I'm not denying API needs, just redirecting them :-/.
>
>
>> The question is just whether to hang it off the string-based API in  
>> this slightly odd way, or to add a new parallel API. Please don't  
>> throw out the valid use case baby with the quirky solution bathwater.
>
> Not throwing out use-cases.
>
>
>> My design taste and compatibility concerns would lean towards a new  
>> parallel API, but I'm willing to give proponents of extended  
>> strings a chance to demonstrate that it is a viable option.
>
> Compatibility is pretty much all or nothing. Trying to cheat  
> requires massive field testing, and even then you may not hear bad  
> news until next year. Why risk this kind of breaking change actually  
> breaking some important web content?

That was my initial reaction as well. I think the burden of proof is  
on those advocating a breaking change to show both of the following:
(a) The risk is low enough.
(b) The value of the breaking change is high enough, compared to the  
available alternatives.

That is how I feel in general about any potentially breaking change to  
any part of the Web platform.


As one minor data point: WebKit returns a String-like object instead  
of a string value for style.filter, and has been doing so for some  
time (to support SVG filters without the risk of being detected as  
IE). This object also has some impossible-per-spec behaviors, which I  
won't go into here since they are not relevant to the point. The point  
is that we haven't had apparent compatibility problems from doing this.

Regards,
Maciej
Received on Saturday, 20 February 2010 02:06:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:02 UTC