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] | [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