Re: [w3c/manifest] Web Manifest Overrides (Issue #1045)

Marcos and I were talking a bit about the proposed approaches and some of the concerns around using Media Query syntax in the manifest. My sentiment on the topic is this:

1. There are distinct advantages to using a syntax that is familiar and consistent for developers: consistency, easier to learn.
2. MQs in CSS are only inferences about the context in which a page is rendered. PWAs do not render a page, they translate values to a host OS, but the inferences from the host OS about context remain useful. There may be benefits to using the CSS parser to handle MQ parsing from the Manifest, but it is equally true that just because we map the MQ syntax to the Manifest, we don’t need to load the CSS parser - that translation could be done directly and would need to map to the host OS’s means of managing different assets based on those contexts (e.g., when packaging for Windows, alternate color scheme icons are supported via asset naming in the bundle). As it stands, we are only likely to map to one MQ right now, which makes embedding the CSS parser overkill; a basic implementation of prefers-color-scheme should be achievable in far less code. If we want to make it clear we aren’t using the CSS parser, we can specifically say we are using an "MQ-like syntax."
3. If we want to use the same configuration for the translations piece (instead of using raw language keys as originally proposed), that could also be accomplished following the MQ-like proposal @marcoscaceres shared previously: `(language=en)` which, for consistency sake, probably makes more sense than the CSS selector `[lang=en*]` as there is no DOM parsing taking place… the system language is what’s being used.
4. Just to draw a line under it again, as I hadn’t seen any other responses to my earlier post, whatever solution we use should accommodate intersections of language and user preference (and whatever else we introduce in the future) cleanly, which is why I strongly favor proposals that allow individual members or portions of members to be rewritten. If it means we need to assign `id` values to complex constructs like `shortcuts` and `icons` to facilitate this, I’m ok with that (though I do believe that arrays would naturally be ordered, unlike names properties, so I don’t believe ordering in those contexts to be an issue).





-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1045#issuecomment-1219770663

You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1045/1219770663@github.com>