[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
TbookCells
- 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.
--
JR
--
John Rankin
More information about the pmwiki-users
mailing list