quick spec for IEs document.activeElement

document.activeElement is an IE thing. Opera supports it partially, and this is basically what one would need to do to match IE's behaviour (after some very quick and cursory testing):

  • when the document is loaded, before any interaction activeElement is the body element (!)
  • activeElement is set after mousedown.
  • it is set to the event's target if it is "focusable" (A, INPUT, BUTTON etc.), otherwise it is set to the event's target's .offsetParent
  • it keeps pointing to the same element until another interaction with the document sets it again

It is also set when you tab through links and form fields. In Opera, spatial navigation and other keyboard navigation should of course set it too.

Haven't checked if the WHATWG or WebAPI are already embracing and/or extending it..

Advertisements

10 thoughts on “quick spec for IEs document.activeElement

  1. Am I missing something?

    opera.addEventListener('AfterEvent.mousedown',function(ujsEv) {
      var ev = ujsEv.event,
        target = ev.target,
        cNode = target && target.selectSingleNode('ancestor-or-self::*[ ((name()="a" or name()="area") and @href) or name()="input" or name()="button" or name()="textarea"]');
      //target.setActive();
      //Method not supported
      //target.focus();
      //Works better
      opera.postError('Clickity Click:ntcNode='+cNode+'ntactiveElement='+document.activeElement+'nt'+((cNode==document.activeElement)?'Same':'Different'));
    },false);
    

    Doesnt seem to work very well on links (buttons and inputs seem to work ok). Uncommenting target.focus() seems to improve things, but still doesnt work properly all the time eg. the "Blog", "Links", "Friends", "About" links work with target.focus() but the link to your Facebook post doesntEdit: I guess the Facebook link doesnt work because of the span in the anchor element? Never the less in IE7 it work as expected

  2. Some more details for Tarquin :-)* when tabbing, IE sets activeElement after keydown events are sent but before blur and focus events.* if focus leaves the document because of keyboard navigation (for example because user focuses the address bar), activeElement is null. It is set to null This doesn't happen if the address bar is focused by a mouse click, which is consistent with the observation that it is set before the blur event and not by the blur event.* if the active element is removed from the document, activeElement is BODY.

  3. "if the active element is removed from the document, activeElement is BODY"Try it here:http://msdn2.microsoft.com/en-us/library/ms537505.aspxRepeatedly run this:javascript:void(document.activeElement.parentNode.removeChild( document.activeElement)); alert(document.activeElement?document.activeElement.tagName: document.activeElement);Notice it seems to step up a series of divs, until it reaches the body. The divs are the offsetParents (tested on my own page). Finally, if you delete the body, it becomes null.On my own site, that triggers standards mode (the MSDN site triggers quirksmode), deleting the body gives the HTML element. Deleting the HTML element gives null. Again, that makes sense wrt offsetParents, since the offsetParent of body is null in quirks, but since it can be rendered separately from the viewport/HTML in standards mode – as it is with my site – and that makes it the offsetParent of BODY.So basically, the algorithm is:If the active element is deleted from the document, the active element becomes the offsetParent of that element. If the element has no offsetParent, then the activeElement becomes null. If the element and its offsetParent are deleted at the same time:document.activeElement.offsetParent.parentNode.removeChild( document.activeElement.offsetParent)then the activeElement becomes the offsetParent of the element's offsetParent – basically stepping up the offsetParent chain until it finds something that still exists – or null if it steps off the end of the offsetParent chain.

  4. I should leave Spec writing to the master of Documenting things :-DThanks for both asking and answering questions 😉

  5. I see that Opera also returns an input element if you have merely pre-focused it with spatial navigation. Is that correct? I guess not but perhaps you guys found use cases for it.Anyhow, it breaks a little keyboard navigation user script I'm making. How can we detect pre-focus as opposed to real focus in Opera?

  6. Hi F_V, I'm not absolutely sure I see the use case for detecting pre-focus.. Can you explain how your script breaks because of the prefocus feature?

  7. The script is a user script that uses a hotkey to enumerate all links on the page for quick keyboard access (see FF's mouseless browsing extension). I use the hotkey L. Using activeElement to check if current focus is in a form field (you don't want the feature to trigger whenever typing an L in a form field) I notice I can't start the script when prefocus happens to linger on a form field. However one can still use Opera's single-key shortcuts when prefocus is around a form field, the shortcuts go to the page not the form.Per definition, an "active" element is the one that takes input. As prefocused elements don't I guess prefocus shouldn't influence activeElement.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s