Closed Bug 381808 Opened 17 years ago Closed 14 years ago

Setting innerHTML on a block element inside an inline element creates extra copies of the inline element

Categories

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

x86
All
defect
Not set
minor

Tracking

()

RESOLVED FIXED

People

(Reporter: phil.crosby, Unassigned)

References

()

Details

(Whiteboard: [fixed by the HTML5 parser])

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060911 Camino/1.0.3
Build Identifier: 

This page doesn't validate, so I'm not sure what the expected behavior really is, but the current mozilla behavior is very curious.

Have a look at this example. Comments in the source explain actual/expected behaviors:
http://philisoft.com/bugs/j/moz/nestedb.html

Workaround is to use <div> tags, not <b>. The only reason I stumbled upon this is because I've seen some "rounded corner" tutorials that use nested <b> tags for the markup, and I've used nested <b> tags on some of my sites without problems. This behavior really had me scratching my head for hours.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
	"http://www.w3.org/TR/html4/strict.dtd">
<html>
<!-- 
	this page doesn't validate; w3c doesn't think you can nest <b> tags. Not sure what the expected behavior should be.
	Filed as: https://bugzilla.mozilla.org/show_bug.cgi?id=381808
-->
<head>
	
<script type="text/javascript">
function init(){
	document.getElementById("msg").innerHTML="section 1";
	
	/* produces the DOM tree (use firebug to inspect):
	
	<b><b><b>
		<div id="msg">
			<b><b><b>section 1</b></b></b>
		</div>
	</b></b></b>
	
	instead of the expected:
	
	<b><b><b>
		<div id="msg">
			section 1
		</div>
	</b></b></b>
	
	*/
}
</script>

<style>
/* these style declarations are optional */
b{
	display:block;
	font-weight:normal;
}
</style>
</head>

<body onload="init();">

	<!-- these two DOM trees will be loaded differently, because the first div has its
		contents set with Javascript through innerHTML, while the second doesn't. 
	-->
	<b><b><b>
		<div id="msg"></div>
	</b></b></b>


	<b><b><b>
		<div id="msg2">section 2</div>
	</b></b></b>
</body>
Attached file testcase
meant to attach as a file
The problem isn't the nesting of <b> tags, but putting a <div> (a block element) "inside" a <b> (an inline element).  See http://ln.hixie.ch/?start=1138169545&count=1.

What this testcase shows is the opposite of what I'd expect, though.  Hmm...
Simply doing

  document.getElementById("msg").innerHTML += "";

causes an extra set of <b>'s to appear inside the div.  I'm pretty sure that's wrong.
Status: UNCONFIRMED → NEW
Component: DOM → DOM: Mozilla Extensions
Ever confirmed: true
Summary: Nodes inside nested <b> elements get nodes added to them when setting their innerHTML → Setting innerHTML on a block element inside an inline element creates extra copies of the inline element
In this test case, <b> is made display:block, which should make any issues about inline elements having nested block elements void.
For layout, sure, but not for HTML parsing...
Attached file Jesse's testcase
Clicking the button just does
  (...).innerHTML += ''
and yet it creates new <big> elements and changes the page's appearance.
There are two separate concepts of block vs inline.  One in CSS and one in HTML.  They don't match.

In any case, the point is that in HTML <b> is not allowed to contain <div> (so the <b> needs to get closed), but the text needs to be bold for compat so we do residual style handling.  HTML5 is going to define a different method of doing this anyway, so at that point we'll need to revisit this bug.
Depends on: 328930
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by the HTML5 parser]
I'm new to reporting, or commenting on bugs in bugzilla, but I'm still experiencing this issue with divs that are wrapped in anchor tags.

<a>
    <div>
       <p>Text</p>

    </div>
</a>
...didn't mean to submit my comment yet.  I know it's not semantic markup, but I notice this doesn't happen in other browsers.  Should I seek a different way to mark up my page, or should I hope for a fix for this?

Thanks.
Jiert, which version of Firefox did you use for testing?
If 3.x, please try something newer, maybe even a nightly FF4 build
http://nightly.mozilla.org/.
3.6.10.  Thanks Olli, I'll see if FF4 does the trick.
Component: DOM: Mozilla Extensions → DOM
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: