[whatwg] Mechanism to find available events

[Charles McCathieNevile]

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.

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.

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

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.

cheers

Chaals

>> On Wed, 29 Dec 2010, Garrett Smith wrote:
>>>
>>> However, how can a program determine if a particular event is generated
>>> by the browser and fired at a particular object? The `("onhashchange"  
>>> in window)` test should theoretically work, but as mentioned, that
>>> isn't interoperable at this point.
>>
>> Neither is a mechanism to find out if an event is going to be fired. :-)
>
> The *proposed* mechanism isn't interoperable -- is that what you're  
> hinting at?
>
> New events are what will need to be detected. Just like contextmenu
> was not interoperable at one point. Now if, prior to that, there had
> been a mechanism to determine if contextmenu events, the developer
> would not know exactly under which circumstances that would occur, but
> he would at least be in a better position to judge than using
> existence inference?
>
>> Let's get what we have already got implemented correctly before adding  
>> new features that do more or less the same thing.
>>
> Already got what?


-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com