[pmwiki-users] nesting divs and tables

John Rankin john.rankin at affinity.co.nz
Sun Aug 6 20:45:37 CDT 2006

On Monday, 7 August 2006 11:11 AM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
>On Mon, Aug 07, 2006 at 11:03:21AM +1200, John Rankin wrote:
>> On Saturday, 5 August 2006 7:15 PM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
>> >Also, out of curiosity, is there anyone who is likely to be
>> >negatively impacted by this change?  Since nesting hasn't been
>> >allowed until now, the only case I can imagine that might cause 
>> >a problem is where an author has relied on (:table:)/(:cell:) 
>> >to automatically close a >>div<</(:div:) and vice-versa.  But
>> >I can't imagine that this is at all common (and, of course,
>> >it's easily fixed when it does occur).
>> I am almost certain that this will comprehensively break the
>> PublishPDF library. Sigh.
>I'm surprised.  Why would it break PublishPDF?

There are several places that may break:

- we call a TbookCells function instead of Cells when processing
  (:table:) makup, so if Cells changes, we'll need to change

- the <div> tag is translated into a <group> tag, which in turn
  is usually translated into a LaTeX minipage; there are various
  special cases, like >>comment<<; I'm not sure what will happen
  if a minipage contains a minipage, but it may be undesirable,
  so (:div:) inside (:div:) is likely to be a problem

- at the moment, ||simple table markup|| inside (:table:) or 
  (:div:) markup works, so I think (:table:) inside (:div:)
  should be OK; and (:div:) inside (:table:) should also be OK;
  in both cases, I expect we'll have to change TbookCells

- a long (:table:) will split across pages, whereas a long 
  (:div:) will fall off the bottom of a page; I don't know how
  nesting divs in tables and tables in divs will affect this

- we also do some things to fix up (:closeall:) -- this needs
  a bit of background...

  * the wikibook DTD uses nested <section>, <subsection>,
    <subsubsection>, ... tags to show document structure

  * we have chosen to interpret heading tags as denoting
    structure, so !!heading markup --> <section><heading>
    ...</heading> ... </section>

  * it works out from the context what level each heading 
    represents; sometimes !!heading --> <section> but in
    other contexts, !!heading --> <subsubsection>

  * when it gets to the end of a page, it has to close any
    open section, subsection, ... tags in the correct order

  * when we assemble several wiki pages into a book, it
    automatically slots headings into the correct place
    in the book hierarchy and includes them in the table
    of contents

- this has a couple of consequences for nested divs and tables

  * if we detect a heading inside a (:div:) or (:table:),
    we treat it as an ordinary heading, rather than as a
    section marker, because otherwise, we end up with
    incorrectly nested tags, such as
<div> ... <section><heading> ... </heading> ... </div> ... </section>

  * so if $MarkupFrame[0]['closeall']['...'] changes,
    the way we process heading markup also has to change 

  * if a page containing a heading is followed by an unclosed
    div or table, we have to prevent this error:
    <section> ... <div> ... </section></div>
    caused when (:closeall:) markup is processed

  * so we add a special markup when we close nested sections
    and have a markup rule that runs after closeall to
    reverse the incorrect nesting

- in other words, at the moment, the way we process nested
  headings assumes that (:div:) and (:table:) do not nest;
  I don't know what the effect will be when this assumption
  is no longer valid

All I can do is test it and see what breaks, but from the
above, it's likely that a few things will stop working.

I hope this explanation makes sense.
>Also, given that it will likely cause problems for PublishPDF,
>I'll definitively provide a "preserve 2.1.11 behavior" option
>for this in the transitions.php module.  The PublishPDF recipe 
>can set 
>    $Transition['nodivnest'] = 1;
>to preserve the old non-nesting behavior until things can 
>be worked out.

Cool! Nesting is in principle a good thing, but the way
html nests things is not the same as the way wikibook xml
nests things, unfortunately.

John Rankin

More information about the pmwiki-users mailing list