Re: Drop foster-parented stuff on the floor if parent gone

On Thu, Dec 25, 2008 at 12:03 PM, Ian Hickson <ian@hixie.ch> wrote:
>
> On Tue, 9 Dec 2008, Henri Sivonen wrote:
>>
>> Deferring tree mutations would become slightly simpler if
>> foster-parented stuff was simply dropped when the table parent is gone.
>
> I haven't made this change. It would make other implementation strategies
> more complex, so there doesn't seem to be an overall clear indication of
> what would be best. Even in the deferred mutation case, it seems like you
> could just use a "foster insert" action instead, which the main thread
> would handle accordingly.

Would it really make other implementations more complex? Having just
briefly looked at Henris code, he had to pass along two insertion
points to the code that dealt with foster parented content, both the
<table> element where the content should be inserted before, and the
alternate insertion point if the <table> doesn't have a parent.

With Henris strategy only the <table> needs to be passed along, if it
doesn't have a parent the operation just returns.

So I would argue that the proposal is in fact reducing complexity no
matter what.

Another argument for why the currently specced algorithm is bad is
that it seems somewhat surprising. If a table is removed something
somewhat unrelated dramatically changes its behavior.

An ideal algorithm would be something like this:
1. Find the last table in the stack of open elements.
2. Find the element in the stack of open elements that is right before
the last table in the stack of open elements. (this is generally the
parent of the table unless the DOM has been mutated)
3. If an element was found in both 1 and 2, and the the table found in
1 is a child of the element found in 2, insert the new node before the
table found in 1 and exit the algorithm.
4. If an element was found in 2, append the new node to 2 and exit the
algorithm.
5. Otherwise drop the node.

This would seem to produce the most consistent behavior in that the
DOM can be modified while parsing happens, without those modifications
having effects other than the ones explicitly performed in the vast
majority of cases.

This is definitely more complex, though not a lot more so, so I think
Henris algorithm would work equally well given that all of this is a
very rare case.

/ Jonas

Received on Wednesday, 31 December 2008 02:00:32 UTC