Following up on this, because I missed Maciej's response.
On Mon, Sep 21, 2009 at 1:22 PM, Maciej Stachowiak <m...@apple.com> wrote:
>
> 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.
>
Maciej, are you saying that if I were to add a flag to disable
SharedWorkers, you'd want it to leave the constructor intact (i.e. not
remove the API) but just not create the actual thread?
That seems bad, as it means web apps can't do capability checking. It seems
better to remove the API. I'm about to add a flag for SharedWorkers
(possibly just within Chromium if I can), so I definitely want to resolve
this.
>
>
>
>> 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
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
