[whatwg] Phrasing semantics feedback omnibus

Calogero Alex Baldacchino alex.baldacchino at email.it
Wed Dec 24 12:16:09 PST 2008


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



More information about the whatwg mailing list