Closed Bug 277407 Opened 20 years ago Closed 20 years ago

No table cells with row.innerHTML='<td>text</td>'

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: martijn.martijn, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(3 files)

Testcase
609 bytes, text/html
Details
Testcase2
628 bytes, text/html
Details
5 test cases
1.41 KB, text/html
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050104 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050104 Firefox/1.0+ See testcase. It seems that I just can't add table cells with row.innerHTML. All the tags get stripped and only the raw text gets added to the row. Reproducible: Always
Attached file Testcase —
Keywords: testcase
Does this work if you have a table outside the tr when you do innerHTML? innerHTML parses in the context of the parent node, and the HTML parser probably throws away the <tr> tag when it comes as the root opening tag (without an open <table> tag).
Attached file Testcase2 —
Then it's working fine. It might be worth knowing that IE6 is not working well with both testcases (not rendering the firt one and on the second one gives a js error).
So sounds like we do this as well or better than IE? ;) Seriously, it sounds like the behavior is more or less correct...
i agree.
Ok, I think I understand now. I guess, this is more or less parser behavior, where Mozilla is 'fixing' my 'broken' html code (I hate it when that happens). Marking invalid. Thanks for looking into it.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Hmm, bug 228920 might be interesting, since -as far as I can see- handles about the same problem. There was a temporary workaround patch checked in for that, which is still in the Mozilla code.
Never mind, comment 7 is bogus.
*** Bug 311042 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Seriously, it sounds like the behavior is more or less correct... How do you know what is "correct" behavior for innerHTML? Is there any specification of how innerHTML should work?
The spec for innerHTML is at http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/innerhtml.asp Since that spec doesn't really cover this case, the spec is "do what IE does, within reason". Since IE totally fails, and since what we do is within the spirit of the spec I referenced, I called it "more or less correct" (which is not the same thing as "correct").
Actually the WHATWG spec defines this so that it should work: http://www.whatwg.org/specs/web-apps/current-work/#innerhtml0 Not a high priority fix, obviously, and let me know if it breaks things, but it seems like a good thing to support if we can. Consistency in the API and all.
Really? So per the WHATWG spec, what DOM does: data:text/html,<!DOCTYPE html><tr><td>Text</td></tr> produce? fwiw, I agree that it would be nice if this can work.
From Ian's comment above, this sees to be a valid bug, please consider re-opening it from the current state of RESOLVED INVALID. "Actually the WHATWG spec defines this so that it should work: http://www.whatwg.org/specs/web-apps/current-work/#innerhtml0" Looking that spec over, it probably also depends on how you interpret the HTML fragment parsing algorithm: http://www.whatwg.org/specs/web-apps/current-work/#html-fragment-parsing-algorithm I created five simple examples. All of them work properly in Safari and Google Chrome. In FireFox versions 2, 3, and 3.5 Example 1 fails but all the others work. Inconsistency like this, having success depend on the order of operations, and having to understand what the parser is doing is pretty annoying for app developers: a couple coworkers and I spent a few engineer hours here trying to figure out what was going on, in the end just being frustrated. Example 0: WORKS Set a <table>'s .innerHTML to '<tr><td>test</td></tr>' Example 1: DOES NOT WORK Create a free-floating <tr> with CreateElement Set the <tr>'s .innerHTML to '<td>test</td>' Append the <tr> to a table Example 2: WORKS Create a free-floating <tr> with CreateElement Create a free-floating <td> with CreateElement Set the <td>'s .innerHTML to 'test' Append the <td> to the <tr>, and the <tr> to a table Example 3: WORKS Create a free-floating <tr> with CreateElement Append the <tr> to a <table> Set the <tr>'s .innerHTML to '<td>test</td>' Append the <tr> to a table Example 4: WORKS Set a <tables>'s .innerHTML to '<tr id="testtr"></tr>' Get the newly-created <tr> with document.getElementById() Set the <tr>'s .innerHTML to '<td>test</td>'
Attached file 5 test cases —
Example 1 (second example) fails in Firefox 2, 3, 3.5, all work in Safari and Chrome
I'm not sure it's really worth reopening all the parser bugs where we've ever decided something differently from IE or Webkit because HTML5 is finally defining this stuff.... We should land the new parser (soon now), then file bugs on specific HTML5 parsing tests we fail. For example, I strongly suspect that Henri's parser changes the behavior here.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: