On Mon, Sep 21, 2009 at 1:22 PM, Maciej Stachowiak <[email protected]> wrote:
> > 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. > Agreed. I would think something like "disable Java" (not the best example, but I think it makes the point) should have obvious side effects though. That said, I can't think of any JavaScript APIs where it does make sense today. And, if not, then we should probably differ such a discussion until there is. > 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). > Given that this really only applies to "experimental" features, I don't think we should spend too much effort on this. But Drew, I do think it'd be valuable if you played around with it. And if any of this isn't too hard/messy to do, I think it would be somewhat valuable. I'm also going to send mail to chromium-dev proposing that we never ship anything but a "dev channel" browser with such experimental features compiled in for the reasons we've discussed here. J
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
