- From: Doug Schepers <schepers@w3.org>
- Date: Sun, 22 Feb 2009 13:18:16 +1100
- To: Ian Hickson <ian@hixie.ch>
- CC: Jonas Sicking <jonas@sicking.cc>, Olli Pettay <Olli.Pettay@helsinki.fi>, HTML WG <public-html@w3.org>, www-svg <www-svg@w3.org>
Hi, Ian- Sorry, I had an action to respond to this, and meant to do so earlier, but I had other demands on my time, and I was trying to work up tests for existing browser behavior. Responses inline... Ian Hickson wrote (on 2/12/09 5:37 PM): > On Thu, 22 Jan 2009, Jonas Sicking wrote: >> On Thu, Jan 22, 2009 at 4:45 PM, Ian Hickson <ian@hixie.ch> wrote: >> > On Mon, 25 Aug 2008, Doug Schepers wrote: >> >> >> >> We have an issue with SVG that we think applies to HTML UAs as well, >> >> and we'd like to align. >> >> >> >> When an element (such as a form field) has focus, and is removed from >> >> the DOM or hidden with e.g. display:none, what should happen with the >> >> focus? >> >> >> >> * Should the element lose focus? >> >> * If it does lose focus, should it throw a blur/focusout event? >> >> * If it does lose focus, where should the document focus go? >> >> * If it doesn't lose focus, should it still receive e.g. keyboard events >> >> when it is in that removed/hidden state? >> >> * If the element is replaced in the DOM, should it regain focus? >> >> * If the element is unhidden, should it regain focus? >> >> * If it does regain/keep focus, should it subsequently begin/keep >> >> receiving events? >> >> >> >> We have a simple test case that seems to indicate that HTML UAs vary >> >> on this: >> >> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0171.html > > http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7 > >> >> Some seem to lose focus, or partially lose focus (retain focus, but >> >> can't receive keyboard events), or lose focus completely. >> >> >> >> We think that the element should lose focus, through a blur/focusout >> >> event, that the focus should go to the document root, and that the >> >> element should not regain focus upon becoming available again. >> > >> > Did the SVG working group come to a conclusion on this issue? >> >> But I too think it'd be great, if not vital, that HTML and SVG do the >> same thing here. > > I couldn't find the relevant text in SVG 1.2 Tiny. Since we didn't get an answer right away (we understand, everyone's busy), the SVG WG decided not to make a conclusion in SVG Tiny 1.2, pending coordination with the HTML WG and browser implementers. > I have made the spec require what is described above as the behavior > desired by the SVG working group. That is, of course, acceptable to the SVG WG. If it is also acceptable to the HTML WG and the browser implementers, we think it would be a nicely consistent behavior for authors. Since there has been little interoperability up to this point, it seems unlikely that there is existing content that relies on any given behavior, but if you have examples to the contrary, that should be taken into account. I did some more testing (the reason for the tardy reply), and it still seems that there is no consistent behavior, though it does seem more consistent than it did when we first tested it (which seems to indicate that there has been some implementation movement here). According to my tests, removing an element removes the focus from it permanently, while making it display:none lets the focus shift back to it after it has display:inline reapplid (though browsers differ as to whether they then allow e.g. an input field to receive text input). I think it would be better to have more consistency, as we described above. Note that there doesn't seem to be a way in HTML to detect which element, if any, is the currently focused element. You can do this in SVG, via the getCurrentFocusedObject() method which returns an event target, and we suggest that HTML5 do something similar. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Sunday, 22 February 2009 02:18:28 UTC