[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
How about to start with this? =) Of course this should be customized a bit, but I think it is a move in right direction. <!-- ==================================================================== --> <!-- Writing default CSS stylesheet --> <!-- Unsure about this special customization - "default.css" template must be executed only once and "/" node in "process.root" mode seems to be working for this purpose, but it is still unclear if it is a proper place to do that. TODO: If we are not chunking - include stylesheet as <head> <style> element --> <xsl:template match="/" mode="process.root"> <xsl:call-template name="default.css"/> <xsl:apply-templates /> </xsl:template> <xsl:template name="default.css"> <xsl:variable name="content"><![CDATA[ /* This is default CSS style for XSL generated HTMLs to make them look like from DSSSL output */ /* For <div class="p"> in sections where <p> was replaced by <div> to allow nested block elements */ .p {margin-top:1em; margin-bottom:1em} li {margin-top:1em; margin-bottom:1em} dt {margin-top:1em; margin-bottom:1em} /* Display notes inline */ .note .p {display:inline} /* For TOC headers look like DSSSL ones - no empty line with TOC elements */ .toc p {margin-bottom:0} .toc dl {margin-top:0} .toc dt {margin:0} /* Customize programlistings */ pre {margin:1ex} /* Make literals look like in DSSSL - vars */ .literal {font:oblique 1em serif;} .parameter {font:italic;} .filename {font:monospace} ]]> </xsl:variable> <xsl:call-template name="write.text.chunk"> <xsl:with-param name="filename" select="concat($base.dir,'default.css')"/> <xsl:with-param name="content" select="$content"/> <xsl:with-param name="quiet" select="$chunk.quietly"/> </xsl:call-template> </xsl:template> <!-- --> BS> Norm, BS> You don't have to say anything, because it *was* a good idea at the time. BS> We all did what we had to do with HTML, given the limited tools of just a BS> short while ago. The point I was trying to make is that the design BS> principles for HTML have changed, and perhaps this would be a good time to BS> reexamine how DocBook XSL generates its HTML. BS> I would like to see some version of the stylesheets generate clean XHTML and BS> a CSS stylesheet. The styles in the stylesheet could be mostly BS> placeholders, but they would make a good starting point for anyone who wants BS> to customize the format of their XHTML. BS> Bob Stayton BS> Sagehill Enterprises BS> DocBook Consulting BS> bobs@sagehill.net BS> ----- Original Message ----- BS> From: "Norman Walsh" <ndw@nwalsh.com> BS> To: <docbook-apps@lists.oasis-open.org> BS> Sent: Thursday, October 28, 2004 5:27 PM BS> Subject: [docbook-apps] Re: Bug #849312 shade.verbatim not working in BS> programlistingco BS> / "Bob Stayton" <bobs@sagehill.net> was heard to say: BS> | Yes, let's move the DocBook HTML into the modern age and not BS> | use tables for such formatting hack. 8^) BS> What can I say? It seemed like a good idea at the time... BS> | There are some other uses of HTML tables that could use a looking at, BS> The others have to be explicitly enabled. I suppose we could remove BS> them too, but getting some aspects of list formatting right with CSS BS> might be a real challenge. BS> | as well as the vestiges of formatting elements like <b>. BS> I think I ripped most of those out the other day when I applied a BS> patch. -- techtonik
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]