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


Elliotte Harold <elharo@metalab.unc.edu> writes:

> Michael Smith wrote:
> 
> >The var element is not a monospaced style. It's typically
> >rendered in italic (non-monospaced). Which makes it inappropriate
> >for marking up programming variables or program arguments.
> 
> The var element is not a style element, period.

I didn't say var is a style element. I just stated: By default,
var is typically (probably universally) rendered in italic type.

The problem is that its default rendering makes it inappropriate
for marking up programming variables or program arguments -- which
most people do not want rendered in italic.

> The problem is that you're using semantic elements (var, code,
> strong, em) as style elements.

No. The stylesheets are using strong and em to say "show this
strongly" and "show this with emphasis". And they are using code
because HTML does not provide the equivalent of a "literal" element.

And the only place the current stylesheets are using var is output
of parameter in paramdef.

> That's just as wrong as using b and i. In fact, it's more wrong
> because at least b and i aren't actively misleading.

You're correct about b and i not being misleading. They are
purely presentation elements that are instructions to a browsers
to render stuff in bold and italic.

I wish we could all pretend that b and i don't exist.  Either
that, or give up on thinking HTML is an adequate vocabulary
for giving logical and structural meaning to content and just see
it ast what it has mostly been used for and mostly continues to be
used for: a rendering vocabulary, like XSL-FO.

People have been asking for years for the stylesheets to dump b
and i and use strong and em instead. I personally never cared much
about it much either way because, although I think HTML is an OK
rendering language, it seesm to me it has way too many deficiencies
to be practically useful for capturing the logical structure of content.

The idea of having the stylesheets output b in some cases and
strong in others, or i in some cases and em in others just seems
like just nuts to me.

And I honestly cannot see anywhere that strong or em are being
used incorrectly by the stylesheets. For example, strong is being
used with userinput to mean "show this more strongly". It is _not_
being used to say "render this in bold".

> If the goal is to avoid presentation based markup, then the HTML element 
> names should be picked based on the appropriate semantic match. When 
> there is no such match, use <span class="whatever"> and add styling via 
> CSS.

The stylesheets already output many (maybe most) inlines with
class values that are the original DocBook element names; example:

  <div class="literallayout">
    <p><strong class="userinput"><code><span><strong class=
    "command">tail</strong></span>&#160;<code class=
    "option">-f</code>&#160;<code class=
    "filename">mta.log</code></code></strong></p>
  </div>

Yeah, I guess they could do always output <span class="foo">
instead of <strong class="foo"> or <em class="foo">, and force
people to set styling via CSS.

But problem is, after that, I would bet that there'd soon be
people posting messages to docbook-apps saying, Hey, what happened
to all my character formatting? -- because they didn't know about
the CSS stylesheet or didn't have it in the expected place.

So what the current stylesheets try to do is provide a default
off-the-shelf rendering that "looks right". Of course not
everybody agrees about what looks right. But people who don't like
what the off-the-shelf stylesheets provide can override it via CSS.

For example, if you don't want userinput or command stuff to show
up in bold, then you just do this:

.userinput {
  font-weight: normal;
}

.command {
  font-weight: normal;
}

There may be cases of elements that you want to style that aren't
getting output without a class value. If/when you run into any, I
guess the thing to do is file a report the project Soureforge site.

And there are a small handful of cases where the stylesheets are
generating hard-coded CSS style attributes -- for example,
<table style="padding-bottom: 1em">. If you run into one that
doesn't seem sensible, I guess it it should be reported at the
Sourceforge site.

smime.p7s



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