Re: DOMString-like objects for the CSSOM

On Feb 19, 2010, at 7:34 PM, Maciej Stachowiak wrote:

> On Feb 19, 2010, at 7:18 PM, Brendan Eich wrote:
>
>> My point here not to dwell on dark magic details (ours wins cuz  
>> it's a static property of code, it does not infect the shared  
>> heap :-P -- seriously, see https://bugzilla.mozilla.org/show_bug.cgi?id=521670) 
>>  or whether it's good to violate normative specs (sometimes :-).
>
> I specifically wanted to avoid digressing into how detectable  
> properties are handled, and whether this particular quirk is still  
> needed, since that is a whole other ball of wax.

Which "that"? We're digressing either way, but the question of the  
string-masquerades-as-undefined quirk being needed wants to be  
answered, because if the answer is "no", then it's not even a "minor  
data point" for the CSS string primitive -> String object  
compatibility "can we get away with it?" question.

(Sorry for the parenthetical asides -- I was being provocative, I  
admit!)


>> Rather I wanted to note that SVG filters don't seem to be used  
>> enough to tell whether this is even a data point, minor or major.  
>> It may have mattered once, because housing maps was *the* mash-up  
>> everyone talked about and tested. But if that mash-up (its google  
>> maps side) no longer uses .filter, is there a compelling reason for  
>> a string that masquerades as undefined?
>
> We'll remove the quirk from WebKit if we get sufficient evidence  
> that a quirk-free style.filter is sufficiently compatible. I do  
> believe the specific sites we know about having a problem in 2006  
> are all fixed. Either Mozilla shipping it and not seeing problems,  
> or us turning it on on trunk, would be sufficient evidence.
>
>> If the SVG working group could rename this property, in practical  
>> deference to the pre-existing (since IE4, IIRC) de-facto Microsoft  
>> standard, that would be helpful.
>
> Agreed. Not sure how likely that is.

To bring this back to the main topic, let's say the CSS string  
primitive -> String object change is "too incompatible" and we need to  
make String objects that appear to be string primitives (to 'typeof',  
'in', etc.). Aside from the Ecma violation (which a value types  
proposal might allow in a future edition, as Mark mentioned), would we  
really be improving the performance for API users?

Sure, they could get numeric values instead of unit-suffixed strings  
from which to parse out leading numeric prefixes, etc. But the object  
model would be fatter: where once were string primitives, now there  
would be objects of some type. For those style properties reflected  
into JS, would this matter? Perhaps not on average, but I could see it  
becoming costly enough at the limit that it should be considered as a  
separate compatibility concern from any type change, however concealed.

I don't know about you, but every time I ignore asymptotic complexity  
on the Web, I get burned. You could say there's no change from string  
primitive with parallel API having new properties, to String object  
with those new properties directly under the String object, except for  
a constant factor. Even those can matter (O(k) not always O(1) in  
practice). It's also not clear how constant the factor is, but I don't  
know enough about what new properties would be standardized under each  
String object.

If the idea is that a parallel API is strictly costlier, I wonder  
whether anyone has evidence. The cost of the proposed String object  
change is something like

C(string primitive) + C(String object) + C(new properties)

vs.

C(string primitive) + C(parallel API object) + C(new properties)

so perhaps it's a tossup. But these costs need to be weighted by how  
often they're used. Some CSS properties reflect into JS; of those,  
some are used without wanting to convert, e.g., "200px" into 200.

IOW, you always get a String object under the proposal, even if some  
of the time, you want only the string primitive inside it. Whereas  
with the parallel API proposal, you pay as you go and old code (even  
if it suffers some high conversion costs) continues to work, and not  
see higher memory costs for the string valued properties that do  
reflect into JS.

Is this making sense?

If so, then one final thought: the parallel API need not entail a new  
API object. There are lots of ways to organize the new API so it is  
"parallel" in some easy-to-use sense.

/be

Received on Saturday, 20 February 2010 04:02:31 UTC