W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2010

[Bug 10221] New: Always coalesce adjacent text nodes even in the case where the previous node was not the one last inserted by the parser.

From: <bugzilla@jessica.w3.org>
Date: Wed, 21 Jul 2010 20:27:41 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-10221-2486@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10221

           Summary: Always coalesce adjacent text nodes even in the case
                    where the previous node was not the one last inserted
                    by the parser.
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: critical
          Priority: P1
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: jgraham@opera.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html@w3.org


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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 21 July 2010 20:27:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:52 UTC