[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

     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,

	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

Received on Friday, 28 November 2008 10:40:54 UTC