Notes - Manifest Working Session (EU/US) (Feb 5, 2026)

*NOTES LINK
<https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.0#bookmark=id.y5z5swmm78i0>*

icon changes for scheme & language

https://github.com/w3c/manifest/issues/975#issuecomment-3836930427

   -

   Chromium
   -

      parsing of icons src
      <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/manifest/manifest_parser.cc;l=1279;drc=8393737e4619e84795f4c565912e1b044fef2a82;bpv=1;bpt=1>
      -

      Choosing of icon: here
      <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/common/manifest/manifest_icon_selector.cc;l=123;drc=8393737e4619e84795f4c565912e1b044fef2a82>
      -

   Webkit: icon src parse
   <https://github.com/WebKit/WebKit/blob/d1cb1bf4763967eb5c1a71526d5100735405e429/Source/WebCore/Modules/applicationmanifest/ApplicationManifestParser.cpp#L300>
   ,
   -

      TODO - how does WebKit “choose” an icon for a given purpose /size -
      does it continue iterating the list and choose the ‘last’ one
that matches?
      -

   Gecko: icon src parse
   <https://github.com/mozilla-firefox/firefox/blob/main/dom/manifest/ImageObjectProcessor.sys.mjs#L197>


So - we could say - if you want localization and/or color schemes, don’t
put ‘src’ in the manifest.

Webextensions code:
https://github.com/WebKit/WebKit/blob/d6d2686c24a7aaedebadd9eba30cfb0b408b7639/Source/WebKit/UIProcess/Extensions/WebExtension.cpp

https://github.com/WebKit/WebKit/blob/7fd3e075edfbbc1ba49cbfb9cae508ae516c8d86/Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionCocoa.mm#L468

Conclusions:

   -

   Because we skip icon parsing if ‘src’ is not present (confirmed chrome,
   webkit gecko), we can use that to ensure we don’t break compatibility
   -

   Options that seemed best right now
   1.

      Fully move to the webextensions format, % needing them / us to
      specify how the ‘any’ size is chosen (first vs fallback). We also need
      non-square sizes for screenshots.
      -

         This is a BIG spec change. We would formalize the new format, and
         have the legacy format ‘parse’ into the new format
         -

         Code change definitely, but likely not huge. Not a new OS
         integration
         -

         Definitely devrel effort
         2.

      Support the webextensions format but ‘parse’ it into the old format.
      This, for devs, is the same as the first option, but for us is less work,
      as the spec change is smaller, and the code changes are smaller
      3.

      Otherwise, doing only color_scheme addition has backwards
      compatibility risk UNLESS we can confirm that Gecko & WebKit will always
      choose the ‘last’ appropriate icon from the list - this is what Chrome
      does. So devs who add color scheme icons would need to make sure
that it is
      ‘first’ in the list, and they have equivalent icon later in the list for
      the legacy impls to choose
      4.

      I18n might be better if the languages are separate, so we could do
      the above two only for color_scheme, and keep the icons and
icons_localized
      situation. This is easier for translators, but might be harder
for devs to
      know exactly what icon is chosen.
      5.

      Other options seem kinda sad, like fully denormalized
      -

         Icons
         -

         Icons_dark_color
         -

         Icons_dark_color_localized
         -

         Icons_localized
         -

         Etc 😢



Filing issues

   -

   https://github.com/w3c/webextensions/issues/949
   -

   https://github.com/w3c/webextensions/issues/950


AI Summary

Dan Murphy and Christian Liebel discussed proposals for changes to the icon
format to support dark/light theme color schemes and localization, noting
that Christian Liebel confirmed current parsing in Chromium and Gecko
ignores icon items if the `source` property is missing, which could enable
backwards-compatible changes. The participants explored aligning with the
web extensions icon format, identifying that the web extensions code uses a
"Best icon size" method to parse sizes without a formal specification. The
main options reviewed for proceeding include a full move to the web
extensions format, introducing the format only for color schemes, or
avoiding the source refactor and introducing `Lang` and `icon scheme`
properties.
AI Details

   -

   Icon Format Proposals and Backwards Compatibility Dan Murphy summarized
   the discussion regarding icon format proposals for dark/light theme color
   support and localization, noting that one proposal suggests a flat list.
   They mentioned an extreme proposal to use dictionary properties for icon
   sizes with values as paths and constraints like languages or color schemes.
   The current approach uses `icons` and `icons localized`. Dan Murphy
   highlighted that backwards compatibility is a difficulty if moving to a
   flat list approach. Christian Liebel confirmed that the current parsing in
   Chromium and Gecko, and potentially WebKit, ignores icon items if the
   `source` property is missing (00:02:47
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.y81p4nfbf800>
   ).



   -

   Alignment with Web Extensions Icon Format The discussion explored
   aligning with the web extensions icon format, which Christian Liebel
   indicated would be quite nice (00:04:58
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.y8o9s1bhvv6f>).
   Dan Murphy noted that if developers omit the `source` property in the
   manifest for localization and/or color schemes, the new format could be
   introduced while maintaining backwards compatibility (00:06:31
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.bxebek7zdz1p>).
   Christian Liebel observed that adopting the web extensions format, where
   properties are assumed to be sizes, would work since image resources with a
   failing or missing `source` are ignored (00:02:47
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.y81p4nfbf800>
   ).



   -

   Web Extensions Specification and Icon Parsing Dan Murphy raised concerns
   about the lack of a formal specification for the web extensions icon
   format, particularly regarding the parsing algorithm for sizes (00:09:14
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.l3ctukz4y6g9>).
   They also pointed out that web app screenshots, unlike web extension icons,
   are not necessarily square and would require size parsing to support
   "integer x integer" (00:12:22
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.lpq6kx38ser1>).
   Dan Murphy and Christian Liebel identified the `Best icon size` method in
   the web extensions code as the parsing logic that iterates through keys and
   attempts to parse integers as sizes (00:22:12
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.qskc1ryneags>
   ).



   -

   Review of Options for Icon Format Changes The participants identified
   three main options for proceeding with changes to support color schemes and
   localization. The first option is a full move to the web extensions format,
   which has the pro of alignment but the con of being a big change to both
   code and spec, and potentially harder for developers and localizers (
   00:24:02
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.uda9adq4w0z>).
   Christian Liebel preferred this "full-blown" version over the second option
   (00:27:13
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.7egyhdgyk0l8>).
   The second option is to introduce the web extensions format only for color
   schemes while keeping the language separate, which Christian Liebel did not
   favor (00:26:11
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.pak6nk4ob84i>).
   The third option is to avoid the source refactor, keep the existing
   structure, and introduce `Lang` and `icon scheme` properties, relying on
   the user agents always choosing the last matching icon (00:28:48
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.bais3ulydij0>
   ).



   -

   Conclusion and Next Steps Dan Murphy summarized that since all confirmed
   user agents skip icon parsing if `source` is absent, this allows for the
   introduction of a new format without breaking backwards compatibility. The
   best options identified include fully moving to the web extensions format,
   supporting the web extensions format but parsing it into the old one (less
   work, smaller spec/code changes), or only adding color scheme support under
   the assumption that user agents choose the last appropriate icon (
   00:35:05
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.ysnxghe8c60f>).
   Christian Liebel suggested the need to discuss these options with Marcos
   and Diego (00:33:24
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.dij74e1v82nb>).
   Dan Murphy noted the necessity of filing issues regarding the web
   extensions spec, particularly around any size fallback and the lack of a
   manifest parsing spec (00:32:03
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.sqdlnfp6kmd7>).
   Christian Liebel recommended adding the internationalization point that
   separating languages might be better for localization teams (00:38:24
   <https://docs.google.com/document/d/1DdU_3NhxOsEnzRUjxUrGqxaGgcom3s9jF5nYhtkG26E/edit?tab=t.qt4o0hqjl7yd#heading=h.bt7dtqr3bp2j>
   ).