[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: lofferta è 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