- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 19 Oct 2011 22:49:05 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: public-script-coord@w3.org
On Wed, Oct 19, 2011 at 10:39 PM, Anne van Kesteren <annevk@opera.com> wrote:
> On Thu, 20 Oct 2011 14:26:37 +0900, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> However, there still is an argument for the constant, which is that it
>> enables feature detection. With for example
>> XMLHttpRequest.responseType, there is no good way to check what types
>> a browser supports. This isn't a big deal right now since all browsers
>> which support .responseType at all, support the full set of values.
>> However as we add more values that will no longer be the case (we
>> already have 3 additional values that we support in Gecko).
>>
>> So if we can find another solution for this problem, then I'm fine
>> with dropping support for string constants.
>
> That is already covered. If you set it to a non-supported value, the value
> remains unchanged. Same with <canvas>.
Sure, but that means significantly more code to test support:
if (XHR.RESPONSE_JSON) { ...
vs.
xhr = new XMLHttpRequest;
xhr.open("GET", "http://dummy.org/");
xhr.responseType = "json";
if (xhr.responseType == "json") { ...
And in the case of the visibility spec it pattern doesn't work at all
since there is no property you can set to see if it works. I.e.
.visibilityState is a readonly property.
> As an aside, overloading does suffer from the feature detection problem (if
> you use [AllowAny] anyway). Not sure how to solve it there, but it has not
> been a big deal thus far.
Indeed, the problem exists here too. I don't actually have any data to
verify your "has not been a big deal" claim. That seems to early to
tell so far in the case of XHR for example.
One solution would be to have an explicit API similar to the
hasFeature of yesteryear. But we'd obviously have to design it better.
/ Jonas
Received on Thursday, 20 October 2011 05:50:12 UTC