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

Re: Selecting for features

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Mon, 12 Jul 2010 12:21:12 -0700
Message-ID: <AANLkTil4Ox5Ff5DlxdbGhpvuOvXgEmqrQAeoK3Qdlzkb@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Sylvain Galineau <sylvaing@microsoft.com>, Eitan Adler <lists@eitanadler.com>, Adrian Price <adrian.price@rogue-technologies.com>, David Woolley <forums@david-woolley.me.uk>, "www-style@w3.org" <www-style@w3.org>
On 7/12/10, Sylvain Galineau <sylvaing@microsoft.com> wrote:
>> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
>> This is somewhat unfair, Sylvain.
> Why is it unfair to state what Modernizr does and doesn't do ?

You're focusing on Modernizr for the example.

While it's great to see these ideas taking hold and being promoted,
feature detection is not Modernizr.

The concepts in Modernizr can be traced to discussions on
comp.lang.javascript. Many of these have been espoused for around 10
years by Jim Ley and Richard Cornford, among others, and were used for
writing cross browser scripts for Netscape Navigator (NN4).

Late 2007/early 2008, I discussed the idea of creating and inserting
divs into the document on comp.lang.javascript. This and other ideas
are being used in Modernizr, but there's more to feature testing than


The idea Glazman promoted is about performing existence inference in
CSS. Existence inference checks can and do fail, and they're not the
same as a usage inference of "capability test", but they are better
than related execution inference.


> That it's more difficult for authors to use in order to do something they
> all
> do in some way, shape or form - many of which far less reliable than
> Modernizr
> - makes it attractive ? The long-run cost and downside of authors using
> dozens of
> incompatible, unreliable and even invalid ways to detect features seems
> greater
> to me than the inconvenience of temporary browser inaccuracies in reporting

Modernizr is organized based on HTML 5, not to reuse patterns and at a
cost of memory use and processing.

At a glance, Modernizr appears to create a few closure-based memory
leaks. It uses `appendChild`, which can trigger "operation aborted" in
MSIE if called at the wrong time, and it appends divs to
documentElement, which is required to raise (throw) a DOM
HIERARCHY_REQUEST_ERR (that error is thrown in older Gecko versions
and reportedly in Konqueror 4).

It's great to see such feature detection taking a broader mainstream
hold. However, most apps only need a few feature tests, and possibly a
feature test that Modernizr doesn't cover (such as new ES5 features
like JSON). Modernizr can't practically cover every known feature test
situation. For the purpose of feature testing, please consider:


Threre are more threads on comp.lang.javascript where these ideas
originated and are continually criticized. Such criticism includes
pointing out where they can cause memory leaks, crash the browser, and
provide poor inferences.

Received on Monday, 12 July 2010 19:21:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:48 UTC