Re: [w3c/manifest] Add support for defining a theme color for both light & dark modes (prefers color scheme) (#975)

carlosjeurissen left a comment (w3c/manifest#975)

## `icons_localized["ru be uk"]`
@marcoscaceres @aphillips  using space separated list of language tags like you are proposing looks quite elegant and makes the yandex case more compelling. If duplicate languages are present as a result of this syntax (ie "ru be" and "ru"), implementations can favour the shortest property ("ru"). Unless there is other subtags (ie "zh-Hans zh-Hant" would win over "zh" if the preferred script is Hans or Hant. It would only make parsing a bit more complicated. Is this "shorthand" something we would want to add to the text version of `_localized` as well?

As for icons specifically, it could make the hybrid (option iv. in @dmurph https://github.com/w3c/manifest/issues/975#issuecomment-3855395861) less verbose in the yandex case.

Unlike for normal localized text, localized resources still need the resource files to be put in the right place. This often still involves developers. So this aspect may not be as important as is the case for localized text members.

@aphillips [mentioned](https://github.com/w3c/manifest/issues/975#issuecomment-3861625815):
> The rest of your example is good, from the point of view that there is a clear "source" (icons) for all of the icons_localized that acts as the root locale entry. The localized icons only override the source when provided.

Just to clarify, given the following syntax:
{
  "icons": [{a},{b},{c}],
  "icons_localized": {
    "fr-CA": [{d}]
  }
}

If the locale is "fr", it would result in [{a},{b},{c}],
and if the locale is "fr-CA", it would result in [{d}] ? (completely discarding any icons in the main icons member)

## Current icons order for equal options
@dmurph you mentioned Chromium always picks the last one. While it seems to generally mostly uses the last one. I found one case where it chooses the first one. This happens in the "install app" submenu. See screenshot:
<details>
  <summary>Click to expand screenshot</summary>
<img width="884" height="969" alt="Image" src="https://github.com/user-attachments/assets/e1f5286a-2853-45d3-8304-4f14d108488e" />  
</details>

## Screenshots
@dmurph reading in the meeting notes a reference to screenshots. While the webExtensions syntax seems very useful for icons, as for icons, implementations always have to choose ONE icon. We may not want to adopt this syntax for screenshots. Unlike icons, the screenshots member has already meaning to the order. The first item in the list is the first one you want to be displayed. Merging this with the constraints order seems to result in an order mismatch.

While using a different syntax for screenshots vs icons sounds counter intuitive. They are already different beasts. Screenshots have a specific order, with properties like `form_factor` which icons do not have. Screenshots on the other hand do not have the `purpose` property.

Many publishers include both light and dark mode screenshots to inform user candidates the app supports both light and dark mode, and how each of them looks like. For screenshots, the `color_scheme` is always a single value. It could be seen as annotation similar to the current `form_factor` screenshots property. It is then up to the store or installation prompt to decide whether or not to display both light/dark screenshots.

Unlike icons, for screenshots, having browsers ignore the `color_scheme` property seems to not have any significant impact.

In a similar fashion, the languages for screenshots are also always a single value. When it comes to screenshots, we can either introduce `screenshots_localized` similar to the `icons_localized`, or add annotations to each screenshot in the form of a `lang: "en"` property. Appending each localized version after the default screenshots would allow implementations to filter-out specific languages while older implementations would simply append them to the list of screenshots. (And hopefully do not download and render all screenshots in this list).

## Constraints precedence
@dmurph [mentioned](https://github.com/w3c/manifest/issues/975#issuecomment-3856671033):
>  "If we are french and also dark mode, we can't get both of those constraints. So which constraint do we drop first? We would jsut want to order them, likely, 1. color_schemes, 2. lang. So we would choose the default dark mode icon, even though it is not french."
There are several approaches here. We can leave the order up to the implementations (messy/unreliable), spec out the exact order (like you mention) OR, we stick to the webExtensions logic. In which the order of the groups determines which constraints take precedence. This basically outsources the precedence responsibility away from the spec/implementation to the manifest author. The latter actually requires the icon-sizes to be grouped like this.

If one of the icon groups contains properties (ie potential constraints) the implementation does not support / understand. The whole icon group should be skipped and the implementation should look at the next object. This allows future extensions with additional constraints without backwards compatibility risks. For example, a developer may prefer svg over webp over png, and specifies them in the type. If a browser does not understand the type, it goes to the next block. Say a new constraint like high contrast were to be introduced, it will safely be ignored by old implementations without any side effects.

If we however let the browser determine the precedence, as specified by @dmurph https://github.com/w3c/manifest/issues/975#issuecomment-3861597966. We can use the same logic for screenshots. For screenshots specifically, we could even re-use the src/sizes as I don't think showing all screenshots is a bad thing see above.

Just keep in mind currently webExtensions are designed to make the author determine the order. However given icon_variants is not widespread yet, the consequences of changing this behaviour seems low. Especially since webkit currently does not discard icon groups with unknown properties (see https://github.com/w3c/webextensions/issues/229#issuecomment-3861401359).

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

Message ID: <w3c/manifest/issues/975/3861853787@github.com>