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

Thanks Marcos!

Seconding what @loubrett said: one of the main objections to using the MQ syntax is that it can't be processed without a browser engine. Given that we're open to using the simplified syntax for icons, I hope we can extend that to the other members too (not just because we need to process them without a browser, but also for consistency).

@alancutter : my feeling is that we've spent a lot of energy trying to generalize this problem and have not come up with an acceptable syntax for quite some time. Sometimes, solving the specific problem you are trying to solve is better than finding a general solution to all conceivable problems (in particular, it means that we don't have to handle "ridiculous" cases that nobody will ever need, like making the name conditional on color scheme, or the theme_color conditional on language, and we can solve specific more complex problems, like icons that may need to be conditional on both, on a case-by-case basis).

So I'm overall in favour of Marcos' purpose-built members. And excited that we appear to be headed towards consensus.

If I may introduce a little bikeshedding: I think we can come up with a consistent naming scheme to avoid having `localized_names`, `theme_colors` and `other_icons`. This is rather similar to the [`display_override`](https://wicg.github.io/manifest-incubations/index.html#display_override-member) member introduced in manifest-incubations: the only real reason we introduced `display_override` instead of just extending the existing `display` member is to avoid introducing new values for that member that would break backwards compatibility. Similarly, I think that's the only reason Marcos is proposing `localized_names`, `theme_colors` and `other_icons`, instead of just allowing `name`, `theme_color` and `icons` to be lists of conditional alternatives. (Albeit, `display_override` is not a list of conditional alternatives, it's just an ordered list of preferences, but it's a very similar concept.)

So I would propose sticking with a consistent `_override` naming scheme, where `X_override` has the implied meaning "this is just an extended version of `X` but you can specify alternative values for that member that will be selected according to some member-specific rule". `name_override`, `theme_color_override` and `icons_override`.

This isn't a hill to die on; I'm happy with any naming that lets us move forward, so treat this as a suggestion.

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

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