[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: Changing <p>...</p> to <p> in DSSSL stylesheets
/ Mårten Lindström <marten.lindstrom@swipnet.se> was heard to say: | Being a newcomer I should probably keep my mouth shut. But ... | | From what I understand, a DocBook PARA containing a list, could also contain | text (#PCDATA), both before and after the list. I.e. | | <para>This is a very special para. It contains: | <itemizedlist> | <listitem> | <para>A list.</para> | </listitem> | <listitem> | <para>Some leading and trailing #PCDATA as well.</para> | </listitem> | </itemizedlist> | Not easy to translate into HTML that. | </para> | | (This certainly seems strange but, as Peter Flynn points out, the list here | is probably best understood to be inline - despite the contained paras.) For the record, Peter's expectations not withstanding, the list is not inline. It's a block list inside a paragraph. | Provided that the DocBook list is translated into a HTML list, then, to | translate the containing para into a HTML p - even if omitting the end tag - | is not legal (if I am right). On the other hand I don't think it would be | legal to translate it to a DIV either - _except_ if the the leading and I think you're right. | If so, ensuring legal HTML would mean creating entirely new P elements for | any freefloating #PCDATA _and_ translating the containing PARA into a HTML | DIV (or omitting it). If you're going to go this far, then the DIVs are completely unnecessary, just translate the preceding list into two <p>'s and a <ul>. | I know practically nothing about DSSSL/Jade but suspect that would not be | easy to do. (Just dropping all para end tags certainly seems a lot simpler.) Exactly. Doing "the right thing" would be difficult and would would require, unless I'm overlooking something, a linear, character by character, walk through each paragraph. Can you say "performance impact". I knew you could. And, naturally, the problem is far worse than the simple example shown. Consider: <para>...<orderedlist><listitem><para>...<itemizedlist><listitem><para>... <informaltable>...<entry><para>...<itemizedlist>...</itemizedlist></para> </entry></informaltable></para></listitem></itemizedlist></para></listitem> </orderedlist></para> I don't think this can reasonably be represented in HTML without some convolution. So the bottom line is this: empty <p> tags would be right sometimes and wrong no more frequently (since the browser (i.e., any SGML parser reading the HTML doctype (hahahaha---he said browser and SGML parser in the same sentence, hehehehe)) inserts the </p> tags at the first block and ignores the (now bogus) </p> tags anyway). | But is anyone using such para elements anyway? Sometimes. I really want to write <para>some introduction to a list: <orderedlist>...</orderedlist> </para> But sometimes I avoid the problem, and write <para>some introduction to a list:</para> <orderedlist>...</orderedlist> just to make the HTML legal. Then I think about how silly it is to dilute the semantics of my source document for HTML and I sigh deeply and mutter something about browser support of XSLT or something. Cheers, norm -- Norman Walsh <ndw@nwalsh.com> | All things are contingent. And http://www.oasis-open.org/docbook/ | there is chaos.--Spalding Gray Member, DocBook Editorial Board |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC