[whatwg] Mechanism to find available events

On 5/1/11, Charles McCathieNevile <chaals at opera.com> wrote:
Unsupported, uninformed opinion and red herrings.

> On Sat, 30 Apr 2011 02:19:24 +0200, Garrett Smith <dhtmlkitchen at gmail.com>
> wrote:
>
>> On 4/29/11, Ian Hickson <ian at hixie.ch> wrote:
>>
>> [...]
>>>> We need a mechanism to detect accurately the features of the browser
>>>> our code's running in, without relying to UA sniffing madness.
>
>>> No such mechanism can exist without actually using the feature, because
>>> there's no way to guarantee that a browser will accurately report what
>>> it supports. Every time we've had such a feature (e.g. DOM hasFeature())
>>> vendors have ended up returning inaccurate values.
>>
>> Is it possible to design something better than hasFeature?
>>
>> Method hasFeature can be expected to have the problems it has because
>> it is not related to any specific object (Node, window, document). As
>> such, this method requires the implementation (browser) to make an
>> unreasonable generalization. Requiring the unreasonable is
>> unreasonable.
>
> True, but I think there is a deeper problem. Browsers need to be roughly
> compatible with sites. From a user perspective, that means "it more or
> less works" while from a site developer's perspective that often means "it
> works exactly as I designed it". This puts the browser and the site author
> in direct conflict, and while the site developer might feel that the user
> is being unfairly hampered if the browser doesn't perform as desired
> torender the site to "its best advantage", the browser feels the user is
> unfairly served if they are being told to go through the hassle of
> changing browsers because of some trivial difference in rendering or
> performance.
>
Red herring.

Subject is: "Re: [whatwg] Mechanism to find available events"

> So we can make all the technical improvements we want. But so long as
> there is a conflict in goals for how to use a feature, as there often is
> with hasFeature(), it is extremely unlikely that we can make that feature
> work in a way that satisfies everyone.
>

Nobody proposed improving hasFeature. I have said many times that the
feature can't be expected to work; it's broken by design.

>> If instead, there were a method designed to check the object in
>> question, it could be specified to require the implementation also
>> check that object's capabilities.
>>
>> I'm not suggesting unequivocal (e.g. right click triggers a context
>> menu) -- that seems too much. I'm suggesting a more closely related
>> inference check.
>>
>> Is a mechanism such as this possible? Why rule it out?
>
> It is possible, but it isn't clear that it will work as you anticipate,

What "it"? Nevermind, I probably shouldn't ask.

> and reasonably likely that it won't for the same non-technical reasons
> hasFeature() doesn't. Improving (or replacing) hasFeature isn't an
> intrinsically bad idea, but it isn't useful without working out how to
> resolve those non-technical issues.
>
> The mobile world (whose UA-sniffing requirements make the one-Web goal on
> Desktop look like a solid reliable reality where developers' lives are
> trouble-free and pleasant) has an alternative solution that is based
> around crowd-sourcing the information on whether something is supported.
> It *is* UA-sniffing madness by most definitions, and it relies on huge
> amounts of data and a system for managing conflicting statements via
> simple trust modelling (it theoretically offers massive scope for abuse
> that permits direct market manipulation), but it has worked well enough
> for them that it is extremely widely used, and the approach has been
> repeated, "merely making technical refinements", over successive
> generations of the technology.
>
Oh boy ,here we go...

When if ever is browser sniffing a "requirement"? It is
(euphamistically speaking)  technological solution. The discussion of
why it is an awful solution to the "too many browsers" problem is off
topic. Yep, this is another red herring. It's so outlandish that it
almost appears as trolling or flame bait. But again, we can forget all
about that.

> Going down that path of course doesn't allow you to do the work
> client-side, which is also a problem for the use-case you're looking at.


> But in an area where I mostly see bad alternatives, it is another option
> that could be the lesser of the available evils in some circumstances.
>
You're imagining something here.

> cheers
>
You have sidetracked the discussion.
-- 
Garrett

Received on Sunday, 1 May 2011 22:40:43 UTC