Re: CSS gap between inline elements

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

On Feb 7, 11:03 am, DrPanic
MiNick (AT) ese_mail_del_buscador_qu...ntra (DOT) com> wrote:
Hello.

I have a problem building an horizontal navlist.

The technique i'm using is very simple: a list with inline LI
elements. It works fine but Mozilla render it with a gap between the
LI elements, I can't understand where that gap comes from. IE7 doen't
render it whith that space between inline LI elements.

This is a capture of the problem:

http://img167.imageshack.us/img167/7283/pruebank5.gif
[...]
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. If you consider it as an obvious
insanity then please help to resolve the infamous
a href="https://bugzilla.mozilla.org/show_bug.cgi?id=26179"

The bug has been resolved as "verified invalid".

But back to the OP's question, and leaving aside DOM methods, if you
write:

<span>foo</span> <span>bar</span>

a space should appear between "foo" and "bar". How can you possibly
consider that a bug?

On Feb 9, 7:19 pm, Ben C <spams... (AT) spam (DOT) eggs> wrote:

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



On Feb 7, 11:03 am, DrPanic
MiNick (AT) ese_mail_del_buscador_qu...ntra (DOT) com> wrote:
Hello.

I have a problem building an horizontal navlist.

The technique i'm using is very simple: a list with inline LI
elements. It works fine but Mozilla render it with a gap between the
LI elements, I can't understand where that gap comes from. IE7 doen't
render it whith that space between inline LI elements.

This is a capture of the problem:

http://img167.imageshack.us/img167/7283/pruebank5.gif
[...]
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. If you consider it as an obvious
insanity then please help to resolve the infamous
a href="https://bugzilla.mozilla.org/show_bug.cgi?id=26179"

The bug has been resolved as "verified invalid".

That doesn't have a lot of importance. HTML either was final, frozen,
and keys from the room dropped into the see, and "either XHTML or no
WWW anymore to you guys". :-) Everything is reversible, it is only the
question of how many firm "go to hell" messages a spec/soft producer
needs to get.

But back to the OP's question, and leaving aside DOM methods, if you
write:

span>foo</span> <span>bar</span

a space should appear between "foo" and "bar". How can you possibly
consider that a bug?

That is not OP's question. OP's question is answered at
http://developer.mozilla.org/en/docs...ace_in_the_DOM
and I already posted this link.

It is also not my question: it is your own question which is
irrelevant to the situation. I will answer it though if you answer
mine.

<span>foo</span> <span>bar</span>
Of course it must be not space removal inside a string, it would be as
absurd as displaying on the screen "Loremipsumdolorsitamet" out of
HTML source "<p>Lorem ipsum dolor sit amet</p>"

Now let me repeat my question:
Do you agree that HTML source like
<ul>
<li id="Item1">Item 1</li>
<li id="Item2">Item 2</li>
</ul>
has to display an element 45px width and 21px height between the two
LI elements? Other words do you agree that a line break in pretty-
print must result in displayable elements of certain width and height?

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

On Feb 9, 7:19 pm, Ben C <spams... (AT) spam (DOT) eggs> wrote:
On 2008-02-09, VK <schools_r... (AT) yahoo (DOT) com> wrote:
On Feb 7, 11:03 am, DrPanic
MiNick (AT) ese_mail_del_buscador_qu...ntra (DOT) com> wrote:
Hello.

I have a problem building an horizontal navlist.

The technique i'm using is very simple: a list with inline LI
elements. It works fine but Mozilla render it with a gap between the
LI elements, I can't understand where that gap comes from.
[...]
But back to the OP's question, and leaving aside DOM methods, if you
write:

span>foo</span> <span>bar</span

a space should appear between "foo" and "bar". How can you possibly
consider that a bug?

That is not OP's question.

I think it is. OP's source looked something like this:

<li>foo</li>
<li>bar</li>

In what you see above, in the source, there is the string '\n '
between the two list items. According to the white-space collapsing
rules (assuming white-space: normal) that all collapses down to one
space.

Now, if li is display: inline and has a thin border, you would expect to
see most of the space between the right border of the first <li> and the
left border of the second one.

That's the gap the OP was talking about.

OP's question is answered at
http://developer.mozilla.org/en/docs...ace_in_the_DOM
and I already posted this link.

OP wasn't asking about the DOM.

It is also not my question: it is your own question which is
irrelevant to the situation. I will answer it though if you answer
mine.

I don't mind answering yours, although I'm not sure I've understood it.

span>foo</span> <span>bar</span
Of course it must be not space removal inside a string, it would be as
absurd as displaying on the screen "Loremipsumdolorsitamet" out of
HTML source "<p>Lorem ipsum dolor sit amet</p>"

Indeed.

Now let me repeat my question:
Do you agree that HTML source like
ul
li id="Item1">Item 1</li
li id="Item2">Item 2</li
/ul
has to display an element 45px width and 21px height between the two
LI elements?

Of course not. But I'm not sure I follow you. Where do you get this 45px
width and 21px element from? Why should the browser display any extra
elements?

Other words do you agree that a line break in pretty- print must
result in displayable elements of certain width and height?

The white-space, including newlines, between </li> and
<li> all collapses down to a single space.

Assuming we're still talking about the case where li is display: inline:

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

should display just the same as

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

or as

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



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

but not the same as

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

This last one should come out as Item1Item2.

On Feb 10, 12:29 am, Ben C <spams... (AT) spam (DOT) eggs> wrote:

That is not OP's question.

I think it is. OP's source looked something like this:

li>foo</li
li>bar</li

In what you see above, in the source, there is the string '\n '
between the two list items. According to the white-space collapsing
rules (assuming white-space: normal) that all collapses down to one
space.

All I see in OP is HTML source alined to the left border, no left
indent, no spaces after line break. So was my sample explaining the
problem.

OP's question is answered at
http://developer.mozilla.org/en/docs...ace_in_the_DOM
and I already posted this link.

OP wasn't asking about the DOM.

OP asked: "I can fix the problem using float:left in the LI elements
but I need to understand why is Mozilla drawing it whith that gap."

The gap appears because Gecko creates phantom nodes in place of pretty-
print line breaks. These are DOM phntom nodes, so a DOM question,
aswered in linked resources. It is not problem of styling (floating,
not floating etc.) at all. Extra styling or special pretty-print
formatting are just workarounds for the said DOM problem.

Now let me repeat my question:
Do you agree that HTML source like
ul
li id="Item1">Item 1</li
li id="Item2">Item 2</li
/ul
has to display an element 45px width and 21px height between the two
LI elements?

Of course not. But I'm not sure I follow you. Where do you get this 45px
width and 21px element from?

From the obvious visual observation reported by OP, shown in my sample
and measured by Javascript/DOM methods in my sample. Did you run the
demo I have posted on say Firefox? Do you understand Javascript enough
to understand what does it measure? If not then I can comment on it.

You confusion - I guess - is that you are using "whitespace" term in
some super-generic W3C way which is so generic that has no practical
sense. Try to forget about "whitespace" and try to think about "new
line" and "space".

Given style rule like:

p {
font-family: monospace;
font-size: 2em;
}

And HTML element like:
<p>Lorem ipsum</p>

Is it obvious to expect to see 2em space between Lorem and ipsum? I
would say of course, and no one is arguing with it.


Now having HTML element like:

<p>Lorem
ipsum</p>

(<p>Lorem followed by new line and nothing else)
Would it be obvious to expect that this form of source code will
produce exactly the same visual result in some browsers as the first
one (with the space)?

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

On Feb 10, 12:29 am, Ben C <spams... (AT) spam (DOT) eggs> wrote:
That is not OP's question.

I think it is. OP's source looked something like this:

li>foo</li
li>bar</li

In what you see above, in the source, there is the string '\n '
between the two list items. According to the white-space collapsing
rules (assuming white-space: normal) that all collapses down to one
space.

All I see in OP is HTML source alined to the left border, no left
indent, no spaces after line break. So was my sample explaining the
problem.

It doesn't matter. Any string of whitespace of any kind (newline, space,
tab)+ all gets collapsed to a single space.

OP's question is answered at
http://developer.mozilla.org/en/docs...ace_in_the_DOM
and I already posted this link.

OP wasn't asking about the DOM.

OP asked: "I can fix the problem using float:left in the LI elements
but I need to understand why is Mozilla drawing it whith that gap."

The gap appears because Gecko creates phantom nodes in place of pretty-
print line breaks.

No it doesn't. The "phantom node" issue is something completely
different.

The gap is just a space, the result of collapsing a newline and maybe
some other spaces.

These are DOM phntom nodes, so a DOM question,
aswered in linked resources. It is not problem of styling (floating,
not floating etc.) at all. Extra styling or special pretty-print
formatting are just workarounds for the said DOM problem.

The DOM issue arises when you use, for example childNodes on the <ul>.

<ul>
<li>foo</li>
<li>bar</li>
</ul>

Now if you did document.getElementsByTagName("ul")[0].childNodes, you'd
find it had I think 5 children:

1. #text
2. the first list-item
3. #text
4. the second list-item
5. #text

The three #text nodes are supposed to be there but they are what are
described as the "phantom nodes" in that Mozilla non-bug you alluded to.

OP is not looking at the DOM with JS. The presence or not of the
"phantom nodes" is therefore irrelevant.

Consider this:

<span>foo </span><span>bar</span>
<span>foo</span> <span>bar</span>

Both display the same as "foo bar". But the DOM trees look different. In
the first case the two span nodes are siblings, in the second they are
separated by a (so-called "phantom") #text node.

Now let me repeat my question:
Do you agree that HTML source like
ul
li id="Item1">Item 1</li
li id="Item2">Item 2</li
/ul
has to display an element 45px width and 21px height between the two
LI elements?

Of course not. But I'm not sure I follow you. Where do you get this 45px
width and 21px element from?

From the obvious visual observation reported by OP, shown in my sample
and measured by Javascript/DOM methods in my sample. Did you run the
demo I have posted on say Firefox? Do you understand Javascript enough
to understand what does it measure? If not then I can comment on it.

I didn't run your example. Perhaps I will go back and take a look at it
though since it might help to explain what you're talking about.

You confusion - I guess - is that you are using "whitespace" term in
some super-generic W3C way which is so generic that has no practical
sense. Try to forget about "whitespace" and try to think about "new
line" and "space".

Newline and space are both whitespace characters, in common usage, which
has nothing to do with the W3C.

I use whitespace in this context to mean space, carriage return and tab.

Given style rule like:

p {
font-family: monospace;
font-size: 2em;
}

And HTML element like:
p>Lorem ipsum</p

Is it obvious to expect to see 2em space between Lorem and ipsum? I
would say of course, and no one is arguing with it.


Now having HTML element like:

p>Lorem
ipsum</p

(<p>Lorem followed by new line and nothing else)
Would it be obvious to expect that this form of source code will
produce exactly the same visual result in some browsers as the first
one (with the space)?

Yes. The newline "collapses" to a single space. The two examples should
display exactly the same (assuming white-space is set to normal or
nowrap).