Should host objects be able to have [[Class]] "Function", "Array" etc.?
mjs at apple.com
Mon Nov 17 21:02:58 PST 2008
On Nov 17, 2008, at 8:38 PM, David-Sarah Hopwood wrote:
> Blake Kaplan wrote:
>> On 11/15/2008 09:40 PM, Garrett Smith wrote:
>>> Standardizing an MSIE property that works differently than in MSIE
>>> creates compatibility problems on the web. A better alternative
>>> be to use a different property name.
>> Who is supposed to use the better name here?
> I can't speak for Garrett Smith, but I think the above comment was
> mainly about 'filter'. In that case, the SVG WG were supposed to check
> whether they treading on an existing widely-used (and documented, if
> proprietary) property name, *before* standardizing their version.
> That they did not do so was a perfectly avoidable mistake.
> Note that Safari's 'filter' hack has several undesirable properties
> that document.all does not have:
> - it is enabled even in 'standards mode'; document.all is only
> enabled in 'quirks mode'.
That's true in Firefox, but not in Safari. We try to limit quirks to
CSS, rendering and parsing and generally do not let quirks mode affect
> - it produces an oddball primitive value, with typeof "string".
> This is more problematic than an oddball host object; the latter
> are two-a-penny.
No, it's an oddball host object, not an oddball primitive. It's a kind
of String object, not a string value.
> - the oddball string can escape to code that doesn't know where
> it came from. The nonstandard behaviour of 'document.all', if
> I understand correctly, only applies when that property reference
> is used directly in a boolean context, and so it can't escape to
> other code.
That is true (though it also applies to the Safari/WebKit version of
the document.all hack, since we return a falsy object in that case
rather than changing evaluation in boolean contexts only).
> - it breaks feature-testing for the standardized version of 'filter',
> since 'if (document.body.style.filter)' does not work.
> Renaming the standardized version, say to 'svgFilter', would have
> avoided this breakage, i.e. 'if (document.body.style.svgFilter)'
> would then work as expected.
I agree that would be good, and I hope the SVG Working Group considers
it but continuing to discuss it here seems off topic to me.
>> I don't think anybody is suggesting that these properties become
>> part of
>> the standard. It seems to me that a conforming implementation
>> should be
>> able to implement such compatibility hacks though, which is why they
>> were brought up.
> If that were intended to be allowed, then ES3.1 would have to be
> changed to specifically allow it. (One way to do so would be to
> replace 'ToBoolean' with a [[ToBoolean]] method, that host objects,
> and only host objects, can override -- although I have not thought
> about possible side-effects of this approach, and this post should
> not be taken as recommending it.)
> In ES3, the 'document.all' and 'filter' hacks are both clearly
> nonconformant, because an IfStatement checks only the result of
> ToBoolean applied to its condition, and ToBoolean is required to
> return true for all objects and non-zero-length strings.
I would prefer that ES3.1 be lenient enough to allow these kinds of
hacks, one way or another. It is unlikely they will be removed, so
there's no benefit to anyone for the standard to claim they are not
More information about the Es-discuss