25-50-25 grid on safari 7

[chrisdrackett]

I'm trying to build a pure-u-1-4 pure-u-2-4 pure-u-1-4 grid and the last element is getting pushed down to the second line in safari 7 beta. Not sure if this is a pure issue or a safari one, but I thought it was worth mentioning.

[SiNNuT]

There are a lot of reported issues still open on grid breakage, on a wide variety of browsers and os's. So i'm guessing safari is not really to blame here. The current grid approach just doesn't seem robust at all, and keeps me from using pure on real projects. I'm guessing this goes for more people.

Makes you wonder if just taking the float approach would be better. Or maybe some other technique to work with inline-block #158

[bradleyfalzon]

@chrisdrackett have you tried pure-u-1-4 pure-u-2-4 pure-u-1-4 ? I didn't think pure-u-2-4 exists, i'd try pure-u-1-2.

[michel-tournier]

Unfortunately I have to agree with @SiNNuT ... because the current grid in version 0.2.1 isn't working properly, it keeps people from using pure on live projects. I was hoping issue #146 (revamping pure grids: mobile first / declarative / less verbose classnames / more simplified / more responsive) would be resolved in version 0.2.2, but a.t.m. it doesn't look that way. In my humble opinion, this is by far the most important and urgent issue to fix.

[ddelrio1986]

@chrisdrackett You should be using pure-u-1-4 pure-u-1-2 pure-u-1-4. Always make sure the fraction is simplified. If that doesn't fix your issue then you must be experiencing this: #41

There are many workarounds present there. I prefer this one which I posted: #41 (comment)

[ericf]

@chrisdrackett can you create a simple HTML snippet with the correct classname pure-u-1-2 which still has this issue? My guess — like others have pointed out — is that you're applying a classname which does not actually have any of Pure Grids' style rules applied.

[adapterik]

@chrisdrackett Would you mind visiting this page http://www.adaptations.com/puregridtest2.html and reporting how the grids fare? This test page applies another approach to the grid which has fixed some issues for me.

I've tested Safari 6 and other browser, researched the cause of some specific problems and come to some conclusions (but it is still ongoing.)

First, the cause of breakage of the grid is most likely due to the font selected for the grid (pure-g) not matching with the "erase the space" fix, which applies letter-spacing: -0.31em to the grid. This has the effect of removing the space that otherwise would be present between grid units if there is one or more white space characters between them. It is supposed to have that effect if the ratio of width/height of a space character in the current font is 0.31. This works for Arial and related or similar fonts. One problem is that different browsers, platforms, and individual installations have different fonts available. If the font is too different, and the width of a space is significantly wider or thinner, there will be problems. A lot of work and all around fun involved in building the list of optimal fonts can be witnessed in #41.

The grid will have problems if the width/height ratio of the space character is different than expected. If the actual ratio is bigger the last grid unit may jump to the next line. This is what I consider "breaking". If the space is smaller (meaning our number is too big) the spacing between the grids will actually be negative, and the units may overlap and the units will not align along a vertical axis, especially visible at the right edge of the grid. This is exacerbated if there are multiple grid units in a row, because the overlapping is additive. As if that is not enough, not all browsers handle "negative spacing" the same -- Firefox just bumps the units against each other (it does not let them overlap), while Chrome and Safari (and I suspect all webkit browsers) will allow them to overlap.

A second issue is that on Safari and some other webkit based browsers, as well as IE8 and Opera12, the conversion of percentage widths to pixels will always round down. Note that it does not round down and up as in "normal" math, but always down . This has the effect of almost always creating shorter grid units than you would expect. The reason for this is that rounding up may result in grid units that eventually exceed the width of the row, and break. (This was the case with IE6 & 7, and is why you need to use width percentages that are below what you really want.) This is all relegated to the realm of "sub pixel" calculations and considerations.

On the test page the

WebKit does provide for subpixel calculations, but apparently it is left up to the browser developer whether to implement it or not. The latest Chrome does, Opera Next/Developer does, Safari 6 does not.

That is why I'm super curious about your results with Safari 7 on the test page cited above. (And ironically even though I've been active on #41, I found this thread through a Google search on Safari 7 experience!)

The fix on http://www.adaptations.com/puregridtest2.html is to use a single web font and use the width/height ratio for a space as measured across multiple browsers (I happened to choose bpmonoregular which is 0.600 on most browsers; a better choice for putting something like this into production would be a custom font designed for just this purpose.) The purpose is to normalize the font, at least, across browsers. This is not proposed as a solution, necessarily, but at least to help understand the problem.

I've tested the major browsers on Linux, Mac, Windows, and am starting on iOS and Android. I'm adjusting this page for the major browsers (just put in a fix for IE7), but am developing a new version for mobile browsers. In Safari 6 there is no breakage, but the right edge of the grid is ragged.

[ericf]

Merged #190 which fixes this.