Re: Selecting for features

On Sat, Jul 10, 2010 at 7:53 PM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
>>Certainly, but that's already an issue. We already have browser vendors claiming full compliance when that's not necessarily the case; they just do it in marketing
>> rather than in code.
>
> That the code returns a match only reflects the developers' belief that they have implemented the feature properly. That is not the same as marketing collateral which no JS code or stylesheet can easily depend on. One can argue that it's not fundamentally any different than what authors already do using libraries such as Modernizr.

There is a fundamental difference between your proposal and Modernizr.
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. Feature *detection* and
feature *deceleration* are two different things. I think that this
library is the best answer to your use case.

> It's quite possible that a browser will make the wrong claim every now and then but that is only a new incentive to fix the underlying bugs as every declaration block they erroneously match could make web pages look worse in their UA.

Or the browsers would mark "yes" and people would come to depend on
the broken functionality thinking that the "yes" means "final". The
browsers would then not be able to change their browser to the actual
correct implementation as developers won't expect the working (ie
marked true) features will change.

> That the mechanism may fail in some cases in practice is no good reason to not try to come up with a standard solution for a very popular feature request imo.

The question is: does the benefit outweigh the downsides? In this case
it likely does not.

-- 
Eitan Adler

Received on Sunday, 11 July 2010 04:02:42 UTC