[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK-APPS: Re: list items HTML formating with XSL
-----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-----
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC