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


Rene Hache wrote:
> 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...

The basic difference is that Transitional includes tags and attributes 
that date back to 1994 or so, while Strict removes them on the 
assumption that you'll be using CSS for that stuff anyway (which is the 
Right Way these days).  If the idea of this endeavor is to make more 
CSS-controlled output, then Strict seems the logical choice.

How much difference is there between XHTML 1.0 and 1.1, anyway?  As 
others have mentioned, the problem is that, pragmatically, XHTML 1.0 can 
be handled by any modern browser by faking it as HTML.  1.1 is harder to 
do that with.  Much as I'd love to be bleeding edge, IE makes that 
impossible. :-)

>>>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 :)

Eh, we've got enough work cut out for ourselves anyway at this point. 
:-)  Besides, the advantage of switching to cleaner (X)HTML output is 
that we can then add different CSS stylesheets later much more easily.

> 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.

Precisely.  Clean code degrades more gracefully, by design.


>>>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" :)

Indeed. :-)  I'd rank my CSS as "pretty good".  I dislike using absolute 
myself, but that's just style preference.

Primarily I think we're coming from opposite directions here.  You're 
coming from a "bare minimum, then add what's needed" angle, where I'm 
coming from a "we've got a lot of stuff here, lets take out what we 
don't really need" angle.  That's bound to end in different places.

Aside from increasing the number of characters in the file, does having 
a div that has no style applied to it actually HURT anything?  I think 
we all agree that <div>...</div> and <span>...</span> are fairly 
useless.  DocBook is just more expressive than XHTML is, and the only 
way to maintain that level of complexity for styling is via extra divs 
and spans (which is what div and span are for, IMHO).  I like having 
that extra expressive power, even if I don't use it in a given project.

> 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.

I can do you one better, as it's online now.  Not the prettiest page 
I've ever done, but it demonstrates what I'm talking about.

http://www.star-fleet.com/library/handbook/

Note how the TOC on the index page is "normal", while the TOCs on each 
chapter page float right with an alternate background color.

> 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.

I'd appreciate it if you were to offer some documentation on that. 
Sounds cool. :-)

> 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.

See above about different angles to go about it.  Anyone else want to 
weigh in here?  I'd much rather go through and triage out what we can 
all agree we don't need and possibly end up with more elements than 
really necessary than triage IN what we all agree we do need and end up 
with fewer elements than really necessary.

Also, if someone has or can provide a test document that uses "all" of 
the features of Docbook and the XSL scripts so that we can get a feel 
for what all is actually generated, that would be very helpful.  It 
would likely help with either triage method. :-)

-- 
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


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