- From: Calogero Alex Baldacchino <alex.baldacchino@email.it>
- Date: Wed, 24 Dec 2008 21:16:09 +0100
Ian Hickson ha scritto: > > On Sun, 30 Nov 2008, Calogero Alex Baldacchino wrote: >> [...] an <activators> element [...] > > I encourage you to look at the <command> element in HTML5. I'm waiting for > implementations of that before looking at access keys. > > I've given a closer look to it and (more quickly) to the overall command architecture: that's a nice abstraction :-) Just one thing: a note says a synthetic click doesn't perform the same actions as required by the click() method, but those seems suitable as pre-click activation steps (or post-click, if needed), eventually telling the UA to take care of the synthetic click source (user's device or document scripts) if such causes any difference, aren't they? And a little aside: it is said context menus should inherit, but the inheritance is not yet defined, so let me suggest a convergence with events flow: during the capture phase, showing the menu might be prevented by stopping the propagation of a triggering event (e.g. by the UA because of a user preference, or by an ancestor's handler to make custom menus available only under certain conditions -- in order to have it working, perhaps each platform-dependent method might be abstracted as a 'right click', as some sort of variant on synthetic clicks); at the target, if a menu is provided for the element, it is shown as described, and the triggering event propagation is stopped (treating the menu show as a kind of post-run default action); otherwise, while bubbling, the triggering event might cause a context menu being shown as soon as an ancestor providing one is found (then stopping the event propagation); if no custom contextual menu is provided in the element subtree, the UA takes the control and shows a proper menu at the target element (if any is provided by the implementation). For access keys, I've never liked them much, though they exist and removing them might break some existing pages, but I'm sure that's been considered in depth (and perhaps browsers vendors will support them anyway, so they can be re-elaborated in due course). Personally, I think key events are more flexible than access keys, but are affected by the same platform- and browser- dependence, which might be mitigated by defining a few properties telling about default modifiers; I'm not sure if that's an issue for DOM Events or if an HTML-specific interface should be defined to be implemented with other DOM Events interfaces altogether, since HTML 5 spec'es interfaces somehow "hooking" to the platform hosting the document (such as Window, where an attribute might list the default modifiers, while a boolean on an event-specific interface might tell whether access modifiers have been pressed by the mean of a boolean -- though I guess an HTML5-side DOM solution would need key events to stabilize). About my half-proposal (no more than half), it was suggested to me by timeless' ideas on generic commands triggered by actions a user might customize AND carry from one UA to another, thus I thought on the fly to something I supposed might have been consistent cross-browser and potentially coexisting with developers' choices, through an embeddable mechanism, either as a part of the document, or a separate document to be linked, or provided as default by the UA, and with some sort of cascading (or precedence) rules, on the same line as CSS; perhaps such might be considered as an evolution. The part I was considering more valuable was what I called (with a temporary name) a 'mousebehavior' describing linear movements of a pointing device: actions might be as easy as a succession of movements in different directions (right, left, up and down), detected as coordinates difference between a 'start' and an 'end' point (detecting one direction at a time); such might be helpful, I guess, as an aid for certain disabilities, in conjunction with a pointing device capable to 'rectify' jugged movements, picking the start point as a mean value in a certain range (the same way a mouse driver considers a 'mouse up' as determining a 'click' if a 'mouse down' happened in a short range of pixels), and the end point as the mean value in a range where the user rests for a certain interval before moving again. Best regards, and happy holidays to everyone (if having holidays in this period) Alex -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Polizza Auto? * Con Direct Line garanzia furto e incendio a soli 30 euro per un anno! Affrettati: l?offerta ? valida fino al 31 Dicembre. * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8512&d=24-12
Received on Wednesday, 24 December 2008 12:16:09 UTC