Re: DOCBOOK: Re: marking up keycaps according to their semantics

[Tobias Reif <tobiasreif@pinkjuice.com>]

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/