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
would
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
scripting behavior.
- 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
allowed.
Regards,
Maciej
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
