Code als Dokumentation: Neue Strategien mit CSS Grid

Ich arbeite für Supercool, eine schnelllebige Designagentur, die maßgeschneiderte Websites für Kunstkunden erstellt, angetrieben vom Standard-System Craft CMS; es ist High-Spec-Grafikdesign mit relativ anspruchsvoller Typografie und Kunstregie. In den letzten Monaten haben wir auf CSS Grid umgestellt. Wir gehen den Übergang langsam an, damit wir neue Paradigmen und Designmethoden entdecken können, anstatt alte Gewohnheiten einfach in eine neue Syntax zu übertragen.

Bisher haben wir eine Reihe wirklich nützlicher Strategien zur Layoutverfolgung entwickelt. Ich habe ein paar überraschend raffinierte Mixins mit benannten Bereichen und Vorlagen geschrieben und wir sind auf einige grundlegende Konventionen gestoßen, um hochlesbaren Code zu erstellen. Ich dachte, es wäre wertvoll, eine vollständig entwickelte Produktionsimplementierung einer einzelnen Hauptkomponente mit Grid zu durchlaufen, einige der auftretenden Designfragen zu erörtern und Sie von einigen Fallstricken fernzuhalten, auf die wir gestoßen sind. CSS Grid ist eine große Spezifikation mit vielen möglichen Ansätzen und vielen richtigen Wegen, Dinge zu tun, aber irgendwann muss man seine Methode festlegen und sie live schalten.

Ich erwarte grundlegende Kenntnisse in CSS, Sass, BEM und Interesse an der Aufgabe, vollständig realisierte, zugängliche, benutzerdefinierte Frameworks mit über 50 Komponenten aus Sketch oder Photoshop-ähnlichen Dokumenten in einem engen Zeitrahmen (z. B. einer Woche) zu prototypisieren.

Zuerst identifizieren und trennen wir das Design in verschiedene Coding-Aufgaben und planen, wie wir sie angehen werden.

1. Typografie: Der Designer hat bereits ein Typographiesystem definiert.
2. Farben: Zuerst erstellen wir ein Theme-Modell und binden dieses dann in das Partial ein.
3. Inhalt: Welche Elemente sind in diesem Block? Was sind seine Variationen? Hier kommt unser BEM-Mixin zum Einsatz.
4. Layout: Hier wird der Inhalt im Block platziert. Möglicherweise möchten Sie hier direkt hinspringen.
5. Konventionen: So entscheiden wir uns, all das Obige zu schreiben. Es gibt viele richtige Antworten in CSS, daher ist es wichtig, dass wir uns alle auf eine Konvention einigen, die Verkehrsregeln. Dies kommt wirklich zuerst, aber der Einfachheit halber werden wir hier enden.

Typografie-System

Wir verwenden Utility-Klassen (z. B. h-text--h1, h-text--badge) für Typografiestile. In einem Projekt kann es hundert Typografiestile geben. Wir exportieren diese Stile von Sketch direkt in unser Patternlab mit Typex. Das ist ein ganz anderes Thema für sich, also legen wir fest, dass Typografie behandelt wird. Wir werden Typografie nicht in unser Komponenten-Partial einbringen.

Farbverwendung

Siehe den Pen
CSS Variable fallbacks mixin v2 von limograf (@Sally_McGrath)
auf CodePen.

Theming sind ein paar winzige Mixins, die eingefügt werden, so dass wir idealerweise nicht viele Farbregeln in unserem Partial sehen werden. Wir speichern sie alle zusammen in einem _themer.scss Partial in unserer "Mixins and Models"-Bibliothek, so dass wir sicher sein können, das Designsystem der Website zu befolgen. So haben diejenigen, die später an dem Build arbeiten, ein Schlüsselreferenzial, das die Design- und Branding-Regeln beschreibt. Beim Erstellen und Pflegen zahlreicher Websites in einem ähnlich ausgerichteten Markt – aber jede mit unterschiedlichen Markenanforderungen – müssen Sie sicherstellen, dass Sie nicht eine Marke mit einer anderen verwechseln! Also, ähnlich wie bei der Typografie, abstrahieren wir die Farbregeln vom Partial. Im Wesentlichen betrachten wir in unserer _header.scss-Datei nur das Layout (soweit wie möglich).

Da wir uns einig sind, dass die Konvention immer das Theming über unser Mixin ist, wird es so in ein Element eingefügt:

@include var($property, $value);

Dann setzen wir ein Theme-Modell, wie Farben auf dieser speziellen Website funktionieren und wenden dieses Theme mit folgendem an eine Komponente an:

@include theme;

Hier ist das Beispiel-Theme-Modell, das wir für diese Seitenüberschrift verwenden werden. Es ist super einfach.

Siehe den Pen
Theme-Modell von limograf (@Sally_McGrath)
auf CodePen.

Wir kombinieren eine Farbe mit Schwarz oder Weiß. Wir verlassen uns auf eine Kontrastregel und kehren sie um, um Akzente zu setzen, vielleicht bei Ereignissen, wie Hover, oder einem hervorgehobenen Call-to-Action. Das ist alles, was wir tun müssen, um das zu erreichen, und jetzt haben wir ein Dokument darüber, wie Farbe wirklich auf dieser Website funktionieren soll. Wir können darauf zurückgreifen, wenn wir die UI debuggen oder erweitern müssen.

Wir wollen auch die Vererbung vorbereiten, um uns zu helfen, also identifizieren wir einige hilfreiche Konventionen:

• Setzen Sie die Füllungen von SVG-Icons in Ihrer Pipeline auf currentColor (und standardisieren Sie sie in CSS auf width: 1em; height: 1em; font-size: inherit;, während wir dabei sind).
• Setzen Sie <body> und <a> auf currentColor) als Basis.
• Schreiben Sie Kurzschriften, erben Sie Ränder (z. B. 1px solid oder 1px solid currentColor).

Mit diesem Theme-Modell können wir eine beliebige Anzahl von Themes generieren, vielleicht als Utility-Klassen speichern, über eine Liste von Modifikatoren innerhalb einer Komponente iterieren oder den Benutzer einfach Variablen direkt auf dem Block im CMS festlegen lassen. Wenn IE 11 unter 1% in unseren Statistiken fällt, können wir mit Variablen viel mehr tun, aber für unsere aktuellen Zwecke ist das genug.

Lassen wir uns nicht ablenken. Was ist mit Grid?!

Inhaltskomponenten

Grid ermöglicht es uns, auf neue Weise genau zu beschreiben, welche Inhalte wir in jedem Partial haben. Es ist wirklich ein Game Changer für Designagenturen, die für jedes Projekt neue UIs entwickeln, und wir entdecken neue (und unterhaltsame) Anwendungen dafür, während wir sie erforschen.

Zur Kontextualisierung: Wir passen jede Benutzeroberfläche für unsere Kunden individuell an, mit benutzerdefinierten Feldern, die auf ihre spezifischen Bedürfnisse und ihr Inhaltsmodell zugeschnitten sind, mithilfe von Craft CMS. Wir haben interne Tools, die Events von Ticketing-APIs abrufen und Einträge aus diesen Daten erstellen, die dann bearbeitet und erweitert (oder vollständig erstellt) im CMS werden können. Der Kunde kann benannte Felder in permanenten Seitenbereichen ausfüllen oder bearbeiten und auch ganze gestaltete, gebrandete Inhaltsblöcke in das Layout jeder Seite einfügen, während er sie erstellt.

Es gibt viel UI. Die Kunden haben viel Kontrolle über den Inhalt und wir viel Kontrolle über das HTML, sodass wir einen hohen Standard an zugänglichem, semantischem Code auf der Seite gewährleisten können. Wir entwickeln das Inhaltsmodell gemeinsam während der Recherche und lassen sie dann mit der Inhaltserstellung loslegen. Sie fügen hinzu, was sie wollen, und wir stellen sicher, dass es funktioniert und immer richtig aussieht. Besser als richtig! Super. (Entschuldigung! :P)

Als Entwickler muss ich konkurrierende Prioritäten abwägen:

• Zugänglichkeit, Benutzerfreundlichkeit
• Branding und Grafikdesign
• Leistung
• Wartung und Codebase-Gesundheit

Betrachten wir diese nacheinander.

Barrierefreiheit (Accessibility)

Zugängliches, logisches HTML ist meine Leidenschaft. Mindestens erwarte ich eine grüne Barrierefreiheitsbewertung bei Lighthouse für meine Projekte. (Wen mache ich was vor, ich will die köstlichen 100!) Kernpfade und Seiten werden mit ein paar Screenreadern getestet, der Tastaturtabulator, Tastaturnavigation), Low-Vision-Simulatoren, Dasher, Sprachzugriff und binärer Schalter. (Ich arbeite auch für Robots and Cake, daher ist dies ein großer Teil meiner Entwicklung.) Ich füge immer wieder riesige klickbare Telefonnummern und E-Mail-Adressen zu Seiten hinzu. Ich möchte einfach, dass die Leute dorthin gelangen, wo sie hinwollen.

Ich habe mir Sorgen darüber gemacht, wie Inhalte mit Grid (und Flexbox) neu geordnet werden können. Nachdem ich jetzt ein paar Builds durchgemacht habe, denke ich tatsächlich, dass Grid uns bei diesem Problem helfen kann. Mit CSS Grid gibt es keinen Grund mehr, das HTML im Dienste des Layouts zu verschieben. Wir können wieder damit beginnen, das gesamte Dokument als eine logische, lineare Sequenz zu betrachten, als unsere erste Sorge.

Branding vs. Leistung vs. Wartung

Kunstveranstaltungsorte erfordern High-Spec-Grafikdesign, das über Druck und Web einheitlich ist, und haben ständig wechselnde Materialien (z. B. Programme, Broschüren, Tickets, Poster, Microsites usw.), die sie ihren Zielgruppen zugänglich machen müssen, einschließlich vertraglicher Marketingverpflichtungen, die erfüllt werden müssen. Wie Sie sich vorstellen können, haben wir viele hochwertige große Bilder, denen wir Priorität einräumen müssen und die normalerweise ein starkes, druckorientiertes Branding aufweisen. Das bedeutet, dass wir möglicherweise etwa fünfzehn benutzerdefinierte Schriftarten (einschließlich Gewichtsvariationen, Display-Schriften usw.) und komplexes CSS auf der Seite ausliefern. Wir müssen uns so schlank wie möglich halten. Wir liefern derzeit CSS mit etwa 20 KB nano Gzipped aus, aber ich arbeite daran, es weiter zu reduzieren.

Wir behalten jedoch die Grid-Bereichsnamen vollständig bei, indem wir reduce identifiers auf false setzen. Es ist weitaus nützlicher, die Layout-Karten in DevTools verfügbar zu haben, als diese wenigen Bytes zu sparen. Für die Wartung, Selbstdokumentation und im Interesse Ihres zukünftigen Selbst, das diese Website ohne Repository-Zugriff in einem verspäteten Zug in Sowerby Bridge debuggt: Bewahren Sie die Karten auf.

Code-Gesundheit

Der Weg, all diese konkurrierenden Bedürfnisse auszubalancieren, besteht darin, Konventionen zu artikulieren und sich darauf zu einigen, damit beim Testen weniger behoben werden muss und gelöste Probleme gelöst bleiben. Wir untersuchen alle Komponenten, die wir erstellen, und stellen sicher, dass sie immer mit einer Überschrift beginnen, dass Links irgendwohin führen und Schaltflächen Aktionen auslösen, dass zählbare Objekte als Liste geliefert und einer Landmarken-Überschrift vorangestellt werden, dass Navs <nav> sind und Zeiten <time> sind und Div-Suppe zum Frühstück gegessen wird – die Grundlagen.

Mit CSS Grid gibt es keine Entschuldigung, das HTML im Dienste des Layouts zu verschieben. Ihr Inhalt kann immer logisch fließen, während Layout-Änderungen in CSS erfolgen. Und da keine Ränder oder Abstände für die Erstellung von Rinnen erforderlich sind, können Sie einfach

.o-grid .o-grid { width:100%; }

...deklarieren, um sicherzustellen, dass eine beliebige Anzahl von verschachtelten Gruppen visuell denselben Seitenraster einnimmt. Das HTML kann ein klarerer Leitfaden dafür sein, was Dinge wirklich sind: ein näher liegendes Dokument.

Siehe den Pen Semantische zugängliche Strukturen sperren von limograf (@Sally_McGrath)
auf CodePen.

Es gibt viel zu verwalten zwischen der Überschrift und der Aktion, und es ist meine Aufgabe, all diese Felder in all diesen Komponenten im Auge zu behalten und sie traversierbar, scannbar, linearisierbar und in irgendeiner logischen, verständlichen Weise leicht lesbar zu machen, während ich sicherstelle, dass ich die Designvorgaben treu umsetze.

Lassen Sie uns mein erstes, überraschend nützliches Grid-Mixin einführen.

@mixin template($elements...) {
  @each $element in $elements {
    &__#{$element} {
      grid-area: $element;
    }
  }
}

Die universelle Verwendung dieses Mixins bedeutet:

1. Jedes Komponenten-Partial beginnt nun mit einer Liste aller möglichen Elemente, was ein sehr praktisches Dokumentationsstück ist, insbesondere beim Twiggen der tatsächlichen Front-End-Komponente.
2. Das Mixin kümmert sich um die Zuweisung der Grid-Bereiche.
3. Element- und Komponentennamen bleiben über Sketch, CSS und HTML hinweg konsistent und jede Inkonsistenz wird sehr offensichtlich, da das Layout fehlschlägt. Ich bin fest, aber fair.
4. BEM-Namensgebung wird automatisch erzwungen, aber sie vermischt die Dinge nicht im Partial.

Nun werden wir im Partial einfach grid-template-areas deklarieren, mit normalen englischen Wörtern, was uns eine Reihe von Karten der Layouts gibt, die auch mit den Datenbankfeldern übereinstimmen. Super lesbar!

Hier ist ein Beispiel für dieses Mixin in Aktion:

Siehe den Pen BEM ELEMENT AUTO ASSIGN von limograf (@Sally_McGrath)
auf CodePen.

Wir haben uns entschieden, bei internen Grids bei benannten Bereichen zu bleiben, weil ich einen großartigen Artikel auf dieser Website gelesen habe, der erklärt, wie Autoprefixer Grid für IE 11 handhaben kann, wenn man sich an die aufgeführten unterstützten Eigenschaften hält – und das tut er größtenteils. Wenn Sie diesen Testfall mit angewendetem Autoprefixer im super nützlichen Debug-Modus in einem Browser-Test betrachten, sehen Sie, dass es funktioniert.

Aber es gibt Fallstricke! Sie müssen Inline-Elemente auf Block setzen, um sicherzustellen, dass sie in IE 11 immer als Grid-Zellen fungieren. Kommentieren Sie die markierte Zeile im Beispiel aus, um zu sehen, was sonst passiert.

Autsch! Seien Sie vorsichtig mit diesen Blöcken. Möglicherweise stellen Sie fest, dass einige Versionen von IE 11 diese Korrektur nicht einmal übernehmen. In diesem Fall könnten Sie versuchen, einfach einfache <p>-Tags zu verwenden... seufz.

Ich nehme display: grid nicht in dieses Mixin auf, da es Szenarien gibt, in denen das eigentliche Grid auf einem inneren Container gesetzt wird, wir aber trotzdem möchten, dass die Grid-Bereiche auf der richtigen BEM-Klasse übereinstimmen.

Also

.c-header{ 
  @include template(title, pretitle, posttitle, producer, venue, credit, quote, nav, infobar, search);
}

Legen wir diese Dinger aus.

Layout

Identifizieren wir einige weitere Regeln, um sicherzustellen, dass diese Komponente problemlos in ein Seitenlayout integriert wird. Zum Zeitpunkt der Erstellung gibt es noch kein Subgrid (aber es wird eines geben!), sodass diese Komponente nichts über das übergeordnete Grid weiß, in dem sie sich befindet. Dies passt gut zum BEM-Komponentenansatz – da jede Komponente flach und isoliert geschrieben wird, um die Vererbung zu begrenzen. Ich trete nicht für BEM (oder BEM-ähnlich, wie wir es offensichtlich verwenden) ein – ich sage nur, dass dies ein Bonus ist, wenn Sie es bereits verwenden.

In diesem Beispiel hat der Designer ein Seitenlayout mit einem 12-Spalten-Grid mit 20px (1,25rem) Rinnen, website-weit, ohne versetzte Teile festgelegt. Unsere Komponente ist eine Seitenregion und wird alle 12 Grid-Spalten belegen. In dieser Übergangszeit verwenden wir weiterhin diese Art von festem Grid, da wir eine Fülle von Systemen haben, die noch auf dieser Idee basieren und mit denen wir integrieren müssen. Hier ist also unsere Konvention für diese Bedingung: Für eine Vollbreitenregion entfällt der Grip Gap und schreiben Sie die Grid-Template-Spalten als Bruchteileinheiten (fr) von 12.

Wenn wir die Dinge auf diese Weise tun, bedeutet das:

1. Die Sichtlinien dieses internen Grids folgen grob dem Grid, in dem es sich befindet;
2. die zugrunde liegenden Designregeln sind im Code leicht erkennbar; und
3. es ist einfach, Dinge genau auszurichten, falls erforderlich.

Ein kurzer Hinweis zum "Ausrichten"

Moment mal... was meine ich mit "Dinge genau ausrichten"? Richtet es sich nicht bereits genau aus?

Nun, nein. Der Ansatz mit den Bruchteilen teilt den Raum perfekt auf, sodass Sie in der Rinne landen. Zwei gerade Spalten landen Sie auf halbem Weg durch die Rinne. Zwei Spalten, von denen eine 2/3 und die andere 1/3 ist, teilen sich 1/3 des Weges durch diese Rinne und so weiter.

Es ist nicht gerade schwer, die Ausrichtung zu korrigieren, da wir die Breite unserer Seiten-Grid-Rinne kennen. Bei einer geraden Teilung könnten wir beispielsweise den Grid-Gap einbeziehen.

Allerdings können wir das bei keiner anderen Teilung tun. Was wir tun können, ist, diesen Gap als Margin hinzuzufügen – die Margin wird innen hinzugefügt, unabhängig von der Box-Sizing-Einstellung. In diesem Beispiel haben wir drei Spalten (zwei benannte Bereiche und ein leerer Raum), die unsere Rinne in Drittel teilen.

So berechnen Sie diese Margins: Stellen Sie sicher, dass die Summe der fr-Einheiten 12 ergibt. Teilen Sie den Grid-Gap durch die Anzahl der Spalten im übergeordneten Grid und multiplizieren Sie ihn dann wie folgt:

Der rechte Margin-Multiplikator von n entspricht der Summe der fr-Einheiten rechts von n. Der linke Margin von n entspricht der Summe der fr-Einheiten links von n.

Also, für grid-template-columns mit dem Wert 2fr 3fr 2fr 4fr 1fr:

 2      3      2     4    1 
0/10   2/7    5/5   7/1  11/0

Siehe den Pen Namensspezifikation innen und Zahlenspezifikation außen – Seitenregion, Desktop von limograf (@Sally_McGrath)
auf CodePen.

Man könnte das sogar als Mixin schreiben, wenn man oft calc() schreibt. Etwas wie dieses zum Ausrichten eines inneren Grids am übergeordneten Grid:

Siehe den Pen Inneres Grid automatisch am übergeordneten Grid ausrichten von limograf (@Sally_McGrath)
auf CodePen.

...und etwas wie dieses, um Margins automatisch zu berechnen, wenn der Name innen und die Zahl außen im Grid angegeben wird:

Siehe den Pen Namensspezifikation innen und Zahlenspezifikation außen – automatische Margin-Berechnung von limograf (@Sally_McGrath)
auf CodePen.

Ich bin sicher, Sie können sich andere Lösungen vorstellen, wie z. B. den Wechsel zu benannten Zeilen, das Hinzufügen zusätzlicher Spalten mit fester Breite oder das Schreiben aller Karten mit 12 benannten Bereichen pro Zeile. Es gibt so viele Möglichkeiten, damit umzugehen, aber ich denke, viele davon nehmen den Vorteil von benannten Bereichen weg. Bereiche geben uns eine lesbare Layout-Karte, die das enthält, was unsere zukünftigen Ichs wissen müssen. Es ist Code als Dokumentation.

Um es klarzustellen: Das Designproblem, das wir hier durchgehen, ist kein Ausrichtungsproblem. Ausrichtung ist mit Grid einfach. Die Frage ist nicht, das unmittelbare, triviale Layoutproblem zu lösen, sondern es so zu lösen, dass wir in sechs Monaten zurückkommen und verstehen können:

1. Welche Elemente sind in der Komponente.
2. Wie sie angeordnet sind.
3. Warum der Code auf diese Weise geschrieben ist.

Die Grid-Spezifikation ist riesig und es ist leicht, sich in den Optionen zu verlieren. Vielleicht ist es besser, zu einem 12-Spalten-Grid zurückzukehren und die Zahlenspezifikation zu verwenden (d. h. explizit auf unser Seiten-Grid zu verweisen, das die Zahlenspezifikation verwendet), wenn eine absolute Ausrichtung erforderlich ist – aber ich glaube, es gibt eine klügere, einfachere Lösung, die noch gefunden werden muss. Für diese Website haben wir schließlich ein Seiten-Grid-Objekt geschrieben und ihm verschachtelte interne Grid-Zellen mit Klassen hinzugefügt: .o-page-grid__sidebar.

Was meinen Sie dazu? Ich sehe hier definitiv unterschiedliche Perspektiven. 🤦‍♀️

Ein echtes, live Grid!

Wir können dies verwenden, um eine generische Seitenüberschrift zu erstellen:

Siehe den Pen
01 – Generische Seitenüberschrift von limograf (@Sally_McGrath)
auf CodePen.

Oder wir können eine Variation der Homepage erstellen:

Siehe den Pen
02 – Homepage von limograf (@Sally_McGrath)
auf CodePen.

Was ist mit einer Hero-Überschrift, die aus unserem Container ausbricht? Sicher! Oder wir können sie auch außerhalb des Containers liefern:

Siehe den Pen
03 – Hero von limograf (@Sally_McGrath)
auf CodePen.

Was kommt als Nächstes? Eine thematisierte Veranstaltungsüberschrift mit einer Vollbreiten-Infobar, die fixiert ist, und einem internen Button, der sich mit der Seitenleiste des übergeordneten Grids ausrichtet? Aber sicher. Ich füge ein übergeordnetes Grid hinzu, damit es leichter zu sehen ist:

Siehe den Pen
04 – Veranstaltungsüberschrift von limograf (@Sally_McGrath)
auf CodePen.

Was ist mit einer Suche mit zentraler Ausrichtung? Lassen Sie uns eine Kollapskolumnentechnik verwenden:

Siehe den Pen
06 – Suche mit zentraler Ausrichtung von limograf (@Sally_McGrath)
auf CodePen.

Hier ist eine Demo aller dieser Variationen als ein Partial. Ja, es ist eine Karte! Und das war's!

Konventionen

Puh, wir haben viel behandelt! Aber Sie sehen, wie flexibel und selbstdokumentierend ein solches System sein kann, richtig?

1. Typografie wird mit einem separaten Typografiesystem behandelt.
2. Farben werden von einem Theme-Partial behandelt, das die zugrunde liegenden Farbregeln des Designs beschreibt, anstatt Elemente einfach Ad-hoc zu färben.
3. Elemente werden so genannt, wie sie sind, in englischer Sprache, und als Liste am Anfang des Partials mit dem Template-Mixin aufgeführt. Diese Liste kann als Referenz in Twig oder eine Vorlage übernommen werden.
4. Korrektes HTML wird immer verwendet und Verschachtelung bricht das Grid nicht. Das bedeutet, Sie können eine beliebige Anzahl von verschachtelten Grids auf denselben Layoutbereich anwenden, indem Sie eine Konvention festlegen.
5. Präzise Ausrichtung erfolgt in einer Zahlenspezifikation und nicht in einer Namensspezifikation (aber beachten Sie, dass Ausrichtung mit Namensspezifikation möglich ist).
6. IE 11 wird unterstützt.

Ich habe noch eine kurze Anmerkung und ein weiteres Beispiel für eine Komponente, die mit benannten Bereichen erstellt wurde. In diesem Beispiel sind Karten keine Regionen, sondern Komponenten, die in ein Grid platziert werden, daher gibt es keinen Grund, die fr von 12-Konvention zu verwenden. Sie können erwarten, dass ein Media-Objekt-Partial wie folgt aussieht:

.c-card {
  &--news {
    align-content: start;
    grid-template-areas: 
      "image"
      "datetime"
      "title";
  }

  &--search {
    justify-content: start;
    grid-template-columns: 1fr 3fr;
    grid-template-areas:
      "image page"
      "image title"
      "image summary";
  }

  &--merchandise {
    grid-gap: 0;
    grid-template-columns: $b 1fr 1fr $b;
    grid-template-areas:
      "image image   image   image"
      ".     title   title   ."
      ".     summary summary ."
      ".     price   action  .";
  }

  &--donations {
    // donations thanks button is too long and must take up more space than input
    grid-gap: 0;
    grid-template-columns: $b 1fr 2fr $b;
    grid-template-areas:
      "image image   image   image"
      ".     title   title   ."
      ".     summary summary ."
      ".     input   action  .";
  }
}

// ...