[whatwg] Mechanism to find available events
chaals at opera.com
Sun May 1 13:29:31 PDT 2011
On Sat, 30 Apr 2011 02:19:24 +0200, Garrett Smith <dhtmlkitchen at gmail.com>
> 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
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
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.
>> 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
More information about the whatwg