Intent to Ship: Media Feeds

[Becca Hughes]

Contact emails

becca...@chromium.org

mlam...@chromium.org

sgb...@google.com

Explainer

https://github.com/WICG/media-feeds/blob/master/explainer.md

Spec

https://wicg.github.io/media-feeds/

TAG review

https://github.com/w3ctag/design-reviews/issues/477

The feedback from the TAG was reviewed and applied.

Summary

We propose a new API to allow a user agent to discover a media feed provided by a website. When fetched by the user agent the site will return a schema.org feed of personalized media recommendations for the user.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/D1sGl6UkCzs/bSiEw3rlCAAJ

Risks

Interoperability and Compatibility

The risk here should be low since the <link> tag for discovering the feed will be ignored on user agents that do not support it. The risk of changing the feed requirements based on developer feedback or product changes is also low since we are using schema.org for our data structures. This means that the structures in the feed have been well defined and discussed and cover most use cases. In the event of adding a new field this should be relatively easy but if we want to remove a field from Media Feed our parser can just ignore it.

Schema.org also provides machine readable definitions that can be used to ensure compatibility. The parser in Chromium uses these definitions to generate code for Media Feeds that adheres to the schema.org specification.

Firefox: No public signals (requested)

Edge: No public signals

Safari: No public signals (requested)

Web developers: Positive

Debuggability

There is an internal WebUI at chrome://media-feeds that allows developers to debug feeds.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,

Chrome OS, Android, and Android WebView)?

We are planning to ship on Windows, Mac, Linux and Chrome OS. For now, Android is not planned to ship.

Is this feature fully tested by web-platform-tests?

Yes. There is also a test suite of sample feeds included in the spec.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1053599

Demo links

https://beccahughes.github.io/media/media-feeds/

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5695114963845120

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

We discussed this at the API owner meeting last week and had a hard time reconciling if this API defines web-exposed behavior or not.

The spec mentioned a "MUST fetch", but doesn't say when this fetch must happen (nor what are its various parameters, e.g. its destination), and if it's something that the document can observe. Is this fetch a browser-initiated one? Is it exposed to the renderer? (e.g. through Service Workers or Resource Timing)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFeLsE%2B%2B%3DvbDpnxUci_6i0uudk0XyzFJfLTksZTbvTnZ5iSu4w%40mail.gmail.com.

[Becca Hughes]

After the discovery is complete, the rest of the logic resides in the browser. Therefore, the fetch is initiated by the browser and is not exposed to the renderer at all.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhQBGQXQt15BRB79Jw2YjHqxEDLmTR6XfgyW_jqERS82w%40mail.gmail.com.

[Chris Harrelson]

Is there anything the page author can do to detect that media feeds were discovered while loading the page?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANi3S8%3DOcfrZSS0vWZoLi6ZqFdB2_Fq6Ze32%2BpW07py%3DOZahdA%40mail.gmail.com.

[Becca Hughes]

There is nothing the page can do, but they could check their server side logs to see if the feed was fetched.

[Yoav Weiss]

On Wed, Jul 1, 2020 at 1:05 AM Becca Hughes <becca...@chromium.org> wrote:

There is nothing the page can do, but they could check their server side logs to see if the feed was fetched.

Since the actual fetch can happen at any arbitrary time (including after the relevant page is done loading), I'm tending to say that this is not a web exposed change.

[Yoav Weiss]

During the API owner call today it was pointed out to me that the feature detection part of this is web exposed, so this does require an LGTM.

But, looking over the spec, I don't see it extending HTMLLinkElement's rel's supported tokens. Thinking about it some more, it's also unclear what purpose would that feature detection serve - is there something developers may choose to do differently based on support for this feature?

So, are there plans to implement and specify feature detection?

[Becca Hughes]

Feature detection doesn't really have a purpose since this should be pretty much transparent to the website and there should not be different behaviour from a website. This is something we could remove?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiiD%2B90YRtZAHMExo40T8juonMf9M8Z-T0njKuxrLTdVQ%40mail.gmail.com.

[Yoav Weiss]

From my perspective, if this doesn't add a supported token to HTMLLinkElement.rel, this doesn't require an LGTM, as the feature is not web exposed. I also don't think the feature should add a token, as there's no action a web developer needs to take if it's not supported.

+Chris Harrelson +Mike West +Daniel Bratell +Manuel Rego Casasnovas - thoughts?

[Mike West]

https://wicg.github.io/media-feeds/#discovery-of-media-feeds relies upon an implicit extension of the (WHATWG) "link type" concept to include `media-feed` (which would ideally be "registered" as per https://html.spec.whatwg.org/multipage/links.html#other-link-types), and similarly defines a new (IETF) link relation type in https://wicg.github.io/media-feeds/#iana-link-relations.

I don't have any particular use cases in mind for a site making use of this information about the user agent's capability today, but it doesn't make sense to me to reserve it as a link type without making that reservation visible to the web. Consider other link types like "help" or "license": these are equally "useless" from a website's perspective, but they're "supported" (and therefore web-visible). I'd prefer that we do the same here.

I see two questions raised since last week's meeting that I'm curious about:

1.  https://github.com/WICG/media-feeds/issues/9 talks about scoping and multiple feeds per origin. Assuming that's something you eventually wanted to do, is there a backwards compatibility story for the feature?

2.  https://github.com/w3ctag/design-reviews/issues/477#issuecomment-652922928 suggests that the cookie story needs more explanation. Would this feature be useful without authenticated requests?

-mike

[Yoav Weiss]

On Tue, Jul 7, 2020 at 1:37 PM Mike West <mk...@chromium.org> wrote:

https://wicg.github.io/media-feeds/#discovery-of-media-feeds relies upon an implicit extension of the (WHATWG) "link type" concept to include `media-feed` (which would ideally be "registered" as per https://html.spec.whatwg.org/multipage/links.html#other-link-types), and similarly defines a new (IETF) link relation type in https://wicg.github.io/media-feeds/#iana-link-relations.

I don't have any particular use cases in mind for a site making use of this information about the user agent's capability today, but it doesn't make sense to me to reserve it as a link type without making that reservation visible to the web. Consider other link types like "help" or "license": these are equally "useless" from a website's perspective, but they're "supported" (and therefore web-visible). I'd prefer that we do the same here.

Can you clarify what you mean by them being web-visible? I don't believe they are feature detectable (e.g. `document.createElement("link").relList.supports("license")` returns "false")

[Daniel Bratell]

I think this is in a grey area but I don't want to delay this work while trying to figure out whether our approval is necessary or not so I might as well just leave an LGTM1 here (since that is what I think about the parts that are exposed to web developers).

If the thread ends in a consensus that the feature is fully external to the web environment, that is something I could accept as well.

/Daniel

[Mike West]

On Tue, Jul 7, 2020 at 2:35 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Jul 7, 2020 at 1:37 PM Mike West <mk...@chromium.org> wrote:

https://wicg.github.io/media-feeds/#discovery-of-media-feeds relies upon an implicit extension of the (WHATWG) "link type" concept to include `media-feed` (which would ideally be "registered" as per https://html.spec.whatwg.org/multipage/links.html#other-link-types), and similarly defines a new (IETF) link relation type in https://wicg.github.io/media-feeds/#iana-link-relations.

I don't have any particular use cases in mind for a site making use of this information about the user agent's capability today, but it doesn't make sense to me to reserve it as a link type without making that reservation visible to the web. Consider other link types like "help" or "license": these are equally "useless" from a website's perspective, but they're "supported" (and therefore web-visible). I'd prefer that we do the same here.

Can you clarify what you mean by them being web-visible? I don't believe they are feature detectable (e.g. `document.createElement("link").relList.supports("license")` returns "false")

You're right. I misread https://html.spec.whatwg.org/multipage/semantics.html#the-link-element:attr-link-rel-7 as including more than it does.

Still, there are a few items in the list of rel values we do publicly "support" (https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/rel_list.cc;drc=d62f6ee92b679fd9bd0de04f38c4951c192a41bb;l=29?originalUrl=https:%2F%2Fcs.chromium.org%2F) that seem only tangentially "useful" to expose. `alternate`, for instance, as well as `icon`, `next`, `canonical`, etc. It seems reasonable to do that here as well (and to update HTML to match (or, I suppose to trim our list accordingly), but that's a distinct intent...).

As Daniel said, this doesn't seem like something on which we should block this intent. I'd like some clarity around the compatibility and credentials bits I asked about, but I'm otherwise comfortable with shipping this.

-mike

[Yoav Weiss]

On Tue, Jul 7, 2020 at 3:18 PM Mike West <mk...@chromium.org> wrote:

On Tue, Jul 7, 2020 at 2:35 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Jul 7, 2020 at 1:37 PM Mike West <mk...@chromium.org> wrote:

https://wicg.github.io/media-feeds/#discovery-of-media-feeds relies upon an implicit extension of the (WHATWG) "link type" concept to include `media-feed` (which would ideally be "registered" as per https://html.spec.whatwg.org/multipage/links.html#other-link-types), and similarly defines a new (IETF) link relation type in https://wicg.github.io/media-feeds/#iana-link-relations.

I don't have any particular use cases in mind for a site making use of this information about the user agent's capability today, but it doesn't make sense to me to reserve it as a link type without making that reservation visible to the web. Consider other link types like "help" or "license": these are equally "useless" from a website's perspective, but they're "supported" (and therefore web-visible). I'd prefer that we do the same here.

Can you clarify what you mean by them being web-visible? I don't believe they are feature detectable (e.g. `document.createElement("link").relList.supports("license")` returns "false")

You're right. I misread https://html.spec.whatwg.org/multipage/semantics.html#the-link-element:attr-link-rel-7 as including more than it does.

Still, there are a few items in the list of rel values we do publicly "support" (https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/rel_list.cc;drc=d62f6ee92b679fd9bd0de04f38c4951c192a41bb;l=29?originalUrl=https:%2F%2Fcs.chromium.org%2F) that seem only tangentially "useful" to expose. `alternate`, for instance, as well as `icon`, `next`, `canonical`, etc. It seems reasonable to do that here as well (and to update HTML to match (or, I suppose to trim our list accordingly), but that's a distinct intent...).

`icon` is a good equivalence here...

In that case, for consistency, it would make sense to add this to that list as well (in implementation and spec).

As Daniel said, this doesn't seem like something on which we should block this intent. I'd like some clarity around the compatibility and credentials bits I asked about, but I'm otherwise comfortable with shipping this.

Agree. I'm also comfortable LGTMing once your questions are answered.

[Becca Hughes]

We do add "media-feed" to the supported list when the feature is enabled (so document.createElement("link").relList.supports("media-feed") would work) although this is something we did for consistency with other link types.

For the multiple feeds per origin to allow for categories. I think here we would still keep the feed as one per origin but allow ItemList as a feed item. That way a feed could contain media items directly or it can contain lists of items for more specific surfaces (e.g. News, Sport). That would also maintain backwards compatibility with this first version since older versions of Chrome would skip the ItemList since they don't support it.

For cookies and authentication, the main value of this feature is in providing recommendations that are personalized to the user and to do so we need to leverage the cookies that are stored in Chrome so the site can identify the user for which the feed is being requested.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgd-CQ0%3DO8E8198jFXjQ6zyfivty7r6p2ZvMXEmiJBmtA%40mail.gmail.com.

[Yoav Weiss]

LGTM2

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgGwVo0xe13L7QR917pig3QYCDX1bk73tU9QGUmFtLOFQ%40mail.gmail.com.