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
