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

Hi Marcos,

As discussed today, we're looking forward to seeing a concrete proposal using media queries, and @loubrett will provide a concrete proposal using the lightweight per-purpose syntax.

There are a few questions I'd like to see answered in the detailed MQ proposal:

- What is the implementation expected to do. (While this isn't something you would put in the spec, I still want to see a discussion of the implementation in the proposal because we can't accept it if it isn't practical to implement.) As I see it, there are three possible implementation paths here:
  - Put a full MQ parser in the OS, so that the OS can respond to changes to the MQ inputs without having to load up a browser.
  - Pre-process all permutations of the MQ inputs at parse time, and store all possibilities in a file that the OS can respond to, so that when there are changes to the inputs, it can respond by selecting the appropriate one. (This works for just {light, dark}, but quickly becomes infeasible if there are many different inputs, especially integer values.)
  - Pre-process the current state at parse time. Re-process it when the app loads. (This would mean that the app's representation in the OS does not respond to changes to the input until the app reloads.)
- Describe which MQ features you are intending to support, or possibly support in the future. (i.e. go through the list of MQ features -- which ones are feasible to include in this proposal?). Describe how the non-supported ones (like viewport size, for instance) would be handled.
- Do you intend for the specification to state which MQ features are supported, and how they apply in a non-browser context, or is that left up to the implementation?
- Do you intend to support all the syntactic constructs of MQ, such as numeric comparison operators? Or define a subset?
- Are there concrete use cases for supporting all of these features or is this just a case of "we might need them in the future"?

Note that I'm focusing a lot on the implementation because my main concern here is that the MQ proposal adds significant complexity to the browser vendor. While I agree that when there is a trade-off between ease of use for the web developer vs ease of implementation for the browser vendor, the developer should win, there is a limit to this. IMO the benefit to the developer of MQ vs the per-purpose syntax would have to be shown to be extremely valuable to outweigh the large implementation overhead, or I would need to better understand how the implementation is not as complex as I think it is. (So before we go down the path of quantifying the benefits and costs, I'd like to have a clear picture of how you think a browser should implement this feature.)

Thanks and looking forward to chatting further.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1045#issuecomment-1203596748
You are receiving this because you are subscribed to this thread.

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