grid type

[PavelLaptev]

What do you think about the $grid type for design tokens? In web development, we often use grids, but I'm wondering if it could also be helpful for other developer areas like iOS/Android.

CSS grid — https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout Swift UI — has the grid concept https://developer.apple.com/documentation/swiftui/grid Android API — https://developer.android.com/reference/android/widget/GridLayout#attr_android:orientation

Figma API — https://www.figma.com/plugin-docs/api/LayoutGrid Penpot implementation — https://community.penpot.app/t/sneak-peek-on-upcoming-penpots-grid-layout-plus-flex-layout-combo/3027

Here are my proposals. The first one is good to provide only one direction per token, which could be not so good, because there could be row and columns at the same time:

GridToken {
  $type: "grid";
  $value: {
    direction: "row" | "column";
    count: NumberTokenI;
    gap: DimensionTokenI | string;
    margin: DimensionTokenI | string;
  };
}

And the most universal, but not so elegant approach:

GridToken {
  $type: "grid";
  $value: {
    columnCount?: number;
    columnGap?: DimensionStringType;
    columnWidth?: DimensionStringType;
    columnMargin?: DimensionStringType;
    rowCount?: number;
    rowGap?: DimensionStringType;
    rowHeight?: DimensionStringType;
    rowMargin?: DimensionStringType;
  };
}

Any thoughts?

[TravisSpomer]

What's an example of where you'd see yourself using a grid design token? I'm struggling to see how this fits in.

[PavelLaptev]

In order to create grid layouts. If you're asking about my personal usage, so I use for grid layouts and in media queries. But I also have a breakpoint property here:

$grid-desktop-breakpoint: 1440px;
$grid-desktop-padding: 50px;
$grid-desktop-columns: 12;
$grid-tablet-breakpoint: 1024px;
$grid-tablet-padding: 40px;
$grid-tablet-columns: 12;
$grid-mobile-breakpoint: 620px;
$grid-mobile-padding: 20px;
$grid-mobile-columns: 6;

I also have an article about building CSS grid system https://dev.to/pavellaptev/simple-grid-system-with-subgrid-classes-2f44

[TravisSpomer]

Sorry, to rephrase, why would you do this with design tokens instead of just writing grid properties in CSS? Everyone here knows what grid layouts are and why they're useful, but I want to hear more about why you would like to express them in design tokens. How would writing grid layouts in design token JSON help you improve consistency between platforms or get designs from design tools to code more efficiently or eliminate tedious repetition?

[PavelLaptev]

Yes, good question. I think in general, it should help to align all platforms that are using grid layouts. Personally, I just want to have a standard type for it, so tools like Style Dictionary, could be aware about this type and I don't need to write additional modifiers. Right now, I just want to see reaction on the proposal. I think if people didn't ask it before, might be it's not needed right now. But it's good to have an issue for it.

[renatewr]

Hi all 👋🏽 . I stumbled across this issue because I am researching how we can use design tokens to handle different grid layouts just based on design tokens/css variables. I work at a large publisher/media company with over 100 publications and we have 4 different "themes", and in some cases the grid column numbers could be different across themes, in one specific component. So the regular spacing system would not solve our needs. So different themes is a use case where grid-layout tokens would be very useful.

[ilikescience]

My initial thought when seeing new token type proposals is to ask: can this be solved with groups? eg, without using a new token type, you might have this:

{
  "grid": {
    "columns": {
      "count": {
        "$type": "number",
        "$value": 12
      },
      "gap": {
        "$type": "dimension",
        "$value": "10px"
      },
      "width": {
        "$type": "dimension",
        "$value": "100px"
      },
      "margin": {
        "$type": "dimension",
        "$value": "20px"
      }
    }
  }
}

I think this still captures the spirit of the design decision; you could even add more context in $description props. If there's value in having the translator "know" that these values should be used to calculate, say, css grid syntax, perhaps that's just a configuration of the translator rather than explicit in the token itself. Eg:

generateCssGridSyntax({
  columnCount: tokens.grid.columns.count,
  columnWidth: tokens.grid.columns.width
}); 
// outputs something like
//  grid-template-columns: repeat(12, 100px);