CSS Grid support

[feross]

CSS Grid support just landed in Chrome, Firefox, Opera, and Safari (including iOS) in March 2017. As automatic updates go out in the coming days, Grid will be at ~72% support by the end of May (by my estimate). There is a polyfill to get support in IE9+.

CSS Grid is way more useful than Flexbox in my experience. Since Flexbox is part of core, I'd like to see Grid added as well. Or, rather than bloat core by adding classes for CSS Grid, we could remove Flexbox from core and make both Flexbox and CSS Grid into optional add-ons.

Thoughts?

(Related issue: #343)

[mrmrs]

Have been noodling on this quite a bit and like most things in my life, feel conflicted. I really like airing on the side of accessibility (in this case in the form of access to non broken ui) - while it is in evergreen browsers there is also a lot of red there from my perspective. For me even 1% of users is still enough to worry about when considering the scale of the internet.

I still don't know how I feel about flex box being in core either. I will definitely create an add on optional module for css grid - because while I have my beliefs about how I like to approach building the web, I don't believe everyone has to share my beliefs.

This is in line with my general thoughts lately about Tachyons and the conflict I currently have internally about where to take the project in the future. As I built tachyons for myself to solve my own problems and absolutely never expected more than 20 people to use it - my general philosophy has been to not include things that I don't constantly use myself. But as the project grows I've been wrestling with whether or not to bend to the wishes of many of the awesome users utilizing tachyons even if I disagree with them. And opens up a larger point of if I should just let go of the project and have people from the community maintain it / contribute more. The only hesitation I have here is that I don't know if Tachyons would have ever come into existence if I listened to smart and awesome developers in the first place :) But recognizing that as more people use Tachyons I emotionally feel a larger obligation to let it fit their needs and recognize I can start a new project no one uses that reflects what I want / need in a css toolkit.

Sorry for the long slightly unrelated response. This has definitely been weighing on me of late as I see more and more companies adopting Tachyons. Definitely interested in community thoughts.

[feross]

@mrmrs As a maintainer in a similar situation, let me say: I feel you! Speaking from experience, I suggest that you focus on what you want the project to be. If you start going down the path of merging features due to pressure, then you will (1) get a less cohesive, curated product (which is why people came to tachyons in the first place) and (2) stop having fun (which can lead to burnout and feelings of guilt).

Personally, if you don't use Flexbox, I would consider removing it from core. You can add interested contributors to that repo and let them go wild. It's a win-win.

I say: make tachyons whatever you want it to be. The big companies have sufficient resources already -- they can fork their own internal version if they don't like your decisions. That happens all the time with my project standard. Your resources -- your passion, your time, your ideas -- are the most valuable resource here.

Rock on! 🎸

EDIT: I'm still interested to see how you'd do Grid in a tachyons-style way, if you ever get the time. But no pressure to put it in core, or to do it at all. Cheers! ❤️

[mogsie]

I had a stab at this and ended up with something that seems somewhat usable, although my mnemonics approach might need some work.

• display: grid → dg, dg-ns dg-m etc

Some prefixes for column start/end:

• grid-column-start → gcs, gcs-ns etc
• grid-column-end → gce etc
• grid-column-start: span → gcss
• grid-column-end: span → gces

Same for row:

• grid-row-start → grs
• grid-row-end → gre
• grid-row-start: span → grss
• grid-row-end: span → gres

So for example gre4 becomes grid-row-end: 4 while gres4 becomes grid-row-end: span 4.

I haven't followed through with gaps in my prototype, but I imagine a few gaps would be useful too:

• grid-gap → gg
• grid-row-gap → grg
• grid-column-gap → gcg

Gaps would probably be most useful if they took the same scale as padding, so perhaps grg1 becomes var(--spacing-extra-small) in scss terms.

In actually defining the grid itself, I found that it is probably most common to write custom CSS to define the grid widths, because the grid itself is often a mix of fractions and minmax expressions. It's possible to define some grid-template-columns that e.g. repeat 1fr 6 times (to get a simple 6-column layout).

This gives us something like this (with the usual -l and -m and -ns modifiers):

<article class="dg-ns my-custom-grid-definition gg2 gg3-l">
  <h1 class="gcs1 gcs2-l gces4 gces5-l">Something here</h1>
  <div class="gcs1 gces3">
    <p>There be dragons</p>
    <p>There be dragons</p>
  </div>
</article>

my-custom-grid-definition would define the grid, something I'd have to do myself of course, not part of tachyons. The custom grid definition could be implicitly responsive (i.e. have different declarations for different breakpoints) or it could be atomic, requiring me to specify which layout I want at different breakpoints. This is up to the customization of course.

This completely ignores named areas, as they would be pretty hard to provide in a generic framework, I believe.

My prototype uses sass, and a tiny excerpt is below (showing only dg and grs5 variations):

.dg {
    display: grid;
}
/*...*/
.grs5 {
    grid-row-start: 5;
}
@media #{$breakpoint-not-small} {
    .dg-ns {
        display: grid;
    }
    /*...*/
    .grs5-ns {
        grid-row-start: 5;
    }
}

@media #{$breakpoint-medium} {
    .dg-m {
        display: grid;
    }
    /*...*/
    .grs5-m {
        grid-row-start: 5;
    }
}

@media #{$breakpoint-large} {
    .dg-l {
        display: grid;
    }
    /*...*/
    .grs5-l {
        grid-row-start: 5;
    }
}

One glaring problem is that this doesn't work with an unlimited number of columns. And as the number of supported columns (or rows) increases, so does the size of this file.

[mogsie]

/cc @dangayle FWIW (ref #343)

[bluestrike2]

@mogsie It looks like you've put a lot of effort into figuring out a viable approach. I was thinking about how one might go about this a while back as well. Once I started into the mental planning phase, I realized that I was making a mistake. I think you've done the same. And if I'm being completely honest, I don't see easy solutions for (1) where to go from here or (2) how to implement an agnostic, flexible CSS Grid solution with fallbacks that can be used in a framework.

CSS-based grids have always been kind of hack-ish using wrappers and widths to push things around. CSS Grid, on the other hand, is kind of radically different. The grid layout is defined in CSS. No need for rows and other extraneous markup hacks to make it all work: your markup doesn't create the grid, so you wind up with a far more rigid separation of layout and markup. Done right, CSS Grid means less CSS and not more, including media queries.

Recreating that in markup is just duplicating what CSS Grid already does. One article (You do not need a CSS Grid based Grid System - Rachel Aaron) on this subject had a very poignant conclusion:

If you limit yourself to what has gone before, by only using the parts of Grid that you can recreate in older browsers, or by using some framework that is limiting itself, you miss out on the creative possibilities of using Grid. In that case why bother? You may as well use the legacy code only, and that would indeed be a shame.

A couple others: The benefits of learning how to code layouts with CSS; The future of layout with CSS: Grid Layouts. The general direction seems to be that to fully take advantage of CSS Grid, we'll wind up hand-coding CSS layouts. Which is a good thing. In truth, it'll be likely more flexible and probably even more efficient when you consider how you need fewer media queries, markup changes to support layouts, etc. But that's still radically different.

This isn't going to make frameworks obsolete. They're still useful as hell. But once people quit trying to recreate legacy stuff with CSS Grid (I'm assuming there were more than a few moments where you wanted to pull your hair out), frameworks will probably wind up divorcing components from layout as much as possible.

Tachyon's components fit into a couple categories, IMO. You have what are effectively full-page layouts with the articles or 404 pages, and some others like cards that definition lists that are effectively layout and grid agnostic. Plug and play.

Those components are items that get placed on a grid. Right now, some use existing float grid components internally. Most can be redone with flexbox, which can still be--and should be--used with CSS Grid to take advantage of their differences. They can compliment each other.

The trickiest part, IMO, is that CSS Grid is absolutely going to change how frameworks are written. That's going to make things harder on framework developers, but it could end up making things even easier on front-end developers. Whether Tachyon should go in that very different direction is @mrmrs's call.

[mogsie]

Thank you for your thoughful response @bluestrike2, it's exactly the type of feedback I was hoping for. I don't see atomic css in general or tachyons specifically as a "framework" per se, more a technique with a particular implementation. It allows me to express the style of an element in the very element definition.

I didn't pull my hair out implementing a standard story layout using this atomic CSS approach. Supporting IE10 was a bit difficult, however. Doing CSS grid in this way does have a few limitations, and that's probably why I'm spending so much time here, to try to see if those limitations are worth it, and if it should just be documented explicitly as no this shouldn't be done as part of a standard tachyons thing, for these reasons: or something like that.

The limitations I've hit upon are:

• If Tachyons defines any grid, it would be a bland, generic 12-column one probably. Very much "against" the spirit of CSS Grid. Probably each project would want to define its own grids; possibly in an atomic and responsive way, just not use any predefined grid from this project.
• It is highly unlikely that tachyons can define any grid areas with names, since names are so open ended.

When it comes to supporting IE (with display: -ms-grid etc) you're effectively limiting yourself quite a lot, since the common denominator, this means:

• explicitly specifying start columns/rows and end spans for every item, not relying on auto-filling or grid-row-start: span 2
• defining additional rows and columns tracks for grid gaps. This means explicitly defining all the grid rows you might possibly need.

I do see value in defining cross browser (CSS Grid + -ms-grid) classes that try to gloss over these limitations, and make use of actual grid support in about 72% of browsers (a lot of the remaining 28% are mobile phones where a fallback should be more than adequate). However, I don't think that it's in Tachyons' interest to include these in the base set (especially given the -ms- grid gap hack).

Example code

/* define the track (IE10+ gets a 1rem grid-gap) */
.my-custom-columns {
  -ms-grid-columns: 8rem 1rem 1fr 1rem 33%;
  grid-template-columns: 8rem 1fr 33%;
  grid-gap: 1rem;
}

.grid-row-2 {
    -ms-grid-row: 3; /* row 3 is "actually" row 2 due to grid-gap hack */
    grid-row-start: 2;
}

.grid-row-span-2 {
  -ms-grid-row-span: 3; /* Needs to span the grid gap too */
  grid-row-end: span 2;
}

Using this approach it's feasible to re-use the grid-row-span-2 type across various projects, but leave the actual grid definition (my-custom-columns) in the project itself (it's just harder to re-use it).

I vote for closing this issue, or perhaps documenting in the README why it's not such a great idea.

[Boscop]

Does this css framework currently support IE8+?

[ShaggyDude]

css grids are the future and the 12 column thing will be a thing of the past. That said IE will continue to slow up progress for some years to come. Just chiming in. I am opting to start using grids now minus gaps because IE.

[vincentdesmares]

Css grid is now handled by 88.17% of the browsers. See https://caniuse.com/#search=css-grid.
Should we start working to integrate it to tachyons?

[mogsie]

@vincentdesmares I'd be interested in your thoughts regarding the comments from September 2017. Adding grid to tachyons is only partially useful IMHO. Defining grids is probably something that is hard to do in a functional way that is reusable for everyone. It is possible to define grids in a functional manner, I still haven't seen how one would do that in a reusable manner, especially when it comes to template definitions, area names etc.

[vincentdesmares]

Sorry @mogsie, after reading all the comments of the thread I realize that it's indeed very difficult to find a pertinent implementation of css-grid for tachyons.

I 100% agree on your answer from Sep 11, 2017. Why one would use a 12 column css-grid layout instead of a float-based? Because css-grid provides a very useful way to place an element wherever it's needed. Providing classes that do that would mean, as you said, that you would end with row X columns X window-size X properties classes. Which would bloat tachyons.

After thinking a bit more about, I guess tachyons could still be useful for smaller use-cases, for example an out-of-the-box "header". But that would go against the tachyons way of composing generic styles. Those classes would be only useful in the very core of their promise.

I think, after a few tachyons users will start to use css-grid, a few new abstractions will appear as easily re-usable and could be added as modules. But I agree that, right now, there is no good use cases to include css-grid in tachyons core.