Categories, meaning & extensibility

[quasicomputational]

I'm a bit concerned around the extensibility situation for categories.

First, in the spec itself, a comprehensive listing of categories that are guaranteed to be understood as a baseline would be a good idea.

The list that is there (in the IDL) is undescribed and opaque; what's the meaning of the different values, and when should they be used? E.G., I see audio and article are separate categories; which one does a spoken rendition of a magazine article fall into? That also seems quite different to a piece of music, but both could fall under audio. Maybe this should be using something like schema.org's ontology, taking a combination of all the (understood) categories.

Categories are inextensible without some way to indicate less-preferred-but-more-understood fallbacks. ARIA and some CSS properties have a first-understood-value-wins rule; alternatively, a combination of all the applicable understood values could be used, like RDFa and microformats.

(This point really is a quibble.) Using un-namespaced tokens for category means that extension is risky, as someone else might be using the values you add. If the values were URLs, anyone could mint new values without risking collisions.

[rayankans]

I agree with all the points you made. The categories in the explainer are currently undescribed and a bit hand-wavy. The point of that field is to give a hint to the browser about the type of the media to be consumed, rather than content, which has all of the pitfalls you described. This is intended to help browsers categorize the entries, and maybe show specialized UI for the different categories.

[jeffposnick]

With the understood caveats that the current example categories are hand-wavy, I think it makes senses to add 'image' as one of the categories that we call out as being meaningful to browsers. If I have a offline-capable PWA that caches various media files, having to categorize a page that displays an image as an 'article' doesn't make sense.

[rektide]

I'd note that:

• media-feeds has some questions about how they want to scope their feeds, that sounds related, https://github.com/WICG/media-feeds/issues/9
• and IMO, notifications also imo direly need channels to scope their notification feeds into too. just created https://github.com/whatwg/notifications/issues/154 to start talking about this.

That content has categories... further reinforces my general sense that "channels"/categories/scope or some kind of top-level containerization context would greatly benefit the web & it's many APIs.