Grid - General requirements discussion

[papafed]

Grid will be 6 columns on phone, 12 on everything else. Grids can be nested so a container can have its own (12 column?) grid. This is how Foundation grid works. This means that column widths must be specified as percentages. I would suggest that we have fewer than 12 sub-columns as it needs to be more rigid than that.

Rows can be full width to allow background colours but content will have max width and be centered.

Breakpoints are: phone: 0 - 639. Content is 100% of width. effective smallest screen is 320. tablet: 640 - 959. Content is 100% of width desktop: 960 - 1439. Max width of content is 1152 widescreen: 1440 - infinity. Max width of 1440

May I suggest that we consistently use Ems rather than PX to describe the max-widths as well as the breakpoints.

THINGS I WOULD LIKE TO PUSH BACK ON.

1. On the visual example there are rows of 5 columns. This does not fit on a 12 column grid - you would need a 60 column one and by then it's not a grid system anymore - it's a do whatever you want system. The grid isn't there to make developers lives easier. It is there to enforce design consistency and discipline, something sorely needed at Three, so lets start by sticking to the 12 columns rule. Factors of 12 only please.
2. It has been suggested that we have percentage columns but fixed-width gutters. This is another idea pinched from Foundation. However foundation cheats at this by using padding on columns to set the gutters. That isn't compatible with putting background colours on them - so you need a 3rd level of nesting and pretty soon your HTML is 20% bigger than it needs to be. The only way to do it with margins is to use css calc() - e.g. .quarter { width: calc(25% - 20px); margin: 0 10px; } This will be slightly slower in rendering than set values, and won't work in IE8. It will also demand a lot of code to cope with nested grids as I assume you will not want the same gutter sizes on these? Can we just have percentage gutters too?
3. Widescreen - There's still a jarring and unnecessary jump in content width between desktop and widescreen. Is there any need for a separate widescreen breakpoint? Why not just let desktop expand to 1440px wide? That would have the same effect and be smooth as butter.

[LucPestille-Three]

Breakpoints: the pixel dimensions were more for the .psd and designers than rules for the development - if we could use ems as a dimension in PhotoShop, we would! I wasn't sure where the breakpoints would fall though - should 'phone' go up to and including 640px / 40em, and the min-width for the next breakpoint be 40.00001em (or whatever the next pixel value is)?

On the rest;

1) Most of the time the 12 column grid is OK, because it divides so well in to halves, thirds, quarters etc, BUT there are instances where we have to shoehorn stuff in to it, or add/remove things because they don't fit. Sometimes we need 5 things across the full page, or 4 things in 1/2 a page - having that flexibility, and being less rigid with the column count, is something that design does need. Since the workload is the difference between something like @extend %grid(5); and @extend %grid(12); (and some, in this case, necessary, css overhead), the juice is worth the squeeze.

2) This is tied to wanting to have a visual consistency between vertical and horizontal spacing - if we can tie vertical spacing to be multiples/divisions of the % margins (rather than ems/px) then % margins is OK (that gets tricky/impossible when nesting grids). I'd hope that somewhere we can have global spacing values that are used everywhere, and that when things are designed and consequently built, those 'real-world' variables are used rather than any px-perfect flat image.

3) The edge-to-edge container at sizes more than ~1000px becomes quite uncomfortable, from a design perspective, since we don't currently scale all the internal elements (icons we do to a degree, and images sometimes, but the font isn't proportional) up with the container.

In trying to compensate for that, having the container 96% wide at 'desktop' with a max-width gives a nice internal size and outer gutter (which starts at ~20px at 960px, the same ish as 'tablet' and 'phone') - however, that 96% means the container grows to ~1300px without a max-width set, before the 'widescreen' breakpoint kicks in, which is even more uncomfortable.

This was also tied to the idea of larger grid margins at 'widescreen', which would help proportionally space columns out, and the idea of some global spacing variables, so that the vertical spacing hierarchy would match (or be tied to, in multiples/divisions of) the horizontal spacing.

Also, the only people who will see that "jump" is devs like us, testing that the breakpoints work - I'd guess that 0.0001% of customers would a) see it, and b) care.

The middle ground is to set to the container to be 100% + 20px margins at mobile/tablet, and 90% wide with a max-width of 1440px at desktop and up - the container is a bit narrow at 960px, and gets a little too wide for my tastes, but would probably be deemed acceptable by most people. There's a jump between tablet and desktop there, but you'd probably only see it rotating a tablet from portrait to landscape, where there's a jump anyway. But I'd prefer the 'jump' from desktop>widescreen and the limits on the width.

I haven't written that much since my GCSEs...

[papafed]

1. Is it really necessary to sometimes have 5 things across a page and sometimes 4? We might get that situation now, but that doesn't mean it's right or acceptable to continue it. Are there examples where it's needed now and we definitely feel that we want to go forward with that when we define the organisms? This is where I feel that design has a role to play in instilling more discipline and enforcing consistency. My own feeling is that you either have a grid or you don't. When you break out of the grid you don't have a grid anymore. I wonder whether we should meet these sorts of requirements by subdividing the columns - this would be possible in the '4 things within ½ a page' scenario. My pushback is not about the code needed to allow it - as you say, it is trivial - I'd actually be removing a little bit of SASS to implement it, rather than writing more. It's more about us having this opportunity - the only one we will ever get - to do it right and really think about the way we want Three's website to work in future, and to .
2. I quite like the visual appearance of the fixed gutters - this pushback is more about the technical complexity in case it can't be done satisfactorily. My gut feeling is that we can do it if we either a) make IE8 fixed width or b) make IE8 (and older Android) fall back to percentages. Having said that I think we must define how we are going to do grids within grids - I suggest that these have no gutters at all and the columns just roll together, but what do you think?
3. If the central column is uncomfortably wide > 1000px or so then why allow it to grow to 1440 on widescreen? Shouldn't we just stop it at the desktop max size and drop the larger breakpoint?

[LucPestille-Three]

1) I'll talk about it with the design team a bit more, but my gut feeling is that we will need that flexibility in the future - there are definitely instances now where we pad things out because there are just too few/many things to fit across the page, and not being forced in to 12 columns (or divisions there of) would help, without sacrificing design consistency.

2) I think fallbacks for IE8 at this point are acceptable - we cant support it forever given its limitations - and the number of people using it is dwindling by the day, hopefully Win 10 will further increase that rate.

I think if we nest grids, then they should definitely still have gutters, but we need a rule about how many nested grids can be used, otherwise we'll end up with columns that are useless. Maybe fixed gutters in nested grids should be divided by their nested level, i.e. the default 20px > 20px > 10px > 5px > 2px (if we go that far)?

3) The 1440px/90em breakpoint and max-width is a bit of a concession to those odd people who browse full screen on 27" monitors - we want to use as much of the screen as possible, without it being ridiculous, but at the same time don't want to make everything very spaced out by not having a max-width. 1440px/90em is a bit of an arbitrary number though, to fit our Macbooks, and if we can't compensate for that larger size with larger fixed gutters, then a smaller max-width is probably a safer bet, design wise.

[papafed]

I've been exploring the thorny problem of making everything line up properly with paddings and margins, and after trying lots of things, and looking at other grids, such as Foundation, I've come to the conclusion that for total reliability the only way to do this is to retain the margins on the first and last columns in the row - as per Foundation.

So for example, let's assume a 20px gutter width. We have our max-width of 1152px, but we still need to retain our 10px left and right margins on each column, including the first and last. This means the width of the visible content would actually appear to be 1152 - 20px = 1132px. We're stuck with this because of the need to centre the grid using "margin: 0 auto" On mobile and tablet breakpoints where we use the full width of the screen we can put a negative 10px margin on the rows to counteract this.

With this in mind, should I widen the max-widths by 20px or leave them as is?

[LucPestille-Three]

Widen them by 20px - if the internal gutters are 20px, then the outer "margin" on the visible content should be the same.

[papafed]

I've had initial success in my efforts to make browsers calculate without the margins. I've going to test that further before doing it the foundation way. We might be able to make this work quite well.

[papafed]

Any defined 'always-on' behaviours regarding how we want to make 12 columns break down to 6, or desktop break down to tablet?

I was thinking of implementing some "span-6-if-phone" or "fit-2-if-tablet" silent classes and then we can pick the appropriate ones when we get round to building molecules.

[papafed]

Ahh, George has written a JS plugin that gives us this flexibility and much more. Splendid. Job done.