OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook-apps] DocBook XSL 1.67.0 released

Peter Eisentraut <peter_e@gmx.net> writes:

> Michael Smith wrote:
> > Here is the list of elements and the mappings that seem right to
> > me. Please let me know if it looks correct to you or what you
> > think should be changed.
> For everyone's entertainment, here is what the DSSSL stylesheets do, 
> which is sort of the combined creation of Adam Di Carlo and myself.


> >   literal                code
> tt  --> I feel that this is the better choice, both literal and tt being 
> the "monospaced, but no semantic" element in their respective 
> languages.

The difference is that literal does not mean "monospaced". It
means "literal". Yeah, it's rendered by default in monospace, but
that does not mean that it means "monospaced".

The problem that we're trying to work around here is that the
people who designed the HTML element set were not thoughtful
enough to provide a real equivalent of what is called the
"literal" element in DocBook.

So we use the closest thing that we can find: code.

The tt element is purely presentation markup (described in the
HTML spec as a "Font style element") that never should have been
part of HTML to begin with.  We should pretend that it's not
available, along with b and i. If we do that, we are left with
choosing from the set of semantic "Phrase elements" that HTML
provides. And the only element in that set that comes close is "code".

> >   userinput              strong+kbd
> kbd  --> ?

See my previous comments about this. The reason for making it
strong is to follow a common convention that's used in computer
texts, the rationale for which is that when you have, say, a
screen example which you're showing users what commands they
should type in and what the expected response from the computer
will be (userinput mixed with computeroutput), it is very useful
to provide an easy way for users to easily distinguish which parts
they are supposed to type in.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]