Re: CSS gap between inline elements

On 2008-02-09, VK <schools_ring (AT) yahoo (DOT) com> wrote:
[...]

function init() {
var message = '';

var menuItem = document.getElementById('Item1');

if (menuItem.nextSibling.nodeType == Node.TEXT_NODE) {
message+= 'The next node after Item 1 is TEXT_NODE\n';
message+= 'It has width of ' +

The first thing is there is obvious bug in your JS here.

menuItem.offsetWidth + 'px ' +
'and height of ' +
menuItem.offsetHeight + 'px';
window.alert(message);

You're alerting the width of Item 1, not the width of the next node
after it.

If you change that to menuItem.nextSibling.offsetWidth Firefox gives you
the value "undefined" (so does Opera).

You probably get undefined whenever you try to get offsetWidth on a
#text node, I'm not sure.

[...]

ul
li id="Item1">Item 1</li
li id="Item2">Item 2</li
/ul
p>This way on Gecko a pretty-print line break (even without space)
leads to a <strong>displayed</strong> element with its own width,
height and other properties.

But if you look at the displayed page, there is no mystery element with
an approx 45px width between the two Items. And if you fix the bug in
the JavaScript, you will see that the "phantom text node" does not have
an offsetWidth of 45px either.

Yes a space appears between Item1 and Item2 because there is a newline
in the source. This is correct behaviour and comes under whitespace
collapsing, not under what DOM tree you get from what HTML source.

If a browser treats:

<li id="Item1">Item 1</li>
<li id="Item2">Item 2</li>

differently from

<li id="Item1">Item 1</li>
<li id="Item2">Item 2</li>

then the bug is in its whitespace handling, not in whether whitespace
nodes should appear in the DOM tree or not.