W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2006

[whatwg] [WA1] Formatting elements

From: Stewart Brodie <stewart.brodie@antplc.com>
Date: Mon, 17 Jul 2006 12:09:26 +0100
Message-ID: <c617f0c9aa9b6268a8811cc51e8cf3a438a05245@localhost>

I tried dry-running the algorithm for handling mis-nested formatting
elements, but I ended up with a tree that looked very odd.  I can't believe
that the output I ended up with is what the desired result of the algorithm
is, so there is a mistake somewhere: either in my execution of the algorithm
or in the algorithm itself.  I took the following fragment of HTML:

<DIV> abc <B> def <I> ghi <P> jkl </B> mno </I> pqr </P> stu

The DIV is chosen to provide a suitable context for testing everything else.
B and I were chosen as formatting elements with short names, P was chosen as
it has no special behaviour as an open tag when in "in body" state (possibly
a mistake?  I'm not certain).  One filled whiteboard later, the result I
ended up with was equivalent to:

<DIV> abc <B> def <I> ghi </I> </B> <I> </I> <P> <I> <B> jkl </B> mno </I>
pqr </P> stu </DIV>

I know it's hard to see when written out textually, but note that for the
text node 'jkl', the I and B elements are the wrong way around!  It all
seems to start going wrong for me in step 7 of the algorithm.  During the
handling of the </B> tag, the clone of I gets created and that's the node
that ends up being the childless I node that has the DIV as its parent
(during step 5 of handling the </I> tag when the I is cloned for a second
time to be the child of the P and adopt the original children of the P)
Firefox generates what I think I would expect and prefer:

<DIV> abc <B> def <I> ghi </I> </B> <P> <B> <I> jkl </I> </B> <I> mno </I>
pqr </P> stu </DIV>

This behaviour would be consistent with disallowing non-phrasing and
non-formatting elements on the stack of open elements when there are
phrasing/formatting elements on the bottom of the stack.  IOW, the <P>
implicitly closes the B and I elements, leaving them in the list of active
formatting elements, and then NOT executing "reconstruct the active
formatting elements" before appending the new P element, leaving that for
when the 'jkl' text node is encountered.

For comparison, Internet Explorer 6 on the other hand treats the P no
differently to the B or I and ends up with:  <DIV> abc <B> def <I> ghi <P>
jkl </P> </I> </B> <I> <P> mno </P> </I> <P> pqr </P> stu </DIV>

The problem here may simply be that appending any node due to opening any
non-formatting/non-phrasing open tag when in "in body" should cause any
formatting/phrasing elements to be popped off the stack of open elements,
and then NOT execute "reconstruct the active formatting elements" (because
it'll be executed automatically when opening the next formatting/phrasing
element or text node anyway)

Stewart Brodie
Software Engineer
ANT Software Limited
Received on Monday, 17 July 2006 04:09:26 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:47 UTC