- From: Christian Liebel <notifications@github.com>
- Date: Mon, 26 Jan 2026 06:14:33 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1176/3799821771@github.com>
christianliebel left a comment (w3ctag/design-reviews#1176) @kbabbitt Thanks for the answer. It would be great if you could add those two links to the explainer for future reference. We think extending `@supports` to detect the presence of at-rules is great for progressive enhancement. We are closing this review as **satisfied with concerns**, with the two primary concerns being: 1. The global recognition of at-rules may lead to false positives. 2. The special handling of media queries, where support is only returned if the at-rule is parsed on the "known media features" path, may be confusing for developers. We think the benefits outweigh these concerns, but we recommend clearly documenting this behavior in developer materials (MDN, etc.), including the treatment of `@charset`. Furthermore, we ask that you ensure cross-vendor consensus. (Side note: We believe that feature detection might theoretically allow for fingerprinting. While feature support could be derived from the user agent string, initiatives are underway to reduce its entropy, such as by freezing or restricting it. In that case, feature detection might provide an additional fingerprinting bit. However, depending on the exact feature, developers are likely already able to query support by defining a certain style and checking if it is applied properly.) -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1176#issuecomment-3799821771 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1176/3799821771@github.com>
Received on Monday, 26 January 2026 14:14:37 UTC