feat: Add spacing tokens and demo

[Scotchester]

ℹ️ PR is to base branch feature/dsdl ℹ️

---

Closes #550

This PR adds spacing tokens to the DSDL CSS and adds a chart of them to the demo page.

Review commit-by-commit to avoid seeing some minor cleanup until last.

For discussion at some point

We currently use Bootstrap's spacing utility classes extensively throughout our projects. This new 8px-based spacing system creates a tension with those in projects where we do not use Sass, because there is not a CSS variable for overriding their base $spacer and adding the additional increments we want would require overriding a Sass map.

Generating our own custom spacing utilities would require a massive amount of work to cover all of the same functionality that Bootstrap's offer (margin + padding * six directional options * 14 increments).

The two options I see are:

1. Convert to Sass everywhere so we can override Bootstrap's Sass.
2. Lean away from using spacing utility classes and apply them via other CSS selectors.

(not necessarily in order of my preference – I'm not 100% sure yet which I think is best)

[netlify]

✅ Deploy Preview for cal-itp-website ready!

Name	Link
🔨 Latest commit	e649639
🔍 Latest deploy log	https://app.netlify.com/projects/cal-itp-website/deploys/693b18927c525d0008c93bc9
😎 Deploy Preview	https://deploy-preview-553--cal-itp-website.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[jgravois]

this is already looking pretty promising.

I'm not 100% sure yet which I think is best

me neither tbh. personally i don't see much/any downside to just using Sass to:

• customize bootstrap to give us all the 8px spacing helpers we need
• compile our own CSS back into a single file
• take advantage of its own nesting

that said, i can live without all that. if we're going to stick to pure CSS my instinct would be to start by defining only the missing spacing increments that we have immediate use for (24px, 80px).

we can try a couple things as we start to lay out mobimart pages and see what feels nicest.

[jgravois]

nice catch 😇

[jgravois]

since you're proposing this in #554, lets revert the change here.

[jgravois]

not sure i see the benefit of canonizing this as a CSS variable, but i'm okay with it.

[Scotchester]

I did it to stay in sync with how Christine laid out the spec, but I think you're right that we should ditch it. I agree with the general principle (hence not adding variables for the different font weights before).

[jgravois]

i could be missing something but defining a px base and calculating final values in rem makes these conversions feel unnecessarily convoluted.

// alternatives
:root {
  --spacing-base: 8px;
  --spacing-05: calc(var(--spacing-base) * 0.5); /* 4px */

  --spacing-base: 0.5rem;
  --spacing-05: calc(var(--spacing-base) * 0.5); /* 4px */
}

[Scotchester]

I agree it's convoluted.

The first alternative doesn't work if we want the result units to be rem.

The second alternative I don't like exactly as written because when we base things off of pixel values (as in the text sizing above), I like seeing that number. It could be added via comment, though, OR we could do something like this:

:root {
  --spacing-base: calc(8 / var(--text-base) * 1em; /* 8px → 0.5rem */
  --spacing-05: calc(var(--spacing-base) * 0.5); /* 0.25rem (4px) */
}

[jgravois]

It could be added via comment, though,

that works for me.

The first alternative doesn't work if we want the result units to be rem.

it may just be that the nuance of rem vs. px is lost on me, but when i tested this in chrome, the computed value is always displayed in px 🤷

[Scotchester]

Hrmmm. I wonder if that's just how Chrome displays it? I suppose the true test would be does it scale if you change the default text size in the browser prefs. I can double-check this.

[thekaveman]

I do know we have discussed this in the past (can't remember where / too lazy to look, maybe Benefits) but rem is important for browser text resizing (e.g. zoom in/out, default text sizes). It scales more appropriately than px or em, leaving our intended designs and layouts in place.

[thekaveman]

OK found some relevant context from Benefits: cal-itp/benefits#1082

[jgravois]

ah. very helpful @thekaveman. thank you!

in my own testing, chrome only displays computed values in px but those values do fluctuate based on the default browser text size when rem is used in the actual declaration.

testing this has me convinced that the simplified calculation below would be sufficient for us.

:root {
  --spacing-base: 0.5rem;
  --spacing-05: calc(var(--spacing-base) * 0.5); /* 0.25rem (4px) */
}

[jgravois]

i also learned that github.com fails to honor non-default browser text sizes completely. i was surprised by this because they've made loads of accessibility improvements over the last few years.

edit: a little poking and a QA with gemini has me convinced that GitHub is making a conscious decision to solely support scaling the entire site on fly in the name of preserving layout precision.

food for thought.

[Scotchester]

edit: a little poking and a QA with gemini has me convinced that GitHub is making a conscious decision to solely support scaling the entire site on fly in the name of preserving layout precision.

That decision doesn't seem unreasonable to me, in the context of an app with such a heavy UI.

For our products, though, I think we should be more flexible.

[Scotchester]

Review commit-by-commit to avoid seeing some minor cleanup until last.

I realize now that I didn't include the new --text-base var in the first commit, which is required for the spacing vars to work. Will fix that with a rebase before merging.