Re: Selecting for features

On Sun, Jul 11, 2010 at 12:17 PM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
>> From: Eitan Adler [mailto:lists@eitanadler.com]
>> Sent: Saturday, July 10, 2010 9:02 PM
>
>> There is a fundamental difference between your proposal and Modernizr.
>
> It's not my proposal.
>
>> Modernznir "detects native availability of features" by actually
>> running code and seeing the result.
>> Your proposal would be based on hard coded Boolean values in the
>> browser.
>
> The interface presented to the author is a set of boolean switches in
> both cases - this feature is there or it's not - and Modernizr does not
> verify the proper working of each feature it reports. Take opacity: all
> Modernizr does is setting the property to '.5' and check the result is
> '0.5' under the assumption that the normalized value proves the feature
> to be fully implemented. Thus a browser bug in the actually rendering of
> opacity would pass completely unnoticed by Modernizr. The latter only
> runs the smallest amount of code known to reflect today's correct
> implementations. It certainly works very well in practice but is not
> inherently more trustworthy - from a technical standpoint - than the
> developers at Mozilla, Apple, Google, Microsoft or Opera turning on
> the 'opacity-is-supported' bit once their code passes all the testcases
> for the feature.
>
>> Feature *detection* and feature *deceleration* are two different things.
>> I think that this library is the best answer to your use case.
>
> I would agree in principle but the difference in this case is, imo, quite
> superficial. It would actually be trivial for any browser to make Modernizr
> detect support for every single feature it checks for. One could add a
> navigator.geolocation property and Modernizr would happily report that the
> platform supports the Geolocation API. That is literally  all it takes today.
> As such Modernizr largely wraps DOM-based boolean feature declarations in a
> convenient interface. If the Modernizr team is able to trust browser vendors
> to not add the navigator.geolocation property without doing the underlying
> API implementation work then why can't you ?

This is somewhat unfair, Sylvain.  Modernizr currently relies on
super-trivial checks for some features *because it works*.  If a
browser started actively lying in the way you suggest, Modernizr would
be updated to test more thoroughly.  (They don't even have to be
*lying* to force Modernizr to have to detect around them; just putting
in buggy or incomplete support may make it annoying enough to detect
and report as "not supporting".)

> The more I look at Modernizr, the more I am inclined to conclude that declarative
> feature detection already does work in practice, except at the cost of downloading
> and executing a script library.

Yes, but only because an independent party is making the declaration,
and is able to provide results at whatever granularity proves useful.
The hasFeature() function provides at least some evidence that
browser-provided information about support is marginally useful at
best.


That said, fantasai's proposal for !supports appears to be less likely
to be lied to than directly asking the browser what they support, and
thus more reliable.  The additional fact that it's somewhat more
difficult to use as browser-detection just makes it even more
attractive.

~TJ

Received on Monday, 12 July 2010 17:11:46 UTC