This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: Re: marking up keycaps according to their semantics
Steinar Bang wrote:
> An advantage of using a different element from <keycap>, is that you
> can declare it with a content model of EMPTY, making DTD-aware editors
> like eg. psgml treat it as an empty element.
I see. I think it's best to supply user-overridable default renderings
in the transformation tools, so supplying none in the doc itself (not
allowing content) would be OK from my POV.
> I don't think <input> is a good choice of element name, though.
I didn't give much thought to it; there probably are many different
names which would be as good or better.
> It gives me HTML form vibes.
It didn't give me those, and I think any name could bring strange
connotations for someone.
> Not sure what would be a good name,
> though. <funckey> perhaps? <moderatorkey>?
Some computer users don't use keys to enter input; but since it's the
most common input device, perhaps it's OK.
funckey sounds good then, or perhaps commandkey, or actionkey.
But then I'd tend to stay with keycap, allow it to be empty, and add an
attribute.
Perhaps
<action type="arrow-up"/>, <action type="esc"/>
or
<nonchar name="control"/>
or
<control name="shift"/> ...
> The disadvantage is, as always, adding one more to the already large
> DocBook element list.
Specifying an attribute for keycap with an enumerated list of values
would be the smallest DTD change.
But adding one new element might not bee a change of too large
dimensions, and might be clearer.
Tobi
--
http://www.pinkjuice.com/