Intent to Implement: Content Index API

[Rayan Kanso]

Contact emails raya...@chromium.org, pe...@chromium.org Explainer https://github.com/rknoll/content-index TAG review https://github.com/w3ctag/design-reviews/issues/379 Summary The content index allows websites to register their offline enabled content in the browser. This allows the browser to improve their offline capabilities and offer content to users to browse through while offline. This data could also be used to improve on-device search and augment browsing history. Motivation Unreliable or even unavailable network connections are very common on mobile devices. This API would allow browsers to show meaningful content to users in these situations and sites to increase user engagement. Browser vendors are already looking for content relevant to the user, based on their browsing history, and make it available to be consumed offline. This is not ideal as it ignores the entity with the most knowledge of that content - the providers themselves. With this API they can highlight user specific, high quality content through the browser. Grouping content by a category (e.g. 'article', 'video', 'audio') allows an even richer experience as the browser is able to understand what kind of content is available and show a relevant UI. Risks

Interoperability and Compatibility The primary risk is lack of adoption by other browser vendors, but we're actively soliciting feedback as part of this project. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals

Debuggability Will have a section in DevTools' Application panel under `Background Services`. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? No, it will not be supported on WebView since it relies on Service Workers.

Is this feature fully tested by web-platform-tests? No, tests will be added as part of the implementation. Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5658416729030656

[Martin Šrámek]

Hey Rayan,

If I understand the explainer correctly, it seems that this could be implemented with various levels of browser involvement. In the simplest form, the website would just use this API to deliver articles, videos, etc. in a structured format for its service worker to display. However, it seems that there's a proposal that the browser could directly display this on the offline tab page, or even further expose the data to the operating system.

Is that right? Does this Intent also involve browser-side changes? 

Best regards,

Martin

--
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/CAL6mntiAAcgo3et47-9_4EQhxXH4CgwFR5eWxiDzxoagyxwZBQ%40mail.gmail.com.

[PhistucK]

> No, it will not be supported on WebView since it relies on Service Workers.

In case you think service workers are unavailable in WebView, this is a misconception. See https://groups.google.com/a/chromium.org/d/msg/chromium-discuss/EnEjyoJRrr8/AiuP240MBwAJ.

☆PhistucK

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

[Rayan Kanso]

Is that right? Does this Intent also involve browser-side changes? 

Yes. Websites will register their offline-enabled content with the browser, and the browser can suggest some of them to the users. For example, you get a list of suggested articles when you open a new tab on Chrome for Android. This would be a good place for the browser to suggest some of the registered articles, especially of the device is currently offline. Exposing the data to the OS is a suggestion to give the content a more native feel. All of these are browser-level decisions though. The proposed API is just for websites being able to register/delete/query content metadata with the browser.

In case you think service workers are unavailable in WebView, this is a misconception

 Yes, that is a good point. The API doesn't make sense within the context of WebView though, so it will still be excluded.

[PhistucK]

> Yes, that is a good point. The API doesn't make sense within the context of WebView though, so it will still be excluded.

Indexing content from hybrid applications (for operating system search mechanism) could be a use case, though.

☆PhistucK