Re: [whatwg] Mechanism to find available events
On Sat, 30 Apr 2011 02:19:24 +0200, Garrett Smith dhtmlkitc...@gmail.com wrote: On 4/29/11, Ian Hickson i...@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
Re: [whatwg] Mechanism to find available events
On 5/1/11, Charles McCathieNevile cha...@opera.com wrote: Unsupported, uninformed opinion and red herrings. On Sat, 30 Apr 2011 02:19:24 +0200, Garrett Smith dhtmlkitc...@gmail.com wrote: On 4/29/11, Ian Hickson i...@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
Re: [whatwg] Mechanism to find available events
On Wed, 29 Dec 2010, Jorge wrote: On 29/12/2010, at 08:27, Ian Hickson wrote: On Mon, 20 Sep 2010, Biju wrote: We need HTMLNode.getSupportedEvents() == returns a text array of event names HTMLNode.isSupportedEvent(eventName) == returns true/false Many times in particular version of browser we dont know whether an HTMLNode/window support particular event. Or what are the alternate events available, so that we can refer some document or do some test to find how it can be used. So I wish we had above methods available. What do you mean by supports an event? You can dispatch any event you want to any event target. It's not you, it's whether *the*browser* dispatches it. Say, oncontextmenu : The code specified by this attribute is called when the associated element is right-clicked or when the mouse button is held down long enough to generate a contextual menu. How could your program detect, unequivocally, that the browser it's running in would dispatch an oncontextmenu when the element is right-clicked or when the mouse button is held down long enough to generate a contextual menu ? 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. 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. :-) Let's get what we have already got implemented correctly before adding new features that do more or less the same thing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Mechanism to find available events
On 4/29/11, Ian Hickson i...@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. 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? 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? -- Garrett
Re: [whatwg] Mechanism to find available events
On 12/29/2010 09:27 AM, Ian Hickson wrote: On Mon, 20 Sep 2010, Biju wrote: We need HTMLNode.getSupportedEvents() == returns a text array of event names HTMLNode.isSupportedEvent(eventName) == returns true/false Many times in particular version of browser we dont know whether an HTMLNode/window support particular event. Or what are the alternate events available, so that we can refer some document or do some test to find how it can be used. So I wish we had above methods available. What do you mean by supports an event? You can dispatch any event you want to any event target. Exactly. And not all events have corresponding onfoo property. And extension and Greasemonkey scripts can add support for any new event types. -Olli
Re: [whatwg] Mechanism to find available events
On 9/20/10, Jonas Sicking jo...@sicking.cc wrote: [...] Indeed, in general we have very poor handling of on* properties. https://bugzilla.mozilla.org/show_bug.cgi?id=414853 What are the plans for fixing that? -- Garrett
Re: [whatwg] Mechanism to find available events
On 29/12/2010, at 08:27, Ian Hickson wrote: On Mon, 20 Sep 2010, Biju wrote: We need HTMLNode.getSupportedEvents() == returns a text array of event names HTMLNode.isSupportedEvent(eventName) == returns true/false Many times in particular version of browser we dont know whether an HTMLNode/window support particular event. Or what are the alternate events available, so that we can refer some document or do some test to find how it can be used. So I wish we had above methods available. What do you mean by supports an event? You can dispatch any event you want to any event target. It's not you, it's whether *the*browser* dispatches it. Say, oncontextmenu : The code specified by this attribute is called when the associated element is right-clicked or when the mouse button is held down long enough to generate a contextual menu. How could your program detect, unequivocally, that the browser it's running in would dispatch an oncontextmenu when the element is right-clicked or when the mouse button is held down long enough to generate a contextual menu ? We need a mechanism to detect accurately the features of the browser our code's running in, without relying to UA sniffing madness. -- Jorge.
Re: [whatwg] Mechanism to find available events
On 12/28/10, Ian Hickson i...@hixie.ch wrote: On Mon, 20 Sep 2010, Biju wrote: We need HTMLNode.getSupportedEvents() == returns a text array of event names HTMLNode.isSupportedEvent(eventName) == returns true/false Many times in particular version of browser we dont know whether an HTMLNode/window support particular event. Or what are the alternate events available, so that we can refer some document or do some test to find how it can be used. So I wish we had above methods available. What do you mean by supports an event? You can dispatch any event you want to any event target. No response from the OP yet, so I'll chime in. Sure, any event can be dispatched to any event target, even made up events. 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. Another strategy for making inferences about event handler properties is to set an event handler attribute, then check the corresponding DOM property, a la `isEventSupported`. This can work but can be tricky for window properties. Yet another approach, mentioned recently on www-dom by Jacob Rossi (though a similar approach was proposed by RobG on c.l.js (or was it iPhone GG?) about two years ago), is to synthesize an event, fire it at a target, and then check the properties of the dispatched event. While that can give valuable information, it does not tell specifically if the browser will create and fire event at the target. Aside from that, the event generation APIs are just awful, and for that, again, I've reified the proposal for extensible event synth API that takes an interface name and a properties object to replace the multiplicitous methods with excessive, unmemorable, and brittle argument lists. The proposed `eventTarget.generatesEvent` would provide a good inference about what events will be fired at an element. It is not intended to be comprehensive about plugins but it would be a useful standard replacement for `isEventSupported`. I don't mind the method name; perhaps instead `eventTarget.isEventTargetFor`. What is stopping generatesEvent/isEventTargetFor from being considered here? -- Garrett
Re: [whatwg] Mechanism to find available events
On 12/29/10, Garrett Smith dhtmlkitc...@gmail.com wrote: [...] Aside from that, the event generation APIs are just awful, and for that, again, I've reified the proposal for extensible event synth API that takes an interface name and a properties object to replace the multiplicitous methods with excessive, unmemorable, and brittle argument lists. Badly written and not proofread. What I meant was: I've reified the proposal for extensible event synth API that takes an interface name and a properties object and posted it on www-dom thread DOM event detection (URL below). The API is intended to replace the multiplicitous methods that have excessive, unmemorable, and brittle argument lists, e.g. initMouseEvent, initKeyboardEvent, initTextEvent, et al. DOM event detection http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0188.html -- Garrett
Re: [whatwg] Mechanism to find available events
On Mon, 20 Sep 2010, Biju wrote: We need HTMLNode.getSupportedEvents() == returns a text array of event names HTMLNode.isSupportedEvent(eventName) == returns true/false Many times in particular version of browser we dont know whether an HTMLNode/window support particular event. Or what are the alternate events available, so that we can refer some document or do some test to find how it can be used. So I wish we had above methods available. What do you mean by supports an event? You can dispatch any event you want to any event target. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Mechanism to find available events
https://bugzilla.mozilla.org/show_bug.cgi?id=264525 We need HTMLNode.getSupportedEvents() == returns a text array of event names HTMLNode.isSupportedEvent(eventName) == returns true/false Many times in particular version of browser we dont know whether an HTMLNode/window support particular event. Or what are the alternate events available, so that we can refer some document or do some test to find how it can be used. So I wish we had above methods available.
Re: [whatwg] Mechanism to find available events
On Mon, Sep 20, 2010 at 11:37 PM, Jonas Sicking jo...@sicking.cc wrote:
if (onhashchange in document.body) {
...
}
assuming
if ('onhashchange' in document.body) {
That should solve one issue, but Firefox is not doing that for all events,
example:- 'onbeforeunload' in window === gives false
also there is no way to discover the all the available events for a node.
Re: [whatwg] Mechanism to find available events
On Mon, Sep 20, 2010 at 8:50 PM, Biju bijumaill...@gmail.com wrote:
On Mon, Sep 20, 2010 at 11:37 PM, Jonas Sicking jo...@sicking.cc wrote:
if (onhashchange in document.body) {
...
}
assuming
if ('onhashchange' in document.body) {
That should solve one issue, but Firefox is not doing that for all events,
example:- 'onbeforeunload' in window === gives false
also there is no way to discover the all the available events for a node.
Indeed, in general we have very poor handling of on* properties. Our
code for dealing with that needs a rewrite.
But my point was that I think the spec already might have a mechanism
for dealing with what you are asking for. So we should encourage
implementations to implement the spec properly, rather than adding
other mechanisms and hoping that browsers get those more right.
/ Jonas
