[whatwg] activeElement

On Thu, 17 May 2007, Hallvord R M Steen wrote:
> if WHATWG is defining document.activeElement, perhaps the WHAT spec 
> should match IE's behaviour more closely on some points. I refer to: 
> http://www.whatwg.org/specs/web-apps/current-work/#activeelement
> * when the document is loaded, before any interaction activeElement is 
> the body element (!) (probably not important, I doubt any site would 
> rely on this)

I've made the default the <body> element instead of the root element, 
which does indeed seem to more accurately reflect IE's behaviour.

> * activeElement is set after mousedown. (important, maybe implied by 
> other stuff about focus handling? I didn't test keydown for e.g. tabbing 
> but pretty sure the same applies.)

This flows from the fact that that's when focus is set. It would vary on a 
platform with different focusing semantics.

> * 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 
> (important, and the offsetParent stuff isn't covered in the current 
> spec)

I couldn't reproduce this. In my testing, only positioned <div> and <span> 
elements were magical in this way.

For example, click the "uuu" text on this test case and you'll see the 
offsetParent (written to the log) is the B element, but the activeElement 
is the DIV element.


I haven't made the spec let positioned <div> and <span> elements get 
focused in this way, because whether an element is positioned or not 
should have no bearing on the semantics of the document.

> * it keeps pointing to the same element until another interaction with 
> the document sets it again (important)

That's already in the spec.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 4 June 2007 21:15:34 UTC