Inline-block and white space in the grid

[scottmontminy]

I hope to raise this as a new issue for clarity sake, but my apologies upfront because I know this has been discussed all over the place related to inuit.css here and here and elsewhere.

In regards to using inline-block for the grid system, do we suspect that the solution of commenting the whitespace between grid elements is the long-term solution for inuit.css?

The commenting solution is no doubt a robust solution (or removing the whitespace altogether). No argument there and I'm thankful for the solution because using inline-block for grid elements is simply awesome.

However, the commenting solution does make our grid dependent on HTML formatting - which although semantically valid seems like it will present it's fair share of challenges when working with a team of developers and/or using the grid on repeating regions generated from a database. Basically, I'm reluctant to use the grid system with this dependency on a production site if this is the long-term solution.

Again, sorry for the redundancy. Amidst all the issue threads I can find on this topic, I'm a little confused about the short-term vs. long-term ramifications. Thanks.

[kevva]

Instead of commenting out white-space you could try using another method by extending the grid in your application specific stylesheet like this:

.grid {
  letter-spacing: -0.31em;
}

/* Opera hack */
.opera:-o-prefocus,
.grid {
  word-spacing: -0.43em;
}

.grid__item {
  letter-spacing: normal;
  word-spacing: normal;
}

[csswizardry]

This will be in place until a more robust solution presents itself, which it so far hasn’t, so I can (with all confidence) say that this solution could well be around forever.

I was always wary of the [letter|word]-spacing hack, and that proved to be problematic. The most robust method is to just have no whitespace (which make sense, as it’s whitespace that causes the issue in the first place).

At work we regularly generate grids from loops and stuff, and you can write your loops in such a way that your comments will take out the whitespace. Also, in teams, people will know something is awry when their grid breaks, and (I would hope) and developer worth their salt will go and find a grid that does work and reverse engineer their solution based on that (or, y’know, speak to someone on the team).

I’m afraid that, although inuit.css is suited to big projects where you might have a big team, it can’t take responsibility for how that team communicates any details of a project.

[scottmontminy]

Thanks guys. Both responses are helpful.

@csswizardry I was hoping to be able to hold your framework accountable for our boneheaded mistakes with formatting. =) Just kidding of course. Many thanks for all the good work on the framework.

Your advice rings true. I figured we'd just fix the white space issues if they arise. We can surely add the HTML formatting style to our process. And we'll definitely experiment with the extension from @kevva (thanks).

[csswizardry]

Don’t mention it!

I’m sorry there isn’t a better solution to this problem, but I guess it’s the price you gotta pay :( If a (decent) solution does pop up though, I’ll be sure to implement it :D

H

[kevva]

Out of curiosity, what is it that you don't like about the letter-spacing solution? It's the least "hacky" one in my opinion.

[RowboTony]

Hi, I use Inuit.css with several CMS frameworks, and this issue is causing all of them to misbehave, watching this issue with great interest for a better/alternative solution. Thank you.

[Anderson-Juhasc]

I think having to use a bad comment in order to use this grid to "inline-block"...

[scottmontminy]

@kevva I've been working with your css fix noted above, and it is testing out fine in all the major browsers.

We've tested:

• IE (8, 9)
• Chrome (25, 26, +Android)
• Firefox (19)
• Safari (6, +Safari)
• Opera (12).

We're feeling pretty good about using it, but I figured I'd check in with you too see if you're seeing any issues.

[kevva]

There shouldn't be any issues as far as I know.

[csswizardry]

If this does work then I might add a $use-markup-grid-fix var to choose between the bulletproof markup method or this bulletproof-so-far one :)

[andykirk]

I've been using it with no problems too.

+1 for the var.

[scottmontminy]

Somehow I'd feel better about it being in the core as an option =), so +1 for the variable choice. Thanks guys.

[csswizardry]

Coolness :D

[kingsidharth]

@csswizardry So will we see the variable soon? I am still using 4.x version so things won't break 😦

[meganox]

Can someone explain to me where the word/letter-spacing values have come from, were they just blindly copied direct from YUI? Any idea how they were derived originally? And I'd love to know if/how they can possibly work for every font on every platform?

Personally I'll be dropping optional end tags as that's the only solution that's actually in the spec that doesn't require weird formatting or spurious comments.

[s4wny]

The hack doesn't work for me so i created a new one.

/**
 * [1] Reset the font-size to the root/default size.
 *     Note: Won't work in IE8 and below
 *     To make it work in IE8 and below just change to "font-size: $my-font-size;".
 */
.grid__item > * {
    font-size: 1rem; /* [1] */
}


/**
 * [1] Font-size 0 removes the white spaces. Won't work on mobiles..
 *     ..because the minimum font-size is 8px.
 */
.grid__item, .grid {
    font-size: 0; /* [1] */
}

[kevva]

@s4wny, just use my solution further up.

[s4wny]

@kevva It didn't work for me.

[kevva]

@s4wny, weird, maybe you've done something wrong? How does your code look like?

[jorgepinon]

This is a known issue with inline-block elements in general, and there's a good and simpler CSS hack:

.grid__item {
margin-right: -4px;
}

Chris Coyier wrote up a good summary:
http://css-tricks.com/fighting-the-space-between-inline-block-elements/

[SamuelTurner]

@jorgepinon As soon as you change the base font size (which lots of people will), that will break.

You can apply that fix outside the framework once you've set the base font size though.

[jorgepinon]

@SamuelTurner Good point. Maybe an em value would do the trick. I'll try to test it when I get some time.

[kleinfreund]

@jorgepinon Em/percentage values would just result in font-size: 0; again, because they are related to the parent.

Also setting margin-right: -4px; is inapproriate. Although gap between the inline-block elements will be 4px sometimes, it is related to the font one is using. It might be 3 or 5px in other fonts.

For me, using commented markup is not clean at all, but only has this one caveat: Being dirty. You don't have to worry about setting a wrong rule in your CSS, because everything works the same. That doesn't apply for all the other given fixes.

[jorgepinon]

@kleinfreund actually I meant to use negative margin without setting the parent's font-size to 0.

It's certainly true that changing font-families would affect the value, but for me this is a cleaner and more natural solution. I understand your point about comments, but I prefer a css solution to a visual problem. Or in this case, a css hack over an html hack. I'm just adding it as another method that some may prefer.

I also work on larger apps and share code among 2 other people, which makes the choice much easier for me. Either maintain html comments on all inline-block sets in all html templates and partials, or set it (and adjust it as needed) in a single place.

[kleinfreund]

@jorgepinon I was talking about negative margin-right as one solution and font-size set to zero as another one you posted in a later comment. Didn't want to mix them up.

I don't know about whether one could run into some problems using negative margin-right in this case. Is the calculated whitespace full pixels wide?

Let me ask this differently: Could different rounding of decimals in browsers result in different whitespace sizes?

[jorgepinon]

@kleinfreund someone set up a useful dabblet that can be used to test all solutions: http://dabblet.com/gist/2422174

I found that -0.24em to -0.26em covers most use cases. For practical purposes, someone could go with -0.26em and lose a pixel at smaller sizes.

There's no doubt that removing whitespace altogether is the safest way (even though it nags at my standardista training). But in practice, for our large-ish template library, this is a more manageable method.

I'd extend the framework to include a switch, something like $use-inlineblock-margin-hack

[jorgepinon]

I created a fiddle to test and it looks like -0.28em works well for almost all sizes with font-family set to "sans-serif". For serif, it's a little better at -0.27em.

I'd set it depending on the font family.

http://jsfiddle.net/jorgeluis/SAd7G/

One last thing (sorry), the negative-margin hack doesn't work on IE7 or below.

[chernushevich]

There is also a method of creating your own font with a square space. Doesn't work in IE8:

http://jsfiddle.net/Lulupard/AAQLT/5/

[graste]

All the attempts without the "markup hack" have problems that do outweigh the "cleanliness" of the HTML by far. And I'm not even speaking about the disadvantages custom fonts have performance wise etc. - especially on mobile with flaky connections and in comparison to some HTML "hackery".

I really don't get all the contempt for the HTML comments or simple whitespace removal (apart from co-workers not liking it or oneself forgetting about it ;-)). I get that it's somewhat annoying when one writes plain old HTML, but it gets less of a problem when a template library/language is used. May it be HAML or Jinja2 or Twig or whatever.

In Haml it's a simple > at the end of the grid item elements:

.grid__item>
    some content
.grid__item>
    more content

In other templating systems like Twig it can be achieved via {% spaceless %} blocks or whitespace modifiers in block definitions (like the - in {%- block asdf -%}). With templating languages it's even possible to create small reusable templates like 2cols, 3cols etc. with code for different numbers of columns that can be used to abstract away the grid boilerplate completely and just fill the column content with blocks in templates via embeds (Twig example):

Simplified 3cols.twig example:

{% set name = name | default("unnamed") %}
{% set col1 = col1 | default("col1") %}
{% set col2 = col2 | default("col2") %}
{% set col3 = col3 | default("col3") %}
<div class="{{ name }}">
    <div class="{{ name }}-container">
        <div class="{{ col1 }}-box">
            <div class="{{ col1 }}">{% block col1 %}{% endblock %}</div>
        </div><!--
        --><div class="{{ col2 }}-box">
            <div class="{{ col2 }}">{% block col2 %}{% endblock %}</div>
        </div><!--
        --><div class="{{ col3 }}-box">
            <div class="{{ col3 }}">{% block col3 %}{% endblock %}</div>
        </div>
    </div>
</div>

Usage in a Twig template:

{% embed '3cols.twig' with { name: 'mywidget', col1: 'shu', col2: 'ha', col3: 'ri' } %}
    {% block col1 %}
        content of column 1
    {% endblock %}
    {% block col2 %}
        {% include ['home.' ~ locale ~ '.twig', 'home.twig'] %}
    {% endblock %}
    {% block col3 %}
        content of column 3
    {% endblock %}
{% endembed %}

The parameters to name the columns with class names are not necessary in this example. Source code like that could be used with the following SCSS to have a nestable grid system without ever having too much to do with the "markup hack" for designers.

[class$="-container"] {
    @extend %grid;
}

[class$="-box"] {
    @extend %grid__item;
}

Now the -box and -container classes can be used to define the grid and grid items and the inner DIVs of those boxes can be used to style the column content. A bit of a DIVitis, but nicely nestable and not that hard to do in most templating languages. About the performance of that attribute value selector...well...I don't know. :-)

Just my 2 cents.

Thanks for inuit.css and csswizardry-grids. It's just so much nicer than maintaining Bootstrap's col_3_6_3 etc. classes in HTML markup. At least that improved in the latest version a bit. It's still LESS though. ;-)

[chernushevich]

Don't see the problem with performance since the font only contains 2 characters and is base64 encoded.

As for why not just remove whitespace – in some cases this code might be used in a premium item, so I'm just trying to make it easier to customise.

[simonseddon]

I've just been taking .5% out of the percentages when this has caused issues. Don't shout.. :/

Removing white space is better and something I'm doing more often now that I've switched to HTML pre-processers (e.g. Jade's pretty:false option does a great job and means I don't have to think about it). Commenting has just never appealed to me, personally. Just my two pence.

[imohkay]

Hey, so I'm not using Inuit on any projects, but inline-block is very advantageous. I've used Django templating, which is similar to Smarty and unless you need repeatables generated from the database, inline-block need not be an issue. When you do need something like repeatables, it's often a good use case to use an unordered list (even sematically), and since you don't need to close list tags with HTML5, this can resolve some of the problems you mention.. I would personally hesitate to use CSS hacks for the whitespace issue, if it can be resolved within the markup, you can sleep peacefully at night :D

[YemSalat]

.grid {
font-size: 0;
}

.grid>* {
font-size: medium; /* IE */
font-size: initial;
}

???
Am I really that smart coming up with this or am I missing something? Works for me in all cases

[kleinfreund]

@YemSalat This is a widely known alternate approach of getting around the inline-block white space issue. All methods have their caveats, even this one.

With the font-size set to zero, you need to keep the element with the grid class without content plus you're able to nest grids.

The point is, it doesn't get easier with this.

[ptim]

I haven't gotten to trying this yet, but how about minifying the html using https://github.com/Moveo/minimize?

minimize.parse(
  '<p class="paragraph" id="title">\n    Some content\n  </p>',
  function (error, data) {
    // data output: <p class="paragraph" id="title">Some content</p>
  }
);

[gyopiazza]

Since the letter-spacing hack is very unpredictable, we could use a Javascript fix to remove whitespace at runtime...

jQuery plugin

jQuery.fn.removeWhitespace = function() {
    textNodes = this.contents().filter(
        function() { return (this.nodeType == 3 && !/\S/.test(this.nodeValue)); })
        .remove();
    return this;
}

Usage:

$('.container').removeWhitespace();

UPDATE: This is actually only good during development, assuming the prodution HTML would be minified and thus spaceless.

[jmp909]

hi.. i was struggling with this a bit. i wanted to make a grid of articles that are split into 2 columns. i had to nest another grid inside my main grid http://pastebin.com/kCYXa8ZA

because i can't seem, to put this without the layout breaking

<div class="grid">
<!--
{% for item in vehicles %}
/--><article>
    <div class="grid__item">...</div><!--
/--><div class="grid__item">...</div><!--
/--></article><!--
{% endfor %}
-->
</div>

any suggestions much appreciated.

enjoying following your work. thanks.

j

[update.. this doesn't solve my nesting problem but i've found you can strip white space in your .twig templates with {% spaceless %} {% endspaceless %} thus removing the need for comments

[graste]

See my comment above – in addition to {% spaceless %} you can use - as a whitespace modifier in twig, e.g. {%- for … -%} – see twig whitespace control docs for details.