[whatwg] accesskey attribute with display:none elements

[Calogero Alex Baldacchino]

Olli Pettay ha scritto:
> On 11/26/2008 05:35 PM, Calogero Alex Baldacchino wrote:
> anyway I think key events handling may
>> be improved and become easier to adopt by adding to a somewhat interface
>> a few constants representing the modifiers combination used by the
>> browser to activate access keys, so those modifiers could be compared to
>> the modifiers 'carried on' by the key event (this would require support
>> for the DOM 3 Events, which I think could be improved/modified too -- if
>> something like the above is yet present in html5 spec and I've missed
>> it, I apologize).
> 
> Note, accesskey events (http://www.w3.org/2008/webapps/track/issues/40)
> won't be probably defined in DOM 3 Events (which is still just a draft).
> And those events are anyway different thing to this problem.

I agree that access keys and related events are outside the scope of W3C 
DOM, since it defines the basic interfaces to structure (or 'model') a 
generic document in order to make it dynamic and interactive through any 
programming technique (such as scripting), but without defining neither 
the 'interaction context' (i.e. a window object), nor the way to bind 
any part of the document to the 'interacting program' (i.e., embedding a 
script, defining how native events must be generated and binded to an 
element for its activation - and an access key with proper modifiers 
would be such). So, unless an 'accesskey' is thought as necessary for 
any element in every possible kind document, that's out of the most 
generic DOM scope. But when it comes to a specific document, specific 
properties binding to specific contexts can be added in the derived, 
specific DOM, by either deriving an interface (i.e. the HTMLElements 
inherits from the Element interface), or defining a separate interface 
to implement along with other interfaces of the same 'level' (i.e. the 
HTMLDocument interface does not inherit from the Document interface, yet 
both interfaces are implemented by an html document node). The latter 
whould be the case: since the accesskey attribute is specific to html 
elements and the key modifiers are specific to the user agent and to the 
underlying platform, an interface could be created, such as an 
'HTMLKeyboardEvent', with just a read only boolean attribute, such as an 
'activationKeys', telling whether the activation modifiers have been 
pressed; then such interface should be declared as necessary along with 
the DOM 3 KeyboardEvent, but, being separated (nor even inherited) from 
the latter, any change on DOM 3 Events draft wouldn't be 'traumatic' 
(once the drafte stabilized, the Window interface, which represents the 
browsing context for any document in a... browser, could declare the 
list of modifiers provided to activate a document element -- right now 
keyboard events are inited with a string representation of modifiers, 
though I'd prefer numeric values available for bitwise or operations, 
like Java virtual key codes, but that's another issue, and is off topic 
here).

Let's come to your concern.

> 
> I'd want it to be specified somewhere how accesskeys should behave in
> display:none content.  Because of the valid use case (dhtml menus) and
> the current behavior of FF2/Safari/Opera and it-is-used-in-the-web, I think
> allowing those accesskeys to work should be ok.
> Of course if there is some *good* argument why they shouldn't work, that
> behavior should be standardized.
> 
> br,
> 
> -Olli

Perhaps a *goog* rationale could be, "if you can't see the control, and 
you can't reach (focus) the control and activate it 'normally', because 
the control is not presented to you as a part of the document, how can 
you be deemed aware of the control and of the way it can be activated? 
that's not the top of usability" (this is especially true for assistive 
technologies, which, as yet told by another contributor, may likely 
skeep everything which is not in the document presentation. -- from the 
usability point of view, the question is even more complex, since there 
is a current of thought considering the presentation of shortcut keys 
inside a menu item, along with it's label and underscored activation 
key, as a wrong practice, but the reasons of such are off this topic, so 
I'm not going any deeper about that). Another rational might be, "the 
same desired behaviour, both visual and 'operational', can be achieved 
without resorting to 'display:none' elements, so there is no need to 
'break' the document presentation and allow the user interact with 
something which is not presented to him/her". So, I stand up for 
standardizing the "disallow accesskey activation for 'display:none' 
elements" behaviour. Regards,
Alex.
 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Scegli la tua suoneria! Il meglio della musica sul tuo cellulare! 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8269&d=27-11