W3C home > Mailing lists > Public > www-style@w3.org > July 2010

RE: Selecting for features

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Sun, 11 Jul 2010 19:17:31 +0000
To: Eitan Adler <lists@eitanadler.com>
CC: Adrian Price <adrian.price@rogue-technologies.com>, David Woolley <forums@david-woolley.me.uk>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E215182A2@TK5EX14MBXC111.redmond.corp.microsoft.com>
> 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 ?

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.
 
> The question is: does the benefit outweigh the downsides? In this case
> it likely does not.

I'm not sure which downsides and evidence you are referring to.

> 
> --
> Eitan Adler

Received on Sunday, 11 July 2010 19:18:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:29 GMT