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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:43 UTC