On Fri, 27 Jan 2006, Alexey Feldgendler wrote: > > 1. What happens with the following: <script src="1.js"><script > src="2.js"> (without closing tags)?
Nothing yet, I haven't specced out the <script> start tag. I plan to say that it would be treated as <script src="1.js">, with the element containing the CDATA text token with value '<script src="2.js">'. > 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. > How it's finally resolved what should be the title of the document? 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). > 3. Insertion mode "after head", and a FRAME opening tag appears. > Shouldn't we switch to "in frameset"? Not according to any of the browsers I tested, no. > 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. No, because that would trigger an easy parse error every time you hit a <p> that wasn't preceeded by another <p>. :-) > 5. How does EM ever get added to the list of active inlines? Oops! I forgot to add that. Added. > 6. Why is unexpected closing tag a difficult parse error in insertion > mode "in body"? That's just a placeholder for now. > 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. Good catch! Fixed. > 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. > 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. > 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. > 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. > 12. I'm afraid that the "Closing inline elements" algorithm is too > radical. For instance, it will clone headers, affecting the document > outline. No, it will only ever clone inline elements, not block-level elements. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
