Automatic Light/Dark Mode in GenerateBlocks

đź”— **Source:** [Automatic Light/Dark Mode in GenerateBlocks](https://www.youtube.com/watch?v=OYDatNGrwVw)
> [!note]+ Document Notes
> ````markdown
>
> ---
> tags: [Assign relevant tags or keywords to the notee to facilitate organization and retrieval. Add a # before each tag. Tags cannot have special characters. Do not use the tag #articles]
> - #wordpress
> - #generatepress
> - #generateblocks
> - #css
> - #colorscheme
> - #preferscolorscheme
> - #lightdark
> - #designtokens
> - #figma
> - #accessibility
> - #a11y
> - #education
> - #opensource
> - #ospo
> Author: Unspecified (YouTube tutorial creator)
> Source: YouTube
> Reference: https://www.youtube.com/watch?v=OYDatNGrwVw
> date created: {{date:YYYY-MM-DD}} {{time:HH:mm}}
>
> ---
>
> # Title: Automatic Light/Dark Mode in GenerateBlocks (Should this be standard in 2025?)
>
<!-- deep-read:sections start -->
## Table of Contents:
- [📝 Summary](#-summary)
- [đź“– Main Content](#-main-content)
- [🗒️ Notes (Timeline Outline)](#-notes-timeline-outline)
- [đź“– References](#-references)
- [🗣️ Paraphrase](#-paraphrase)
- [đź“° Newsletter](#-newsletter)
- [âś… Action Items](#-action-items)
- [đź§Ş Hypotheses](#-hypotheses)
- [📊 Methodology](#-methodology)
- [âť“ Questions](#-questions)
- [đź”® Future Research](#-future-research)
- [đź’ˇ Implications](#-implications)
- [đź§ Learning Styles Assessment](#-learning-styles-assessment)
- [📊 Accessibility Assessment](#-accessibility-assessment)
- [🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment)
- [âś… Logical validity](#-logical-validity)
- [🕵️ DARVO Analysis](#-darvo-analysis)
- [🔍 SEO Evaluation](#-seo-evaluation)
- [🎯 Conclusion](#-conclusion)
### References: Include a list of sources consulted and cited in the article.
---
## 📝 Summary:
The video walks through implementing **automatic light/dark mode** for a WordPress site using **GeneratePress** + **GenerateBlocks** with a **design-token** workflow and a small amount of **CSS**. Plan palettes in **Figma** (surface, text, border, brand), register the **light** palette in GeneratePress, then connect tokens to CSS Color 5’s `light-dark()` inside a `body` rule, and declare `:root { color-scheme: light dark; }` so the browser adapts built-in UI and defaults to the user’s OS preference. It also covers a common pitfall (button text flipping to the wrong color) and suggests a fix via **constant tokens**; a user-controlled toggle is proposed for a follow-up.
---
## đź“– Main Content:
A **standards-first** approach (no JS required) delivers automatic theming that respects the user’s OS setting while keeping design consistent and maintainable. The flow is:
1) **Design** palettes in Figma with named variables.
2) **Register** tokens in GeneratePress as the **light** set (theme limitation).
3) **Bridge** tokens to `light-dark()` pairs via CSS on `body`.
4) **Verify** by switching OS appearance; handle edge cases with constant tokens (e.g., `--white` for button text).
**Starter CSS (from the walkthrough):**
```css
:root { color-scheme: light dark; }
body{
--surface: light-dark(#ffffff, #000000);
--text: light-dark(#000000, #ffffff);
--border: light-dark(#e5e7eb, #1f2937);
--brand: light-dark(#6d28d9, #6d28d9); /* constant brand color */
}
/* Example usage */
.section { background: var(--surface); color: var(--text); }
.section { border-block-start: 1px solid var(--border); }
.button--brand { background: var(--brand); color: #fff; } /* constant token for legibility */
````
> **Fallback tip:** If `light-dark()` isn’t fully supported in a target browser, pair this with custom properties and a media query:
```css
body{ --surface: #fff; --text: #000; }
@media (prefers-color-scheme: dark){
body{ --surface: #000; --text: #fff; }
}
```
### 🗒️ Notes (Timeline Outline)
> Direct timestamp links jump to the exact moment on YouTube.
* **Why dual modes** — trend & UX
* [0:00–0:12](https://www.youtube.com/watch?v=OYDatNGrwVw&t=0): Clients are increasingly asking for both light & dark designs.
* [0:14–0:26](https://www.youtube.com/watch?v=OYDatNGrwVw&t=14): Many sites already follow OS preferences; users may never notice the other mode.
* [0:28–0:36](https://www.youtube.com/watch?v=OYDatNGrwVw&t=28): Browsers do much of the heavy lifting if you use the right CSS hooks.
* **Plan first in Figma** — token thinking
* [0:54–1:06](https://www.youtube.com/watch?v=OYDatNGrwVw&t=54): Retrofitting is harder; plan both palettes early.
* [1:17–1:35](https://www.youtube.com/watch?v=OYDatNGrwVw&t=77): Variables: **surface**, **text**, **borders**, **brand**.
* [1:42–2:11](https://www.youtube.com/watch?v=OYDatNGrwVw&t=102): Light vs dark palette choices; brand stays constant.
* **WordPress setup** — GeneratePress & GenerateBlocks
* [2:19–2:41](https://www.youtube.com/watch?v=OYDatNGrwVw&t=139): Structure exists; colors not yet tokenized in blocks.
* [2:49–3:11](https://www.youtube.com/watch?v=OYDatNGrwVw&t=169): OS toggle demo shows the site doesn’t respond yet.
* [3:22–4:18](https://www.youtube.com/watch?v=OYDatNGrwVw&t=202): Add **light** tokens in Customizer first due to theme limitation.
* **Assign tokens to UI**
* [4:21–5:02](https://www.youtube.com/watch?v=OYDatNGrwVw&t=261): Section bg → `surface`; text → `text`; border → `border`; button bg → `brand`; button text → `surface` (sets up a pitfall).
* **Enable auto-theming via CSS**
* [5:42–6:20](https://www.youtube.com/watch?v=OYDatNGrwVw&t=342): `:root { color-scheme: light dark; }` to inform the UA.
* [6:36–7:08](https://www.youtube.com/watch?v=OYDatNGrwVw&t=396): GeneratePress can’t store `light-dark()` in palette fields; override in CSS.
* **Wire tokens with `light-dark()`**
* [7:10–8:24](https://www.youtube.com/watch?v=OYDatNGrwVw&t=430): Redeclare tokens on `body` with `light-dark()`; confirm live by OS switching.
* [8:40–9:26](https://www.youtube.com/watch?v=OYDatNGrwVw&t=520): Add `--text` and `--border` pairs.
* [9:32–10:12](https://www.youtube.com/watch?v=OYDatNGrwVw&t=572): `--brand` uses same value for both modes (future flexibility retained).
* **Common pitfall & fix**
* [10:14–10:34](https://www.youtube.com/watch?v=OYDatNGrwVw&t=614): Button text uses `--surface` (flips to black in dark mode) → illegible.
* [10:40–11:30](https://www.youtube.com/watch?v=OYDatNGrwVw&t=640): Fix with a **constant token** (e.g., `--white`) or a palette swatch that never flips; update hover, too.
* **Authoring experience & QA**
* [11:33–12:03](https://www.youtube.com/watch?v=OYDatNGrwVw&t=693): OS switching works in-editor → better QA while building.
* **User choice vs OS preference**
* [12:05–12:32](https://www.youtube.com/watch?v=OYDatNGrwVw&t=725): Consider adding a **site toggle** for users who prefer the other mode.
---
## đź“– References:
* MDN: `color-scheme` — [https://developer.mozilla.org/docs/Web/CSS/color-scheme](https://developer.mozilla.org/docs/Web/CSS/color-scheme)
* MDN: `@media (prefers-color-scheme)` — [https://developer.mozilla.org/docs/Web/CSS/@media/prefers-color-scheme](https://developer.mozilla.org/docs/Web/CSS/@media/prefers-color-scheme)
* CSS Color Module Level 5 `light-dark()` — [https://drafts.csswg.org/css-color-5/#light-dark](https://drafts.csswg.org/css-color-5/#light-dark)
* GeneratePress Docs — [https://docs.generatepress.com](https://docs.generatepress.com)
* GenerateBlocks Docs — [https://generateblocks.com/docs/](https://generateblocks.com/docs/)
* Figma Variables — [https://help.figma.com/hc/en-us/articles/1500007748302-Create-variables](https://help.figma.com/hc/en-us/articles/1500007748302-Create-variables)
---
## 🗣️ Paraphrase:
1. **Design upfront** ([0:54–1:06](https://www.youtube.com/watch?v=OYDatNGrwVw&t=54))
*Original:* Retrofitting is possible but tougher; plan light/dark with variables.
*Paraphrase:* “Bolting on dark mode later works, but it’s clunky. Define surface/text/border/brand tokens on day one and build two palettes from the start.”
2. **CSS-only auto theming** ([5:42–8:24](https://www.youtube.com/watch?v=OYDatNGrwVw&t=342))
*Original:* Declare `color-scheme` and attach tokens to `light-dark()` for automatic OS–driven switching.
*Paraphrase:* “Tell the browser you support both themes, then bind your design tokens to paired values. The site follows the user’s OS without any JavaScript.”
---
## đź“° Newsletter:
**Auto Light/Dark Mode in WordPress (No JS, Just CSS).**
This week we’re shipping a snack-sized guide to **automatic theming** with **GeneratePress + GenerateBlocks**. Plan tokens in Figma (surface, text, border, brand), set the **light** palette in the Customizer, then drop in:
```css
:root { color-scheme: light dark; }
body{
--surface: light-dark(#fff,#000);
--text: light-dark(#000,#fff);
--border: light-dark(#e5e7eb,#1f2937);
--brand: light-dark(#6d28d9,#6d28d9);
}
```
Boom—your site now respects OS preferences and your **CTAs** stay crisp (use a constant token for button text). Want a **user toggle** too? Add a keyboard-accessible switch, persist with `localStorage`, and gate styles via `[data-theme]`.
🎥 Watch the walkthrough: [https://www.youtube.com/watch?v=OYDatNGrwVw](https://www.youtube.com/watch?v=OYDatNGrwVw)
📚 MDN: `color-scheme`, `prefers-color-scheme`, `light-dark()`
Bonus: Less JS, better **performance**, happier eyes. 🌓
---
## âś… Action Items:
**Reusable analysis prompt tuned for your role (GoDaddy Developer Advocate, OSS/WordPress educator, aspiring OSPO director):**
> **Prompt to run on any article/video:**
> Evaluate how this content advances **open-source advocacy**, **contributor onboarding**, and **education** in the WordPress ecosystem.
>
> 1. **Standards & Sustainability:** List where web standards (e.g., `color-scheme`, `light-dark()`) replace third-party dependencies. Identify upstreamable gaps (e.g., theme support for paired tokens) and propose funding/sponsorship targets.
> 2. **Contributor Engagement:** Extract *first-issue* tasks for Make Teams (Docs/Training/Themes/Meta). Provide code sample PRs (theme.json, pattern libs), and a contributor ladder note.
> 3. **Ecosystem Alignment:** Map techniques to block themes, Global Styles, and accessibility mandates. Note plugin interoperability and migration steps.
> 4. **Education Track:** Outline a micro-curriculum (Figma tokens → Global Styles → CSS bridges → automated contrast tests), with labs using PHP/JS/HTML/CSS/Git/GitHub.
> 5. **OSPO Readiness:** Propose policy language for token governance, accessibility KPIs (AA/AAA contrast), and performance SLIs (LCP/INP). Add risk register (browser support, theme limits) with mitigations and rollout plan.
---
## đź§Ş Hypotheses:
* **H1:** Token-first design reduces dark-mode defects by ≥50% versus ad-hoc overrides.
* **H2:** CSS-only theming (`color-scheme` + `light-dark()`) improves Web Vitals (INP/CLS) vs. JS toggles.
* **H3:** Providing a site-level theme toggle increases user satisfaction and decreases bounce for dark-mode users on bright designs.
* **H4:** Documented patterns raise first-time contributor success rates on block theme issues.
### 📊 Methodology:
* **Data Sources:** Lighthouse CI, Web Vitals RUM, aXe/Deque results, GitHub issues, support tickets.
* **Design:**
* A/B: JS-toggle page vs. CSS-only page; compare INP/CLS.
* Before/After: Bug counts before vs. after tokenization.
* Survey: Preference for OS-driven vs. site toggle.
* **Analysis:** Mann–Whitney for non-normal metrics; chi-square on pass/fail contrast; thematic analysis of user feedback.
### âť“ Questions:
* Which components should **never flip** (e.g., logos/brand text) to prevent contrast loss? ([10:14–11:30](https://www.youtube.com/watch?v=OYDatNGrwVw&t=614))
* Should brand hues adapt in dark mode for **perceived contrast** and **vibrancy**? ([9:32–10:12](https://www.youtube.com/watch?v=OYDatNGrwVw&t=572))
* What’s the simplest **toggle UX** that’s keyboard/AT-friendly and coexists with OS preferences? ([12:05–12:32](https://www.youtube.com/watch?v=OYDatNGrwVw&t=725))
### đź”® Future Research:
* Theme/Customizer support for paired values (native `light-dark()` authoring).
* Centralized **design tokens registry** for WordPress block themes with guaranteed contrast scales.
* Editor tooling that previews **OS mode**, **forced-colors**, and **reduced motion** in-place.
### đź’ˇ Implications:
* **Accessibility by default**, **less JS**, better **maintainability**.
* Clear token governance → OSPO policy alignment, consistent UI, measurable KPIs.
---
## đź§ Learning Styles Assessment:
**Estimated readability:** Grade **9–10**.
1. **Visual (Spatial)**
* *Present:* On-screen palette demos & switching.
* *Improve:* Add token maps, before/after screenshots, and flow diagrams.
2. **Aural (Auditory)**
* *Present:* Narrated walkthrough.
* *Improve:* Provide an audio summary + chaptered timestamps.
3. **Verbal (Linguistic)**
* *Present:* Stepwise instructions.
* *Improve:* Add a glossary (token, `color-scheme`, `light-dark()`), link out to MDN.
4. **Physical (Kinesthetic)**
* *Present:* Hands-on changes in Customizer/Blocks.
* *Improve:* Provide a starter repo and a copy-paste lab.
5. **Logical (Mathematical)**
* *Present:* Conditional token mapping.
* *Improve:* Decision tables for flipping vs. constant tokens; contrast formulas.
6. **Social (Interpersonal)**
* *Present:* Comments invite toggle requests.
* *Improve:* Link to a community thread/PR template for feedback.
7. **Solitary (Intrapersonal)**
* *Present:* Watch & pause workflow suits self-study.
* *Improve:* Add reflection checklists (“Which components should be constant?”).
8. **Naturalistic**
* *Present:* None explicit.
* *Improve:* Use day/night metaphors; discuss eye-strain/energy contexts.
---
## 📊 Accessibility Assessment:
* **Screen Reader:** Use semantic headings; theme toggle button needs `aria-pressed` + clear `aria-label`.
* **Keyboard:** Toggle in tab order; operable via Enter/Space; focus not trapped; remembers state.
* **Contrast:** Test AA/AAA in both modes; consider brand shade adjustments in dark mode.
* **Text Resizing:** Support 200–400% zoom; avoid fixed heights; allow line-height growth.
* **Forced Colors:** Add `@media (forced-colors: active)` fixes to avoid invisible borders/icons.
* **Motion:** Respect `prefers-reduced-motion`; avoid flashy transitions when swapping themes.
---
## 🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment:
* **Cultural Relevance:** Provide RTL examples and CJK font considerations.
* **Inclusive Language:** Define jargon; keep instructions in plain language.
* **Neurodiversity:** Short, numbered steps; consistent token naming; chunked code samples.
* **Representation:** Invite showcases from a diverse set of theme authors & regions.
* **Psychological Safety:** Present theme choice as user agency—no value judgments.
---
## âś… Logical validity:
**Tone:** Practical and instructional.
**Strong reasoning instances**
1. **Plan-first tokens** ([0:54–1:35](https://www.youtube.com/watch?v=OYDatNGrwVw&t=54))
* *Why strong:* Reduces retrofitting complexity; aligns design/dev.
* *Boost:* Add a token-to-component checklist.
2. **Standards-first CSS** ([5:42–8:24](https://www.youtube.com/watch?v=OYDatNGrwVw&t=342))
* *Why strong:* Portable, low technical debt, good perf.
* *Boost:* List browser support + fallbacks.
3. **Edge-case constant tokens** ([10:14–11:30](https://www.youtube.com/watch?v=OYDatNGrwVw&t=614))
* *Why strong:* Preserves legibility for CTAs.
* *Boost:* Add CI contrast checks.
**Potential weaknesses**
* **Hasty generalization:** Calling it “simple” may understate browser/theming caveats.
* *Remedy:* Explicitly note support matrices and theme.json alternatives.
---
## 🕵️ DARVO Analysis:
This is a neutral technical tutorial; **no conflict** or allegations.
* **Deny:** None. The author openly acknowledges a GeneratePress limitation and reports it to the maintainer ([6:36–7:08](https://www.youtube.com/watch?v=OYDatNGrwVw&t=396)).
* **Attack:** None. No disparagement of tools/people; tone remains constructive.
* **Reverse Victim/Offender:** None. No framing of self as harmed party.
**Conclusion:** **No DARVO tactics detected**; rhetoric is transparent and solution-oriented.
---
## 🔍 SEO Evaluation:
1. **Keywords:** wordpress dark mode, generateblocks, generatepress, css color-scheme, prefers-color-scheme, light-dark, design tokens, accessibility.
2. **Meta Description (150–160):** “Add automatic light/dark mode to WordPress using GenerateBlocks and CSS (`color-scheme`, `light-dark()`), with tokens, tips, and pitfalls—no JS needed.”
3. **Title Tag (≤60):** “WordPress Auto Dark Mode with GenerateBlocks (CSS-only)”
4. **Headers:** H2s for “Plan Tokens,” “Wire with `light-dark()`,” “Fix Pitfalls,” “Add a Toggle.”
5. **Length:** Aim 1,500–2,000 words with code and screenshots.
6. **Links:** Internal (Global Styles/theme.json posts); External (MDN, CSS Color 5, GP/GB docs).
7. **URL:** `/wordpress-generateblocks-auto-dark-mode`
8. **Images:** Alt text like “Light vs dark token map”; compress for speed.
9. **Mobile:** Responsive images; avoid blocking JS; fast LCP.
10. **Engagement:** Timestamps, copyable CSS, starter repo; clear CTA.
11. **Schema:** `Article` + `VideoObject` with timestamped clips.
12. **Social:** OG/Twitter cards with split light/dark preview.
---
## 🎯 Conclusion:
A **token-first**, **standards-based** approach using `color-scheme`, `light-dark()`, and custom properties lets WordPress sites built with **GeneratePress/GenerateBlocks** follow user OS preferences automatically—with strong accessibility and minimal complexity. Handle exceptions via **constant tokens**, validate contrast in CI, and (optionally) add a **user toggle** to respect individual preference. This pattern is portable, performant, and contributor-friendly—well suited to be documented and adopted widely across the WordPress ecosystem.
```
::contentReference[oaicite:0]{index=0}
```
<!-- deep-read:sections end -->
[[3. Resources/Readwise/Full Document Contents/Articles/Automatic LightDark Mode in GenerateBlocks|Full Document Contents]]
## Highlights
- in our light hex value and our dark hex value. I'll go ahead and copy that light mode hex value. We'll jump back over here, type in the pound sign, and paste that in a comma. Pound sign again. And let's go ahead and grab our dark variant. I'm just going to steal this from Figma. We'll go back into our website and paste that in. And now, if you watch this border at the top here, as I switch from light and dark mode, it's switching between those two colors. It's a little hard to tell because they're not totally different, but it is switching between these. Now, the last ([View Highlight](https://read.readwise.io/read/01k5cnw5qygt8tp91265qnwshk))
- sign before it. We'll put a comma, and we'll just put that same value in again. This gives us the ability to switch that later if we do decide we want a slightly different color in dark or light mode. We can get that taken care of. Now, the problem I alluded to earlier that we kind of created for ourselves is with this button text here. In light mode, we want it to be that same color as the background, which is white. So, we just assigned it to the surface variable. But when we switch over to dark mode, now the surface variable is actually black. ([View Highlight](https://read.readwise.io/read/01k5cnw5sghn4esnernw2ek41g))
- And this doesn't work as well inside of our button. I actually want that to stay white no matter what. So, we need to set up another color that's not going to switch back and forth. Now, like you saw, we can do that by setting up a variable and giving it the same value in both light and dark mode. But, if there's ones that you know are not going to switch, you could just go back in here into your global styles. And maybe we just call this white by default. And we'll just give it a white value and go ahead and publish those changes. We'll go back in here and edit the page. ([View Highlight](https://read.readwise.io/read/01k5cnw5tfyq6vmnapmeh0kw90))