This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec says: "Note: The attributes marked with an asterisk have a different meaning when specified on body elements as those elements expose event handlers of the Window object with the same names." The following attributes are asterisked: onblur, onerror, onfocus, onload. For improved interop with other browsers we would like the list to be defined as follows: * onmouseup, * onmousemove, * onmouseover * onmouseout * onclick * onkeyup * onkeypress * onkeydown * on[before][de]activate * oncontextmenu * ondblclick * focusin * focusout * onmouseenter * onmouseleave * onmousewheel * on[before]copy
Opera: onblur onfocus onhashchange onload onmessage onresize onscroll onstorage onunload WebKit: onbeforeunload onblur onerror onfocus onhashchange onload onmessage onoffline ononline onpopstate onresize onstorage onunload Mozilla doesn't do this in the same way so I wasn't able to get a good list easily.
Removing from those lists the event handlers that HTML doesn't define on elements, we get: Opera: onblur onfocus onload onscroll WebKit: onblur onerror onfocus onload The list in the spec is: onblur onerror onfocus onload onscroll It seems therefore that the spec is consistent with what is required for interoperability. In particular, none of the browsers I tested support the mouse or key events on document.body as mirroring the Window equivalents, and none seem to support the "[before][de]activate", "[before]copy", and "focus[in/out]" events. (Unfortunately I don't have access to Windows currently so could not test IE.) EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The spec seems to specify what is necessary for interop. If my testing is incorrect please provide test cases demonstrating the problem and reopen the bug. Thanks!
The interop concern is when attempting to interact with the "blank" area of a page (below the content contained by the <body> element. If the <body> handlers are not forwarded to the window, then the body element itself must register the listeners; and given that the blank area under the <body> is represented by the <html> element, then user-actions that would expect to trigger the events specified on the <body> would not fire because the target of the events is the <html> element. This is IE9's current behavior, which is not compatible with its own "Quirks Mode" because in Quirks mode, the <body> _is_ the full viewport, while in non-quirks mode the <html> element is the viewport and manifests this compatibility difference. Our testing of the above scenario show that Firefox forwards the handlers to the window. WebKit has no need to do the forwarding because the <body> seems to act as the viewport itself in this scenario.
Here's the details and testing methodology; please reconsider the resolution. <!DOCTYPE html><html><head> <!-- This shows that in Firefox/IE9/Opera, for a full screen browser window, the body element is only a small block of yellow, the rest of the page is grey, represented by the HTML element. Chrome treats the body as the viewport which is not compliant with CSS 2.1 AFAIK, therefore I automatically disqualify it from this testing --> <style>html { background-color: grey; } body { background-color: yellow; } </style> </head> <body onclick="alert('Target: '+event.target + '\nCurrentTarget: '+event.currentTarget)"> Here's some text in the body element.</body> </body> </html> So, open the test page in IE9, and click anywhere in the grey area (html element). The event model will dispatch the click event to the HTML element and bubble it down from there. If the body element retained the onclick event handler, I would expect no alert to fire, and indeed this is what happens in IE9. This is not the best behavior for the web, however, because many sites expect those handlers to work and fire in the grey areas of the webpage (e.g., context menus). I believe that without a spec change, that IE9's behavior is correct "per spec". I like Firefox's approach. In Firefox, the body element's onclick content attribute is mirrored on the window's onclick IDL attribute (the two are bound together, just like onblur, onfocus, etc.; those content attributes marked with an asterisk). So, in the above scenario, the parser actually assigns the onclick handler to the window. This is verified by the target and currentTarget of the alert when it fires: Target: HTMLHtmlElement, currentTarget: Window Opera supports this scenario, but not in the way firefox does--apparently they fire the click event with target:HTMLBodyElement, and currentTarget: HTMLBodyElement. This doesn't make much sense to me because I'm clicking on the HTML element, but at least the event fires. As noted in the test comment above, Chrome works in this scenario also because I can't click on the HTML element--the BODY element takes up the whole viewport. My conclusion is to have the spec changed by adding more of the body element's content attributes to the list of event handlers mirrored on the window. My testing in Firefox concludes that the list should be [at least]: * onmouseup, * onmousemove, * onmouseover * onmouseout * onclick * onkeyup * onkeypress * onkeydown * oncontextmenu * ondblclick I hope this helps, -Travis
Interesting, Firefox does indeed do that. Weird. Every other browser I tested (Chrome dev, which fixes the bug you mentioned; Opera 10.x; IE8) does this the way the spec describes. Given that the behaviour is somewhat reasonable, I think following the path of least resistance to interop is the way to go here (i.e. go with the majority of implementations). Note that working around this as an author is trivial - just move the onclick="" from <body> to <html>. That already works in all the browsers I tested (IE8, Firefox, Chrome, Opera, Safari). This isn't the case for onload="", onblur="", etc, which is why it makes sense to have them special-cased on <body>. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: see above
(In reply to comment #4) > This is not the best behavior for the web, however, because many sites > expect those handlers to work and fire in the grey areas of the webpage (e.g., > context menus). Do you know any URLs for sites that expect that (either standards mode or quirks mode)?