font-size:0 DOES NOT kill white space bug in Saf/Chr

**Paul O'B** · Nov 4, 2010 08:54

Originally Posted by noonnope

i confess. my google search was: inline-table bugs. but that didn't end up as expected. i actually came across another thing.

I already explained this in the quiz:

The reason that this fixes the whitespace bug is down to the rules contained in the specs for table elements here.

As I understand it the method works because the browser has to construct anonymous elements to make the table complete and so in effect it constructs anonymous table-rows and anonymous table cells around the inline-blocks. I believe its rule 5 here that specifically kills the whitespace in this structure as white text nodes are explicitly set to display:none in this structure.

i believe the answer is indeed this: inline-block is useless. and since the problem was the use of inline-block in the first place, the answer is always replace it with table-cell.

I'm afraid that you may have misunderstood because that changes the element to behave like a table-cell in all aspects and the elements will not wrap to the next line as they do with display:inline-block.

display:table-cell is fine if you want cell behaviour exactly but doesn't satisfy the requirements of the quiz or indeed the OPs original question and isn't suitable for centered wrapping menus.

Just try your code in the OPs original post or in the quiz and you will see completely different behaviour.

display:inline-block is the only way to accomplish this.

**noonnope** · Nov 4, 2010 13:16

Originally Posted by Paul O'B

I already explained this in the quiz:

yes you did. but in "reverse". it implied but didn't point. you know, like for dummies

and it was never as clear as this:

Code:

<DIV style="display: table-cell">
</DIV>
<DIV style="display: table-cell">
</DIV>

The above example would have a table and a table row implied around it.

simple concepts are the mark of genius.

you're saying: only put the table to generate table row and table cell.
i'm saying (not really me, i'm just quoting): only put the table cell to generate table row and table.

the later just feels more right. and in tone with how optional tags and optional elements are described in specs. you can omit the parent (html, body), putting the child in will generate it. but by putting in the parent, the child is not implied to be generated.

and i was doing the search today, at work. for bugs not explanations. to dismantle the inline-block solution, not to explain it.

******************************************************

Originally Posted by Paul O'B

I'm afraid that you may have misunderstood because that changes the element to behave like a table-cell in all aspects and the elements will not wrap to the next line as they do with display:inline-block.

indeed it does not wrap. i see it as a good thing. if it's a horizontal menu, it should not expand multiple lines when viewport shrinks. think about multilevel horizontal menus.

******************************************************

Originally Posted by Paul O'B

display:table-cell is fine if you want cell behaviour exactly but doesn't satisfy the requirements of the quiz [...]

a quiz is a quiz. but still...

|
\/

Originally Posted by Paul O'B

However, I will say that if you do have good alternative or different methods of producing the above then we would still like to see them even if they don't precisely fit into the quiz aspect.

/\
|

******************************************************

Originally Posted by Paul O'B

[...] or indeed the OPs original question [...]

what was the OP's trouble:

space between inline items still remains

setting display:table-cell fully covers it. i don't see any "keep the inline-block" requirement.

******************************************************

Originally Posted by Paul O'B

[...] and isn't suitable for centered wrapping menus.

you need to give some reasons.

******************************************************

Originally Posted by Paul O'B

Just try your code in the OPs original post [...]

ok, here it is.

Code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Untitled Document</title>
<style type="text/css"> 
*{margin:0; padding:0; list-style:none;}
body {text-align:center;}
ul {display:inline-block;}
li {display:table-cell; padding:10px; background:silver;}
li a{font-size:12px;}
</style>
</head>

<body>
<ul>
	<li><a href="#">Item</a></li>
  <li><a href="#">Item</a></li>
	<li><a href="#">Item</a></li>
	<li><a href="#">Item</a></li>
	<li><a href="#">Item</a></li>
</ul>
</body>
</html>

******************************************************

notice in the code above that i can use inline-block just fine. just for other purposes. i'm not absurd in my rejection of an idea:

Originally Posted by Paul O'B

display:inline-block is the only way to accomplish this.

******************************************************

i'm not petty and i can recognize when ANY person proves to be right:

Originally Posted by deathshadow60

Since as a rule I would never put inline-block on a LI since IE knows it not... usually when I need this there are ANCHORS inside the LI and I'd probably never use inline-block on anything other than a menu.

thank you ds60 and bravo... for your knowledge and instinct

**Paul O'B** · Nov 4, 2010 14:13

Originally Posted by noonnope

indeed it does not wrap.

As I said it then fails on two points it does not wrap and it also does not fix the problem related to inline-block which I believe was the OPs original intention.

Display:table-cell is a completely different behaviour and has nothing to do with the way that inline-block works and is used. The table-cell elements will not wrap and remain centred and are therefore not suitable for a fluid layout or for many other types of layout (e.g a centered gallery in a fluid layout).

Display table-cell is useful for other situations where you don't want elements to wrap. Both have their uses but both are different and one isn't a cure for the other.

I could do something similar with floats but it isn't a cure for the inline-block problem and would have slightly different characteristics just like table-cell does.

There's nothing wrong with the table-cell approach when the layout requires it so I don't really see where this discussion is going. It's just another method for doing something else. It just doesn't replace inline-block in any form.

ok, here it is.

Code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Untitled Document</title>
<style type="text/css"> 
*{margin:0; padding:0; list-style:none;}
body {text-align:center;}
ul {display:inline-block;}
li {display:table-cell; padding:10px; background:silver;}
li a{font-size:12px;}
</style>
</head>

<body>
<ul>
    <li><a href="#">Item</a></li>
  <li><a href="#">Item</a></li>
    <li><a href="#">Item</a></li>
    <li><a href="#">Item</a></li>
    <li><a href="#">Item</a></li>
</ul>
</body>
</html>

Ok add another 50 list items and see what happens! The page will be fixed massively wide and you will have to scroll horizontally to see the items. Next try it with display:inline-block to see the different behaviour.

Both are different and both would be used in different situations.

**noonnope** · Nov 4, 2010 14:37

the discussion is going the way: "OP doesn't need to fix inline-block because OP doesn't need inline-block to begin with".

that's my own conclusion. there is a viable alternative, other than the tag chaining or white space manipulation.

instead of

using display:inline-block on the child elements
and use css to manipulate white space among them
and then set the parent to display:table where that css fails on them (to force child element behave like table-cell)

simply use

display:table-cell on the child elements

straight up and lose the roundabout. and that's all.

(by the way, using display:table on the parent to make the child behave like table-cell is a thing that somewhat overrides your idea of not changing the display:inline-block on the child, don't you think?)

**************************

Originally Posted by Paul O'B

Ok add another 50 list items and see what happens! The page will be fixed massively wide and you will have to scroll horizontally to see the items.

about that. remember what you said

Originally Posted by Paul O'B

Now that example is just plain silly [...]. That's a whole different discussion.

I can't actually believe that you gave that as an honest example!

**Rayzur** · Nov 4, 2010 15:01

i didn't put ie6-7 hacks there to keep it clean and clear.

Originally Posted by noonnope

display:table-cell

and
lose the roundabout. and that's all.

All but IE6/7 that is! Even though you have stated that you excluded them it would require more CSS than the inline-block method to bring it back to working order for them. We also loose the option of setting vertical margins when they wrap. I won't mention horizontal margins since the whole point of this thread was to get the LI beside each other.

Code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Untitled Document</title>
<style type="text/css"> 

body {
width:50%;
margin:0 auto;
text-align:center;
border:1px solid #000;
}

ul {
display:inline-block;
margin:0;
padding:0;
list-style:none;
}

li {
display:table-cell;
margin:10px 0; /*sorry no can do in table-cells*/
padding:10px;
background:silver;
}

</style>
</head>

<body>
<ul>
    <li>Item One</li>
    <li>Item Two</li>
    <li>Item Three</li>
    <li>Item Four</li>
    <li>Item Five</li>
</ul>
</body>
</html>

As Paul stated,

It's just another method for doing something else. It just doesn't replace inline-block in any form.

**noonnope** · Nov 4, 2010 15:07

no, ie6-7 don't need but the same display:inline used before.

wrapping. on a menu. not desirable. again, think about multiline menus.

oh, and i can do what you say i can't (wrapping out of the question, since in the example you provided the white space bug has no part; or even a sensible place in this thread):

Code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Untitled Document</title>
<style type="text/css"> 

body {
width:50%;
margin:0 auto;
text-align:center;
border:1px solid #000;
}

ul {
display:inline-block;
margin:0;
padding:10px; /*no problem, i can do it here*/
list-style:none;
}

li {
display:table-cell;
margin:10px 0; /*sorry no can do in table-cells*/
padding:10px;
background:silver;
}

</style>
</head>

<body>
<ul>
    <li>Item One</li>
    <li>Item Two</li>
    <li>Item Three</li>
    <li>Item Four</li>
    <li>Item Five</li>
</ul>
</body>
</html>

maybe you misunderstood. i said: replace inline-block for this example. for the better table-cell. and it does replace it. moreover, i've used inline-block my self. on the <ul>.

your logic must be screaming somehow, i hope:

by the way, using display:table on the parent to make the inline-block child behave like table-cell is a thing that somewhat overrides your idea of not changing the display:inline-block on the child, don't you think?

**Rayzur** · Nov 4, 2010 15:30

Padding is not a REAL substitute for margins.

wrapping out of the question

See that's the problem, we can create many versions that have nothing to do with the OP's code.

no, ie6-7 don't need but the same display:inline used before.

The OP was using inline-block for a reason: It gives the option of setting dimensions and using REAL margins on either axis.
(At least that's the reason I use inline-blocks)

Seems you have abandoned you tag chaining and gone off chasing other whimsical notions.

**noonnope** · Nov 4, 2010 16:32

no i didn't.

the

"formatting must be free of constraints so that i can do whatever i like with it, but i will follow no formatting rules but the ones i care since there are no such rules"

and

"you can't impose rules on formatting to prevent stupid bugs because i will try and find a way to break it so that you will look for stupid css solutions"

are really shady. if i was to use inline-blocks, i would still use tag chaining to remove the white space bug, if that bug was still... bugging me.

but i did manage to understand, from other's knowledge (ds60 for example, and i'm not petty but admit he was on the right track), an alternate solution for the OP, that doesn't require inline-block on <li>s. which i'm sure it doesn't bother him at all. and i'm sure it wasn't even a requirement to begin with. that was only for the quiz.

again, one solution for the OP has these steps:

set display:inline-block on <li>s
use css white space manipulation declarations to remove the white space bug in some UAs
use display:table on the <ul> parent to impose a table-cell behaviour on the <li>s to remove white space bug in some other UAs

that makes this solution look like a like a roundabout.

my understanding of an alternate solution is simpler, and goes straight to the 3rd step on the first solution:

set display:table-cell in <li>s

this simple one-step makes the first two steps in the first solution look redundant and somewhat illogical.

i know it's not fair to say that, but it seems you're ignoring the obvious and have gone chasing whimsical notions, w/o a hope of ever turning back.

**Rayzur** · Nov 4, 2010 18:17

my understanding of an alternate solution is simpler, and goes straight to the 3rd step on the first solution:

set display:table-cell in <li>s

this simple one-step makes the first two steps in the first solution look redundant and somewhat illogical.

That's just it, it is an alternate solution that imposes different display rules on me. Rules that I may not want, hence the whole reason I would have been using inline-blocks in the first place.

We have already explained what inline-blocks can do that table-cells can't.

an alternate solution for the OP, that doesn't require inline-block on <li>s. which i'm sure it doesn't bother him at all. and i'm sure it wasn't even a requirement to begin with. that was only for the quiz.

You will have to take that up with the OP since I can't speak for him. But yes you are correct, I set the rules for the quiz using inline-block in order to show how to overcome the Webkit bug while retaining the normal behavior that inline-blocks give us when that is what we WANT.

i know it's not fair to say that, but it seems you're ignoring the obvious and have gone chasing whimsical notions, w/o a hope of ever turning back.

No, I understand what you have done with the table-cell and it could work for someone somewhere at sometime. It just has nothing to do with inline-block behavior as we keep pointing out.

**noonnope** · Nov 4, 2010 23:52

Originally Posted by noonnope

the discussion is going the way: "OP doesn't need to fix inline-block because OP doesn't need inline-block to begin with".

that's my own conclusion. there is a viable alternative, other than the tag chaining or white space manipulation.

**************************

Originally Posted by Rayzur

That's just it, it is an alternate solution that imposes different display rules on me. Rules that I may not want, hence the whole reason I would have been using inline-blocks in the first place.

No, I understand what you have done with the table-cell and it could work for someone somewhere at sometime. It just has nothing to do with inline-block behavior as we keep pointing out.

**************************

it seems we begin to see eye to eye

**Stomme poes** · Nov 5, 2010 02:54

wrapping. on a menu. not desirable. again, think about multiline menus.

scrolling. on a menu. also not desirable (unless your page has a fixed min-width at some point anyway). People don't mind scrolling down nearly as much as they mind scrolling sideways.
inline-block if whitespace isn't an issue anyway and you want one css for many sizes:
large
medium
small

You can get away with display: table if it's small enough though:
large
medium
but ultimately has to be changed to something else at small sizes then:
small
(last one tested well on the phones around the office, but they're all "smart" ... needs more testing.)

**noonnope** · Nov 5, 2010 06:32

Originally Posted by Stomme poes

scrolling. on a menu. also not desirable.

yes. desirable. your simple example disregards the fact that most menus have drop downs. and some are multilevel.

your's is a showcase for severely simple menus.

accessibility means nada in this case if your drop down multilevel menu would wrap

**Stomme poes** · Nov 5, 2010 08:19

your simple example disregards the fact that most menus have drop downs.

Source?

But yes, if there are dropdowns, the menu should not wrap. Yet another reason developers should try to avoid dropdown menus if reasonably possible.

**noonnope** · Nov 5, 2010 08:44

Originally Posted by Stomme poes

But yes, if there are dropdowns, the menu should not wrap. Yet another reason developers should try to avoid dropdown menus if reasonably possible.

i'm sorry Sp, but that's just hilarious

i've used drop down menus on dos programming but i must not use them on gui web?

you say i should not use some features because there are NOW devices that MAY NOT be able to handle the results properly? that my page should be kept under a certain standard because of the penalty some devices may impose on it?

going down this road, you should not use images wider than, i don't know, 100px?, restrain from using words bigger than, i don't know, 10 letters?, on <h1>, never use sidebars...

mind you, that's a list on a short notice, incomplete as i've yet to know what width do you think i should cater for, and what feats i have to rub down for it, instead of providing a normal rich browsing experience.

and mind you, technology moves fast. in a year, or less, all your current "worries" will be forgot.

it seems to always come to this: all has been done before web. resolutions for gui os, zoom capabilities for gui applications, resizing for images and video. web and web devices are not bringing any new challenges. there are only old challenges that seem new due to the web hype and improper implementations. and there are already answers for all of them. a little research will keep you from rediscovering America.

**Stomme poes** · Nov 5, 2010 09:52

http://www.useit.com/alertbox/20001112.html this is why I try to avoid them, though megadropdowns get a better score

**noonnope** · Nov 5, 2010 13:14

i'm a little confuse. from what little i understand, it seems that in the link you provided, the author tries to mouth <select> element but he words out drop down menu, creating a confusion. and he advices to limit the number of <option> elements for it. which i'm all for.

but isn't that for drop down menus some old recommendations are saying to REPLACE <select> with <ul>? it appears the article and the author experience are previous to them. and we're talking <ul> menus not <select> menus.

**Stomme poes** · Nov 6, 2010 06:14

He means ul menus too (back then there were a lot of people doing these DHTML select-drop-down menus too for some reason). His issue with them are the small mouseover area and multiple levels. He rates the mega-menus better because of their larger mouse-over area, but I find them harder to work with CSS-alone (they can be, but not well... they pretty much need javascript) and of course they are large so also get in the way (again, Javascript is usually necessary to prevent accidental activations as the mouse moves around the page).

I used to do a lot of drop-down menus when I first started, but the last few years I have looked at ux research and decided to try to limit them. Dropdowns are actually more user-friendly than lots of click-click-click through steps, but that's on downloaded applications and OS software, where the programmer has control over the interface client. On the web you have all those issues with users having crappy mice, Javascript is unknown, browser may not keyboard correctly if a link is off-screen... bleh.

So I go for menus who are wrappable and hopefully can avoid dropdowns. This way I can ensure better compatibility with screens (menu can wrap) and I don't have to worry "does this user have a touch screen? oh noes" and can think better ways for users to navigate the site.