This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 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    | 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]