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

[Michael Smith <smith@xml-doc.org>]

Norman Walsh <ndw@nwalsh.com> writes:

> / Elliotte Harold <elharo@metalab.unc.edu> was heard to say:
> [...]
> | Longer term, I'd also think about whether a few of these like
> | systemitem, filename, and email need to be indicated with <span
> | style="font-style: monospace"> instead of using code or samp at all.
> | HTML is not as expressive as DocBook so clearly we're going to lose
> | some semantics when transforming to HTML. However, we really shouldn't
> | change the semantics, or add inaccurate semantics if we can help it.
> 
> Indeed. I'd be happy with <span class="filename">, but inline style
> doesn't appeal to me at all.

I think some users might not be as happy with it, because then
they would be forced to style it via CSS, while now, with 
<code class="filename">, they get a default rendering for it that
most would find reasonable, I think.

I know "code" is not the best name for marking up a filename. But
there's nothing else close in the set of "phrase elements" that
HTML provides. And going back to using presentational markup like
"tt" seems much more wrong to me.

I don't know of any instances where the stylesheets are generating
HTML inlines for which users can't override styling. Even in cases
like <strong class="userinput"> the default bold rendering that
the strong tag causes can be easily overridden via CSS.

I guess you could instead have <span class="userinput"> and put an
embedded style block in the head of each page with a default style of
font-weight: bold for the userinput class, but I can't really see
what that buys you. If users want CSS, it seems to me easier and
better for them to control it via an external stylesheet, and not
mess around with trying to embed CSS info in each generated HTML page.

PGP signature