On Fri, 27 Jan 2006 08:08:49 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
Ok, I specced out what I think is a workable algorithm that works a lot
better than what we had before.
It still only supports <p> and <em> elements inside <body> for now, but
at least it does so in a way compatible with Safari and Mozilla's DOMs,
and compatible with Opera and IE's renderings.
http://whatwg.org/specs/web-apps/current-work/#the-main
http://whatwg.org/specs/web-apps/current-work/#closing
http://whatwg.org/specs/web-apps/current-work/#how-to
1. What happens with the following: <script src="1.js"><script src="2.js">
(without closing tags)?
2. With the described algorithm it's possible to build DOM with, for
example, two TITLE nodes, which is invalid. At what point should it be
handled? How it's finally resolved what should be the title of the
document?
3. Insertion mode "after head", and a FRAME opening tag appears. Shouldn't
we switch to "in frameset"?
4. Insertion mode "in body", action for opening P. It can instead start
with the words "Act as if a closing P had been encountered, then ..." This
will better reflect what we are doing.
5. How does EM ever get added to the list of active inlines?
6. Why is unexpected closing tag a difficult parse error in insertion mode
"in body"?
7. End of file immediately after a closing BODY tag will cause an infinite
loop. End of file should be handled in "after body" insertion mode.
8. I don't think it's right to define a parsing algorithm that only works
for UAs that support scripts and frames, and then do define variations for
those who need the noscript and noframes content. The parsing algorithm
should be uniform and produce the same DOM no matter if the UA supports
scripts or frames. It should be the rendering engine's decision to show
frames, the noframes content, or both (actually, it might be toggled by
the user even after parsing the document).
9. Mozilla seems to also honor TABLE and TR as elements that inline
styling doesn't leak though. These should be included in the definition of
"in scope".
10. Step 5 of the "Closing inline elements" algorithm. I think that the
conditions for reparenting should be made more strict: if the element
immediately above the furthest block in the stack of open elements is not
the parent of the furthest block (i.e. the furthest block seems to be
relocated by a script), don't reparent it.
11. Step 6.6 of the "Closing inline elements" algorithm. If the furthest
block is the same as the nearest block, how do cloned nodes get added to
the stack of open elements?
12. I'm afraid that the "Closing inline elements" algorithm is too
radical. For instance, it will clone headers, affecting the document
outline.
--
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] <[EMAIL PROTECTED]>
