Manifest-icon-like metadata artworks.

[xxyzzzq]

Make the artwork spec more like WebApp manifest icons, which has src,
type and sizes fields. The texts are based on pull request #126

Fixes #56

[mounirlamouri]

I think we should use FrozenArray here while things are readonly (I don't think it should be readonly but that's orthogonal ;)).

[xxyzzzq]

Done.

[eric-carlson]

artwork is a mass noun so it does not need to be pluralized.

[xxyzzzq]

Done.

[mounirlamouri]

With Eric comment applied this lgtm.

[foolip]

It doesn't look like one can do anything with a MediaArtwork instance, so should it have a constructor? Presumably manifests of this form will make sense for things other than Media Session as well, but the name MediaArtwork probably won't make sense in that context.

Assuming there's still the ambition of having this for notifications as well, where can the shared bits be put so that both specs can use them?

[foolip]

What I'm getting at here is that maybe it would be nice if artwork were a FrozenArray<SomeDictionary> artwork where SomeDictionary wouldn't have an interface object (because it's not an interface). But the trouble is of course that then you could do session.metadata.artwork[0].src = 'bla' and that wouldn't do anything useful. Is it possible to just freeze those objects as well, is that a pattern that exists anywhere in the platform? @annevk @domenic

[foolip]

Also CC @doomdavve

[mounirlamouri]

I don't think using dictionaries this way would be legal. To quote WebIDL: "Dictionaries must not be used as the type of an attribute, constant or exception field."

[foolip]

Tried to find good URL, filed w3c/manifest#469 instead.

In the meantime, can you use https here?

[xxyzzzq]

Done.

[foolip]

I don't think using dictionaries this way would be legal. To quote WebIDL: "Dictionaries must not be used as the type of an attribute, constant or exception field."

Strictly speaking it wouldn't violate that, but it would be (unacceptably) weird if session.metadata.artwork[0].src = 'bla' changed the src property without that taking effect.

Since the internal object will have to be a copy of what is passed (with src resolved), perhaps we could just say in prose that these new objects are frozen?

[mvano]

I don't think it's common practice to try again with another source when an image resource fails to decode or turns out to be unsupported. Is there precedent for this? In notifications, we just fall back to having nothing or a default resource.

[xxyzzzq]

Now we say "the user agent may have fallback behavior such as displaying an default image as artwork."

[domenic]

is that a pattern that exists anywhere in the platform? @annevk @domenic

Yes, it is used by Notification.prototype.actions: https://notifications.spec.whatwg.org/#dom-notification-actions (but see also whatwg/notifications#74 for a wording tweak).

[mvano]

For context, I'm making a similar change in the notifications spec: whatwg/notifications#76

@domenic: I think we could stop calling freeze (or SetIntegrityLevel) there by using an interface with readonly attributes instead of a dictionary.

[domenic]

Yes, but that would be semantically different... The whole question is whether we should be creating dummy interfaces to work around how Web IDL makes it awkward to have frozen dictionary instances, or whether we should just use ES's primitives to reuse the dictionaries we already have.