Here are my thoughts, in no good order - ideally these could be rewritten into a sensible order and specified in more strict spec-speak language:
Icon selection algorithm
Icons MUST be specified as
<link> children of the document’s
<head> with rules following the current HTML Standard. Beyond this, icons may be defined in any order - User Agents MUST NOT prioritize definition order over size in any way.
User-Agents have a “minimum viable resolution” (heretofore known as the MVR). (On a traditional desktop, this would be 16x16, on an Android phone running Chrome on Lollipop, this would be 192x192, etc.) If and only if no icons are specified in the head that provide at least the size of the MVR, User-Agents MAY look for icons in legacy vendor locations. For this reason, it is recommended that developers implement either a vector source with
sizes="any", or a sufficiently large raster source, as a final fallback.
User-Agents MUST start by loading the icon defined by a link that is smallest while still being greater than the MVR. (For the purposes of this selection algorithm, “any” has an infinite size.)
Caveat: if an icon is defined that is smaller but “close” (by the UA’s assessment) to the MVR, and the next-largest would be “prohibitively large” (again by the UA’s assessment) to retrieve, the User-Agent MAY elect to upscale the “close” smaller icon (or display a reduced-size version with transparent margins). The User-Agent MUST NOT request undefined / vendor-specific locations as long as a larger icon is defined.
(Example a User-Agent with an MVR of 196px encounters a page with a 192px icon defined and a 9000px icon defined, that User-Agent MUST use either the 192px icon upscaled, or retrieve the 9000px icon. it MUST NOT look for /apple-touch-precomposed-196px.)
If an icon fails to load (eg. 404), User-Agents MUST re-enter this logic with that icon removed from the pool. User-Agents MUST retry loading that icon the next time the page is loaded.
If any icon link is specified without a size in the head, if no suitable links with sizes are specified, the first one MUST be retrieved before resorting to vendor icons. If, after retrieval, it is larger than the MVR, it MUST be downscaled using the User-Agent’s best-quality downscaling. If it is smaller than the MVR, User-Agents MAY search fo an alternative in legacy vendor locations.
manifest.json takes precedence only when a page is being “installed” in some way, in which case it is assumed that the User-Agent will retrieve all relative icon sizes needed to represent the icon in its interface (using the same downscale-next-largest logic).
(Maybe manifest.json could be used as an alternative in the event that no icon links are defined in
<head> - that would be polyfillable.)
Vendors are strongly discouraged from implementing any new vendor-specific icon locations (read: plz no apple-touch-icon-973px in 2017).
Each page has a property (or method) like
document.displayIcon that resolves to the URL of the icon that is being used to represent the page live. (Assigning to this property could set the href on the corresponding link element, or create one on demand if none is present.)
Icons are retrieved the same way as stylesheets, and are refreshed with the same logic.
(One thing that would be cool would be if the fetch(es) for this (these) resource(s) were also exposed, but the Fetch API isn’t sufficiently specced out to permit designing this yet AFAIK.)