Untangle the vendored Bulma style.css (prevent another silent style.css/.scss collision)

Background

PR #2026 added assets/css/style.scss to fix #1483 (in-page anchor jumps hiding behind the fixed navbar). It merged fine and GitHub Pages rebuilt successfully — but the new rule never showed up on the live site. PR #2062 root-causes and fixes it, and turned up a bigger underlying issue worth tracking on its own.

What's going on

Bulma is a CSS framework (like Bootstrap) — a set of pre-written CSS classes (.navbar, .hero-body, .button.is-info, .column, etc.) you build HTML with instead of hand-writing layout/component CSS. It's not a Jekyll theme; our own HTML already leans on Bulma's class names throughout the site (e.g. div.hero-body > button.is-info, and the bulma-social CDN stylesheet for share buttons in _includes/head.html). Normally a project vendors Bulma's Sass source and compiles it itself, which is what lets you override Bulma's variables (colors, spacing, etc.) before compiling and cleanly pick up new Bulma versions later.

That's not what this site does. assets/css/style.css (12,262 lines) is a one-time, already-compiled snapshot of Bulma's output CSS, checked into the repo directly back in April 2021 (e88b321d, "first shot at the design refactor") — see .github/LICENSE-BULMA. There's no Bulma source file anywhere in the repo, no build step for it, and site.theme is unset in _config.yml. Because only the compiled output exists, the only way to customize anything is to hand-edit that generated file after the fact — which is exactly what's happened since 2021 (scattered mid-file edits like link colors and navbar tweaks, plus rules appended at the tail like .donate-hero, .impact-card, #back-to-top).

style.scss and the vendored style.css both compile/copy to the same Jekyll output path (/assets/css/style.css); in production the static file silently won, dropping PR #2026's new rule with no build error. This will happen again to the next contributor who reasonably assumes the project has a normal Sass build — and every hand-edit to the 12k-line file carries more risk than it should.

The good news: jekyll-sass-converter is already available (pulled in transitively via the github-pages gem — see Gemfile.lock), so using Sass properly needs no new dependency. And there's exactly one place in the codebase that references the stylesheet (_includes/head.html), so restructuring is low-risk to wire up.

Proposed plan (phased — each box is its own PR, tackle in order as time allows)

• Phase 0 — Immediate fix. Resolve the silent collision so the fix for #1483 actually reaches production. (#2062, open)
• Phase 1 — Guardrail against recurrence. Add a short comment header at the top of style.css explaining what it is and warning against adding a sibling .scss/.sass file with the same name; add a small CI check (in linting.yaml) that fails if a new source file under assets/ would collide with an existing compiled destination path.
• Phase 2 — Document it. Add a short section (e.g. in docs/details.md) explaining the current CSS setup (vendored Bulma + hand edits, no build step) so it's no longer a surprise to new contributors.
• Phase 3 — Separate hand-written CSS from vendored Bulma output. Extract the identifiable custom rules (navbar/menu tweaks, link colors, #back-to-top, .carousel-wrapper/.glider-*, .donate-hero, .impact-card, etc.) out of style.css into a new assets/css/custom.css, loaded after the vendored file. Rename the remainder to make clear it's generated/vendored (e.g. assets/css/bulma.css). Pure move, no visual change — verifiable via local jekyll serve diff. Can be done incrementally, a few rules per PR.
• Phase 4 — (Optional/future) Real Sass build. Vendor actual Bulma source Sass (pinned version) and compile it via the already-available jekyll-sass-converter, reconstructing current customizations as Sass variable overrides where practical. This is the only phase that would let us actually upgrade Bulma or use its Sass features — but it's the highest-effort, highest-risk step and isn't required for the site to work well. Only take this on if there's appetite for it later; Phases 1–3 already remove the immediate risk and most of the maintenance pain.

Filed after investigating the PR #2026 regression — see PR #2062 for the immediate fix this issue's Phase 0 refers to.

🤖 Generated with Claude Code

Start by reading assets/css/style.css, assets/css/style.scss, _includes/head.html, .github/workflows/linting.yaml, and docs/details.md, then run the local Jekyll build or serve workflow. Choose one proposed phase, verify that the resulting site has no stylesheet path collision, and confirm the relevant guardrail, documentation, or CSS separation is complete without a visual change.