grids spacing wrong without Arial on pure-g, pure-g-r

[adapterik]

This was reported on yui3 grids and still exists (http://yuilibrary.com/projects/yui3/ticket/2533215.)
The summary is that the letter spacing = -0.31em hack placed on the pure-g[-r] class to make the grid units work well only works (well) if the font family is Arial. It may appear to work for other font families (pure sets the font family for the html tag to sans-serif), but the spacing is not perfect, and it breaks down in certain browsers (atm it fails on FF/Linux for me.) The general solution is ensure that the pure-g and pure-g-r divs get Arial, and that your own content within the pure-u-x-x divs get whatever font you want (so I guess that means resetting back to sans-serif for pure compatibility.)
My interrim solution is to add css like this

.pure-g, .pure-g-r {
    font-family: Arial;
}

in my own css file loaded after pure, and also either resetting the font for all the pure-u-x-x

.pure-u-1, .pure-u-1-2, ...
    font-family: sans-serif;
}

or using a container (which I always do anyway) inside the pure-u-x-x which sets the font (and does other as well.)

I think the best solution is to handle the pure-g, and pure-u stuff inside of pure.

[rmasters]

I'm experiencing this issue as well - even without custom fonts - on Google Chrome 27.0.1453.94 m (Windows), pure (all) 0.1.0

An example with tables: http://jsfiddle.net/yQHzr/

[adapterik]

Hi rmasters,
What you are seeing is the effect of the "letter-spacing: -.31em" hack. It is supposed to affect just the "pure-u-1" and "pure-u-x-x" unit classes since it is set in "pure-g" and "pure-g-r" grid container classes. Each letter is backed up by 0.31em. The unit classes undo this by setting "letter-spacing: normal", so when you place content in a unit class div you don't see this at all.. Seeing squashed text like that means there is not a valid unit unit class between your content and the grid class. In your case, this is because "pure-u-1-1" is not a valid unit class -- you want to be using "pure-u-1" instead.
I used to run into this from time to time during development, and it drove me crazy until I discovered why. It was usually due to malformed html. I think this should be highlighted in the grid documentation.

[ericf]

@msweeney Would you be able to look into this?

[msweeney]

@adapterik Can you provide a pointer to your specific issue? I am unable to reproduce the issue on the ticket you mention when running the jsfiddle frame source standalone.

Here's the source I've plucked from the jsfiddle iframe: https://gist.github.com/msweeney/5686514. Are you seeing the issue here? If not, can you tweak the gist to force it?

[msweeney]

@adapterik NM, I am able to reproduce with verdana.

While the proposed solution is a fine workaround, breaking font inheritance within units is a showstopper for rolling it into grids.

I'll try and come up with a cleaner solution.

[adapterik]

@msweeney Here is a gist demonstrating the issue with Pure: https://gist.github.com/adapterik/a7eace0083987d004682

Without moving off of my chair, I can reproduce the problem on FF 21 / Linux; it is not present on current Chrome / Linux.

Since Pure grids are by and large the same as YUI3 grids, the comments from the bug report I had referenced are relevant.

Can you explain why font inheritance for units is important? I thought that, for one, the best practice for using grids is to provide a content wrapper inside of units, with the purpose of providing font characteristics, padding, gutters, etc.

[msweeney]

@adapterik OK, thanks. Apparently your issue is limited to FF Linux.

Breaking font inheritance is important because generally a page level font is set that inherits to all elements on the page. Forcing users to also set the font for content within units is not the same as the non-inherited properties you mention.

[msweeney]

Currently I can reproduce this issue reliably by using verdana.

I've pushed a branch to my fork that uses ex units rather than em, which resolves the issue, for verdana at least, without negatively impacting sans-serif:
https://github.com/msweeney/pure/tree/unit-spacing

@adapterik I'm lacking a Linux test environment. Can you try my branch and see if that resolves your issue?

Or add the following to a style block on your test page (after the grids.css include):

.pure-g {
    letter-spacing: -0.69ex;
}

[adapterik]

@msweeney This does work if the global (on html) font is Verdana, but not universally -- e.g. Courier. I think the best solution would be to address it head-on: The proportion -0.31 is designed to work on a universally available font with specific metrics. If it is applied to any other font the results cannot be ensured. I imagine other universal fonts will have similar predictable metrics, so for some common subset it may be possible to fiddle with the letter spacing to make it mostly work. I wouldn't hazard to guess what would happen in the mobile browser world.

One reason I would even suggest hard coding a font into pure-g and pure-u is that Pure already does this -- not only html, but button, input, select, and textarea all have sans-serif explicitly set. And the css generated by the skin builder includes at least two hard coded font family settings. So it would seem to fit into the "opinionated" nature of Pure to fiddle with the fonts directly. I would think it well within the purview of a web developer using Pure and YUI to have a few lines of CSS to override the font. Really it would just be adding all the pure-u classes the the css statement that already would be present to override html, button, input, etc. That could even be generated by the skin builder if it had a setting for the font.

[msweeney]

@adapterik Thanks for testing and the Courier feedback. At this point I am looking for a solution that is flexible enough for common fonts without the heavy handedness of your proposal.

Normalize applies the font to the HTML, but this (or BODY) is where the global font would be normally be applied, so the "opinion" is really a default. Ditto for the other elements you mention, which will never contain children so the inheritance is a non-issue there. Breaking global font inheritance and forcing developers to set a font-family on grid units goes too far in my opinion.

[adapterik]

@msweeney No problem. I really appreciate you taking the time to address this.

Maybe in addition to whatever solution you come up with there could be documentation on how to solve this problem by hand. It does seem rather inherent to this technique. For comparison, I also use YAML, which uses floats for grid, and it specifies what and why you need specific classes to solve problems with that approach. As it is now, it is not hard to override the pure-g and pure-u css to make this work.

re: my "opinion" slant -- I was really just bouncing off of something I read in the Pure docs or the blog which joked that Pure was gently opinionated. And re: the font applied to HTML et al., it is really just to note that for true global reset of font, you have to know what Pure/normalize are doing already. And this may just be me, but compared to the complexity of the css, html and javascript for a typical website using YUI or Pure grids,the extra code to set the font inside a grid unit doesn't seem so heavy.

Another possible solution would be for Pure and skin builder to produce less files? Global defaults like font, colors, border radius, etc. can be modified locally. No need, really, to set defaults only to override them later.

[msweeney]

@adapterik Sure, no problem.

I agree that a preprocessor would be better for handling defaults and customization in general and think we should move to that model, however we still need to provide robust pre-built solutions.

We should consider using layout techniques other than inline-block when possible (flex, table) and make grids more robust in general.

[rmasters]

@adapterik Thanks for spotting that, it's been driving me mad!

[SiNNuT]

Apparently it is not hard to fall into the trap that causes squashed text because the Grid builder page, that is linked to from purecss.io shows exactly this behaviour :)

yui/gridbuilder#13

[visionmonster]

you can just remove the space in-between the elements that have the class="pure-u-*" on them since it's the line-break that is causing you to need to use the letter-space trickery.

works:

monospace

monospace

doesn't work:

monospace

monospace

here's a fiddle http://jsfiddle.net/visionmonster/9yxNY/

This works in IE10, IE10 in IE7 mode, OSX safari 6, OSX FF21, OSX chrome 28, TouchPad, iOS 6.

I had played around with setting the font-size to 0 on the pure-g div and then setting it to 1rem on the pure-u-* elements like:

.pure-g{
font-size:0;
*font-size:1em;
letter-spacing: normal;
*word-spacing: -0.43em;
}
.pure-g > *{font-size:1rem;}

but this method feels much more fragile; fiddle's here: http://jsfiddle.net/visionmonster/qeKp3/

[adapterik]

Hi @visionmonster, thanks for your input. If only the the font-size: 0 fix worked universally, or rem were support was deeper.

There are several articles and follow up discussion storms on this topic where many possible solutions have been aired to the "remove space between inline-blocks". E.g.

http://www.vanseodesign.com/css/inline-blocks/

Most methods, including the 0 font size, do not work universally. If a method doesn't work across the swath of YUI supported browsers and platforms, it can't be used. However, as your method and YUI's show, there can be ways to selectively apply css hacks. However, it is such a delicate balancing act that introducing changes or a new solution can easily have unintended consequences. (Witness this bug report!)

The docs inside of pure or css grids explains the tweaks pretty well and shows the value of relying on the collective experience accreted in a well-vetted solution:

https://github.com/yui/pure/blob/master/src/grids/css/grids-core.css

I'm quite sure that removing spacing between pure-u-* units would not be favored since a grid is usually interlaced within a fairly complex page. It is so much easier to maintain html if it is indented in a regular fashion and multiple hands touching it would surely break it at some point. I think the spacing solution is more popular with folks doing small sections of inline-block, e.g. menus.

[julienlz]

Hello, it fails for me on Chrome for Android (Nexus 7) with Georgia font, the grid is broken. Same thing at purecss.io on 3 columns.

.pure-g {
    letter-spacing: -0.69ex;
}

this trick don't work, the only thing i can do is detect chrome/android and reset Arial font

if (navigator.userAgent.match(/(Android)/i) && window.chrome) 
$('.pure-g, .pure-g-r').css('font-family','Arial');

[adapterik]

Hi @julienlz, a few things.

The letter-spacing: -0.69ex; hack is not going to be a reliable fix. It will suffer the same problem as the -0.31em one, but the metrics being slightly different, will behave ... slightly differently.

Also, I wouldn't recommend that you spot-fix the problem with browser sniffing like that. For one, browser sniffing is not reliable, and if you discover more cases you'll need to keep adding to it. Secondly, why not just fix the problem for all browsers? And why not fix in css? With js, it is possible that you will get a flash of broken grid before it is fixed.

Finally, I think you should reset the font for the pure-u* as well. In many cases the Arial font may end up being the same as sans-serif and you won't notice the difference. But you'll have problems if you have set a specific font in the web app, or the Arial and sans-serif don't map to the same font.

Good luck and thanks for contributing this -- hopefully it will be fixed soon.

[trnelson]

I think this is the same issue, but I've noticed that with two divs side-by-side (i.e. a pure-u-1-3 and a pure-u-2-3) if I use a Google font, it drops the second div below the first. Assuming this has to do with a width change on the second div of some sort. My CSS is as follows:

@import url(http://fonts.googleapis.com/css?family=Arvo|Sanchez);
body {
    font-family: Sanchez, Georgia, Times New Roman, Serif; /* <----- THIS FONT */
}

[leo-unglaub]

This also affects #119

[ericf]

Here's an interestion solution from @jonathantneal which uses a custom web font: https://github.com/jonathantneal/layout-webfont

[adapterik]

@ericf interesting -- but still carries the fundamental issue that the inner inline-block unit needs to have the font family reset explicitly. Also if Arial or substitutions have stable, cross-browser, cross-platform metrics so that a space is 0.31em, is there a need to introduce another dependency?

[trnelson]

To get around the issue I was able to assign the font-family declaration to the individual containers (as opposed to the full body tag) and that seemed to work in my scenario. In the end I actually ended up using another framework, for completely different reasons. I'm really looking forward to using Pure again soon though!

[jonathantneal]

Came here from @ericf. I'll point out the obvious. If you use inline-block layouts, you'll need to redeclare styles, and there are other caveats.

If you use a custom webfont, or any non-monospace font, or letter-spacing, or word-spacing, then the -.31em solution will create a conflict, and you will need to redeclare the custom font family or letter spacing or word-spacing on children of the layout. IMO, this option is the worst, as it presents the most variables.

If you use a custom webfont, then the layout font solution will create a conflict, and you will need to redeclare the custom font family on children of the layout. Also, most browsers delay loading the web font, which causes an unacceptable, momentary shift in the layout. IMO, this option is almost as bad as the previous solution, but there are less consequences.

If you use a custom fontsize, then the font size 0 solution will create a conflict, and you will need to redeclare the custom font size on children of the layout. I've heard certain Android devices may have an issue with this. IMO, this option is the best, as it presents the least variables.

[tilomitra]

@jonathantneal With the font size 0 solution, how do you recommend resetting the font-size for IE6/7/8? 1rem won't work.

I agree that the font-size solution requires the least variables. I will check to see if this works on Android 4.0+, since that's what Pure supports.

[jonathantneal]

@tilomitra

My work-around for the font size 0 solution is the same for all three solutions I described.

<div class="stack">
    <div class="panel">hello world</div>
</div>

If .stack zeros out the font-size, and .panel is inline-block, then you'll need to redeclare the font-size on .panel. I do this by using multiple selectors to assign the font-size both in and outside of the layout.

.stack { font-size: 0; }
.panel { display: inline-block; }
body, .panel { font-size: 16px; }

[MilesWilford]

I tested this on my Android devices and wanted to contribute what I found. I'll put up full-resolution screenshots.

In Chrome for Android, the grid is entirely dysfunctional:

The problem is identical when tested in the 4.0.3 AOSP Browser.

In the 4.2 Browser, gaps can sometimes show up as well:

What's the advantage of this inline-block and negative text spacing approach over a more typical clearfixed float approach?

[lkraav]

Here's the webkit browser from Nokia N9

Here's @adapterik testpage2

Firefox 15 (latest on Harmattan :/) OTOH handles 030rc2 grids perfectly.

[lkraav]

@adapterik just wanted to let you know that your effort is much appreciated here, at least. I think the amount of your research work into these issues needs to be properly acknowledged. Whatever "proper" might be :)

[adapterik]

Here's the webkit browser from Nokia N9

@ikraav Thanks, and thanks for testing. I need to add web fonts that support Android and older IE.

[adapterik]

@ericf Awesome, man, now that is the YUI way.
Do you happen to know how the flexbox grids fare in browsers with partial support?

[ericf]

@adapterik Basically all newish versions of WebKit and IE 10+ will use Flexbox. We are only opting into Flexbox in browsers which support the new syntax and wrapping; i.e., currently Firefox cannot use this approach. We'll have more details on this in a blog post coming out soon (hopefully today if we can fix our site deploy issues).

[david-hc]

How about using negative margin

[ckizer]

So how is this going to be fixed once and for all? It seems extremely short sided to design a responsive grid system that doesn't work with fonts on browsers. Why would the developers keep going down a path that isn't future proof?

Is there any responsive grid system that is small and light weight, but doesn't have this problem? Bootstrap is too heavy for me.

[kierenevans]

It is fixed already for browsers that support flexbox. As more browsers implement it, we won't need the font stack solution.

[ckizer]

Thanks. Primarily latest versions of chrome and safari correct?

Sent from my iPhone

On Mar 3, 2014, at 1:03 AM, Kieren Evans notifications@github.com wrote:

It is fixed already for browsers that support flexbox. As more browsers implement it, we won't need the font stack solution.

—
Reply to this email directly or view it on GitHub.

[ericf]

@ckizer this issue was fixed months ago, for all browsers and OSes that we've tested on.

[adapterik]

@ericf I believe there may be one small issue remaining with FF, since it doesn't (yet, but will very soon) support enough flexbox -- empty (or short) grid rows still take up height.
One can fix this by fiddling with font-size or line-height for pure-g (setting to 0, then setting back to desired within grid units, or as I prefer, content containers within grid units). I know this approach draws frowns, and may have its own drawbacks, but is there another way to solve this particular issue?
Even when FF 28 is out, there will be a need to support older browsers, so the issue doesn't go away ... yet.

[dannyfritz]

Oh no. Not this again! Haha.

[adapterik]

Muahahaaa （｀๏ ̯๏´）

[ericf]

This issue is closed. If anyway has a bug, with a simple, reproducible use-case, please create a new GH issue. Thanks!

[adapterik]

no problem, will do.

[ItalyPaleAle]

What about Open Sans and Source Sans Pro? Will they work? If not, how can we change the CSS code to use them? (want to use those fonts for all browser - also, we're targeting only modern browsers, i.e. IE10+ etc).

[ckizer]

I'm still getting this issue in safari. I added the code to the bottom of my stylesheet:

/* Putting the font-family to Arial makes sure the
letter and word spacing collapsing works */
.pure-g,
.pure-g-r {
    font-family: "Helvetica", "Arial", sans-serif;
}

/* Declaring the font-family on the children ensures
that the grid doesn't flow to a new line. */
.pure-g [class *= "pure-u"],
.pure-g-r [class *= "pure-u"] {
  font-family: 'Neue';
}

Was able to fix it by renaming my custom pure-grid back to old pure-g prefixes.

[stuartlamour]

please don't hardcode font stacks in a plugin.

[stuartlamour]

ever.

[esr360]

Setting the following CSS will fix the whitespace issue in between columns in Webkit browsers regardless of typeface:

.pure-g,
.pure-g-r {
    display: table;
    width: 100%;
}

Combined with the previous letter-spacing hack that works with IE and Firefox, you can get inline-block columns that work perfectly in all browsers except Opera (though the letter-spacing needs setting to "-1em" and not "-0.31em" to work with all typefaces):

https://github.com/esr360/Kayzen-GS#solving-the-whitespace-issue

http://esr360.github.io/Kayzen-GS/

As far as I can tell, apart from the slight mis-calculations Opera causes on the columns, there's no real downside to this method.

[SimonTeixidor]

This is still broken on Ubuntu 14.04 Server Edition with Firefox 39:

To reproduce, install Ubuntu 14.04 Server Edition with a basic window manager (I use DWM, but I bet any window manager that doesn't pull in extra fonts will work) and Firefox. Load a basic test page, like:

<html>
    <head>
        <title>Pure CSS broken grids.</title>
        <link rel="stylesheet" href="http://yui.yahooapis.com/pure/0.6.0/pure-min.css">
    </head>
    <body>
        <div class="pure-g">
            <div class="pure-u-1-3">Thirds</div>
            <div class="pure-u-1-3">Thirds</div>
            <div class="pure-u-1-3">Thirds</div>
        </div>
    </body>
</html>

And watch the third column end up on a new row.

The issue is resolved when the gsfonts package is installed.