Raise the compile floor to Baseline 2024, stop polyfilling light-dark()

[minimaldesign]

Closes#56.

The verdict on the issue

Verified end to end. With the shipped floor, light-dark() expands into the scratch-property + @supports triplet described in the issue, including the @supports not (…) { :root * { … } } rule that, inside @layer theme, beats a component's token override in @layer components. The "colors go unset, not light" fallback analysis is correct spec behavior for tokens. And the polyfill was not only in consumer builds: dist/mcss.css shipped 403 --csstools-* declarations.

The root cause is that defaults and supports css-cascade-layers resolves to a minimum of Chrome 109 (the last Windows 7 build, kept alive by usage-based defaults), two years short of light-dark().

What else the old floor was transforming

Tested feature by feature through the repo config:

• Nesting: 189 nested rules across 37 files, silently flattened in dist and consumer builds, while the docs claim native nesting.
• Relative color syntax: 4 uses wrapped in @supports gates that cannot produce real fallbacks (var() inputs), pure noise.
• Nothing else: oklch()/color-mix()/hwb() are unused, and :has(), @scope, @container, @property, random() all passed through already. @custom-media compiling is the one intended transform and is unchanged.

The fix (issue's option 1)

.browserslistrc is now baseline 2024, which resolves to Chrome/Edge 130, Firefox 132, Safari 18.2+. That kills the light-dark() polyfill, un-flattens nesting, and drops the relative-color gates in one move. Note that baseline widely available would not work today: it resolves to Chrome 121, below light-dark()'s Chrome 123, so the polyfill still fires. Verified empirically.

Results: dist/mcss.css 159 kB → 130 kB, dist/mcss.min.css 121 kB → 94 kB (17.8 → 15.9 kB gzip), zero csstools artifacts in dist, the site build, and the per-file outputs.

Docs

• start.mdx: browser support rewritten for the new floor; the light-dark() fallback claim corrected (tokens holding an unsupported function make consuming properties invalid at computed-value time, so pre-2024 browsers get unset colors, not the light palette).
• PostCSS setup post: new floor section explaining the baseline 2024 query, the browserslist ≥ 4.25 requirement, a fourth output-check grep (grep -c "csstools" → 0), and a troubleshooting entry for the toggle variables.
• CHANGELOG.md: 1.3.0 with the floor raise under Breaking, per the 1.2.0 precedent.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for mcssdev ready!

Name	Link
🔨 Latest commit	4bfbcd8
🔍 Latest deploy log	https://app.netlify.com/projects/mcssdev/deploys/6a6cc93c693f9100082ee892
😎 Deploy Preview	https://deploy-preview-57--mcssdev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 100 Accessibility: 98 Best Practices: 100 SEO: 97 PWA: 60 View the detailed breakdown and full score reports

---

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

[minimaldesign]

Closes#56.

The verdict on the issue

Verified end to end. With the shipped floor, light-dark() expands into the scratch-property + @supports triplet described in the issue, including the @supports not (…) { :root * { … } } rule that, inside @layer theme, beats a component's token override in @layer components. The "colors go unset, not light" fallback analysis is correct spec behavior for tokens. And the polyfill was not only in consumer builds: dist/mcss.css shipped 403 --csstools-* declarations.

The root cause is that defaults and supports css-cascade-layers resolves to a minimum of Chrome 109 (the last Windows 7 build, kept alive by usage-based defaults), two years short of light-dark().

What else the old floor was transforming

Tested feature by feature through the repo config:

• Nesting: 189 nested rules across 37 files, silently flattened in dist and consumer builds, while the docs claim native nesting.
• Relative color syntax: 4 uses wrapped in @supports gates that cannot produce real fallbacks (var() inputs), pure noise.
• Nothing else: oklch()/color-mix()/hwb() are unused, and :has(), @scope, @container, @property, random() all passed through already. @custom-media compiling is the one intended transform and is unchanged.

The fix (issue's option 1)

.browserslistrc is now baseline 2024, which resolves to Chrome/Edge 130, Firefox 132, Safari 18.2+. That kills the light-dark() polyfill, un-flattens nesting, and drops the relative-color gates in one move. Note that baseline widely available would not work today: it resolves to Chrome 121, below light-dark()'s Chrome 123, so the polyfill still fires. Verified empirically.

Results: dist/mcss.css 159 kB → 130 kB, dist/mcss.min.css 121 kB → 94 kB (17.8 → 15.9 kB gzip), zero csstools artifacts in dist, the site build, and the per-file outputs.

Docs

• start.mdx: browser support rewritten for the new floor; the light-dark() fallback claim corrected (tokens holding an unsupported function make consuming properties invalid at computed-value time, so pre-2024 browsers get unset colors, not the light palette).
• PostCSS setup post: new floor section explaining the baseline 2024 query, the browserslist ≥ 4.25 requirement, a fourth output-check grep (grep -c "csstools" → 0), and a troubleshooting entry for the toggle variables.
• CHANGELOG.md: 1.3.0 with the floor raise under Breaking, per the 1.2.0 precedent.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for mcssdev ready!

Name	Link
🔨 Latest commit	4bfbcd8
🔍 Latest deploy log	https://app.netlify.com/projects/mcssdev/deploys/6a6cc93c693f9100082ee892
😎 Deploy Preview	https://deploy-preview-57--mcssdev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 100 Accessibility: 98 Best Practices: 100 SEO: 97 PWA: 60 View the detailed breakdown and full score reports

---

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

[minimaldesign]

Closes#56.

The verdict on the issue

Verified end to end. With the shipped floor, light-dark() expands into the scratch-property + @supports triplet described in the issue, including the @supports not (…) { :root * { … } } rule that, inside @layer theme, beats a component's token override in @layer components. The "colors go unset, not light" fallback analysis is correct spec behavior for tokens. And the polyfill was not only in consumer builds: dist/mcss.css shipped 403 --csstools-* declarations.

The root cause is that defaults and supports css-cascade-layers resolves to a minimum of Chrome 109 (the last Windows 7 build, kept alive by usage-based defaults), two years short of light-dark().

What else the old floor was transforming

Tested feature by feature through the repo config:

• Nesting: 189 nested rules across 37 files, silently flattened in dist and consumer builds, while the docs claim native nesting.
• Relative color syntax: 4 uses wrapped in @supports gates that cannot produce real fallbacks (var() inputs), pure noise.
• Nothing else: oklch()/color-mix()/hwb() are unused, and :has(), @scope, @container, @property, random() all passed through already. @custom-media compiling is the one intended transform and is unchanged.

The fix (issue's option 1)

.browserslistrc is now baseline 2024, which resolves to Chrome/Edge 130, Firefox 132, Safari 18.2+. That kills the light-dark() polyfill, un-flattens nesting, and drops the relative-color gates in one move. Note that baseline widely available would not work today: it resolves to Chrome 121, below light-dark()'s Chrome 123, so the polyfill still fires. Verified empirically.

Results: dist/mcss.css 159 kB → 130 kB, dist/mcss.min.css 121 kB → 94 kB (17.8 → 15.9 kB gzip), zero csstools artifacts in dist, the site build, and the per-file outputs.

Docs

• start.mdx: browser support rewritten for the new floor; the light-dark() fallback claim corrected (tokens holding an unsupported function make consuming properties invalid at computed-value time, so pre-2024 browsers get unset colors, not the light palette).
• PostCSS setup post: new floor section explaining the baseline 2024 query, the browserslist ≥ 4.25 requirement, a fourth output-check grep (grep -c "csstools" → 0), and a troubleshooting entry for the toggle variables.
• CHANGELOG.md: 1.3.0 with the floor raise under Breaking, per the 1.2.0 precedent.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for mcssdev ready!

Name	Link
🔨 Latest commit	4bfbcd8
🔍 Latest deploy log	https://app.netlify.com/projects/mcssdev/deploys/6a6cc93c693f9100082ee892
😎 Deploy Preview	https://deploy-preview-57--mcssdev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 100 Accessibility: 98 Best Practices: 100 SEO: 97 PWA: 60 View the detailed breakdown and full score reports

---

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

[minimaldesign]

Closes#56.

The verdict on the issue

Verified end to end. With the shipped floor, light-dark() expands into the scratch-property + @supports triplet described in the issue, including the @supports not (…) { :root * { … } } rule that, inside @layer theme, beats a component's token override in @layer components. The "colors go unset, not light" fallback analysis is correct spec behavior for tokens. And the polyfill was not only in consumer builds: dist/mcss.css shipped 403 --csstools-* declarations.

The root cause is that defaults and supports css-cascade-layers resolves to a minimum of Chrome 109 (the last Windows 7 build, kept alive by usage-based defaults), two years short of light-dark().

What else the old floor was transforming

Tested feature by feature through the repo config:

• Nesting: 189 nested rules across 37 files, silently flattened in dist and consumer builds, while the docs claim native nesting.
• Relative color syntax: 4 uses wrapped in @supports gates that cannot produce real fallbacks (var() inputs), pure noise.
• Nothing else: oklch()/color-mix()/hwb() are unused, and :has(), @scope, @container, @property, random() all passed through already. @custom-media compiling is the one intended transform and is unchanged.

The fix (issue's option 1)

.browserslistrc is now baseline 2024, which resolves to Chrome/Edge 130, Firefox 132, Safari 18.2+. That kills the light-dark() polyfill, un-flattens nesting, and drops the relative-color gates in one move. Note that baseline widely available would not work today: it resolves to Chrome 121, below light-dark()'s Chrome 123, so the polyfill still fires. Verified empirically.

Results: dist/mcss.css 159 kB → 130 kB, dist/mcss.min.css 121 kB → 94 kB (17.8 → 15.9 kB gzip), zero csstools artifacts in dist, the site build, and the per-file outputs.

Docs

• start.mdx: browser support rewritten for the new floor; the light-dark() fallback claim corrected (tokens holding an unsupported function make consuming properties invalid at computed-value time, so pre-2024 browsers get unset colors, not the light palette).
• PostCSS setup post: new floor section explaining the baseline 2024 query, the browserslist ≥ 4.25 requirement, a fourth output-check grep (grep -c "csstools" → 0), and a troubleshooting entry for the toggle variables.
• CHANGELOG.md: 1.3.0 with the floor raise under Breaking, per the 1.2.0 precedent.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for mcssdev ready!

Name	Link
🔨 Latest commit	4bfbcd8
🔍 Latest deploy log	https://app.netlify.com/projects/mcssdev/deploys/6a6cc93c693f9100082ee892
😎 Deploy Preview	https://deploy-preview-57--mcssdev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 100 Accessibility: 98 Best Practices: 100 SEO: 97 PWA: 60 View the detailed breakdown and full score reports

---

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

[minimaldesign]

Closes#56.

The verdict on the issue

Verified end to end. With the shipped floor, light-dark() expands into the scratch-property + @supports triplet described in the issue, including the @supports not (…) { :root * { … } } rule that, inside @layer theme, beats a component's token override in @layer components. The "colors go unset, not light" fallback analysis is correct spec behavior for tokens. And the polyfill was not only in consumer builds: dist/mcss.css shipped 403 --csstools-* declarations.

The root cause is that defaults and supports css-cascade-layers resolves to a minimum of Chrome 109 (the last Windows 7 build, kept alive by usage-based defaults), two years short of light-dark().

What else the old floor was transforming

Tested feature by feature through the repo config:

• Nesting: 189 nested rules across 37 files, silently flattened in dist and consumer builds, while the docs claim native nesting.
• Relative color syntax: 4 uses wrapped in @supports gates that cannot produce real fallbacks (var() inputs), pure noise.
• Nothing else: oklch()/color-mix()/hwb() are unused, and :has(), @scope, @container, @property, random() all passed through already. @custom-media compiling is the one intended transform and is unchanged.

The fix (issue's option 1)

.browserslistrc is now baseline 2024, which resolves to Chrome/Edge 130, Firefox 132, Safari 18.2+. That kills the light-dark() polyfill, un-flattens nesting, and drops the relative-color gates in one move. Note that baseline widely available would not work today: it resolves to Chrome 121, below light-dark()'s Chrome 123, so the polyfill still fires. Verified empirically.

Results: dist/mcss.css 159 kB → 130 kB, dist/mcss.min.css 121 kB → 94 kB (17.8 → 15.9 kB gzip), zero csstools artifacts in dist, the site build, and the per-file outputs.

Docs

• start.mdx: browser support rewritten for the new floor; the light-dark() fallback claim corrected (tokens holding an unsupported function make consuming properties invalid at computed-value time, so pre-2024 browsers get unset colors, not the light palette).
• PostCSS setup post: new floor section explaining the baseline 2024 query, the browserslist ≥ 4.25 requirement, a fourth output-check grep (grep -c "csstools" → 0), and a troubleshooting entry for the toggle variables.
• CHANGELOG.md: 1.3.0 with the floor raise under Breaking, per the 1.2.0 precedent.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for mcssdev ready!

Name	Link
🔨 Latest commit	4bfbcd8
🔍 Latest deploy log	https://app.netlify.com/projects/mcssdev/deploys/6a6cc93c693f9100082ee892
😎 Deploy Preview	https://deploy-preview-57--mcssdev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 100 Accessibility: 98 Best Practices: 100 SEO: 97 PWA: 60 View the detailed breakdown and full score reports

---

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

[minimaldesign]

Closes#56.

The verdict on the issue

Verified end to end. With the shipped floor, light-dark() expands into the scratch-property + @supports triplet described in the issue, including the @supports not (…) { :root * { … } } rule that, inside @layer theme, beats a component's token override in @layer components. The "colors go unset, not light" fallback analysis is correct spec behavior for tokens. And the polyfill was not only in consumer builds: dist/mcss.css shipped 403 --csstools-* declarations.

The root cause is that defaults and supports css-cascade-layers resolves to a minimum of Chrome 109 (the last Windows 7 build, kept alive by usage-based defaults), two years short of light-dark().

What else the old floor was transforming

Tested feature by feature through the repo config:

• Nesting: 189 nested rules across 37 files, silently flattened in dist and consumer builds, while the docs claim native nesting.
• Relative color syntax: 4 uses wrapped in @supports gates that cannot produce real fallbacks (var() inputs), pure noise.
• Nothing else: oklch()/color-mix()/hwb() are unused, and :has(), @scope, @container, @property, random() all passed through already. @custom-media compiling is the one intended transform and is unchanged.

The fix (issue's option 1)

.browserslistrc is now baseline 2024, which resolves to Chrome/Edge 130, Firefox 132, Safari 18.2+. That kills the light-dark() polyfill, un-flattens nesting, and drops the relative-color gates in one move. Note that baseline widely available would not work today: it resolves to Chrome 121, below light-dark()'s Chrome 123, so the polyfill still fires. Verified empirically.

Results: dist/mcss.css 159 kB → 130 kB, dist/mcss.min.css 121 kB → 94 kB (17.8 → 15.9 kB gzip), zero csstools artifacts in dist, the site build, and the per-file outputs.

Docs

• start.mdx: browser support rewritten for the new floor; the light-dark() fallback claim corrected (tokens holding an unsupported function make consuming properties invalid at computed-value time, so pre-2024 browsers get unset colors, not the light palette).
• PostCSS setup post: new floor section explaining the baseline 2024 query, the browserslist ≥ 4.25 requirement, a fourth output-check grep (grep -c "csstools" → 0), and a troubleshooting entry for the toggle variables.
• CHANGELOG.md: 1.3.0 with the floor raise under Breaking, per the 1.2.0 precedent.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for mcssdev ready!

Name	Link
🔨 Latest commit	4bfbcd8
🔍 Latest deploy log	https://app.netlify.com/projects/mcssdev/deploys/6a6cc93c693f9100082ee892
😎 Deploy Preview	https://deploy-preview-57--mcssdev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 100 Accessibility: 98 Best Practices: 100 SEO: 97 PWA: 60 View the detailed breakdown and full score reports

---

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

[minimaldesign]

Closes#56.

The verdict on the issue

Verified end to end. With the shipped floor, light-dark() expands into the scratch-property + @supports triplet described in the issue, including the @supports not (…) { :root * { … } } rule that, inside @layer theme, beats a component's token override in @layer components. The "colors go unset, not light" fallback analysis is correct spec behavior for tokens. And the polyfill was not only in consumer builds: dist/mcss.css shipped 403 --csstools-* declarations.

The root cause is that defaults and supports css-cascade-layers resolves to a minimum of Chrome 109 (the last Windows 7 build, kept alive by usage-based defaults), two years short of light-dark().

What else the old floor was transforming

Tested feature by feature through the repo config:

• Nesting: 189 nested rules across 37 files, silently flattened in dist and consumer builds, while the docs claim native nesting.
• Relative color syntax: 4 uses wrapped in @supports gates that cannot produce real fallbacks (var() inputs), pure noise.
• Nothing else: oklch()/color-mix()/hwb() are unused, and :has(), @scope, @container, @property, random() all passed through already. @custom-media compiling is the one intended transform and is unchanged.

The fix (issue's option 1)

.browserslistrc is now baseline 2024, which resolves to Chrome/Edge 130, Firefox 132, Safari 18.2+. That kills the light-dark() polyfill, un-flattens nesting, and drops the relative-color gates in one move. Note that baseline widely available would not work today: it resolves to Chrome 121, below light-dark()'s Chrome 123, so the polyfill still fires. Verified empirically.

Results: dist/mcss.css 159 kB → 130 kB, dist/mcss.min.css 121 kB → 94 kB (17.8 → 15.9 kB gzip), zero csstools artifacts in dist, the site build, and the per-file outputs.

Docs

• start.mdx: browser support rewritten for the new floor; the light-dark() fallback claim corrected (tokens holding an unsupported function make consuming properties invalid at computed-value time, so pre-2024 browsers get unset colors, not the light palette).
• PostCSS setup post: new floor section explaining the baseline 2024 query, the browserslist ≥ 4.25 requirement, a fourth output-check grep (grep -c "csstools" → 0), and a troubleshooting entry for the toggle variables.
• CHANGELOG.md: 1.3.0 with the floor raise under Breaking, per the 1.2.0 precedent.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for mcssdev ready!

Name	Link
🔨 Latest commit	4bfbcd8
🔍 Latest deploy log	https://app.netlify.com/projects/mcssdev/deploys/6a6cc93c693f9100082ee892
😎 Deploy Preview	https://deploy-preview-57--mcssdev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 100 Accessibility: 98 Best Practices: 100 SEO: 97 PWA: 60 View the detailed breakdown and full score reports

---

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

[minimaldesign]

Closes#56.

The verdict on the issue

Verified end to end. With the shipped floor, light-dark() expands into the scratch-property + @supports triplet described in the issue, including the @supports not (…) { :root * { … } } rule that, inside @layer theme, beats a component's token override in @layer components. The "colors go unset, not light" fallback analysis is correct spec behavior for tokens. And the polyfill was not only in consumer builds: dist/mcss.css shipped 403 --csstools-* declarations.

The root cause is that defaults and supports css-cascade-layers resolves to a minimum of Chrome 109 (the last Windows 7 build, kept alive by usage-based defaults), two years short of light-dark().

What else the old floor was transforming

Tested feature by feature through the repo config:

• Nesting: 189 nested rules across 37 files, silently flattened in dist and consumer builds, while the docs claim native nesting.
• Relative color syntax: 4 uses wrapped in @supports gates that cannot produce real fallbacks (var() inputs), pure noise.
• Nothing else: oklch()/color-mix()/hwb() are unused, and :has(), @scope, @container, @property, random() all passed through already. @custom-media compiling is the one intended transform and is unchanged.

The fix (issue's option 1)

.browserslistrc is now baseline 2024, which resolves to Chrome/Edge 130, Firefox 132, Safari 18.2+. That kills the light-dark() polyfill, un-flattens nesting, and drops the relative-color gates in one move. Note that baseline widely available would not work today: it resolves to Chrome 121, below light-dark()'s Chrome 123, so the polyfill still fires. Verified empirically.

Results: dist/mcss.css 159 kB → 130 kB, dist/mcss.min.css 121 kB → 94 kB (17.8 → 15.9 kB gzip), zero csstools artifacts in dist, the site build, and the per-file outputs.

Docs

• start.mdx: browser support rewritten for the new floor; the light-dark() fallback claim corrected (tokens holding an unsupported function make consuming properties invalid at computed-value time, so pre-2024 browsers get unset colors, not the light palette).
• PostCSS setup post: new floor section explaining the baseline 2024 query, the browserslist ≥ 4.25 requirement, a fourth output-check grep (grep -c "csstools" → 0), and a troubleshooting entry for the toggle variables.
• CHANGELOG.md: 1.3.0 with the floor raise under Breaking, per the 1.2.0 precedent.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for mcssdev ready!

Name	Link
🔨 Latest commit	4bfbcd8
🔍 Latest deploy log	https://app.netlify.com/projects/mcssdev/deploys/6a6cc93c693f9100082ee892
😎 Deploy Preview	https://deploy-preview-57--mcssdev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 100 Accessibility: 98 Best Practices: 100 SEO: 97 PWA: 60 View the detailed breakdown and full score reports

---

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