- From: James Robinson <jamesr@google.com>
- Date: Wed, 19 Jun 2013 14:05:12 -0700
- To: Brandon Benvie <bbenvie@mozilla.com>
- Cc: whatwg <whatwg@lists.whatwg.org>
On Wed, Jun 19, 2013 at 1:22 PM, Brandon Benvie <bbenvie@mozilla.com> wrote:
> On 6/19/2013 12:46 PM, Boris Zbarsky wrote:
>
>> On 6/19/13 3:43 PM, Kenneth Russell wrote:
>>
>>> Accurate feature detection in libraries like Modernizr was mentioned
>>> as a key use case:
>>>
>>> http://lists.whatwg.org/**pipermail/whatwg-whatwg.org/**
>>> 2012-September/037249.html<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037249.html>
>>>
>>
>> Right, this is the use case that's not really making sense to me. The
>> fact that Modernizr was doing this _eagerly_ sounds like a bug in Modernizr
>> to me...
>>
>
> The point of using Modernizr or something like it is to detect
> availability of features on page load, and then conditionally load
> polyfills/alternate fallback implementations. It specifically does need to
> do eager detection to be useful. It can't wait until the first usage to do
> feature detection; it needs to be done up front when preparing dependencies
> for the main application.
>
What would a page using Modernizr (or other library) to feature detect
WebGL do if the supportsContext('webgl') call succeeds but the later
getContext('webgl') call fails?
I'm also failing to see the utility of the supportsContext() call. It's
impossible for a browser to promise that supportsContext('webgl') implies
that getContext('webgl') will succeed without doing all of the expensive
work, so any correctly authored page will have to handle a
getContext('webgl') failure anyway.
- James
> This is also why Modernizr provides a custom build tool. It allows for
> users to only do the feature detection on features they know they need to
> care about, because each check has some cost that needs to be paid early on
> in a page load.
>
Received on Wednesday, 19 June 2013 21:05:37 UTC