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

I thought it was a clever solution so I decided to test it out but found that no matter what i do a sliver of white space between inline items still remains… when viewed in Safari or Chrome… ;(

am I missing something here:

<!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;}
ul{font-size:0}
li {display:inline-block; 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>

ADD Opera to that list…

so it only kills the white space bug in IE and FF??

try this:

<!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;}
li {display:inline-block; 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>

whitespace in the markup between two inline-block elements translates into rendered whitespace.
the solution: chain the end tag for the previous inline-block element to the start tag for the next inline-block element: </li><li>, so there is no whitespace between them.

it will work cross browser w/o the need for font-size:0.

or like this:

  <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>

which actually is better than both of the above examples.

i’ve tried the css hacks: font-size:0, negative letter-spacing, negative word-spacing, but those fail as unnecessary css code, when a simple html markup adjustment will do just fine, w/o affecting the way you read it.

why:

  • while there is no rule saying you have to put ending tags for the previous elements on separate lines than the start tags for the next elements
  • there is a rule saying not to use meaningless anomalous css rules

font-size:0 DOES NOT kill white space bug in Saf/Chrome
Yes it is a documented bug in webkit when using inline-block, it does not happen with display:inline. Why in the world they chose (if done intentionally) to render inline-block differently is beyond me. They need to get it fixed as it makes no sense at all.

For those of us who do not like to mangle the html there is a workaround for the Webkit 1px bug.

There are 2 tricks to this and they both leave the 1px gap in webkit.

  1. font-size:0; on parent (reset child in px only :rolleyes:)
  2. word-spacing:-.5em;

Here is what does work in Webkit!

  • letter-spacing:-.5em;

But it leaves a gap in FF if the inline-blocks drop to a new line, the gap is about 3px (pending upon font-size) and it is seen on the left side of the new line/row. It is not a problem if your blocks remain on one line though.

http://www.css-lab.com/lab-work/inline-block/hide-text-node-px.html

But there is a condition, Opera requires word-spacing along with it but FF will work with either letter or word spacing.

div {
    width:930px;
    margin:0 auto;
    padding:0 0 15px;
    background:#333;    
    [COLOR=Blue]text-align:center;[/COLOR] /* center the children */
    [COLOR=Blue]word-spacing:-.3em;[/COLOR]/* hide whitespace in Opera,FF,IE [B](mandatory for Opera!)*/[/B] 
    [COLOR=Blue]letter-spacing:-.3em;[/COLOR]/* hide whitespace [B](mandatory for WebKit)+(throws FF off on new row!)*/[/B]
}    
div p {
    width:280px; /*300px total*/
    margin:15px 0 0;
    padding:10px;
    display:inline-block;
    vertical-align:top;
    background:#FFA500;    
[COLOR=Blue]    text-align:left; /* reset from parent */
    word-spacing:0; /* reset from parent */
    letter-spacing:0; /* reset from parent */[/COLOR]
}

As you can see our CSS is starting to get bloaty and we have the FF problem as well.

This turns into a “Pick your poison” and what is suitable for one’s personal taste may not be acceptable for another. Noonope doesn’t mind butchering the html but I try my best to avoid that. If Webkit would simply address this issue then it would not be a problem, even if it is just 1px!

You can target Webkit with the @media screen and (-webkit-min-device-pixel-ratio:0) property and eliminate some resets and the FF issue of wrapping blocks.

http://www.css-lab.com/lab-work/inline-block/hide-text-node-em.html

div {
    width:59em;
    margin:0 auto;
    padding:0 0 1em;
    background:#333;    
    [COLOR=Blue]text-align:center;[/COLOR] /* center the children */
    [COLOR=Blue]word-spacing:-.3em;[/COLOR]/* hide whitespace in Opera,FF,IE [B](mandatory for Opera!)[/B]*/ 
}

[COLOR=DarkGreen]@media screen and (-webkit-min-device-pixel-ratio:0) [/COLOR]{
    div {[COLOR=Blue]letter-spacing:-.3em;[/COLOR]}/* hide whitespace [B](mandatory for WebKit)[/B]*/
}    

div p {
    width:18em; /*19em total*/
    margin:1em 0 0;
    padding:.5em;
    display:inline-block;
    vertical-align:top;
    background:#FFA500;    
[COLOR=Blue]    text-align:left; /* reset from parent */
    word-spacing:0; /* reset from parent */
    letter-spacing:0;[/COLOR] [B]/* reset for webkit */[/B]
}

Is it worth all that just to fix Webkit, NOT REALLY. But in those cases where the 1px bug breaks your design and you are opposed to mangling the html it seems to be the only solution until Webkit fixes this.

[…] when a simple html markup adjustment will do just fine, w/o affecting the way you read it.

why:

  • while there is no rule saying you have to put ending tags for the previous elements on separate lines than the start tags for the next elements
  • there is a rule saying not to use meaningless anomalous css rules

which is better:

  <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>

or

<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>

i’ll say the first one not only does not “mangle the html” it also brings clarity. :slight_smile:

chaining the end tag for the previous element to the start tag for next inline-block element seems to me to be the solution, having also better results than expected when applied smart :wink:

remember: there is no rule against chaining, there is no mangle if you do it properly. :slight_smile: oh, did i mention: works the same for all browsers, font-size:0 or not :wink:

I think I explained myself in my post:

Is it worth all that just to fix Webkit, NOT REALLY. But in those cases where the 1px bug breaks your design and you are opposed to mangling the html it seems to be the only solution until Webkit fixes this.
It is a personal preference as to whether one tweaks the html, I choose not to when possible. That’s just me though!

I tend to agree with Gary T. now, but I used to tweak the html in the past.

http://gtwebdev.com/workshop/gaps/white-space-bug.php

gary t.
The common fix has been to remove the offending white space;

<ul><li>
  list item</li><li>
  list item</li><li>
  list item</li><li>
  list item</li>
</ul>

<ul><
  li>list item</li><
  li>list item</li><
  li>list item</li><
  li>list item</li><
/ul>

<ul><li>list item</li><!--
--><li>list item</li><!--
--><li>list item</li><!--
--><li>list item</li><!--
--></ul>

That works, but is ugly. In the case of non-trivial lists, the formatting can make the list code all but unreadable. Plus, jiggering the html formatting to control display is just wrong.

:rofl:

that’s a good one! “looks ugly”! man, this is beyond Zen! what about “word-spacing:-0.3em”, “letter-spacing:-0.5em”, “font-size:0”? i don’t see but butt ugly css hack here, but that’s just me, right :slight_smile:

i apologize Rayzur, but i’m not laughing at you :cool:

but you are “tweaking” the html when you put the whitespace there in the first place! also, when it’s not possible not to “re-tweak” you html markup? that’s beyond my power of understanding! it’s just whitespace you almost groundlessly put there in the first place.

i don’t recall reading something like this in the specs: “end tag and start tag, respectively, for two li sibling elements should have whitespace separating them or even be on different lines” :slight_smile: but i recall reading some serious rules about whitespace in those specs :wink:

it seems to me that “jiggering the html formatting” is something non-existent. there are so many ways to format your html code, starting from how you can use spaces and not use tabs and ending with minified versions that you cannot read properly, that “html formatting” looks like the shoe Cinderella left behind. there is no one size shoe :wink:

also, there is an html requirement to format html markup? no.

there is a css requirement not to use meaningless anomalous css rules? i like to think so.

so, what’s left: follow non-existent “html formatting rules” but brake the fundamentals of css development? this is something only a twisted mind could ever sale! :rofl:

Well I knew both HTML mark up hacks. BTW, the comment hack will have side effect on IE if you use adjacent sibling selectors.

Tho I am kinda torn as removing the white space between element does not actually affect the SEMANTICS, it is in fact adding extra work for presentation sake. Anyway, in principle you shouldn’t have alter the mark-up for the presentation which is why the font-size:0 technique seemed so brilliant to me!

BTW

For those of us who do not like to mangle the html there is a workaround for the Webkit 1px bug.

is it always 1px? I am testing this and it seems to be a different amount based on the font…

I’d say the first one is less clear because you could confuse it for a single LI element containing five anchors. When I read HTML, I often skim down where the indentations meet the tags and so I might not see the end of each line.

Although it is the simplest solution, some people are very picky about their HTML (myself included). Another solution is to use comments:

<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>

Whether that’s better or worse than the other method is debatable, but it’s still ugly!

Edit:

Whoops, Ray’s mentioned it. Serves me right for opening a thread, leaving it open for an hour and then replying.

when you write

<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>

instead of

<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>

you have already altered the html markup for your “presentational” needs. you hacked it for it not needs whitespace, not a w3c requirement, nor UAs request. your need. so altering html markup for your “presentational” needs is good, but for UAs “presentation” is bad? not a good trade off :slight_smile:

that’s a weak and moot point to ever think about solving it with: “word-spacing:-0.3em”, “letter-spacing:-0.5em”, “font-size:0”. how’s that for plagued css? is this a solution? not for a normal mind, no :slight_smile:

it seems to me like a base for not wanting to hand over the hostage but get killed in the action :slight_smile:

and

</li><!--
--><li>

it’s so Zen i cannot express it! :rofl: talking about weird solutions to non-existent problems.

What about it? It is using CSS to control presentation!

I don’t like using font-size:0; either since it forces you to reset the children in px only.

All we would need for x-browser compliance is just word-spacing: if Webkit would fix this silly mess. We would not need to mix additional rules.

I explained it here:

Yes it is a documented bug in webkit when using inline-block, it does not happen with display:inline. Why in the world they chose (if done intentionally) to render inline-block differently is beyond me. They need to get it fixed as it makes no sense at all.
Webkit obeys word-spacing just fine with display:inline :rolleyes:

inline-block is supposed to obey the same initial rules as display:inline, the only thing that makes it different is that it is capable of taking on dimensions (just like an image)

suit your self :slight_smile:

if you would, by common sense, apply html formatting in a good way, for UAs also, not just for you and on personal whims, you wouldn’t need any mix of any rules to fix something that doesn’t need fixing :slight_smile: let me say it again: i recall reading some serious rules about whitespace in those specs :wink:

??

I never said it was better…

ok :cool:

when I use the word “prese4ntetional” I am referring to the the job of CSS.

For example , changing the source order so that navigational ULs come first or last in the mark up with the specific intent of putting a column left or right in the layout. Or adding a span or div to clear things…is presentational, even if it validates 100%. I know sometimes this things can’t be avoided. some times the trick is just too neat to pass up, and sometimes one wonders if 20K of semi-cross-browser-compatible CSS is worth all the headache to avoid adding one tag…

Still I like to shoot for 100%

ok, i think we all know what css is about :slight_smile: what the said above has to do with the subject at hand?

i fail to see how “manipulating” whitespace in your markup translates or relates to presentational purpose pollution?

your subjective “manipulation” of the whitespace in the markup, when using new lines and indentation to format html code, is messing up your rendered web page in this case.

what’s left to do: get rid of that “presentational” whitespace “manipulation” to help you save 20K of “semi-cross-browser-compatible CSS” howler that has no good lesson in it. is that “ugly-ing” the markup? does it mean it’s extra work for presentation sake? i fail to see that. i only see how your rules for formatting are hurting your html end result. hence, those rules are not good.

but what i see is:

this “fix it even if it’s not broken, because i use whitespace rules in a weird way” is
a weird kind of surgery: “entering the left ear, passing through the brain, only to extract a wax cap in the right ear” :wink:

or “the markup is ugly so let’s fix it and ruin the css” is the kind of “i bought a new hat but i needed to cut a little off of my ears to make it fit” :wink:

yeah, those can be done, but where’s the common sense and logic?

font-size:0 == a brilliant solution? more like a monkey forcing things through holes as they don’t fit :slight_smile:

Uhm, since you don’t seem to be centering those (the ONLY reason to use inline-block) I’d suggest setting the LI to display:inline and then floating the anchors. Floats don’t have the whitespace quirk. (I wouldn’t call it a bug)… I also would HIGHLY suggest specifying a line-height since christmas only knows what it’s going to inherit.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
	xmlns="http://www.w3.org/1999/xhtml"
	lang="en"
	xml:lang="en"
><head>

<meta
	http-equiv="Content-Type"
	content="text/html; charset=utf-8"
/>

<meta
	http-equiv="Content-Language"
	content="en"
/>

<title>
	Test Menu
</title>

<style type="text/css"><!--

/* null margins and padding to give good cross-browser baseline */
html,body,address,blockquote,div,
form,fieldset,caption,
h1,h2,h3,h4,h5,h6,
hr,ul,li,ol,ul,
table,tr,td,th,p,img {
	margin:0;
	padding:0;
}

img,fieldset {
	border:none;
}

#demoMenu {
	list-style:none;
	overflow:hidden; /* wrap floats */
	width:100&#37;; /* trips haslayout, wraps floats IE */
}

#demoMenu li {
	display:inline;
}

#demoMenu a {
	float:left;
	padding:10px;
	font:normal 12px/14px arial,helvetica,sans-serif;
	background:#DDD;
}
--></style>

</head><body>

<ul id="demoMenu">
	<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>

Works just fine. Even if I was going for inline-block I wouldn’t be doing it on the LI or even trying to apply styling to the LI since IE can’t make block-level tags inline-block. Set the LI to display:inline, don’t even TRY to apply any other styling to it, and target the anchor instead.

Oh, and depending on font that letter-spacing trick Rayzur mentioned for webkit can be inaccurate and result in the elements overlapping. For MOST fonts 0.4em is closer but can still result in +/-1px from the desired effect. You can test this by putting a 1px border on each side.

… and I’d never try to use font-size:0 on a wrapping element in the first place since it automatically restricts you to use PX font sizes. (mind you other things may do that too, but it’s just a bad idea all-around)

If you ARE trying to center it the word-spacing and letter-spacing combination also causes problems with centering or right alignment in Firefux as of 3.5, as it will subtract the letter-spacing from the width of the first element, making the centering off by that much. Still, word-spacing is the correct behavior, and word-spacing is NOT supposed to collapse inline-level elements over each-other; as such it’s the correct unit to use when/if webkit pulls it’s head out of it’s ass on it… and due to the no-collapse rule you can set absurd values like -2em and it will still work… unlike letter-spacing which DOES allow for overlap which is why you end up playing games with the amount and NEVER having it work right everywhere.

Which is why I’ll often say “shtup it” and just float them. It’s less headaches. It also means you don’t need the ‘exact’ whitespace… manipulating the markup just to remove oddball whitespace behaviors is just asking for it to break sometime/someplace/somewhere in the future.

</li><li>

while i don’t have any comments on the code, i do have a few thoughts on the whitespace “abuse”.

whatever your reasons may be, you are resorting to the same techniques of chaining the end tag with the start tag (which can’t even be called a technique, it’s just an also correct way to write code: w/o formating).

you are manipulating the markup in a way it’s not supposed to be used: putting whitespace between elements (new lines, tabs, spaces, indentations) based on your whims on how it should look like. there are no w3c or UAs requirements for doing so, it’s just your wish to do so.

for some, your similar “manipulation” of the markup means just that: “asking for it to break sometime/someplace/somewhere in the future”.

why: because there isn’t really a standard way of formatting your markup, it’s a subjective implementation. as such, what it may appear to you as the perfection itself, it would possibly be misinterpreted or be annoyingly formatted for others, which will lead to breaking :slight_smile:

the fact remains that if:

  • you want to use inline-block
  • you need to get rid of the whitespace appearing

your best common sense solution is just that:

  • get rid of the subjective formatting rules that are breaking the rendering
  • don’t look for stupid solutions: font-size:0 etc as clever solutions for a non-existent problem
  • don’t pretend the formatting is a stronger point than it is (only when it suits you), just to appear en vogue and wise

for me, resorting to far too many whitespace formatting rules is the cause for “oddball whitespace behaviours” in the first place. you are removing formatting as the main cause for that bad behaviour. if you want, formatting is a bad habit. it leads to creation of additional useless nodes in the DOM, nodes that are interpreted differently by UAs, that’s the bad way to code your html markup! i understand and use the help formatting brings with it, but only as long as it really helps :slight_smile:

I respect the wisdom of the members in this forum. It’s why i post most of my “theoretical” questions here.

noonnope,
I dont see anything wrong with avoiding a white space bug by getting rid of the already unused white space. it is in fact the simplest way. I don’t even think it looks ugly.

</li><li> or </div><div> or even </p><p> are all valid markup. To date I use that method of coding, but I am always looking to improve. The actual issues is when someone code this way to make the css work ( presentational) it invites someone who may later update mark up to not understand this and start putting it the “usual way”… which is why I liked being able to hide the white space from the CSS, if I could.

The thing that frustrates me with CSS is how often great solutions anre not universal solutions. This especially frustrating when it is present in MODERN browsers ( at least with IE we could say F#@$$%%#$%CK! and put in a conditional. It also feels like kinda a tease, you know… I mean display:inline:block works sooo well in FF, gets fixed with this method in IE!!! you almost DONT expect to even have to check with Webkit… but voila!