Re: DOMString-like objects for the CSSOM

On Feb 19, 2010, at 7:18 PM, Brendan Eich wrote:

> I think we're on a tangent here, but perhaps it's worth following.  
> Here goes:
>
> On Feb 19, 2010, at 6:06 PM, Maciej Stachowiak wrote:
>
>> 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.
>
> We at Mozilla have considered that approach, both for implementation  
> benefits vs. costs, and for developer-facing complexity reasons. We  
> are sticking with our guns and not making a magic, ECMA-violating  
> type. We may be lobbying for a name change for the SVG filter  
> property (I'm not sure where that stands). See
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=374216 (your name was  
> invoked in https://bugzilla.mozilla.org/show_bug.cgi? 
> id=374216#c23 ;-).
>
> Quoting from https://bugzilla.mozilla.org/show_bug.cgi?id=374216#c46
>
> "I've checked out http://www.housingmaps.com/ and it seems no  
> different with or without dark magic (the popup windows appear just  
> the same) so perhaps google maps has changed in the last 4 years."
>
> ("Dark magic" refers to any hack such as WebKit's masquerades-as- 
> undefined strings and objects, or Gecko's detecting vs. non- 
> detecting execution contexts, by which a property could be both a  
> string or object *and* a falsy value.)
>
> 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.

>
> 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.

Regards,
Maciej

Received on Saturday, 20 February 2010 03:35:14 UTC