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] improve DocBook's HTML output


Bob,

I like your ideas, especially strict [X]HTML output, but I wonder
about the danger of having one 'html.stylesheet' param that might
overwrite something we have modified manually:

At Sat, 28 Nov 2009 10:41:21 -0800, Bob Stayton wrote:

...
> I think two params could control this feature:
...
> 2.  A new param named 'generate.css', which when set to 1, will generate a 
> CSS stylesheet file. The name of the file is given by the existing 
> 'html.stylesheet' param. The generated stylesheet would contain selectors 
> for all class attributes in the HTML output, and any styles that are needed 
> to format the new clean version of an element.   Most of the selectors would 
> be empty of styles, but would be available for further styling of the HTML 
> output.  If 'generate.css' is zero, then it is up to the user to supply the 
> CSS file.  By default, 'generate.css' should be zero so as to not overwrite 
> an existing CSS file.
>
> Once this mechanism is in place, we could gradually comb through the 
> existing XSL and gradually replace deprecated HTML coding with clean coding.

That would be very good!

> So if you were just starting out, you could run the process with 
> 'generate.css' = 1 and 'make.strict.html' = 1 to generate a starting CSS 
> file.  After you edit the CSS file, though, you would leave 'generate.css' = 
> 0 and just run with 'make.strict.html' = 1.

I worry about changing the meaning of 'html.stylesheet'.  I might
forget to set 'generate.css' = 0 and then overwrite my own custom CSS.
It might work better to keep 'html.stylesheet' for the user's custom
CSS as now and generate a new stylesheet, say, 'generated.stylesheet'.  
Then both could be used, with priority going to the user's custom CSS.

I think that would cause less breakage for those of us who already
have fairly complex stylesheets.  We could leave 'generate.css' = 1
and experiment with selectors by overriding them in our own stylesheets.
Then we would not need to change the XSLT stylesheet params often.
As the XSLT stylesheets are updated, we could see new default CSS
output in 'generated.stylesheet' and maybe modify it in our own
custom 'html.stylesheet'.  Maybe that would give us stability in 
our projects and help us share ideas for new default styles.

Thanks.

Greg Peterson <peterson@notredame.ac.jp>


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