"text-align: justify;" inline-block elements properly?

A few other questions have already addressed how best to apply text-align: justify to get inline-block elements to spread out evenly… for example, How do I *really* justify a horizontal menu in HTML+CSS?

However, the 100% width element that "clears" the line of inline-block elements is given its own line by the browser. I can't figure out how to get rid of that empty vertical space without using line-height: 0; on the parent element.

For an example of the problem, see this fiddle

For my solution that uses line-height: 0;, see this fiddle

The solution I'm using requires that a new line-height be applied to the child elements, but any previously set line-height is lost. Is anyone aware of a better solution? I want to avoid tables so that the elements can wrap when necessary, and also flexbox because the browser support isn't there yet. I also want to avoid floats because the number of elements being spaced out will be arbitrary.

Solution 1:

Updated the "Future" solution info below; still not yet fully supported.

Present Workaround (IE8+, FF, Chrome Tested)

See this fiddle.

Relevant CSS

.prevNext {
    text-align: justify;
}

.prevNext a {
    display: inline-block;
    position: relative;
    top: 1.2em; /* your line-height */
}

.prevNext:before{
    content: '';
    display: block;
    width: 100%;
    margin-bottom: -1.2em; /* your line-height */
}

.prevNext:after {
    content: '';
    display: inline-block;
    width: 100%;
}

Explanation

The display: block on the :before element with the negative bottom margin pulls the lines of text up one line height which eliminates the extra line, but displaces the text. Then with the position: relative on the inline-block elements the displacement is counteracted, but without adding the additional line back.

Though css cannot directly access a line-height "unit" per se, the use of em in the margin-bottom and top settings easily accommodates any line-height given as one of the multiplier values. So 1.2, 120%, or 1.2em are all equal in calculation with respect to line-height, which makes the use of em a good choice here, as even if line-height: 1.2 is set, then 1.2em for margin-bottom and top will match. Good coding to normalize the look of a site means at some point line-height should be defined explicitly, so if any of the multiplier methods are used, then the equivalent em unit will give the same value as the line-height. And if line-height is set to a non-em length, such as px, that instead could be set.

Definitely having a variable or mixin using a css preprocessor such as LESS or SCSS could help keep these values matching the appropriate line-height, or javascript could be used to dynamically read such, but really, the line-height should be known in the context of where this is being used, and the appropriate settings here made.

UPDATE for minified text (no spaces) issue

Kubi's comment noted that a minification of the html that removes the spaces between the <a> elements causes the justification to fail. A pseudo-space within the <a> tag does not help (but that is expected, as the space is happening inside the inline-block element), a <wbr> added between the <a> tags does not help (probably because a break is not necessary to the next line), so if minification is desired, then the solution is a hard coded non-breaking space character  --other space characters like thin space and en space did not work (surprisingly).

Nearing a Future Clean Solution

A solution in which webkit was behind the times (as of first writing this) was:

.prevNext {
    text-align: justify;
    -moz-text-align-last: justify;
    -webkit-text-align-last: justify; /* not implemented yet, and will not be */
    text-align-last: justify; /* IE */
}

It works in FF 12.0+ and IE8+ (buggy in IE7).

For Webkit, as of version 39 (at least, might have crept in earlier) it does support it without the -webkit- extension but only if the user has enabled the experimental features (which can be done at chrome://flags/#enable-experimental-web-platform-features). Rumor is that version 41 or 42 should see full support. Since it is not seamlessly supported by webkit yet, it is still only a partial solution. However, I thought I should post it as it can be useful for some.

Solution 2:

Consider the following:

.prevNext {
    display: table;
    width: 100%
}

.prevNext a {
    display: table-cell;
    text-align: center
}

​(Also see the edited fiddle.) Is that what you are looking for? The advantage of this technique is that you can add more items and they will all be centered automatically. Supported by all modern Web browsers.

Solution 3:

First off, I like the approach of the pseudo-element in order to keep the markup semantic. I think you should stick with the overall approach. It's far better than resorting to tables, unnecessary markup, or over the top scripts to grab the positioning data.

For everyone stressed about text-align being hacky - c'mon! It's better that the html be semantic at the expense of the CSS than vice versa.

So, from my understanding, you're trying to achieve this justified inline-block effect without having to worry about resetting the line-height every time right? I contend that you simply add

.prevNext *{
    line-height: 1.2;  /* or normal */
}

Then you can go about coding as though nothing happened. Here's Paul Irish's quote about the * selector if you're worried about performance:

"...you are not allowed to care about the performance of * unless you concatenate all your javascript, have it at the bottom, minify your css and js, gzip all your assets, and losslessly compress all your images. If you aren't getting 90+ Page Speed scores, it's way too early to be thinking about selector optimization."

Hope this helps!

-J Cole Morrison