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

Re: Selecting for features

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 12 Jul 2010 11:19:58 -0700
Message-ID: <AANLkTilJvz8LThNpP3jSuSG1xHnxbnC8SLH_bvUmwiVu@mail.gmail.com>
To: Sylvain Galineau <sylvaing@microsoft.com>
Cc: 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 Mon, Jul 12, 2010 at 10:40 AM, 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 ?
> I am being told that Modernizr is better than declarative feature
> detection because it 'runs code and checks the results'. In most
> cases, it doesn't do that at all. It checks for simple boolean indicators
> of the existence of a feature. That this is actually sufficient and
> effective in practice does show that we are already much closer to
> declarative feature detection that we think we are. That, imo, is a fair
> statement.

Stating what Modernizr does and doesn't do is obviously fine.
However, stating that and then implying that that's all Modernizr can
or will ever do is unfair.  Modernizr doesn't exist in a hypothetical
universe where browsers are actively malicious.  In the real world, in
current conditions, many features can be accurately tested for with a
trivial existence check.  That's not a property of the feature itself,
or a statement about the efficacy of existence checks.  It's a
statement about the current state of the world - all of the browsers
which support geo expose the property, all of the browser which don't
support geo don't expose the property.  Thus checking the property
correctly splits the world into yes/no groups.

It is in Modernizr's interest to find the simplest and most trivial
test which correctly discriminates, because it's meant to be a
light-weight include that you don't have to think about.  If it was
more expensive, it would have to set things up so that you could
include particular tests that you care about, which would be more
difficult and annoying to use.

>> Modernizr currently relies on super-trivial checks for some features
>> *because it works*.
>
> Precisely. Basic boolean feature detection already works.

For some features, given the current state of browsers.  For other
features, and other times, it doesn't.

>> If a browser started actively lying in the way you suggest, Modernizr
>> would be updated to test more thoroughly.
>
> Of course. That it doesn't need to do more complex testing than checking for
> the presence of a property across so many features tells us something about
> the fear of browser lies destroying the value of declarative feature detection.
>
>> 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.
>
> Past failures are no proof of future ones. But yes, the fact that an
> independent party is doing the testing is a significant factor here.

Indeed.

> Still, given the much higher conformance pressure on browser vendors
> and increasing interop trend these days, I don't believe extrapolating
> from the past is that useful.

While true, I'm still gun-shy about this.

>> 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.
>
> 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 said
> features through a clean, simple standard mechanism.

Yes, it makes it better.  UA detection is an unqualified bad thing.
It's good to make that as hard as possible, so that feature detection
has a comparatively lower cost, because feature detection *is*
generally more expensive.

I think an invalid feature detector is generally still better than an
invalid UA detector.

~TJ
Received on Monday, 12 July 2010 18:20:53 GMT

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