Skip navigation.

exploreopera

| Help

Sign up | Help

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..

Facebook, or how to make me trust a websitealignment of megaliths

Comments

avatar

By hartley231, # 16. May 2007, 15:34:00

avatar
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:\n\tcNode='+cNode+'\n\tactiveElement='+document.activeElement+'\n\t'+((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 doesnt

Edit: I guess the Facebook link doesnt work because of the span in the anchor element? Never the less in IE7 it work as expected

By Stoen, # 18. May 2007, 03:40:34

avatar
Stoen: nice test script, thanks. The link click issue was indeed the problem I was investigating.

By hallvors, # 18. May 2007, 10:12:41

avatar
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.

By hallvors, # 18. May 2007, 10:48:48

avatar
(and if anyone wants to explore futher here's a playground you could build futher tests on:
http://files.myopera.com/hallvors/testcases/activeElement.htm )

By hallvors, # 18. May 2007, 10:53:42

avatar
"if the active element is removed from the document, activeElement is BODY"

Try it here:
http://msdn2.microsoft.com/en-us/library/ms537505.aspx

Repeatedly 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.

By tarquinwj, # 18. May 2007, 11:22:35

avatar
I should leave Spec writing to the master of Documenting things :-D
Thanks for both asking and answering questions :wink:

By hallvors, # 20. May 2007, 09:10:48

Write a comment

You must be logged in to write a comment. if you're not a registered member, please sign up.