- From: Tab Atkins Jr. via GitHub <noreply@w3.org>
- Date: Tue, 15 Jul 2025 22:34:34 +0000
- To: public-css-archive@w3.org
Given that we're never extending or changing `@charset` in any way (the correct solution is "just use UTF-8, you maniac"), I don't care particularly much whether it's supported or not in `@supports`. Purely on cost-benefit, I think it's worth leaving it out; more or less nobody even *thinks* of `@charset` in the first place, and there is *literally* nothing you can do in response to any such test (since it's processed solely in a pre-processing step before parsing even occurs). If there is *ever* a use-case for testing whether a given charset is supported by the browser in CSS, I'd be fine with defining a `charset()` testing function, but I just don't see how it's worth anyone's time to add special-case handling of `@charset` in `@supports` itself. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11116#issuecomment-3075953684 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 15 July 2025 22:34:35 UTC