- From: Calogero Alex Baldacchino <alex.baldacchino@email.it>
- Date: Fri, 28 Nov 2008 19:40:54 +0100
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
Received on Friday, 28 November 2008 10:40:54 UTC