RE: Selecting for features

> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Monday, July 12, 2010 11:20 AM
> To: Sylvain Galineau
> Cc: Eitan Adler; Adrian Price; David Woolley; www-style@w3.org
> Subject: Re: Selecting for features


> 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.  

Where and how did I do that ? That certainly was not my intention.
I am saying that if this all the Modernizr team has to do today for 
so many features then maybe some of the concerns about letting browsers 
declare feature support *might* be overblown to some degree.

> Modernizr doesn't exist in a hypothetical universe where browsers are 
> actively malicious.  

I am not concerned about malicious implementation except for the sake
of argument. It is enough to consider that the presence of a property 
says next to nothing about the completeness, interop or quality of a 
feature's implementation. Yet, this works just fine for many authors' 
purposes. That's notable and a very relevant fact in this debate.

> 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.

Without a definition of what 'support' means, this doesn't seem that useful
in practice. Do they support the same geoloc functionality in an interoperable 
manner as defined by a reasonably complete set of testcases ? Can an author 
trust the geo code he wrote and tested in Chrome will work unchanged in Firefox 
on the basis of this Modernizr check ? I honestly don't know what the answer is 
in this specified case, but if yes how was that established ?

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

I'm sure that's true. I'm also sure that's totally insufficient to lean
one way or the other on this topic.

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

> 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.

We agree on this last one.

I think the underlying issue here is: when does a browser vendor make their 
platform declare support for a feature ? The significant concern seems to be 
that browser makers have every incentive to do so as early as possible. While 
the Modernizr folks not only work after the fact but have every incentive to 
get it right.

Thus what we ideally want is a clear, verifiable criteria for a UA to claim support.
For instance: the spec/feature is in CR, the testsuite for the spec/feature is
stable, an implementation report has been submitted showing the browser passes all 
current testcases for the feature. 

One may argue that this will be expensive and slow given the lag between implementation
and the availability of a complete, stable test suites. But as I am of the opinion 
that we should all write and submit testcases earlier in the process, I don't mind 
creating an incentive for browser vendor to do just that. Never mind the extra incentive 
to stabilize specifications in a timely manner as implementations ship.

Received on Monday, 12 July 2010 19:51:55 UTC