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] Simpler XHTML output


A lot of the div stuff comes from the titlepage mechanism in DocBook XSL.
As an example of some div tags that can be pared down, consider this XHTML
output at the top of a chunk:

<div class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="FOprocessors"/>FO processors</h2></div></div><div/></div>

All that just to present the title of the chunk.  8^)

I would put forth the proposition that a div without a class or id attribute
is a div that isn't useful for CSS and can be eliminated.  Same with empty
divs.  It may be that some of those divs are useful under different
circumstances when more titlepage information is to be output.  But the
stylesheet should only output divs if they can serve a purpose.

Bob Stayton
Sagehill Enterprises
DocBook Consulting
bobs@sagehill.net


----- Original Message ----- 
From: "Larry Garfield" <larry@garfieldtech.com>
To: "Docbook-Apps" <docbook-apps@lists.oasis-open.org>
Sent: Monday, April 25, 2005 5:24 PM
Subject: Re: [docbook-apps] Simpler XHTML output


> I have to agree with Bob, here.  Yes, by default the stylesheets
> generate a lot of divs that have no default style.  That's a good thing,
> because it means that their style is entirely at our mercy. :-)  Yes it
> makes the code a bit larger, but I don't believe it makes any
> significant difference to the processing time on the client.  It can be
> more difficult to read IF you're code is not nicely indented, but using
> the chunker.output.indent option the resulting HTML is perfectly fine
> for me.
>
> I too thought the extraneous divs were extraneous at first, until I very
> quickly ran into a case where they were needed.  I had (have) a
> multi-page output document with one chapter per HTML file, all using one
> DocBook XSL-specified CSS file.  Each chapter therefore has a TOC of its
> own in addition to the main TOC on the index page.  I wanted to style
> the TOC off to the right side in a float with a different background to
> make it more distinct and to save space.  My first cut doing that was
> simply:
>
> div.toc {
> background: Yellow;
> width: 20%;
> float: right;
> }
>
> Of course, that then did the same to the main TOC, which was clearly
> bad.  So I changed the selector to div.chapter div.toc, and all was
> right with the world.
>
> Were the .chapter div not there, all would not have been right with the
> world.  The same cannot be accomplished with IDs, at least not in a way
> that would work in both single-page and chunked output.  (You'd have to
> give every chapter TOC its own ID, and then styling them all the same
> would be a huge pain.)
>
> I guess consider that a use case. :-)  I suppose there may be divs in
> there that are extraneous in 99% of cases, but for most divs if they
> only problem they cause is that the code doesn't look as "pristine" then
> I'd rather err on the side of functionality.  Don't throw the baby out
> with the bath water.
>
> For myself, I am more interested in just an XHTML 1.0 Strict, W3C
> Accessibility Guideline-friendly version of the output.  Remove the body
> attributes, use some structure other than tables to lay out the header
> and footer nav bars, etc.  Having a dozen sect1 divs in the page that I
> am not taking advantage of does not make the page not XHTML 1.0 Strict,
> nor does it violate W3C Accessibility Guidelines (AFAIK).
>
> Bob Stayton wrote:
> >>My view.
> >>  Keep it simple, very simple. Omit all the class attributes, nested
> >>divisions, etc etc.
> >>  I.e. all content is part of the normal flow.
> >
> >
> > I don't understand how you will apply styles if there is no way to
select
> > content in CSS.  It will certainly be simple, but it won't be styled.
8^)
> >
> > I guess I thought the goal of this project was to create an XHTML that
could
> > be completely controlled by a CSS.  In the current XHTML/HTML output,
that
> > is not the case because some styles are hard coded in deference to those
who
> > don't normally use CSS.  But if we create an XHTML that is explicitly
> > dependent on CSS for styling, then we can use the full power of CSS.
> >
> > I agree that complexity should be moved from the XHTML to the CSS, but
we
> > need the hooks in the XHTML to apply the CSS, no?   The div elements
serve a
> > purpose in creating a structure in the XHTML that CSS can work with.
Since
> > CSS styles can cascade down through the structure, you can set styles at
the
> > appropriate level and override them as needed in lower levels.  I agree
that
> > we should eliminate div elements that don't serve that purpose, but I
can't
> > see removing them all.
> >
> > Bob Stayton
> > Sagehill Enterprises
> > DocBook Consulting
> > bobs@sagehill.net
>
> -- 
> Larry Garfield AIM: LOLG42
> larry@garfieldtech.com ICQ: 6817012
>
> "If nature has made any one thing less susceptible than all others of
> exclusive property, it is the action of the thinking power called an
> idea, which an individual may exclusively possess as long as he keeps it
> to himself; but the moment it is divulged, it forces itself into the
> possession of every one, and the receiver cannot dispossess himself of
> it."  -- Thomas Jefferson
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>
>
>




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