This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10221 - Always coalesce adjacent text nodes even in the case where the previous node was not the one last inserted by the parser.
Summary: Always coalesce adjacent text nodes even in the case where the previous node ...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC All
: P1 critical
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-21 20:27 UTC by James Graham
Modified: 2010-10-04 13:59 UTC (History)
7 users (show)

See Also:

Attachments

Description James Graham 2010-07-21 20:27:41 UTC 
Always coalesce adjacent text nodes even in the case where the previous node was not the one last inserted by the parser.

For markup like
<table>
a
<tr></tr>
b
<tr></tr>

The spec currently requires two text nodes to be created, one for "a" and one for "b". This is different to the usual behaviour where adjacent text nodes are coalesced. The original reason for the change was to defend against N^2 behaviour from growing the text buffer. However this behaviour is not implemented by Gecko or (I believe) WebKit ToT. Nor is it implemented in html5lib and indeed is a problem for some non-DOM tree formats that have no concept of text nodes. It is possible to prevent the N^2 behaviour with a sufficiently clever implementation. Given this, the spec should revert to coalesce always.
Comment 1 Henri Sivonen 2010-07-22 08:24:48 UTC 
My current thinking is that the parser should coalesce. If that's a perf problem when the node size gets very large, then I think implementors should invoke the DoS avoidance limits trump card cause in the spec and not coalesce too large nodes in any situation--be it foster-parenting, document.write() or discretionary flushes for incremental layout of huge text nodes.
Comment 2 Ian 'Hixie' Hickson 2010-08-16 20:38:14 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.

This is going to lead to some very interesting test cases. I especially like this one (listed in the spec):

A<script>
var text = document.getElementsByTagName('script')[0].firstChild;
text.data = 'B';
document.body.appendChild(text);
</script>C

(Should result in two text nodes.)
Comment 3 contributor 2010-08-16 20:38:56 UTC 
Checked in as WHATWG revision r5298.
Check-in comment: Coalesce text nodes even if they're not parser-inserted.
http://html5.org/tools/web-apps-tracker?from=5297&to=5298