Specify columns widths using absolute or percent units

[kavanagh]

So we have

<div data-o-grid-sizing="5 S12 XL3">

Where 5, 12 and 3 are specifying column widths. And by using these numbers we are specifying a width relative to a total amount of columns, let's say in our case it's 12.

So 6 is 50% of a 12 column grid.

But what if we change the total number of columns to be 16? Must we change all references from 6 to 8.

Would it be better to use a number system that more directly expresses the width of the element as a percentage of it's parent's column width?

So the html above could become

1.

<div data-o-grid-sizing="50 S100 XL25">

or 2.

<div data-o-grid-sizing="0.5 S1 XL0.25">

or 3.

<div data-o-grid-sizing="5 S10 XL2.5">

or something similar?

[triblondon]

This is an approach favoured by the CSS wizardry framework, but bear in mind that we are not reading the numbers and processing them using maths, we're just doing string matching, so the range of options has to be finite. Fractions expressed as decimals are therefore probably not workable.

We could have the CSS wizardry approach of 'one-fifth', 'two-eighths' etc, but that involves having a lot more selectors. With a 12 col grid, you can concisely do halves, thirds, quarters, or sixths, without all the extra syntax. I think we should stick with that.

[kavanagh]

Another related note here would be that it's restrictive to have the total amount of columns as a constant throughout your app.

For example it should be possible to use a 12 column grid on some elements of a page and a 16 column grid on other elements. Being able to mix grids in this way can be useful. I needed this recently and had to abandon my chosen grid solution because the column width was a constant.

[kavanagh]

Just an idea to illustrate what I'm talking about...

Given a grid row such as:

<div data-o-grid-row="12 S1 M1">
   <div id="col-a" data-o-grid-column="0.4 S1"></div>
   <div id="col-b" data-o-grid-column="0.6 S1"></div>
</div>

I can see the row is 12 columns wide and #col-a is 40% of that. #col-b is 60%. On small screens the row is 1 columns wide. The rows are 100% of that.

The data-o-grid-row attribute is the default value, there would be no need to add this attribute for normal grid rows. It just shows that the default, all rows are 12 columns wide (on 'normal' width viewports) and 1 column wide on small viewports. The data-o-grid-column attribute defines how to set columns widths within that row.

However if you wanted to override the column width of a row from 12 (on normal) and 1 (on small) then you could do something like this.

<div data-o-grid-row="16 S2">
   <div data-o-grid-column="0.4 S0.5"></div>
   <div data-o-grid-column="0.6 S0.5"></div>
</div>

So for this row the grid is 16 columns wide and two columns wide on small screen. The columns are still proportionally the same width but as the total amount of columns has changed they are are physically different width.

[triblondon]

As I understand it the design team has decided on a 12 column grid as a standard. I'm not unsympathetic to the idea of having a more flexible system - in fact, it would be great to be able to have flexbox-like flexibility with grid-like responsiveness, but I want to move on and I don't think we need that right now.

Also, the syntax you've suggested would be fiendishly hard to support using regular CSS, which ultimately the SASS has to compile to, and I suspect we'd have to have trillions of selectors to cover all possible permutations.

Nothing is compelling you to use the FT grid, so I'd like to do it like this, and then assess case by case where product teams feel they need to use something else, to see how we can either amend the grid to support them, or convince them to alter their requirements so we can all use the same grid (or indeed they could go their own way).

[wheresrhys]

As I understand it the design team has decided on a 12 column grid as a standard.

Speaking to Paul before christmas he was disappointed that each nested level of the grid resets columns to be 1/12 of the nested element's container. So the original request for 12 columns was likely based on an implicit assumption that the 12 columns would be a page-wide thing that all elements could be snapped to. o-grid doesn't meet this requirement and afaik most css grids don't.

However he did acknowledge that being able to divide e.g. a container that spans 7 columns into 2 or 3 equal columns would also be a requirement, and that this isn't possible using a canonical, page-level 12 column grid. It may be possible to meet both requirements... maybe some other grid already manages to?

What Luke wants could be achievable, and some of it probably quite easily. There could for instance be variables (all defaulting to false) such as

• $o-grid-percentage-widths: 33.3333 66.666667 0.2 which generate extra column width selectors (probably very easy to implement)
• $o-row-width-variants: 12 5 which generate extra sets of rules for what percentage value e.g. [..~="3"] evaluates to (more work, and other than syntactic convenience, may not even add any functionality above and beyond the previous bullet)

The above would all be unavailable to module developers

@kavanagh you were using column in the data attribute in your example. Does mean this gets your vote for the attribute name? I think your idea is a good example of how sizing could turn out to be too unspecific a term

[triblondon]

being able to divide e.g. a container that spans 7 columns into 2 or 3 equal columns would also be a requirement, and that this isn't possible using a canonical, page-level 12 column grid

Why not? 2 and 3 both divide into 12, so in your 7-span container, you set up a new grid row with 6-6 or 4-4-4.

I think Luke's point in using column was to distinguish from the row rule that he added. But I would think we would continue to mark a row container using an o-grid-row class.

Anyway, what you'e talking about are additional features that don't negate the currently agreed featureset, but instead add to it, so I'd be prepared to consider adding this in future, just not right now. I have to balance the desire for a million different features with other developers who fundamentally hate grids and will kick up a holy stink over anything that's a byte larger than it absolutely has to be. There's also the ease of use issue - there's a cost to making something ever more configurable, in that it becomes ever harder to actually understand how the bloody thing works.

I'll happily keep this open but I really want to move on from grid ASAP.

[wheresrhys]

you set up a new grid row with 6-6 or 4-4-4.

but then within that row you're no longer to align to the page-level 12-columns. Hard to describe, easier to show some time on a piece of paper.

Back to Luke's idea, if the grid as we know it was built using a mixin (wouldn't need much work on top of what's already in there)

$o-grid-default-selector: null !default;
$o-grid-default-column-count: 12;

@mixin createGrid(
    $selector: $o-grid-default-selector // name of the class or fragment of data-o-row that wraps this grid
    $numberOfCols: , $o-grid-default-column-count// n
    $includeSizingSelectors: true, // true includes all from 1 to n, false includes none, or a list of integers can be specified
    $includePercentSelectors: null // list of percentage sizes to include also
)

The first two params would allow any number of configurations for not much effort. The behaviour for the 2 last parameters needn't be implemented immediately either so could be earmarked for later depending on if there's demand for it. For Luke's proposed responsively switching between grid definitions we could emit warnings that (S|M|L|XL)?\d+ are reserved words in the $selector parameter but other than that leave it completely for now.

[kavanagh]

Anyway, what you'e talking about are additional features that don't negate the currently agreed featureset, but instead add to it, so I'd be prepared to consider adding this in future, just not right now.

@triblondon Sure thing. Rhys was eliciting feedback for v2, hence why this is under the v2 milestone. Not sure of the scope of v2. Fully understand wanting to move on at this point.

@wheresrhys No, that wasn't a vote for a particular attribute naming convention. I wrote that before I read issue #24. I'll leave my tupence on that issue.

[kaelig]

I gave a go at solving this problem by having human friendly colspans: https://github.com/Financial-Times/o-grid/blob/refactor-mqs/src/scss/_main.scss#L80

Let me know what you think!

[kaelig]

Please find the documentation of the human friendly keywords here: https://github.com/Financial-Times/o-grid/tree/refactor-mqs#using-keywords