Re: [docbook-apps] Simpler XHTML output

[Rene Hache <rene dot hache at gmail dot com>]

Larry,

> Transitional?  Why only Transitional?  We already have XHTML
> Transitional.  A style-free script would have to generate Strict code,
> whether it calls it Transitional or Strict, almost by definition.

I only put transitional because it seemed to be what people are asking
for. Personally, I would opt for XHTML 1.1, but many seemed to object.
Ultimately, it's for others to discuss since I don't have enough
understanding here. Transitional was only tossed out there as a new
starting point. Let the games begin...

> > 2. Included in the output will be a default CSS file with a basic
> > layout for screen, print and handheld devices. The CSS file should be
> > fully functional in current browsers: Opera 7+, Mozilla 1.0 and IE 6.
> 
> I don't think print is an issue we need consider.  If print is your
> intended output, use FO.  For screen output, you should probably also
> consider Konqueror and Safari (which sadly can't be considered a single
> engine anymore).  Fortunately the level that the basic CSS file will be
> working at should work well in everything, I'd imagine.

Sure, print isn't really necessary. But if everybody wants me to lead
the css design aspect (I won't be offended if not), knowing me I will
probably end up throwing that in anyway :)

For handhelds, I would just worry about handhelds that can handle CSS.
Otherwise, in my opinion, it's too much hassle. But a valid XHTML is
better for non CSS capable handhelds anyway.

> > 3. Outputted XHTML code will aim to be as simple (meaning fewer tags)
> > as possible to facilitate CSS layout, and be completely table-less
> > expect for tabular data.
> 
> "except", not "expect". :-)

Thanks for catching that.

> And I want to be clear on what exactly that means.  Removing div and
> span elements that have no class or id attributes makes sense.  But I'd
> really hate to have to lose the power of having so many CSS hooks just
> for the sake of not using tables for navigation.

> > 5. Unless specified via the role attribute (or some other mechanism),
> > The only DIV to be generated inside the main content div will be
> > admonitions, sidebars and highlights.
> >
> > COMMENT: It is still my personal preference to not generate extra
> > divs, but the majority seems to be leaning the other way. Maybe not
> > generating those extra divs might be an option in the customization
> > layer?
> 
> I don't know how easy a "reduced.div" flag would be to implement.  Bob?
> 
> But from your description, it means that my TOC styling (see previous
> email) wouldn't work with this setup.  That's not even a particularly
> complex example.  As I said, I really don't want to lose that ability
> for the sake of one fewer tables in the output.

On both your last points, I have to differ with you, but respect were
you are coming from. From my perspectives, it really is a matter of a
correctly placing a class or id attribute here and there. I don't know
how proficient you are at CSS, but my web pages have very few class or
id attributes (relatively speaking), but my layouts can end up looking
very complex. I guess different people have a different view of the
word "simple" :)

I also re-read you TOC example, and although I can't "quite" see it
visually, I am almost positive that you don't need the div.toc to make
it do what you want it to do. You can always send me a screen shot and
some code to demonstrate.

> > 6. All graphics that will be used for navigation purposes or
> > admonitions will be handled by the stylesheet. This will ensure
> > maximum functionality accross various mediums and facilitate meeting
> > accessibility standards.
> 
> Good.  How exactly would you do that, though?  Background image?

Yes, and no. There are a quite a few CSS tricks out there called image
replacements techniques. There a good way to add visual navigation
that are still fully accessible to screen readers and downgrade easily
in non-CSS browsers or handhelds, without putting image tags in the
XHTML code. But yes, background images are part of how they work.

Switching emphasis, I guess I would propose producing an output that
has no divs or spans other than the ones I mentionned in point #5, as
a starting point. Then we can add them as we see fit and necessary, in
the cleanest way possible. If this is a feasible way of working, but
tell me what you think.

Later,
Rene

---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org