cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [Woody] - <wd:hotkey> status?
Date Fri, 21 Nov 2003 10:06:52 GMT
Marc Portier wrote:

>
>
> Sylvain Wallez wrote:
>
>> Antonio Gallardo wrote:
>>
>>> Hi:
>>>
>>> Reviewing old mails, I found we agreed to add to the woody template
>>> specification an initial tag that was called <wd:hotkey>
>>>
>>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105848333001636&w=2
>>>
>>> Please, follow the above thread.
>>>
>>> I don't know if I miss something, but I don't see it anymore.
>>>  
>>>
>>
>> We currently only have <wd:hint> and <wd:help> implemented in the 
>> styling. Adding the hotkey is still to be done.
>>
>> Now what about naming it <wd:accesskey> or <wd:access-key>? This 
>> would be more similar to the corresponding "acceskey" HTML attribute.
>>
>> I also noticed that, although the HTML spec recommends to underline 
>> the accesskey in the label, no browser seems to do it. Any 
>> hint/advice on this?
>
>
> first idea is to have:
>
> <wd:label><wd:accesskey>N</wd:accesskey>ame:</wd:label>
>
> of course we will need some fit with the i18n support
>
> suggestion, just keep the current:
> <wd:label>
> <i18n:text key="prompt.name" />
> </wd:label>
>
> where
> <message key="prompt.name"><wi:accesskey>N</wi:accesskey>ame:</message>


I love this, as it avoids separate definitions of label and key in the 
i18n catalogue.

> ? hm, I don't actually don't know if current i18n transformer is 
> supporting mixed content-model messages, anyone?


Yes, it does (IIRC, this is new in 2.1).

> also this approach would require us however to make some upfront 
> suggestions on the order of template and i18n transformer? (and thus 
> reflect that in the namespace-prefix in the message)


As i18n must come after the woodytransformer, <wi:accesskey> makes 
sense. But when the label is in the definition, we'll have a 
<wi:accesskey> inside a <wd:label>...

I suggested some time ago to have <wi:label> in the form definition 
since, its just "transported" by the widget to produce the instance (no 
processing occurs on it), but I'm not sure that mixing prefixes is so 
intuitive. OTOH, "wi:" clearly indicates that it's an optional and 
view-only data.

> biggest plus for this approach to me seems to be that you are assuring 
> that the access-key _is_ part of the label, regardless of the language?


Yep. And formatting becomes trivial, since there's no need to look the 
the key and split the label.

> in any case I would find it logical to have the accesskey-node 
> dependent (i.e. child or attribute) of the label attribute
>
>
>
> thinking of other possibilities I'm only arriving at a specific 
> attribute to wd:label
>
> <wd:label acceskey="i18n:accesskey.name" >
>     <i18n:text>prompt.name</i18n:text>
> <wd:label>
>
> where then
> prompt.name=Name:
> accesskey.name=N
>
> seems easier at first, but still fails to support the underlining?


Well, it makes a verbose and complex definition, and doesn't help to 
write the XSL...

> what do you guys think?


+1 for <wi:accesskey> in labels!

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message