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: