Re: Black-box equivalence of parsing fragments directly into context node

On Tue, 2 Dec 2008, Henri Sivonen wrote:
> On Dec 2, 2008, at 06:45, Ian Hickson wrote:
> > On Mon, 17 Nov 2008, Henri Sivonen wrote:
> > > Is there a reason why the spec doesn't prescribe this? Why does the 
> > > spec specify parsing into another document first and then moving the 
> > > nodes over?
> > 
> > The algorithm is intended to be used for purposes other than 
> > innerHTML.
> 
> What other purposes? For HTML fragments in Atom and RSS?

For example, yes. Basically anything that might need a fragment processed.


> > On Wed, 26 Nov 2008, Jonas Sicking wrote:
> > > 
> > > Why couldn't the spec instead say to use the ownerDocument of the 
> > > context node (like Henri is suggesting) and parse into a 
> > > documentFragment node? I.e. why do we need the new Document node and 
> > > the new <html> node?
> > 
> > I guess we could do that, but what would it gain us? Implementations 
> > are free to optimise this anyway.
> 
> In general, when the spec says something that differs significantly from 
> what one might implement, there's overhead in trying to figure out if 
> the spec says a different thing for a specific reason that would foil 
> the optimization.

Yes, but it's not like all implementations are going to implement it 
exactly as we spec it even if we do it the way you describe, so that would 
likely end up being a false economy (with the disadvantage that the model 
you describe is, IMHO, harder to reason about).


> > On Wed, 26 Nov 2008, Henri Sivonen wrote:
> > > 
> > > Why is there even a need for parsing into a document fragment? Would 
> > > mutation events or something of that nature go wrong if parsing 
> > > directly into the context node?
> > 
> > We'd quench those anyway.
> 
> The spec is clear that the act of parsing the fragment doesn't cause 
> mutation events to fire. However, the spec isn't clear on whether 
> mutation events should fire for the act of inserting the fragment into 
> the main document.

Clarified.


> > On Wed, 26 Nov 2008, Boris Zbarsky wrote:
> > > 
> > > From a spec point of view the only obvious issue I see here is that the
> > > mutation event behavior means the parser needs to take pains to produce
> > > the same results as would be produced by the currently-specified
> > > algorithm even in cases when mutation events rearrange the DOM.
> > 
> > Surely we don't want any mutation events firing during innerHTML.
> > 
> > The spec currently says:
> > 
> > # DOM mutation events must not fire for changes caused by the UA parsing
> > # the document. (Conceptually, the parser is not mutating the DOM, it is
> > # constructing it.) This includes the parsing of any content inserted
> > # using document.write() and document.writeln() calls.
> 
> But the act of inserting the fragment into the document is conceptually a
> scripted mutation, isn't it?

Once mutation events are more stable, if we want them to fire for these 
mutations, then we can add them back, with a clear definition of how they 
work. That's dependent on what DOM3 Events ends up saying.


> > On Thu, 27 Nov 2008, Henri Sivonen wrote:
> > > 
> > > For efficient buffering, it's important for the parser to know when 
> > > it needs to drive buffers into a safe point so that document.write() 
> > > can insert into the stream. So far, at least my assumption has been 
> > > that scripts can only execute as a side effect of a parser action 
> > > when a <script> element (either HTML or SVG) is popped off the 
> > > stack. Now it has turned out that scripts can execute as a side 
> > > effect of a parser action also when an <svg> element is popped off 
> > > the stack.
> > 
> > Ew, that seems highly problematic. Where is this defined?
> 
> http://www.w3.org/TR/SVG/interact.html#LoadEvent Now I notice that it's 
> even worse than <svg onload>: It's onload on any element in the SVG 
> namespace.

I don't see where the actual normative requirement is. Could you 
elaborate?

Even based on the (requirement-free) descriptive sentence for SVGLoad in 
that table, there's nothing that says it should be synchronous. If 
anything, the dependence on other resources implies it can't be.

I can mention the SVGLoad event explicitly in the definition of the event 
loop if that would help, but really I'd much rather the SVG spec was 
written to actually define how this is really supposed to work.


> > > I think the document.write()-safe points need to be enumerated. In 
> > > the other cases (which hopefully form an empty set), 
> > > document.write() should be a no-op. That is, I think the spec should 
> > > either specifically make the load event for <svg> a safe point for 
> > > document.write() or it should make document.write() a no-op if 
> > > executed at that point. The fewer these document.write()-safe points 
> > > are, the better.
> > 
> > I don't understand what you mean by "safe point".
> 
> I meant a point where there's at least one parser method on the call 
> stack but re-entering the parser with document.write() indeed writes 
> (either by immediate tokenization or by inserting to the stream and 
> returning without tokenizing immediately).
>
> > If you call document.write() from <svg>, then you'll blow away the 
> > document, since the insertion point won't have been defined.
> 
> That's not a safe point, then. :-)

(Note -- the above assumed that SVGLoad firing on <svg> was synchronous, 
which I don't think it really is.)


> (On its face, blowing away the document seems more complex than making 
> document.write a no-op if called from an SVG onload handler. I need to 
> study existing cases of blowing away the document more carefully.)

Blowing away the document happens because document.open() is implicitly 
called. It can always be explicitly called. I don't think we want to be 
adding more ways that document.open() can react here.


> SVG <script> elements should behave exactly like HTML <script> elements 
> as far as the insertion point goes, though, right?

That would be nice. If the issue of SVG-in-text/html is resolved, then 
that is something we need to spec out.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 2 December 2008 10:17:36 UTC