jst and I were talking about this a while ago, and this has now come up again on the WHATWG mailing list. Currently ScanDocStructure will take anything it's given and send it back out, leaving decisions about what is "unknown" and "malformed" to where packet boundaries lie, etc. We should make it require a fixed number of tokens to do its work, so while it won't be perfect, it'll be deterministic, which is better than what we have now. Someone (ahem) should probably do some sort of measuring to see what a good number of lookahead tokens is that balances good decisions against speedy rendering.

This uses an empty script element to simulate a packet boundary, and is equivalent (other than s/packet boundary/script/) to the problem that's been bugging people about the output of the testing tinderboxes (pre-bug 370344). If you wanted to add this to reftest, the reference would be the same testcase without the script element (which produces the results described).

Note also that some approaches to fixing this bug might not fix the testcase in comment 1, although I believe the approach in bug 328930 (implementing the WHATWG spec's error handling) would.

(In reply to comment #2) > Note also that some approaches to fixing this bug might not fix the testcase in > comment 1, although I believe the approach in bug 328930 (implementing the > WHATWG spec's error handling) would. I think that, in this case, we'd consistently not have the desired behavior here (that is, the <tt> would have no effect), but you are correct that bug 328930 would present the desired effect.