On Sep 21, 2009, at 12:31 PM, Jeremy Orlow wrote:
On Mon, Sep 21, 2009 at 12:17 PM, Maciej Stachowiak <[email protected]>
wrote:
On Sep 18, 2009, at 1:30 PM, Jeremy Orlow wrote:
On Fri, Sep 18, 2009 at 12:59 PM, Alexey Proskuryakov
<[email protected]> wrote:
18.09.2009, в 12:24, Jeremy Orlow написал(а):
I'm not sure if we've hit any compatibility issues with this yet,
but it seems quite plausible that someone would compare
window.localStorage (or sessionStorage or database) to undefined
and, since it's null (vs. undefined), their script would assume
it's available.
Note that they can also do '"localStorage" in window', which we
can't easily prevent from returning true.
That's true. And unfortunate.
What would be involved in making it not return true?
It would be pretty complicated to do that based on a runtime
setting. You would need a custom getter for any object that has
properties which may appear or disappear based on settings.
Some of these already have a custom getter. Maybe it makes sense to
go ahead and do it for them?
This is probably too complicated to be worth it. Or at least, if we
added that level of code complexity I would begin to doubt the
merits of supporting runtime enabling of Web platform features.
I think it depends on why it's enabled at run time. If it's a
feature that some users might want to completely turn off, then I
think there's some merit to going the extra mile to disable it in
run time. But if it's something that's disabled because it's
experimental, then I'd lean towards your point of view.
Fair enough. But I would be against user-level preferences that add or
remove entire APIs. Rather, the preference should affect the behavior
of the API (possibly making it do nothing). So far the only actual
user-level preference I'm aware of that effectively disables APIs is
private browsing. And I think the way it works (in both Safari and
Chrome, even though it is different) is better than it would be to
make storage-related APIs disappear completely.
Which is a shame, because if ("localStorage" in window) is a
generally a better way to feature test than if
(window.localStorage). The latter idiom is problematic for
attributes where a possible valid value is something that evaluates
to false, or where computing the value can be expensive. For
example, if (document.body.outerHTML) would be an awful way to test
whether outerHTML is available.
Agreed. In practice, I can't think of anything we'd disable in run
time like that, but it's obviously more difficult for the web
developer to know this.
Even though this style of feature test is better, it's tragically much
less common than if (window.fooBar), so it's likely not a problem in
practice.
Even if we can't make the property not show up, would you agree that
returning undefined is better than returning null?
Slightly better. The only real difference it would make is if someone
tests using a === comparison to undefined (as opposed to == or just a
plain boolean test).
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
