Re: [whatwg] accesskey attribute with display:none elements
On Fri, 28 Nov 2008 05:01:42 +1100, Olli Pettay
wrote:
On 11/27/2008 06:52 PM, Calogero Alex Baldacchino wrote:
Perhaps a *good* rationale could be, "if you can't see the control,
There are other modalities than just visual.
Sure. But users generally expect the page to work the same dependent on
usage, not dependent on their modality (which the page can't be sure of
anyway).
So, I stand up for
standardizing the "disallow accesskey activation for 'display:none'
elements" behaviour.
So you're willing to break accesskeys on some websites.
Note, I'm not very strongly supporting accesskeys on display:none
elements, but breaking existing web sites doesn't sound good.
In principle I think it makes good sense for accesskeys not to work on
things that are disply:none. But in practice, I think Olli's argument ("it
ain't broke so lets not 'fix' it - especially in a way that breaks stuff")
is the one that carries the most weight.
cheers
Chaals
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay ha scritto:
On 11/27/2008 06:52 PM, Calogero Alex Baldacchino wrote:
Perhaps a *good* rationale could be, "if you can't see the control,
There are other modalities than just visual.
Indeed, and the display property applies to every and each the very same
way. From http://www.w3.org/TR/CSS21/visuren.html#propdef-display
'display'
Value: inline | block | list-item | run-in | inline-block | table
| inline-table | table-row-group | table-header-group |
table-footer-group | table-row | table-column-group | table-column |
table-cell | table-caption | none | inherit
Initial:inline
Applies to: all elements
Inherited: no
Percentages:N/A
*Media: all*
If you care of any media aving trouble with 'display:none' (and might be
for a visual browser + a screen reader), you have to change the value
for that media. But if one can afford to write different style sheets
for different media, one can also afford to avoid 'display:none' at all
when it comes to interaction, and instead emulate it by setting a bounch
of other properties so that the element occuped 1px or so, without
affecting heavily the overall visual layout, and without problems with
non-visual media (but there is another possibility, yet working only
with css 2 compliant browsers: a menu can have an absolute positioning,
or being floating, and a zindex telling if it's in front of or behind
another element, which in turn can be opaque, so switching the zindex
could work as fine as switching the display property).
> So, I stand up for
standardizing the "disallow accesskey activation for 'display:none'
elements" behaviour.
So you're willing to break accesskeys on some websites.
HTML *5* is the next evolution of HTML, that means it's almost a new
language looking backward with one eye and forward with the other,
carrying on something from the past and throwing away somthing else,
finding some compromises for the transition phase. I think that hiding
something to the user (whatever is the presentation modality), as if
that wasn't in the document at all ('display:none' as a stronger
semantics than just being hidden, invisible, behind something, and so
on), but expecting the user would interact with that, is not the best
possible practise, and since, as far as I remember, there have never
been assurances on good working of accesskeys, a break with old,
non-standard behaviours could not be a "murderer". But, however...
Note, I'm not very strongly supporting accesskeys on display:none elements,
but breaking existing web sites doesn't sound good.
-Olli
but the question could be another. The new behaviour of FF3 breaks
compatibility with existing HTML *4* (or xhtml) sites, without being an
HTML *5* *only* browser (perhaps, at some point in the future, html 5
could become the 'older' backward compatibility basis, like today
browsers provide older features, i.e. document.all or document.layer,
along with newer DOM features), so that break, though not being in
contrast with any standard, could be deemed a kind of bug. My point now
is: let's state *HTML 5* elements cannot be activated through accesskeys
when they have a display propery of 'none', but user agents are left
free (after all that's never been a standard) to activate non-HTML 5
elements with the property 'display:none' for backward compatibility.
That should mean the old, non-standard behaviour could be turned on for
existing websites just by adding a dtd reference in the doctype
declaration. Does it sound acceptable at you?
Regards, Alex.
--
P.S. I take it separate because off topic, but I'd really consider
something like,
HTMLKeybordEvent{
readonly boolean attribute activationModifiers;
}
independent from generic DOM keyboard events, yet easily bindable to
them and quite safe from changes in DOM 3 Events Working Draft.
--
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=28-11
Re: [whatwg] accesskey attribute with display:none elements
On 11/27/2008 06:52 PM, Calogero Alex Baldacchino wrote: Perhaps a *good* rationale could be, "if you can't see the control, There are other modalities than just visual. > Another rational might be, "the same desired behaviour, both visual and 'operational', can be achieved without resorting to 'display:none' elements, Not easily, at least not very easily. > So, I stand up for standardizing the "disallow accesskey activation for 'display:none' elements" behaviour. So you're willing to break accesskeys on some websites. Note, I'm not very strongly supporting accesskeys on display:none elements, but breaking existing web sites doesn't sound good. -Olli
Re: [whatwg] accesskey attribute with display:none elements
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
Re: [whatwg] accesskey attribute with display:none elements
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'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
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay ha scritto:
On 11/26/2008 02:34 AM, Calogero Alex Baldacchino wrote:
A
better way to do what you aim would consist of setting a listener for
key events on a displayable element and choosing a different operation
basing on the pressed key(s);
This is not content author friendly way to do it, because different
browsers/OSes
use different keys to activate accesskey targets.
-Olli
On one hand, whoever wished to write a 'complex' web application, with
keybord shortcuts, should be aware of this concern and try and deal with
it, since it's even more complex than you wrote, and might affect
accesskey attributes too. The problem is, keybord shortcuts have always
been strongly platform-dependent, while the web is aimed as a somewhat
cross-platform architecture, so both accesskeys and key events handling
cannot be 'fully author friendly'. I mean, a somewhat browser, on a
somewhat OS, might use the same combination of modifiers (i.e. crtl+alt
- just an example, not thinking on a real situation) to activate both
its own controls (which take precedence) and a web page controls, so
there is always a chance to choose an accesskey which won't work on a
particular platform. Perhaps it was an heavier concern a few (or even
several) years ago, since nowaday I think most browsers take great care
on this matter, however such problem might arise from time to time, i.e.
with a new browser version, or a version supporting a new OS (or a new
OS version), or using an old browser version apparently compatible with
a new OS version (but such should be a concern more for browser/os
developers than for web developers, since the latter can only assume the
underlying platform - browser + os - works correctly, and cannot care
about any 'bug' outside their work, yet access keys, whatever way
handled, cannot be though as a 'fully and always' reliable mechanism,
while mouse clicks and tab-key navigation plus return-key activation
usually are). Perhaps, keybord shortcuts may work better in a 'make
application state'.
I agree that setting an accesskey attribute is easyer to deal with than
handling key events, and the 'no-dimension, display:inline elements
trick' stands always out there; 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).
On the other hand, the key events listener could just operate on single
alphanumerical characters, something like (javascript-style)
switch(pressedKey){
case 'a' : doSomething(); return;
case 'b' : doSomethingElse(); return;
}
so to bypass any modifiers concern, with some extra care to avoid
interferences with textual fields (and to avoid casual key pressing by
the user - i.e. the very first time a key listened for is pressed, the
webapp could just show an advise and list all valid shortcuts). Anyway,
even in this case there would be chances to clash with a browser default
behaviour for some keys (i.e. when the key is a digit).
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Scopri i games più scaricati su cellulare! Gioca la tua partita!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8272&d=26-11
Re: [whatwg] accesskey attribute with display:none elements
On 11/26/2008 02:34 AM, Calogero Alex Baldacchino wrote: A better way to do what you aim would consist of setting a listener for key events on a displayable element and choosing a different operation basing on the pressed key(s); This is not content author friendly way to do it, because different browsers/OSes use different keys to activate accesskey targets. -Olli
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay ha scritto: On 11/25/2008 11:17 PM, Calogero Alex Baldacchino wrote: > Maybe, the standard behaviour (for both 'display:none' and > 'visibility:hidden') could be just focusing (and changing visibility) > after pressing the access key (so the user notices what's happening > before activating any 'control'), then activating the element after a > second press. > That isn't what any of the browsers do currently, so I'm not in favor of this pretty strange behavior. And how could the browser know how to change the display value? From display:none to display:inline or display:block or display:inline-block or what? Maybe I've replied to quickly, sorry for this. The user agent should have a default style sheet with a default display value for each element, so that value could apply (this may lead to unwanted results if the element had a different display value before the value "none" was set, and this case should be handled by script). I guess what you wish is something like a shortcut in a desktop application, letting you access any control in a menu without showing and esploring the menu. Despite this could be a desireable behaviour for a web application, I think it could also be used to trick the user, or cause an unwanted operation to be performed as a consequence of a casual key pressing, thus the idea of showing the control before activating it, giving the user a chance to stop the operation. For the possible tricks, I guess that might be a minor concern (since there are far 'better' ways to compromise your navigation); anyway, consider that an element constraint with 'display:none' is not a part of the formatting structure for any media and you cannot access it anyway (i.e. you cannot click on it, you cannot reach it by pressing the tab key). That's not just invisible, that's not presented to you at all, almost if that wasn't in the document tree, so that's not focusable at all, and accessing it through an access key would be quite a tricky way to bypass the above 'restrictions' (as if that was forced into the document layout). A better way to do what you aim would consist of setting a listener for key events on a displayable element and choosing a different operation basing on the pressed key(s); a perhaps tricky alternative would be using controls with an accesskey attribute properly set and 'emulating' the 'display:none' layout property by setting their width, height, margin, etc., to a value of zero, and their display property to the 'inline' value. I guess any browser allowing the behaviour you ask for any element with a 'display:none' value perhaps just works around a somewhat misuse of the display property as a quirk. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Incontri con Meetic : Primo sito d'incontri in Europa - Milioni di single ! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8293&d=26-11
Re: [whatwg] accesskey attribute with display:none elements
On 11/26/2008 12:39 AM, Benjamin Hawkes-Lewis wrote: Olli Pettay wrote: Couldn't you style such elements visible with :focus and :active? What you mean? How do you focus a display:none element? Good point. You can't. Isn't that a problem in practice? i.e. When do you want a control to have an accesskey but _not_ be focusable? For example when you want to execute some JS when accesskey is pressed: That behavior is used in the web https://bugzilla.mozilla.org/show_bug.cgi?id=419059&mark=1#c1 The comment mentions dhtml menus and that is a valid use case for accesskeys in display:none elements. -Olli
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay wrote: Couldn't you style such elements visible with :focus and :active? What you mean? How do you focus a display:none element? Good point. You can't. Isn't that a problem in practice? i.e. When do you want a control to have an accesskey but _not_ be focusable? And, either way, is there any reason why it should report the accesskey but not the element? 'it'? You mean "assistive technology" here? or what? Sorry, yes, assistive technology (or any user technology really). -- Benjamin Hawkes-Lewis
Re: [whatwg] accesskey attribute with display:none elements
On 11/25/2008 11:54 PM, Benjamin Hawkes-Lewis wrote: Olli Pettay wrote: I think allowing hidden elements to be activated is useful for web apps, especially because there isn't any API to add listeners for accesskey activation. Hmm … Couldn't you style such elements visible with :focus and :active? What you mean? How do you focus a display:none element? Does popular assistive technology report accesskey on elements that aren't rendered (display: none;) rather than merely hidden off-left (position:absolute; left:-9em;)? (It tends not to report elements that are display: none; at all, note.) Aaron, any comments to this? And, either way, is there any reason why it should report the accesskey but not the element? 'it'? You mean "assistive technology" here? or what? -Olli
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay wrote: I think allowing hidden elements to be activated is useful for web apps, especially because there isn't any API to add listeners for accesskey activation. Hmm … Couldn't you style such elements visible with :focus and :active? Does popular assistive technology report accesskey on elements that aren't rendered (display: none;) rather than merely hidden off-left (position:absolute; left:-9em;)? (It tends not to report elements that are display: none; at all, note.) And, either way, is there any reason why it should report the accesskey but not the element? -- Benjamin Hawkes-Lewis
Re: [whatwg] accesskey attribute with display:none elements
On 11/25/2008 11:17 PM, Calogero Alex Baldacchino wrote: > Maybe, the standard behaviour (for both 'display:none' and > 'visibility:hidden') could be just focusing (and changing visibility) > after pressing the access key (so the user notices what's happening > before activating any 'control'), then activating the element after a > second press. > That isn't what any of the browsers do currently, so I'm not in favor of this pretty strange behavior. And how could the browser know how to change the display value? From display:none to display:inline or display:block or display:inline-block or what?
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay ha scritto: Hi all, currently it isn't specified anywhere (AFAIK) what should happen if the element which has an accesskey attribute is hidden using display:none. HTML4 says the following: "Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the A element, the user agent generally follows the link..." The problem is that focusing and activating isn't the same thing. FF2, Safari 3.x and Opera 9.6 can activate display:none accesskey targets. FF3 changed the behavior to require visible and focusable element. IE7 doesn't seem to activate, only focus (at least elements), and because hidden element isn't really focusable, it doesn't seem to do anything with elements with display:none. A simple testcase https://bugzilla.mozilla.org/attachment.cgi?id=339588 I think allowing hidden elements to be activated is useful for web apps, especially because there isn't any API to add listeners for accesskey activation. (Key event listeners could do something similar, but they'd need to handle all the different browsers and OSes.) So I prefer what FF2, Safari and Opera do, and would like to change FF3.1 to work the same way. Anyway, I hope some behavior could be standardized. Comments? br, -Olli Maybe, the standard behaviour (for both 'display:none' and 'visibility:hidden') could be just focusing (and changing visibility) after pressing the access key (so the user notices what's happening before activating any 'control'), then activating the element after a second press. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Incontri con Meetic : Primo sito d'incontri in Europa - Milioni di single ! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8293&d=25-11
[whatwg] accesskey attribute with display:none elements
Hi all, currently it isn't specified anywhere (AFAIK) what should happen if the element which has an accesskey attribute is hidden using display:none. HTML4 says the following: "Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the A element, the user agent generally follows the link..." The problem is that focusing and activating isn't the same thing. FF2, Safari 3.x and Opera 9.6 can activate display:none accesskey targets. FF3 changed the behavior to require visible and focusable element. IE7 doesn't seem to activate, only focus (at least elements), and because hidden element isn't really focusable, it doesn't seem to do anything with elements with display:none. A simple testcase https://bugzilla.mozilla.org/attachment.cgi?id=339588 I think allowing hidden elements to be activated is useful for web apps, especially because there isn't any API to add listeners for accesskey activation. (Key event listeners could do something similar, but they'd need to handle all the different browsers and OSes.) So I prefer what FF2, Safari and Opera do, and would like to change FF3.1 to work the same way. Anyway, I hope some behavior could be standardized. Comments? br, -Olli
