docbook: Thread: Updated XSL Stylesheets

Subject: Re: Updated XSL Stylesheets
From: Bob Stayton ####@####.####
Date: 3 Jul 2003 09:31:56 -0000
Message-Id: <20030703024630.A24631@sco.com>

On Wed, Jul 02, 2003 at 01:50:06PM -0400, Emma Jane Hogbin wrote:

[stuff deleted]
> 
> > >         For the XHTML version
> > > 	  there are namespaces put into elements that don't allow them.
> > 
> > This is a bug in the version of xsltproc you are using.
> > Try a later version.
> 
> Bah. Debian did all the installing and that is the latest version
> according to unstable. This is the version I'm using:
> emmajane@debian:/web/ref$ xsltproc -version
> Using libxml 20507, libxslt 10030 and libexslt 720
> xsltproc was compiled against libxml 20507, libxslt 10030 and libexslt 720
> libxslt 10030 was compiled against libxml 20507
> libexslt 720 was compiled against libxml 20507

Well, that's the version of xsltproc that I'm using,
and I see the namespace declaration only on the <html>
element when I use the straight DocBook xhtml stylesheets
(both docbook.xsl and chunk.xsl).  

Looking at the tldp customization files, I can see the problem.
They use the wrong namespace for xhtml
(xmlns="http://www.w3.org/TR/xhtml1/transitional).
The correct namespace is http://www.w3.org/1999/xhtml,
even for the transitional version.  See
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd.

-- 

Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The SCO Group                               fax:   (831) 429-1887
                                            email: ####@####.####

Subject: Re: Updated XSL Stylesheets
From: Emma Jane Hogbin ####@####.####
Date: 4 Jul 2003 03:58:10 -0000
Message-Id: <20030704035809.GA1464@xtrinsic.com>

On Tue, Jul 01, 2003 at 08:23:52PM -0500, David Horton wrote:
> Some day soon I would like to process the same Docbook XML document 
> using both Norman Walsh's docbook-xsl and the tldp-xsl customizations 
> and then put the html outputs through a validator.  This should 
> determine which one is causing the HTML sloppiness.

I've found that the problems are in the tldp-html-common.xsl file. I don't
have enough vocabulary to describe the problem properly; however, I'll
give it a try. David I'll email you my two revised files: styles.css and
tldp-html-common.xsl -- I've added some comments to the top of the xsl
file.

There are a number of elements that are specifically called in the
tldp-html-common.xsl file: <pre>, author headings (calls <i>) and <meta>.
These are the only elements that do not validate correctly because of an
xmlns attribute that is not allowed in the (above) elements.

An example looks like this:

<xsl:template name="user.head.content">
  <xsl:param name="node" select="."/>
  <meta name="generator" content="Experimental LDP.XSL $Revision: 1.4 $"/>
  <xsl:text>
  </xsl:text>
  <xsl:comment> Generated by LDP XSLT customization layer
      based on Norman Walsh's DocBook XSL stylesheets.
      More information at http://www.tldp.org/ </xsl:comment>
  <xsl:text>
  </xsl:text>
</xsl:template>

NOTE: the <meta /> tag. This results in an incorrectly added xmlns in the
final HTML document. I don't know enough about XSLT to know how to fix
this, but there must be a way to print an element that is recognized
somehow and therefore doesn't get an xmlns attribute added to it.

I propose competely removing the formatting changes for <pre>. All they
were doing was adding a table with a background color. This can be done in
the stylesheets. Another style sheet correctly adds a
class="docbookattribute" if tldp-html-common.xsl <pre> section is removed, 
which is good as specific classes can be styled from the style sheet if
you want to have one type of <pre> that is different from another.

So that the formatting isn't lost the following should be added to the
styles.css file:
	pre {
		background: #E0E0E0;
		margin: 0 5%;
		padding: 5%;
	}
This duplicates the styling effects that were being achieved by the XSLT
template which means the <table> formatting can be removed.

In the styles.css file I would reduce the margin to:
	body {
		margin: 5%; /* was 72pt; */
		font-family: sans-serif;
	}

I hope this helps!

emma

-- 
Emma Jane Hogbin
[[ 416 417 2868 ][ www.xtrinsic.com ]]

Subject: Re: Updated XSL Stylesheets
From: Emma Jane Hogbin ####@####.####
Date: 4 Jul 2003 18:03:40 -0000
Message-Id: <20030704180339.GA2596@xtrinsic.com>

On Thu, Jul 03, 2003 at 02:46:30AM -0700, Bob Stayton wrote:
> Looking at the tldp customization files, I can see the problem.
> They use the wrong namespace for xhtml
> (xmlns="http://www.w3.org/TR/xhtml1/transitional).
> The correct namespace is http://www.w3.org/1999/xhtml,
> even for the transitional version.  See
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd.

Correcting this results in valid XHTML 1.0 Transitional documents, thanks!

David: I've been unable to email you the updated files because your ISP is
blocking my ISP. If you'd like a copy of them, I've put them online:
http://xtrinsic.com/geek/code/tldp-xls.zip

thanks,

emma

-- 
Emma Jane Hogbin
[[ 416 417 2868 ][ www.xtrinsic.com ]]

Subject: Re: Updated XSL Stylesheets
From: David Horton ####@####.####
Date: 7 Jul 2003 02:23:28 -0000
Message-Id: <3F08DB27.10403@megsinet.net>

Emma Jane Hogbin wrote:

> On Tue, Jul 01, 2003 at 08:23:52PM -0500, David Horton wrote:
> 
>>Some day soon I would like to process the same Docbook XML document 
>>using both Norman Walsh's docbook-xsl and the tldp-xsl customizations 
>>and then put the html outputs through a validator.  This should 
>>determine which one is causing the HTML sloppiness.
> 
> 
> I've found that the problems are in the tldp-html-common.xsl file. I don't
> have enough vocabulary to describe the problem properly; however, I'll
> give it a try. David I'll email you my two revised files: styles.css and
> tldp-html-common.xsl -- I've added some comments to the top of the xsl
> file.
> 
> There are a number of elements that are specifically called in the
> tldp-html-common.xsl file: <pre>, author headings (calls <i>) and <meta>.
> These are the only elements that do not validate correctly because of an
> xmlns attribute that is not allowed in the (above) elements.
> 
> An example looks like this:
> 
> <xsl:template name="user.head.content">
>   <xsl:param name="node" select="."/>
>   <meta name="generator" content="Experimental LDP.XSL $Revision: 1.4 $"/>
>   <xsl:text>
>   </xsl:text>
>   <xsl:comment> Generated by LDP XSLT customization layer
>       based on Norman Walsh's DocBook XSL stylesheets.
>       More information at http://www.tldp.org/ </xsl:comment>
>   <xsl:text>
>   </xsl:text>
> </xsl:template>
> 
> NOTE: the <meta /> tag. This results in an incorrectly added xmlns in the
> final HTML document. I don't know enough about XSLT to know how to fix
> this, but there must be a way to print an element that is recognized
> somehow and therefore doesn't get an xmlns attribute added to it.
> 

I think that the trick to getting <meta>, <i> and <pre> to not have the 
xml namespace attributes is to replace them with <html:meta>, <html:i> 
and <html:pre> respectively.  My understanding is that this says to the 
XSLT processor, "hey, this is html coming up, not the default 
namespace."  The default namespace being xml in this case.  It may also 
be necessary to add a declaration of the html namespace at the beginning 
of the stylesheet, but I'm not positive on this.

> I propose competely removing the formatting changes for <pre>. All they
> were doing was adding a table with a background color. This can be done in
> the stylesheets. Another style sheet correctly adds a
> class="docbookattribute" if tldp-html-common.xsl <pre> section is removed, 
> which is good as specific classes can be styled from the style sheet if
> you want to have one type of <pre> that is different from another.
> 
> So that the formatting isn't lost the following should be added to the
> styles.css file:
> 	pre {
> 		background: #E0E0E0;
> 		margin: 0 5%;
> 		padding: 5%;
> 	}
> This duplicates the styling effects that were being achieved by the XSLT
> template which means the <table> formatting can be removed.
> 
> In the styles.css file I would reduce the margin to:
> 	body {
> 		margin: 5%; /* was 72pt; */
> 		font-family: sans-serif;
> 	}

I like the idea of getting rid of gratuitous <table>'s.  Do you think it 
would be better to do one CSS style for all <pre> tags or do many styles 
based on class?  That way it's easier to customize, like maybe "screen" 
gets a box drawn around it, but "programlisting" does not.  Or is that 
getting carried away?

Dave

Subject: Re: Updated XSL Stylesheets
From: Emma Jane Hogbin ####@####.####
Date: 7 Jul 2003 02:39:58 -0000
Message-Id: <20030707023956.GA10294@xtrinsic.com>

On Sun, Jul 06, 2003 at 09:29:59PM -0500, David Horton wrote:
> I think that the trick to getting <meta>, <i> and <pre> to not have the 
> xml namespace attributes is to replace them with <html:meta>, <html:i> 
> and <html:pre> respectively.  My understanding is that this says to the 
> XSLT processor, "hey, this is html coming up, not the default 
> namespace."  The default namespace being xml in this case.  It may also 
> be necessary to add a declaration of the html namespace at the beginning 
> of the stylesheet, but I'm not positive on this.

I figured out how to fix this in a later email. Bob Stayton pointed this
out to me. The URL is wrong for the xml namespace. If the URL is fixed
then the document will validate.

> I like the idea of getting rid of gratuitous <table>'s.  Do you think it 
> would be better to do one CSS style for all <pre> tags or do many styles 
> based on class?  That way it's easier to customize, like maybe "screen" 
> gets a box drawn around it, but "programlisting" does not.  Or is that 
> getting carried away?

I would do one style for all <pre>s with optional classes afterward. For
example you can combined pre.screen. Anything that <pre> and <pre
class="screen"> have in common will use the values from <pre
class="screen">. Anything that is not shared will take on whatever value
is set.

For example:
	pre { background: #E0E0E0; }
	pre.screen { border: 1px solid blue; }
	pre.programlisting { background: red; }

<pre class="screen"> will be gray with a blue border
<pre class="programlisting"> will be red with a blue border

Even if there are no additional styles added to the different types of
<pre>s I would recommend leaving the classes in. If it is decided later on
to change them then the documents don't need to be re-processed.

emma

-- 
Emma Jane Hogbin
[[ 416 417 2868 ][ www.xtrinsic.com ]]

Subject: Re: Updated XSL Stylesheets
From: David Horton ####@####.####
Date: 7 Jul 2003 21:44:43 -0000
Message-Id: <3F09EB54.5070600@megsinet.net>

Emma Jane Hogbin wrote:
> On Sun, Jul 06, 2003 at 09:29:59PM -0500, David Horton wrote:
-snip-
>>I like the idea of getting rid of gratuitous <table>'s.  Do you think it 
>>would be better to do one CSS style for all <pre> tags or do many styles 
>>based on class?  That way it's easier to customize, like maybe "screen" 
>>gets a box drawn around it, but "programlisting" does not.  Or is that 
>>getting carried away?
> 
> 
> I would do one style for all <pre>s with optional classes afterward. For
> example you can combined pre.screen. Anything that <pre> and <pre
> class="screen"> have in common will use the values from <pre
> class="screen">. Anything that is not shared will take on whatever value
> is set.
> 
> For example:
> 	pre { background: #E0E0E0; }
> 	pre.screen { border: 1px solid blue; }
> 	pre.programlisting { background: red; }
> 
> <pre class="screen"> will be gray with a blue border
> <pre class="programlisting"> will be red with a blue border
> 
> Even if there are no additional styles added to the different types of
> <pre>s I would recommend leaving the classes in. If it is decided later on
> to change them then the documents don't need to be re-processed.
> 
> emma
> 

Looks like a good way to do it.  --Dave

©The Linux Documentation Project, 2014. Listserver maintained by dr Serge Victor on ibiblio.org servers. See current spam statz.