[whatwg] Fallback styles for legacy user agents [was: Re: Deprecating <small> , <b> ?]

Sun Nov 30 11:15:37 PST 2008

timeless ha scritto:
> i don't really want to spend a lot of time with this, but any feature
> authors are provided will be abused.
>
> among my list of things which i wish were never let out of pandora's
> box are defining accesskeys (instead of commands) in html, and another
> which i'd hope dies on the vine is aural css.
>
> sure it is theoretically nice to let someone encode audio. however on
> average it's going to be used more often by advertisers than actual
> content developers.
>   

Of course, advertisers could avail of aural CSS, but they can right now 
embed a voice registration into a flash ad, targeting a wider audience...

> the amount of effort required to invest in a feature which is
> generally not useful far exceeds any value offered to the user by the
> agent.
>
> in the case of accesskeys, a much more useful research area is to
> developer a browser global way of accessing content which works well
> for the device/useragent/user. enabling each site to design its own
> poor access keys is much less useful than letting browsers be
> configured by their users or share keybindings from one browser to
> another for a given site.
>   

Accesskeys are an attempt to reproduce offline applications' shortcuts 
in web pages; maybe they're not the best, since they suffer for a double 
dependence, from the browser settings and the underlying operating 
system settings. So, if you even could make modifiers consistent from 
one browser to another on the same platform, you couldn't easily do the 
same cross-platform. Yet the overall mechanism might be improved. One 
way to achieve this could be using key events, to create a more 
articulate environment, and (anyway) establishing a generic reference to 
a browser default modifiers (the ones provided for accesskeys) could be 
usefull for cross-browser, cross-platform consistence (perhaps even for 
your purposes).

For the rest, do you want to develope a browser (or a browser to be 
developed) with the option to bypass default accesskeys at the user 
will? That's possible, even without a direct support by the html: just 
add this option and make it working like any other browser 
customization, then store somewhere the users' choices on a somewhat 
profile. Do you want generic commands, like mouse-keys combinations, or 
mouse gestures too? That's the same, all to do is intercepting the 
command before the document and translate it into an activation of the 
desired control (i.e., by generating the activation behavior as defined 
in section 3.4.1.7 Interactive content). Do you wish to exchange the 
profile between browsers? Well, perhaps you're asking for a common 
profile format and a shared local storage among browsers... uhm, no, 
that would fail cross-platform (i.e. using a different OS or a different 
computer), so another solution should be found... perhaps storing users' 
webapps profiles in a remote server could solve such, and new services 
could start around such possibility, but perhaps that could lead to some 
security concerns, and perhaps, at the moment, it could be better to 
leave to each site developers the choice of default keybindings and the 
implementation of a mechanism to let the user customize the site/the 
webapp, storing the user's choices either locally or remotely on the 
site/the webapp server. Maybe a future version of html could endorse 
support for such (if not convenient at the moment). Perhaps an element 
could have an "activators" attribute holding the id of an "activatorset" 
element, which could be something like,

<activatorset id="foo">

    <sequence type="keys">
       <key type="identifier" state="down" value="a_unicode_value_here" />
       <key type="modifier" state="down" value="&defaultModifiers;" />
       <!-- a state of 'down' stands for a contemporary pression, 
regardless the order
             of items declaration, and there can be any order for 
releasing pressed keys,
             but after the first release (state="up"), any other 
pression must happen after
             the released key - or mouse button -->
       <key type="special" state="down" value="&arrow_left;" />
       <key type="any" state="up" />
       <!-- when every declared item is released, the command fires and 
synthetic click activation
             steps are run, perhaps adding an "activation" event 
carrying the proper sequence of keys
             and mouse actions, so the developer can choose among 
handling the (sinthetic) click,
             the "activation" event or the DOMActivate event -->
    </sequence><!-- the first activation sequence is defined, any other 
is an alternative way to activate a control -->

    <sequence type="mouse">
       <mousebutton type="left" state="down" />
       <mousebutton type="right" state="down" />
       <!-- here state has the same meaning of above: users can press 
them contemprary, or one first, then
             the other while still holding the other down -->
       <mousebehaviour type="move-right" />
       <mousebehaviour type="wheel" value="-3" />
       <!-- mouse behaviours should happen in order, however the only 
needed requirements is to respect
             the order of pressions and releasing -->
       <mousebutton type="any" state="up" />
    </sequence>

    <sequence type="mix" > <!-- keys and mouse -->
       <key type="modifier" state="down" value="&AltGraph;" /> <!-- 
entyties to be defined somewhere -->
       <mousebutton type="right" state="down" />
       <mousebutton type="right" state="up" />
       <key type="identifier" state="down" value="unicode_here" />
       <mousebutton type="left" state="down" />
       <mousebutton type="left" state="up"/>
       <key type="any" state="up" />
    </sequence>

    <sequence type="external" /><!-- this should be implied and refers 
to any other type of activation,
                                                        such as pressing 
tab then enter, or focusing elements by voice -
                                                        a further 
version could cover direct speech activation - or just
                                                        clicking over 
the element -->
</activatorset>

the above could be a node descendent from an <activators> element, which 
might be enabled or disabled, and have no children, but a "src" 
attribute keeping a URL targeting an XML file, with the above format and 
a root element calle <activators> as well, so to be able to just keep 
any descendent activatorset  and put it in the document. Such xml schema 
could be the format for users preferences remotely (or locally) stored, 
though I'd leave to the web application a chance to choose whether to 
let the user redefine default actions or not (anyway, there will be 
always a chance to clash with both browser and operative system default 
behaviours).

Any other idea? Just propose it. Come on, let's change the world! :-P

Regards, 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:
 Scopri le supernovità dei games per cellulare! Giocale tutte!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8271&d=30-11