[whatwg] accesskey attribute with display:none elements
Calogero Alex Baldacchino
alex.baldacchino at email.it
Fri Nov 28 10:40:54 PST 2008
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
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
Applies to: all elements
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.
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?
P.S. I take it separate because off topic, but I'd really consider
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
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
More information about the whatwg