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

I agree with Michael that we don't want to force people to use CSS to get
output that renders reasonably well.  But there are many people who want
clean, semantically marked up XHTML so they can apply one or more external
CSS stylesheets to it.  Is there any reason we can't provide a stylesheet
parameter that specifies "style-free" XHTML output, with the expectation
that if you use that option you will be using a CSS stylesheet for all your
styling?  I think that would settle a lot of these usage arguments.

Bob Stayton
Sagehill Enterprises
DocBook Consulting

----- Original Message ----- 
From: "Michael Smith" <smith@xml-doc.org>
To: "Elliotte Harold" <elharo@metalab.unc.edu>
Cc: "Michael Smith" <smith@xml-doc.org>; <docbook-apps@lists.oasis-open.org>
Sent: Thursday, November 11, 2004 11:12 AM
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.

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