-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reintroduce MediaMetadata artwork (a URL) #126
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -88,6 +88,7 @@ urlPrefix: https://html.spec.whatwg.org/multipage/; spec: HTML | |
urlPrefix: https://url.spec.whatwg.org/; | ||
type: dfn; urlPrefix: #concept- | ||
text: url parser | ||
text: url serializer | ||
text: event listener | ||
urlPrefix: https://fetch.spec.whatwg.org/; spec: FETCH | ||
type: dfn; urlPrefix: #concept- | ||
|
@@ -289,8 +290,18 @@ attribute must return the <a>media session</a>'s <a>kind</a>. | |
|
||
The <dfn attribute for="MediaSession"><code>metadata</code></dfn> attribute, on | ||
getting, must return the <a>media session</a>'s <a lt="media session | ||
metadata">metadata</a>. On setting, the <a>media session</a>'s <a lt="media | ||
session metadata">metadata</a> must be set to the new value. | ||
metadata">metadata</a>. On setting, user agent must run the following steps: | ||
|
||
<ol> | ||
<li> | ||
Set the <a>media session</a>'s <a lt="media session metadata">metadata</a> | ||
to the new value. | ||
</li> | ||
<li> | ||
Run the <a>fetch steps</a> for <a>media session</a>'s <a lt="media session | ||
metadata">metadata</a>. | ||
</li> | ||
</ol> | ||
|
||
The <dfn method for="MediaSession"><code>activate()</code></dfn> method, when | ||
invoked, must run these steps: | ||
|
@@ -1123,15 +1134,23 @@ interface MediaMetadata { | |
readonly attribute DOMString title; | ||
readonly attribute DOMString artist; | ||
readonly attribute DOMString album; | ||
readonly attribute USVString artwork; | ||
}; | ||
|
||
dictionary MediaMetadataInit { | ||
DOMString title = ""; | ||
DOMString artist = ""; | ||
DOMString album = ""; | ||
USVString artwork; | ||
}; | ||
</pre> | ||
|
||
A {{MediaMetadata}} object has a <dfn for="MediaMetadata">title</dfn>, an <dfn | ||
for="MediaMetadata">artist</dfn>, and an <dfn for="MediaMetadata">album</dfn>. | ||
|
||
A {{MediaMetadata}} object <em>can</em> have an <dfn for="MediaMetadata">artwork | ||
URL</dfn> and a <dfn for="MediaMetadata">artwork resource</dfn>. | ||
|
||
The <dfn constructor | ||
for="MediaMetadata"><code>MediaMetadata(<var>init</var>)</code></dfn> | ||
constructor, when invoked, must run the following steps: | ||
|
@@ -1141,16 +1160,79 @@ constructor, when invoked, must run the following steps: | |
Let <var>metadata</var> be a new {{MediaMetadata}} object. | ||
</li> | ||
<li> | ||
Set <var>metadata</var>'s {{MediaMetadata/title}}, {{MediaMetadata/artist}}, | ||
and {{MediaMetadata/album}} attributes to the values of <var>init</var>'s | ||
{{MediaMetadataInit/title}}, {{MediaMetadataInit/artist}}, and | ||
{{MediaMetadataInit/album}} members, respectively. | ||
Set <var>metadata</var>'s <a>title</a> to <var>init</var>'s | ||
<code>title</code>. | ||
</li> | ||
<li> | ||
Set <var>metadata</var>'s <a>artist</a> to <var>init</var>'s | ||
<code>artist</code>. | ||
</li> | ||
<li> | ||
Set <var>metadata</var>'s <a>album</a> to <var>init</var>'s | ||
<code>album</code>. | ||
</li> | ||
<li> | ||
Let <var>baseURL</var> be the <a>API base URL</a> specified by the <a>entry | ||
settings object</a>. | ||
</li> | ||
<li> | ||
If <var>init</var>'s <code>artwork</code> is present, | ||
<a lt="url parser">parse</a> it using <var>baseURL</var>, and if that does | ||
not return failure, set <var>metadata</var>'s <a>artwork URL</a> to the | ||
return value. (Otherwise <a>artwork URL</a> is not set.) | ||
</li> | ||
<li> | ||
Return <var>metadata</var>. | ||
</li> | ||
</ol> | ||
|
||
The <dfn attribute for="MediaMetadata"><code>title</code></dfn> attribute must | ||
return the {{MediaMetadata}} objects's <a>title</a>. | ||
|
||
The <dfn attribute for="MediaMetadata"><code>artist</code></dfn> attribute must | ||
return the {{MediaMetadata}} objects's <a>artist</a>. | ||
|
||
The <dfn attribute for="MediaMetadata"><code>album</code></dfn> attribute must | ||
return the {{MediaMetadata}} objects's <a>album</a>. | ||
|
||
The <dfn attribute for="MediaMetadata"><code>artwork</code></dfn> attribute must | ||
return the {{MediaMetadata}} objects's <a>artwork URL</a>, <a lt="url | ||
serializer">serialized</a>, and the empty string if there is no <a>artwork | ||
URL</a> otherwise. | ||
|
||
The <dfn>fetch steps</dfn> for a given {{MediaMetadata}} object | ||
<var>metadata</var> are: | ||
|
||
<ol> | ||
<!-- XXX https://www.w3.org/Bugs/Public/show_bug.cgi?id=24055 --> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we mention how addressing this bug would affect the fetch steps? (It's not obvious to me.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @annevk, do you think resolving that bug would change anything about how notifications fetch/decode images? If not, I don't think it'd affect media sessions either. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It would probably clarify a number of things, including how SVG is detected and that images are sniffed, etc. |
||
<li> | ||
If <var>metadata</var> has no <a>artwork URL</a>, then terminate these | ||
steps. | ||
</li> | ||
<li> | ||
If the platform supports displaying media artwork, <a>fetch</a> | ||
<var>metadata</var>'s <a>artwork URL</a>. | ||
|
||
Then, <a>in parallel</a>: | ||
|
||
<ol> | ||
<li> | ||
Wait for the <a>response</a>. | ||
</li> | ||
<li> | ||
If the <a>response</a>'s <a>internal response</a>'s | ||
<a lt="response type">type</a> is <i>default</i>, attempt to decode the | ||
resource as image. | ||
</li> | ||
<li> | ||
If the image format is supported, set <var>metadata</var>'s <a>artwork | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. An implementation will likely have a maximum image size. Bigger images will probably be scaled down or be otherwise handled. Is this something we need to mention in the spec? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you think? I'm thinking that this is something that just happens if necessary and can be seen as an instance of https://html.spec.whatwg.org/#hardwareLimitations If we use a manifest for artwork, then the problem doesn't magically go away, but at least the web developer could provide an image of the appropriate size if they make the effort. |
||
resource</a> to the decoded resource. (Otherwise <var>metadata</var> has | ||
no <a>artwork resource</a>.) | ||
</li> | ||
</ol> | ||
</li> | ||
</ol> | ||
|
||
<h2 id="extensions-to-the-htmlmediaelement-interface">Extensions to the | ||
{{HTMLMediaElement}} interface</h2> | ||
|
||
|
@@ -1353,6 +1435,7 @@ When the user agent is to <dfn>resume a web audio object</dfn> for a given | |
title: "Episode Title", | ||
artist: "Podcast Host", | ||
album: "Podcast Title", | ||
artwork: "podcast.jpg", | ||
}); | ||
</pre> | ||
</div> | ||
|
@@ -1385,6 +1468,7 @@ When the user agent is to <dfn>resume a web audio object</dfn> for a given | |
title: event.target == audio1 ? "Chapter 1" : "Chapter 2", | ||
artist: "An Author", | ||
album: "A Book", | ||
artwork: "cover.jpg", | ||
}); | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed in #58, this doesn't address preloading of artwork. Not sure if that is something we must address right away or if it can wait for later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't SW be used for preloading?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could. My current plan is to have these fetch steps, but do leave the timing up to the UA, with the advice that it should happen as late as possible. If one wants prefetching, one could use SW or
<link rel=preload>
.