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

@tomayac wrote:
> Regarding Purpose-built objects and members, it's not clear if your proposal would require CSS user preference media query parsing or not, since in your proposal you mention two ways:
> Can you clarify?

You are spot on and this is exactly what we need to discuss. 

@alancutter wrote: 
> I'm somewhat skeptical an acceptable syntax can be found though.

Same, why I proposed just skipping all that and just using "whatever_members" express the same semantics by hard-coding the solution. 

And 💯 to everything @mgiuca said on the matter. 

@loubrett wrote: 
> The main problem that I’m trying to solve with a dark theme_color is that currently when you open an app, you’ll see a flash of the manifest theme_color before the browser loads and the html theme_color takes over.

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

 1. app is installed with manifest that declares dark + light theme_colors.
 2. App starts, start_url loads. 
 3. HTML theme_color kicks in (mismatch!).

The solution is make sure the HTML theme is set via:

```HTML
<meta name="theme-color" media="(prefers-color-scheme: dark)" content="yellow">
<meta name="theme-color" media="(prefers-color-scheme: light)" content="blue">
```
(Or just leave it to the manifest to do its thing… only include the theme colors if not installed)

> If we have a media query for the theme_color we would still need to wait for the browser in order to evaluate the media query.
> So your point that media queries don't work for icons also applies here. Therefore I think we should use the "scheme": "dark" syntax for the color objects instead of a media query so that it can be handled by the OS.

Sorry, let me try to be more clear. I’m proposing that the MQs are evaluated and (statically) transformed at install time, **not** evaluated at start/runtime. So: 
 
1. Manifest -> theme_color_overrides [{MQ}, {MQ}].
2. **At install time**,  each {MQ} is converted to a native equivalent representation (e.g., on iOS, something in an XML .plist).
3. User launches the app.
4. OS reads the native (XML or whatever) description, launches the app and applies the theme color based on the OS scheme (i.e., all native, no MQ evaluation needed because there is no media query).

Implementations already take “static snapshots” of things in the manifest and convert them to OS equivalent data: in particular `theme_color` and `background_color` start as CSS colors and are then converted to  Android/iOS equivalent static colors (e.g., the css keyword `red` becomes some hex representation equivalent on Android/iOS).

The .2 above is the non-trivial part, and @mgiuca is raising valid concerns about. 
 
@mgiuca wrote:
> 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).

Right. That's why I was proposing the browser convert the MQ to a static representation at install time, like  we do with the color members. The valid question/concern is: how difficult is it going to be to do that? 

Putting on my WebKit hat for a second, and having chatted with @dcrousso, we think it could be doable… but we would need to check how insane MQs could get and how much trouble it is to translate them to OS equivalents… it’s on us (WebKit folks) to show that it would work and it’s not insanely complicated. 

On the other hand, if it does all get too crazy, falling back to a simple `"scheme": "dark"` (and other `prefers_` equivalents) is definitely a workable solution, even if it does reinvent the wheel a bit. 

The motivating factors on the Webkit side are:

 * don’t reinvent the [CSSMQ `prefers_`] wheel. 
 * don’t burden developers with learning a new thing (when the CSS one will do). 

@mgiuca wrote:
> 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.

Something like that would work... the other reason I chose `localized_X` is because those members would only accept "localized objects". Bikeshedding on the above would be good, specially if we have agreement about the specific types. At the same time, "_overrides" could be fine even if members accept different object types. 


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

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

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