- From: Matt Giuca <notifications@github.com>
- Date: Thu, 04 Aug 2022 21:09:01 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/1045/1206019934@github.com>
@bathos that's a cool idea to align on this. (To be clear: I don't think that we can _use_ the UPMF Client Hints header for this use case, because we want it encoded in the manifest so it doesn't require a round-trip to the server at all to update the theme colour based on the user's mode preference. But I think what you're saying is that there's precedent for having a subset of MQ selectors without using the CSS MQ syntax.) I think what this precedent shows is that: 1. We can make use of the CSS MQ features' _semantics_ without having to reuse its syntax or parser. (e.g. UMPF Client Hints spec defines the meaning of the `Sec-CH-Prefers-Color-Scheme` client hint as "modeled after the `prefers-color-scheme` user preference media feature as defined in Media Queries".) That's a good idea, to define a condition that's exactly the same logic as Media Queries, but without actually using the full parser. 2. We can carefully define a subset of MQ features that make sense in this non-CSS context (in their case, in the context of HTTP requests; in our case, in the context of the operating system UI). UMPF Client Hints do not allow _all possible_ MQs, but rather a hand-picked subset which could be expanded in the future as more use cases are requested. Both of those points apply to the manifest as well. What that suggests to me is that a proposal here that avoids using MQ syntax should still use the exact name `"prefers-color-scheme"`, to align with CSS and suggest that we're using the same name and same semantics as what's defined in CSS. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/manifest/issues/1045#issuecomment-1206019934 You are receiving this because you are subscribed to this thread. Message ID: <w3c/manifest/issues/1045/1206019934@github.com>
Received on Friday, 5 August 2022 04:09:13 UTC