DOCBOOK-APPS: Re: list items HTML formating with XSL

[Norman Walsh <ndw at nwalsh dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ jaccoud@petrobras.com.br was heard to say:
|>| Would it be very difficult to condition the emission of these styling
|>| attributes to a stylesheet parameter, say emit.style.attribs ? We can
| then
|>
|>There's already css.decoration. I've changed the list generation
|>templates to output type on ul only if css.decoration != 0.
|>
|>| produce a suitable default CSS to serve as a initial point for styling.
|>| Most of these attributs occur only in tables.
|>
|> I think you can turn all of those off by setting table.borders.with.css=0
|>
|>(But the resulting tables are probably going to be a lot uglier because
|>there's so much that HTML can't do.)
|
| Thank you. But now I can see why I got confused. The parameter names appear
| inconsistent to me. Isn't it strange that a parameter called
| 'css.decoration' would produce the type attribute when set to true? You

Yes. Controlling list type based on css.decoration is a bit odd.

| see, type is defined entirely by HTML, not by CSS. The equivalent CSS code
| for type="disc" would be to use style="list-style-type: disc;". (Yes, it is
| very verbose. However, it was not intended to be used primarily inline, but
| rather in a separate CSS file.) The same applies to the table attributes:
| color, background, border, etc. are all HTML, not CSS (although there are
| CSS equivalents for them).

Well, if css.decoration is true the stylesheets output inline styles
(style="...") to set border attributes. I suppose they should do all the
table formatting with CSS. But CSS isn't quite ubiquitous yet.

| To avoid confusion without changing the parameter semantics, it would be
| nice to rename them. Or better still, to use separate attributes to
| segregate the desired effects: the list- and table-bound attributes turn
| decoration on and off for them, and a separate general attribute selects a
| language for the styling (transitional HTML or CSS). Would that involve too
| much
| coding? I can help.

I'll think about it. I'm trying to avoid a total proliferation of
parameters.

| (BTW: Some entries in pt_br.xml have not been translated/localized. How
| should I proceed to post the corrections? Should I send you the
| modifications? I wasn't able to reach the address stamped in the file
| header, do I need special access for that?)

Grab the original file from gentext/locale in CVS and send a modified
version back to me (or post it as a patch at SourceForge).

                                        Be seeing you,
                                          norm

- -- 
Norman Walsh <ndw@nwalsh.com>      | What is more wonderful than the
http://www.oasis-open.org/docbook/ | delight which the mind feels when
Chair, DocBook Technical Committee | it *knows*? This delight is not
                                   | for anything beyond the knowing,
                                   | but is in the act of knowing. It
                                   | is the satisfaction of a primary
                                   | instinct.--Mark Rutherford
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+KCgnOyltUcwYWjsRArSsAJ916ZiZ8hbeaRqbj9ooo5J410FuHQCfQ43e
bLzjxy6DuukpH6nLq1RtMBs=
=dHO5
-----END PGP SIGNATURE-----