[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK-APPS: Re: Is it time to rely on CSS?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 / jaccoud@petrobras.com.br was heard to say: | WYSIWYG, and to expect visual conformance in all browsers is futile. I | think a viable strategy for the DocBook stylesheets is to avoid generating | styling code, and concentrate in the HTML semantic markup. This way, is is To a very large extent, that is just what the stylesheets do. | We don't need to embed CSS2 in the XSL stylesheets at all. They only need | to provide the hooks (<div>s, <span>s, and class attributes) to allow CSS | to do its job. The point is, what should be generated for those places where some formatting distinction would be desirable even in the case when CSS is not used? Or when HTML doesn't provide semantic markup for the distinction? There are two cases: 1. Elements that you'd like to have distinguished and where there's reasonable HTML markup that can be used. 2. Elements that you'd like to have distinguished but for which no HTML markup provides the desired effect. Figure titles are an example of the first case. Using: <p><b>Figure Title</b></p> produces a decent result in basically all browsers. Using <div class="figtitlediv"><span class="figtitle">Figure Title</span></div> would be semantically purer in some ways, but would be indistinct if no CSS was provided. List item bullets are an example of the second case. HTML doesn't provide a mechanism for overriding the bullet on an individual list item. So if an author specifies an alternate mark for an individual item in an itemizedlist, the stylesheets basically have to use CSS for it. Table cell borders are an even better example of the second case. HTML doesn't provide any mechanism for supporting borders on selected table rows or cells. So there's no way to support CALS colsep and rowsep except through CSS. And what's particularly challenging here is the fact that it varies on a per-cell basis; there's no "class" of cell that could be used. As a middle ground, the stylesheets could start generating a <style> element in the head and using it instead of inline style wherever possible. But note that they'd generate the same <style> in every file, even if none of those styles was ever used. Be seeing you, norm - -- Norman Walsh <ndw@nwalsh.com> | There is no such thing as an http://www.oasis-open.org/docbook/ | absolute certainty, but there is Chair, DocBook Technical Committee | assurance sufficient for the | purposes of human life.--John | Stuart Mill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/> iD8DBQE+Lp+XOyltUcwYWjsRAlrHAJ9EAl8hu8I9ahqquSWzLmjp/c05ggCgo5Xw 3YQ1xpXjBiIKEqM6NbZ/Xdg= =bglg -----END PGP SIGNATURE-----
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC