Re: [docbook-apps] DocBook XSL stylesheets violate structure-oriented paradigm

[Gabor Kovesdan <gabor@kovesdan.org>]

On 2012.07.06. 19:31, Jirka Kosek wrote:
> On 6.7.2012 18:43, Gabor Kovesdan wrote:
>
> > can also be embedded into the output HTML file. If not because of the
> > single file, why would anyone nowadays need an obsolete HTML file
> > polluted with lots of deprecated formatting elements?
> Could you point us to deprecated formatting elements emitted by
> stylesheets?
I meant the HTML Transitional attributes. I know you could argue with 
the word "deprecated" since it is not officially stated as such nowhere 
but in 1999 HTML4 clearly expressed that those should be replaced with 
CSS styling. Look at the initial comment here:
http://www.w3.org/TR/REC-html40/sgml/loosedtd.html

Since then 13 years passed and it became a well-known practice to use 
CSS and separate structure and layout.
> > I think it just
> > encourages people keep using bad practices, adds complexity to the
> > stylesheets and adds overhead for the stylesheet developers. All modern
> > browsers can now deal with HTML Strict + CSS.
> Browsers deal with HTML5 + CSS so there is no need to target legacy HTML
> Strict.
Ok, you're right, it was quite a subjective statement. But finding a 
browser that doesn't support CSS is much harder than finding one that 
doesn't support HTML5. Using HTML Strict would be a good compromise and 
we would get cleaner output.
> > Thanks, I'll take a look at this. Actually, in this case I use the
> > stylesheets as a basis of DocBook Slides stylesheets that I'm working on
> > in Summer of Code. And there I wanted to give a default CSS formatting
> > for the tables.
> You can simply use selectors
>
> .informaltable table
> .table table
>
> to match only real DocBook tables not tables used for navigation and few
> other things.
This is what I was going to do but the class attribute was missing.
> > > I'm surprised about the comment about class attributes.  The stylesheets emit class values for pretty much every element.  An informaltable is contained in a div element with class="informaltable".  Was that not present in your output?
> > No, definitely not. And I just call <xsl:apply-templates/> to generate the content part of my foils so I haven't made any customizations on informaltables.
> You are probably using HTML table model not CALS. It seems that for HTML
> table model enclosing <div> with proper class is not emitted, this is
> bug. Probably no one faced this before because legacy DocBook users as
> me are relying on CALS tables.
Yes, switching to CALS tables solved the problem, now I have the 
enclosing div element. But HTML tables should be fixed as well. Shall I 
file a report to the bug tracker?
> > Apart from this particular issue, I'm a FreeBSD doc developer and I'm
> > working on migrating from DocBook 4.1 SGML and DSSSL to DocBook 4.2 and
> > XSLT.  I talked to another FreeBSD developer about this migration and he
> > had the same complaint about the XSLT stylesheets. He said he couldn't
> > format his HTML output with CSS and he rewrote the stylesheets from
> > scratch for a smaller subset of elements he uses. So I'm not the only
> > one who had such problems.
> My experience is that the current output can be restyled in any way
> using CSS.
OK but not a HTML table. :)
> > Accommodating many type of users - as you say
> > - is good and an important point but I think not supporting the commonly
> > accepted correct usage in favor of some legacy features is a wrong
> > decision. Maybe the development directions should be reconsidered.
> There are XSLT 2.0 based stylesheets that aim to output more clean and
> more HTML5ish code:
>
> https://github.com/docbook/xslt20-stylesheets
Nice to see that it is also progressing in such a direction. But it is a 
pity that there's no such a fast XSLT 2.0 processor out like xsltproc 
for XSLT 1.0.

Gabor