inline-block version about susy

[mirisuzanne]

Short answer: no.

Longer answer: Moving from floats to inline-block has a few minor gains (mainly no clearfix), but introduces a major setback. White-space between grid-elements is rendered, leaving you with no control over proper grid spacing. The only appropriate solution that I've seen involves adjustments to letter-spacing - which need to be applied carefully, and in very specific ways. In the end, you've added a much more strict set of grid requirements - losing the ability to nest elements among other things.

[ariroseonline]

I was battling the whitespace thing. However, I found that setting whitespace:nowrap on the parent element of the inline-block elements solves the problem, at least in FF, Chrome, Safari. I don't really know why, since W3schools never says it collapses all of the whitespace, but it works. Do you think this is a reliable method cross-browser?

I like inline-block because it's really good for vertically lining up inputs across a row when you have different padding and margins on the inputs.

[mirisuzanne]

I'd be happy to look at a demo - especially if you can re-create the AG test (on the current Susy home page, and also in the susy-next branch test folder. Basically just a demonstration of complex grid nesting.

Susy Next is built to handle different output modules, and I'd love to add an inline-block module if there's a good way to do it.

[tsi]

I like playing with inline-block layouts too.
@ericam another advantage would be bi-directionality - when your design switches from LTR to RTL - with inline-block they just work! no overrides required.
@ariroseonline adding white-space: nowrap is probably not a good idea - your white-space is still there, it is just the line-break that is being prevented. leaving you with spans that overflow their container.
http://codepen.io/tsi/pen/mfcpx

My favorite trick is using margin-right: -.25em - http://codepen.io/tsi/pen/gHzdt but that still feels very hacky.

[mirisuzanne]

Yeah, I'd be ok with the -.25em approach if I trusted that number to be consistent across fonts. Maybe, now that developers often control the fonts, that just means we would need a setting to override -.25 if it wasn't working for your particular font...

[DavidOliver]

To avoid the potential inaccuracy of setting a negative margin, what about setting the containing element to font-size: 0 and resetting elements within it to font-size: 1rem or whatever? I've had success with this and made myself a little mixin. Something like:

=zero-font-size
    font-size: 0

    & > *
        font-size: $base-font-size

[tsi]

I don't know. this -.25em "hack" can only be trusted if we know that the white space is there.
If there is no white space, this trick will cause elements to overlap - http://codepen.io/tsi/pen/wfctv
I use this in many occasions, but I don't know if we should use this in a generic layout system such as susy, on the other hand - your suggestion about a margin parameter may actually make it very usable, allowing you to have no margin at all when there's no white-space.
I'd rather start digging into flex-box and css grids though :)

[tsi]

My last comment was referring to eric's last one.
@DavidOliver - that solution is very good for handling the white-space issue but it might introduce a bigger one by breaking font-size cascading down the DOM, this might become critical when using ems for layout widths.

[DavidOliver]

@tsi, Yes, if it were ever provided it would have to be made clear that it's best not used with em font-sizing schemes.

[ariroseonline]

@tsi Good catch, and thanks for the codepen!

@ericam Use floats by default, and then implement an inline-block (-.25em) experimental mode with override? I wouldn't want to be a developer encountering strange behavior that needed a font related fix.

[mirisuzanne]

Yeah, inline-block will never be our default. I'm willing to consider an inline-block module (or plugin) if someone builds a nice one, but I'm with @tsi — my energy is more likely to go into flex-box or grids.

[jbowyers]

Bit late here but wanted to mention that I spent some time trying to find a reliable way to use inline-block for layout and came to the conclusion that it is not possible. See:
http://codepen.io/jbowyers/pen/pxgJk

The primary issue is, the space between elements depends on the font-family and the same font can have different spacing in different browsers and OSs. So, there is no reliable way to determine the negative margin value.

[krazyjakee]

Hope nobody minds me leaving this here, but here is a solution to fix heights in javascript since that seems to be the only option for responsive, floated grids.

(Requires jQuery but is easily ported to vanilla)

var gridCells = $(".grid-cells");
gridCells.height(Math.max.apply(null, gridCells.map(function() {
  return $(this).height();
}).get()));

Any other solutions/corrections welcome.

[ShadyMind]

I wrote a little example for inline-block layout at codepen. Works in latest chrome, firefox and ie8 for me.