Mobile-first approach to grids (and get rid of o-useragent)

[kaelig]

The current implementation of grids has some great ideas but its main limitation is that it doesn't enable us to add layouts.

Adding a new layout size (for example: adding the XS layout) would result in gaps where "no layout exists", that's where a mobile-first approach comes in to solve this problem makes design changes easier.

Files to review

• src/sass/_variables.scss
• src/sass/_main.scss
• src/js/getCurrentLayout.js: new JS helper to know what layout is currently displayed to the user

  Have a look

• Test demo
• All demos

  Documentation

• New README
• SassDoc

  Sass MQ

A Sass mixin that helps manipulating media queries in an elegant, mobile-first way.

It mainly helps with breakpoint management and could also help with IE 8 Support (read about how the Guardian uses it).

• Documentation
• SassDoc

Let's have a chat about this very soon :) We'd like to ship it in early January and update this list of dependents as soon as possible: next-header o-ft-footer o-ft-forms o-ft-header o-hierarchical-nav o-techdocs.

[AlbertoElias]

/ping @SarahHornsey @danskinner @pauloneillft

[wheresrhys]

Nice work! Maybe use a different name for $o-grid-enable-enhanced-experience though; 'enhanced' is a loaded term these days - in other modules/products it always means the js experience - so it's confusing here to use it to mean 'responsive'

[kaelig]

Good point, @wheresrhys. Let's talk about it on Thursday.

[matthew-andrews]

Hi Kaelig just had another go to try to get this to work in Next.

We previously used extend quite a lot to make some of our elements behave as if they had had grid data attributes. e.g. https://github.com/Financial-Times/next-header/blob/master/src/scss/_base.scss#L11-L13

I had assumed we'd be able to do something similar with mixins, e.g.:-

@include @oGridRow();
@include @oGridColumn();
@include @oGridColspan(12);

But that doesn't seem to be the case… Should we continue expect to do something like this? It's quite nice to keep component's markup simple and not need to have to put the data attributes everywhere. But I can see that doing this makes thing simpler in other ways.

Basically, I've no strong opinions either way but I would like some guidance as to which approach we should move towards.

[kaelig]

@matthew-andrews looks like I need to document this further, because what you describe is entirely doable but I hadn't thought of putting examples in the readme…

// equivalent to data-o-grid-colspan="8 S5 M9"
.el {
  width: oGridColumnWidth(8);

  @include oGridRespondTo(S) {
   width: oGridColumnWidth(5);
  }
  @include oGridRespondTo(M) {
   width: oGridColumnWidth(9);
  }
}

You could also use the oGridRespondTo mixin like this:

.el {
  @include oGridRespondTo($until: L) {
   width: oGridColumnWidth(9); // 9 col wide until L
  }
  @include oGridRespondTo($from: S, $until: L) {
   width: oGridColumnWidth(9); // 9 col wide from S until L
  }
  @include oGridRespondTo($from: M, $until: L) {
   width: oGridColumnWidth(9); // 9 col wide only on M layout
  }
}

Does that help? Let me know if you see additional use cases that I should document, and I'll add them to the README.