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

@bathos :

> Oh, wild! I see what you mean about ECMA-402: it makes no semantic assertion about order and expressly permits other specs /implementations to overlay their own. I’m not sure what makes RFC 7159 vague since “An object is an unordered collection of...” is about as unambiguous as a semantic assertion can get — is that text not actually normative or something? In any case I hadn’t realized they conflicted on this and appreciate the info.

Yeah you're right I think: RFC 7159 does seem fairly opinionated that the objects' order should not matter (later on it says "JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software.  Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences.". I don't know where I got the impression that it allowed the order to matter.

@marcoscaceres :

> Got it. But hat will happen no matter what if there is a mismatch between the manifest and the HTML.

Yes, but the idea is that there should not be a mismatch between the manifest and HTML. If there is a mismatch, there will be a flash. All we are trying to do is make it possible for developers to write an app that has no mismatch.

I think what you are suggesting here is that the manifest parser (at parse time, not at app load time) runs the MQ parser with both a dark and light context, and then stores the result in an OS-specific context. That is theoretically possible (though it still creates a non-trivial dependency between the manifest parser and CSS parser which did not exist before). But it still has a number of issues:

- It requires us to run the MQ parser for a limited hard-coded set of configurations in advance. That doesn't work well with combinations (e.g. if we have the capability to do an AND condition of, say, theme colour and language, we would need to run it  on all permutations). The alternative is to be very limited in what operations are supported. If your goal is to not invent a new language for developers to learn, I would say it's harmful to claim it's CSS MQ when in reality it's a (potentially undocumented) subset of CSS MQ.
- It's not clear what values we would ascribe to other MQ features that aren't applicable at the OS level, which is almost all of them. For example, say that a MQ in the manifest uses the viewport size features like `width` and `height`. How would we reflect those at the OS level? What value would we ascribe to those "meaningless" features?
- Even for features that do make sense at the OS level, it isn't feasible to preprocess them unless they have a very limited range (like `light` and `dark`). For example, what if the manifest includes "(prefers-color-scheme: dark) and (resolution > 150dpi)" for one option, and "(prefers-color-scheme: light) and (resolution < 150dpi)" for another option? How do we pre-process this meaningfully? Even though `resolution` does make sense at the OS level, it still is probably not something we can "preprocess" because we would literally need to run the query over every possible resolution.
- Since we're planning to use this for translations, it's worth pointing out that there is no `language` MQ feature. Not insurmountable, as we could get it added to CSS, but that's yet another yak to shave.

I can see the appeal of using MQs for this instead of "inventing a new wheel", but this really feels like using a sledgehammer when we need tweezers. We have a fairly simple feature request (be able to make manifest options conditional on theme colour and language), and while the CSS MQ can do the former, it can't (yet) do the latter, and it can do so many other things we don't want.

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

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

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