On Fri, 27 Jan 2006 13:36:46 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
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?
Not sure what you are asking. The <title> parsing is fully defined in the
parser section now.
No, I mean, <title>A</title><title>B</title>. This is invalid HTML, but
how should it be handled? What will become the actual title of the
document -- A or B?
I haven't defined that yet, that will be defined as part of the
redefinition of |document.title| (or |window.title| or whatever it is).
I think this answers my question.
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).
Sadly, that's not compatible with the Web.
UAs that support frames treat <noframes> as CDATA. That mea, e.g., that
<script> tags inside <noframes> don't get executed, and that <input>
elements inside <noscript> don't get added to forms. We can't change
that.
But UAs can't parse them that way because they wouldn't show anything if
we did that. So forcibly they have to have a different parsing mode.
At least, that's what it looks like to me. I'm open to better
suggestions.
Just a raw thought: we could parse what's inside <noframes> or <noscript>
into a completely different DOM tree which isn't a subtree of the main
document but is available as, for example, document.noframes and
document.noscript. It's easy to move that into the main document if
needed. But it's a different parsing mode anyway, so I doubt there are any
benefits from this.
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".
Yeah, I haven't defined <table> parsing yet.
No, I mean the part you already wrote, "The stack of open elements", point
3: "Otherwise, if node is one of the following..."
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.
This requires that the parser check something every time we do residual
style processing -- something which will only rarely be hit anyway --
which is a performance hit. I don't think the advantage of doing this
outweighs the disadvantage of a perf hit.
Doesn't Safari do it?
But, actually, I think it's not important because if an author writes
something like <B><I></B></I>, he most probably suffers from brain
damage^W^W^W^W doesn't have a clear vision of parent-child relationships
between these elements, and hardly attempts to access the DOM tree at all.
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?
They will get re-added by the inline reconstruction step when the next
inline element or text node is seen.
No, I mean the elements are added to the DOM tree but not to the stack of
open elements. The stack seems to go out of sync.
--
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] <[EMAIL PROTECTED]>
