We often want the elements to butt up against each other. In the case of navigation, that means it avoids the awkward little unclickable gaps.

This isn't a "bug" (I don't think). It's just the way setting elements on a line works. You want spaces between words that you type to be spaces right? The spaces between these blocks are just like spaces between words. That's not to say the spec couldn't be updated to say that spaces between inline-block elements should be nothing, but I'm fairly certain that is a huge can of worms that is unlikely to ever happen.

Here's some ways to fight the gap and get inline-block elements sitting directly next to each other.

Remove the spaces

The reason you get the spaces is because, well, you have spaces between the elements (a line break and a few tabs counts as a space, just to be clear). Minimized HTML will solve this problem, or one of these tricks:

<ul>
<li>
one</li><li>
two</li><li>
three</li>
</ul>

or

<ul>
<li>one</li
><li>two</li
><li>three</li>
</ul>

or with comments...

<ul>
<li>one</li><!--
--><li>two</li><!--
--><li>three</li>
</ul>

They're all pretty funky, but it does the trick.

Negative margin

You can scoot the elements back into place with negative 4px of margin (may need to be adjusted based on font size of parent). Apparently this is problematic in older IE (6 & 7), but if you don't care about those browsers at least you can keep the code formatting clean.

nav a {
display: inline-block;
margin-right: -4px;
}

Skip the closing tag

HTML5 doesn't care anyway. Although you gotta admit, it feels weird.

<ul>
<li>one
<li>two
<li>three
</ul>

Set the font size to zero

A space that has zero font-size is... zero width.

nav {
font-size: 0;
}
nav a {
font-size: 16px;
}

Matt Stow reports that the font-size: 0; technique has some problems on Android. Quote: Pre-Jellybean does not remove the space at all, and Jellybean has a bug whereby the last element randomly has a tiny bit of space.See research.

Also note, if you're sizing fonts in ems, this zero font size thing can be an issue, since ems cascade the children would also have zero font size. Rems would be of help here, otherwise any other non-cascading font-size to bump it back up.

Another weirdness! Doug Stewart showed me that if you use @font-face with this technique, the fonts will lose anti-aliasing in Safari 5.0.x. (test case) (screenshot).

Just float them instead

Maybe they don't need to be inline-block at all, maybe they can just be floated one way or another. That allows you to set their width and height and padding and stuff. You just can't center them like you can by text-align: center; the parent of inline-block elements. Well... you kinda can but it's weird.

Just use flexbox instead

If the browser support is acceptable to you and what you need out of inline-block is centering, you could use flexbox. They aren't exactly interchangeable layout models or anything, but you might get what you need out of it.

@Landis and @Julian: You guys may want to reconsider the negative margin technique. Here’s an example as to why. It’s best to use designs that are not dependent on zero white-space. If you have to, use the comment method or don’t use carriage returns between elements.

Using negative margin too, think that’s best because you are actually adjusting the elements position. Using left: -5px; might be a good idea, but of course that brings all kinds of scary risks with it.

This solution isn’t bulletproof because it counts on three assumptions: the width of the space equal to 0.31em (nearly true for Arial/Helvetica, but false for Times New Roman etc.), the limit for the negative word-spacing that prevents words from overlapping (true for FF and IE8+, almost true for Opera, but false for WebKit and IE7-) and the WebKit bug that word-spacing is completely ignored for inline-blocks. When this bug is fixed, the inline-blocks will be “squeezed” a bit because the word-spacing is too big and the second assumption falis in WebKit.

Just saying… I have used the YUI grid system for over a year now and have had no problems. I have tested about every grid system out there, and the YUI one takes the cup for being both light weight, bullet proof, and responsive (with modification). Here’s my version… for responsive layouts… with shorthand… converted to a common denominator. Basically, you can omit the”yui-3-” part of the class names, and grid units are “base 24” as such: .u-4-24, .u-6-24, .u-18-24, etc… or you can still use yahoo’s original names if you like using calculators.

Sreejesh KV, such a sollution is definitely better than a negative margin :) Especially when the elements need to be alined left where the negative-margin method would shift the first list item too.
The way I used to handle it is not to apply the shift for the first element via the :first-child selector.

Floating, suggested by many people here, makes the elements block-level, they are not inline-blocks anymore then). That’s cheating)))

I use float because all the tutorials on making a nav bar I every found used float and it’s simple and makes sense. I wasn’t even aware there were other ways and thought float was the right way to do it.

It’s interesting to see other options for when I’m working with someone else’s code and they did it one of the other ways.

I just don’t like the idea of leaving out closing tags and am not looking forward to working with code where they are left out just because they can be. I don’t put those closing tags in there for the browser, they are for me when I’m reading the code :-)

So the issue is called “bike shedding” and in CSS3 there will be a property to fix this as the spec calls for. So what it comes down to, as Chris said, is the space between elements. So you could do:
<ul><li>one</li><li>two</li><li>three</li></ul>

but that makes the code really unmanageable. My findings led me to what Geert De Deckere posted as the best way to solve the problem.

The negative margin method is *incredibly* unreliable: the -4px is only appropriate for one specific font size on one system. Using an em value seems to works across systems, though I forget the exact value right now…

Awesome article..i came across that type of list but didnt knew the reason..now i know :) hope u wont mind if i write this trick up in my blog..Not to mention, i will have a back link to this post ;) awesome stuff

Thanks for your explanation. I’ve met this problem quite often, but haven’t found any article saying about this, until now. I do float the elements, it works, but other solutions mentioned in this article sounds great, too.
Thanks.

As long as my links aren’t too long, it remains fairly easy to read, but it also solves the spaces issue, and since it’s going to display horizontally anyway, I actually kind of PREFER writing it out horizontally. Maybe I’m just weird like that.

I have had great success in the past with the font-size: 0; on the parent ul and the proper font size set on the li. I only use this when the list items need to be centered though. I use floated blocks for everything else.

For those of you who say you just use floats, how do you handle centering a variable number of variable width blocks? Inline-blocks are just so convenient for that, but if there is a way I can do it with floats, I’d love to know how.

I’ve always floated elements to remove the whitespace personally, though if this has been infeasible for some reason… I irritate my pedanticism and simply place all the LI tags on one long line, HTML comments seems to be a better method.

I’ve poked a bit with display: table and came up with a solution for fixin this as you can see here.

Basically you define display: table on the parent element (in your first example this is nav). If you want to align the children centered you need to define a width for the parent element which is not possible in every case.
Maybe this comes in handy some time.

It’s funny, I’ve been using the inline-block method exclusively for many many years, and rarely do I worry about the white-space issue. I just don’t design layouts that rely on zero space between elements.

When I do have to worry about it, I either use the comment method or just not have a carriage return between the elements. Either way, the fix is so much easier than everyone is making it out.

I stay away from all CSS methods because of browser inconsistencies. I’m also not sure if Chrome allows for zero font-size, at least it didn’t use to allow it. The negative margin should also present problems because not all browsers calculate the white-space exactly the same.

In my opinion, from using inline-block for so long, is avoid designs that are dependent on zero white-space (it’s easier than you think) or just use the comment method or no carriage return.

Zero font-size trick is probably most practical currently. By the way, when using it, it makes sense to use `rem`-unit font-size for child elements to keep layout em-aware. `rem` means font-size of document’s root element (`html` element in case of HTML document), and the unit is supported by current versions of all browsers (incl. IE9). Pixel font-size value can be used simultaneously (before `rem`-unit value) as a fallback for older browsers:

It is 100% semantically equivalent to putting closing tags directly before the next sibling’s opening tag or the parent’s closing tag. It results in the same DOM tree (with no text nodes between items). Of cours the first option is XML-incompatible, but it’s only about syntax, not semantics :)

@SelenIT: Yes, omitting closing tags is formally valid in HTML5, but is just unacceptable for me since I consider that part of HTML syntax as a big mistake in its design, so I’m not going to use this “feature” anyway. I prefer HTML document to be syntactically standalone, generally without need for any tag-name dictionaries to parse it. It’s ok if you are not a perfectionist like me though. ;-)

@Taurif I’m almost certain that the spacing is dependent on the font being used and how that font is displayed by the browser. The negative margin method is not very reliable because of this uncertainty.

I’d recommend using the comment method, avoiding carriage returns between elements or just avoid designing elements that are dependent on zero white-space — it’s easier than you think.

@Taufix I don’t think that is totally correct. When a type of font triggers a space between elements that measures 0.25em, then it *should* remain 0.25em even when the font-size is increased. Em’s are a relative measure, they scale with the font-size.

The issue is it doesn’t really work like that. Different fonts can have different spacing specs, so for one font it may be 0.25em and for another it may be 0.2em. It’s even worse when you enlarge the font. Then, what was perfect can now be broken.

I just don’t get it. Why deal with all of the CSS shinanagens? You know what is 100% bullet-proof? Using the comment method or not using a carriage return between list-items. Anything else is a futile fight against browser inconsistencies and a slew of variables. Or, maybe I’m just crazy :P

The negative-margin solution is actually not accurate, the exact number depends on font-size and font-family. Some families do have an exact white space, like Courier New. I wrote about it a while ago although I wouldn’t recommend the solution I came up with back then, it’s way too complicated. Right now I use a negative margin (but I use em instead of px for obvious reasons) and I don’t bother too much about pixel perfection. Here’s my complicated solution: http://nerd.vasilis.nl/remove-whitespace-inline-block/

To me it seems that removing the closing </li> tags should not resolve this issue (that is, the spaces should not go away). Since HTML5 allows closing list item tags to be omitted, then the spacing should still be preserved. Omitting the closing tags should be exactly the same result as including them. I guess it’s assuming that the elements are butting up against each other, but that doesn’t seem right, especially if the new list item starts on the next line.

I think that’s a bug in all browsers and should be reported. Maybe I’m wrong, but my reaction is that the spacing should be the same as when the closing tags are included.

I’ve been using the inline-block method exclusively for many many years without a single issue. What most don’t realize is most of your time consumed with cross-browser debugging is *because* of floats.

With inline-block, there are two issues that can come up (this article address one), they are predictable and their solutions are easy. This should be a no brainer.

Floats were never designed to be used for laying out a page. Floats for this purpose are a hack. Inline-block is *the* way to layout a page.

You’re right. Nearly all developers use float rather than inline-block. This has bugged me to no end for a long time. I think it’s just habit, and no one has come along, kicked them in the arse and told them to break it.

I’ve been trying to get the word out for years. I even got so feed up with it, I wrote a jsFiddle trying to provide a link that I could just throw in a comment such as this: http://jsfiddle.net/Cerebrl/ZkQnD/

If using zoom is your main complaint, then don’t fret! Just throw it in an official IE conditional and your done (see my Fiddle)! This very, very simple work-around gets inline-block working all the way down to IE6 and is only presented to the very browsers that need it. To every other browser, it’s just a comment.

When I switched over to inline-block, my development time drastically decreased. My cross-browser testing is very easy, and everything is as it should be, the world is right.

The white-space issue is not as bad as one would think. Just try to avoid designs that require zero spacing; it’s easier than you think. If you do have a situation that requires it, just throw in the comment method or don’t place returns between elements.

Worst case scenario, just use floats, but I’ll tell you that I use floats so infrequently, that I’ve nearly forgotten how to clear them :)

Optional closing tags are not new invention. They were long-supported feature of HTML2-4, implemented in all existing browser engines. WHATWG and W3C just had to document this reality in the new standard, because of it’s design principles like ‘pave the cowpath’ and need for backwards compatibility with existing content and browsers.

In fact, optional tags are a big advantage of HTML because they just provide several correct ways to mark up the same robust and predictable DOM structure. For example, you can always be sure that any TABLE element will have at least one TBODY child, any other option is impossible by design. With “strict” XML parsing it’s not the case, in XHTML we can have the table without tbody as well as with it. So what is really “stricter”?

Because of this “bug” I almost always use floats instead of inline-blocks (and a little bit because of IE7), but the former just feels “wrong”. Floats aren’t designed to be used for a navigation or things like that, inline-blocks is definitely the way to go. Regarding the gap, I definitely will have a look at the font-size trick in the future. Seems pretty decent.

I prefer to close up the spaces between tags. It’s not always pretty but it is the closest to the behaviour desired – no spaces. Negative margins always feel wrong in some way to me, margins get a lot get for positioning everything layouts, I never see them as a very elegant solution. I think word/letter spacing will become the best option.

I try to always use inline-block, as it is in a sense, more semantic than float and also it doesn’t break any flow nor I need to add clearfix and such.
Since I usually develop in frameworks or at least not pure HTML, having my code to write the output inlined as it doesn’t output the spaces or line-breaks between tags and it also “compress” a little =D
And for those who says that my code becomes hard to read, I usually use any dev-tool available (usually in Chrome, but could be firebug in Firefox for example) which automagically converts and clean up the HTML. And my code that output the HTML is pretty well formated.
So for me is the best solution and I really don’t care that much for browsers that doesn’t support inline-block. =P

For the methods mentioned:
– Breaking the tags: I really hate this.. seems to me broken HTML… I don’t even use word wrap because of that
– Negative margin (or word-spacing): works ok if you take care of your font and font-size
– Float: prefer not to use if possible (I even try to change the CSS framework to inline-block when possible)
– Comments: it works well for pure HTML, any other way to generate HTML becomes hard to write/maintain

… but I think I like your first one better! It looks much cleaner, and it’s much easier to read.

By the way, Justin, I completely agree with all of your comments! I made the switch a few months ago, and now I barely ever use floats. It’s SO much easier. Plus, by using the HTML syntax above, I don’t have to mess with browser inconsistencies and crazy hacks. It just works! It’s even easier when used with LESS. I just do this:

Trust me, inline-block is simpler. I’m going to assume you pretty much exclusively use float and rarely (or never) use inline-block, and because of this, float seems simple because it’s familiar to you, it’s comfortable.

Inline-block is superior to float and is much simpler in almost every layout configurations. Floats need clearfixes (how many do we need again for the different browsers?) all the time, and they cause the majority of cross-browser inconsistencies. That doesn’t sound “so easy”.

If you design right, the majority of the time you shouldn’t have to worry about the white-space at all, and when you do, it’s a very easy fix. The example white-space issue Chris used above is really easy to fix without even having to worry about white-space — just put the red background on the ul and you’re done.

Like I said, just think about the design, and you can use inline-block without worry. Once you “convert” over, your development time will noticebly decrease.

@Justin, we don’t need to clear float if we set the parent element to have overflow hidden, so no need for clearfixes. I think there is a design where pixel perfect is important and that is where I find float to be better. It is might be easier for me as well as I have used float for many years, so I know more or less the behavior of it in most browsers.

That said, inline-block is a very easy solution for design that doesn’t need pixel perfect and I only use it for that case. I’m not usually design sites (there are designers, I’m front-end dev), so I only choose whatever works best for their design. :)

@Jeffri I still don’t understand the argument though. Pixel perfection (I’m assuming your mean zero spacing) CAN be achieved with inline-block. I do it all the time. Just get rid of the space between the elements (either literally doing it or using a comment) and you’re done. That’s it.

Plus, the overflow: hidden method for floats seems like a hack because it certainly isn’t logical behavior for CSS. The danger with this is browsers could easily see it as a bug and fix it, and there went your layout. It also can’t be a bullet-proof method for all/old browsers.

You’re welcome. I’m glad I could help! Yes, considering the amount of variables now in web design, no longer is it just Webkit, Mozilla and IE for desktop, but a slew of mobile browsers as well, we need bullet-proof ways to ensure our designs don’t break.

Since floats are inherently buggy since they’re taken out of document flow, different browsers have to decide how to render them and their interaction with other elements. It just makes more since to use something that follows a traditional since of document flow, so there is much less interpretation. I hope it helps you with your future development.

If you don’t want spaces between words than simply remove them in the HTML. The spaces between inline-blocks are no different. Negative margins is just a hack thats bound to cause difficulties later on.

Removing the spaces in the HTML is a sinch if your view only echos HTML and no leading or trailing whitespace. This is how I do it.

But, inline-blocks are not tricky, at all. That’s what I find so strange about this whole debate. They couldn’t be more simple. If you don’t want the white space, remove it in the markup. It’s that simple.

While 0=0rem, using the suffix in this case protects browsers without rem support. While negative word-spacing won’t fix all browsers, it also appears to do no damage. By combing these rules, we should be able to eliminate unwanted spacing in many of the modern browsers and maybe a few older ones as well.

As you can see from my previous comment, I recently set about tackling this exact same issue. I had a moment today to do some cross-browser testing of my code. My parameters for coding an inline-block collapsing whitespace fix were:

– No pixel resetting of fonts.
– No negative margin calculations for differents fonts and/or browsers.
– Apply inline-block but remove whitespace between them universally, unobtrusively and across browsers and platforms.

I believe I was successful in meeting those requirements in this jsFiddle:

If you want one element on the left and one on the right then a float is better – unless you know the width between then to add margins.

Inline is great BUT sometimes you need inline-block and ie6&7 can struggle with this, even when using zoom which might not be appropriate at that moment.

Using any kind of negative margins is always going to cause trouble down the road if font size changes and you need pixel perfect. Also the added spacing is above and below in my experience.

The font size thing look a good solution but I wonder about what google does if it sees font-size:0?

Would love to be able to float but still have things centrally aligned. Unless I have misunderstood doesn’t the example http://jsfiddle.net/kpadx/ just use padding to achieve the effect which is reliant on knowing the width?

When using inline-block, aligning the elements left, right or center is extremely easy. Just use text-align! The inline-blocks act the same as text-characters, so text-align works flawlessly in manipulating their position.

I’ve even shown how to do it with one left and one right. See here: jsFiddle

IE6 and IE7 work perfectly fine with inline-block, but you have to use both display: inline; WITH zoom: 1; The easiest least hackish way to do this is use a conditional comment for IE7 and under and copy all your inline-elements into a style tag and give them the necessary properties.

I’d be quite annoyed if I had to go in after your code, Justin, to fix or make alterations to your elements. I don’t want to have to hunt for where the next beginning / ending tag is over and over — not to mention having to deal with code generated dynamically where adjusting the white space may be more of a nightmare than anything else.

Those spamming “just use float!” apparently have never tried centering the text.

After reading all the comments, I think it’s safe to say there’s no clean way of implementing this without a variety of inconsistent hacks.

Lol, I’ve been using inline-block for years within teams of other developers and have never once had any complaints about my code style (they usually love it).

Here’s the big reveal: I rarely ever have to deal with the whitespace issue discussed here, and that’s because it’s easy to design interfaces that don’t require zero whitespace between elements. This whole thing is really a false issue.

If you design knowing inline-block will be used, you can easily alter how you design seamless interfaces with no issues of having to deal with unwanted whitespace. I do it day-in day-out in the most complex web applications.

When I do have the issue, I just use the comment method. And, it’s almost always within large sections concerning layouts that are never dynamically manipulated, so it’s never really an issue. Once I’m designing the internal elements of a web page or app, I almost always want padding between the elements.

Anyway, thanks for the comment, but I don’t think your argument holds water. Take care.

There are more bad developers than good out there so having no one make a point of it doesn’t exactly ‘hold water’. I have looked at the code provided and I’m already annoyed by it let alone in a larger web application environment.

You speak of designing knowing inline-block will be used: I surely hope you don’t mean you’re basing your designs on the use of inline-block rather than what the UX / branding / design calls for.

I’d love to see some examples of your websites where you’ve designed “knowing inline-block will be used”.

There are too many wish-washy developers out there with sub par development techniques, so you’ll have to excuse me for questioning the validity of a hack given those on the forefront of these specs don’t bother wasting their time with it.

“I surely hope you don’t mean you’re basing your designs on the use of inline-block rather than what the UX / branding / design calls for.”

I’m not implying that at all. I’ll give an example. Many designers, when building a horizontal navigation bar, will place backgrounds on the li’s and so they need zero whitespace to prevent gaps. Why not just place the background on the ul’s instead? Now, your nav doesn’t require zero whitespace. If an li needs a hover state, just give that li a different background, leaving the others with none.

I also see so many designers just do things because floats allow them to do it, not because it’s the right way or the best way, but just because they can. It’s more about just changing how you solve design problems. I’m *not* talking about altering the aesthetic or brand of the interface to allow inline-block, I’m talking about changing how you solve problems that designs present.

“I’d love to see some examples of your websites where you’ve designed “knowing inline-block will be used”.”

Well, most of what I do is under NDA and behind firewalls, but you’re more than welcome to visit Ka-Prow Bistro to see one of my few public clients.

You are also welcome to visit my Dribbble account where you can see snapshots of some of my work; visit my Forrst account to visit some of my design and development contributions; check me out on Quora where I talk about application development, UX, neuroscience and psychology.

I use inline-block with close and open tags butting up to one another. You can still format your HTML code nicely and it uses no hacks. All I do is include all inline-block rules as inline in an ie6-7 file in an if statement.

I loathe floats for layout. Even the name “float” suggests a lack of real place and control of the elements in question.

“Where would you like these 2 sofas mate?”
“Oh if you could ‘float’ them next to each other that would be great. Don’t worry. I’ll put something meaningless and invisible underneath them so the floor knows they exist.”“Eh? WTF?!”

There is an easy not well known way to avoid spaces between inline-blocks, and is this:

<li>One</li><li>Two</li><li>Three</li>

Yea I know it’s terrible, but it’s the fastest solution out there.
I know it because I had the opposite problem, I had an html compressor on server side which was minifying my html code. The issue was that I needed space because otherwise text-align: justify won’t work (read it on specs)!

I just want to make a shameless plug for my white-space project. With it, you can write white-space: none; in your external CSS. There is lots of information in the README, so I won’t go into details here.

There’s actually a really easy way to remove whitespace that’s both easy and semantic. It’s called a custom font with zero-width spaces. Then you just change the font on the container and voila. Here’s a download to the font I just cooked up in font-forge with the css @font-face declaration included. Suit to taste. zipped zero-width space font (click File > Download to save to your computer)

Could someone e-mail the link on how to avoid whitespaces between news blocks in Dreamweaver? I know I’m doing it wrong with absolute AP Divs by moving them downwards every time a new story comes in. Basically, I’m selecting all AP divs and moving every single element which is an overkill when there are over 10 stories on a page.

I use a background image encapsulated into AP divs. Is there a way (CSS or any other) of sliding all previous stories down? Would appreciate the solution, not the discussion of how outdated AP divs are. I haven’t arrived to a perfect CSS solution yet.

I would have never imagined that a line break in the code would count as white space when rendering. Since I can’t use floats for the specific markup I have, I went with DRaev’s solution, because it looks clean and it’s very readable.

I think we should cooperate to get the best possible solution without changing code style.

Afaik, there seems to be at least two ways:

One is to use a custom font with spaces character of zero width; should be working fine and I think we can easily add a custom whitespace, in the case we are already using a font via @font-face. That way the font defines some part of the UI…

Two is a white-space: none; polyfill. Never tried but a polyfill is a common solution to tricky issues.

I’ve created a compressor for Jekyll. It’s a layout with lots of Liquid inside, that removes all the unnessecary whitespaces during the rendering. It works without external plugins, so you can use it on Github Pages.

👋

CSS-Tricks* is created, written by, and maintained by Chris Coyier and a team of swell people. It is built on WordPress and powered up by Jetpack. It is made possible through sponsorships from products and services we like.