Clarfiy behavior of <link rel=manifest media>

[marcoscaceres]

What is the expected behavior when there is a media attribute present? Should it be ignored?

[mounirlamouri]

We should ignore media attribute such as rel='icon' do. It's a footgun. And we want the manifest to be a unique way to describe a web app. Having media being applied would be crazy.

[marcoscaceres]

It wouldn't be crazy, it would just be kinda weird (but that's ok). Of the behavior is already specified to work out of the box with link, then I think we should leave it.

[anssiko]

@marcoscaceres Wouldn't that be like restricting bookmarking of a page depending on the media type http://www.w3.org/TR/CSS21/media.html#media-types and media features http://www.w3.org/TR/css3-mediaqueries/#media1? Seems a bit weird indeed, and I have hard time figuring out a good use case.

Given we only support a single <link rel="manifest"> per document currently (I assume we do not want to allow multiple per document), this does not seem too helpful:

<!-- use only if media_query_list evaluates true, otherwise act as if there is no manifest -->
<link rel="manifest" media="<media_query_list>" href="manifest.json">

[marcoscaceres]

So, we've banned media for now (as well as having event fire onload/error, etc.).

For the record: I still don't think we should be screwing with the semantic/behavior of elements. Creating special cases leads to unpredictability and inconsistency in the platform. Banning things that we get for "free" (by virtue that they are explicit in the definition of the link element) because we are not able to come up with use cases right now doesn't feel right to me personally.

I'd really like to get a bit more input here from people like @Hixie, @darobin, @hsivonen before we ship anything.

[marcoscaceres]

See also: #188 (comment)

[marcoscaceres]

Just noting that the strongest case for banning media is to allow synchronization of manifests across devices: so that installed apps can be synched across devices. In order to make that workable, we need #168 (conditional system for handling future extensions - i.e., a way of declaring media-query-like things in the manifest).

[annevk]

Wait why would you ban the events? That seems wrong.

[marcoscaceres]

@annevk I'll preface this comment by stating that I think we should fire the events and keep consistency with HTML.

I think @mounirlamouri's rationale is that some user agents may only load the resource when needed (when a user presses "add to homescreen") while other user agents may apply it dynamically at some point in time (even in the background without loading any HTML documents at all, in case of applications synching across devices). IIUC, there would not be any certainty across UAs about when the event would fire - leading to unreliable behavior for devs. Personally, I don't see this as a problem (as it might be the same as with stylesheets that match on particular media - and likely on particular user agents). The other argument is that there is not a strong use case for firing the event: what would devs do with it?

[annevk]

They could detect it being used, for instance. I'm not sure what the rationale was for style sheets, but I'm not sure why it would not apply to this.

[marcoscaceres]

Just a thought: if we are looking at special-casing the behavior of link for manifests, then link might not be the right element for associating a manifest with a web application. We should maybe use an attribute on the html element instead (as we did way back about a year ago).

[ehsan]

I've been talking to Marcos about the downsides of using the link element for this purpose for a while, and here's a summary of my thoughts so far on this issue.

1. Using the link element means that we are going to need to dishonor CORS by default, which seems wrong for a new fetch operation added to the platform.
2. It means that we are going to need to handle the case where there are multiple manifest links in the document.
3. It means that we need to worry about dispatching the load/error events and as previously noted here, the time at which the UA decides to load the manifest might be UA dependent which makes the usefulness of authors depend on those events questionable.
4. We're going to need to do hacks for the media attribute, as also noted here.

It seems to me like at this point perhaps we should reconsider whether link is the right element for this job, since it seems to me like we're spending more time making the existing semantics of the link element adapt to this case than the potential benefit we'd get out of reusing this element. Here's a strawman counter proposal: how about we use an attribute on the document element (name to be bikeshedded) to point to a URL where the manifest can be found?

[stain]

media does not make sense for many link relations, why is it a problem to ignore it also for rel="manifest"?

Edit: On second thought, given the quite media-specific content of the manifest, then the media attribute should very much be honoured. You might want "display": "fullscreen"; "orientation": "landscape" on media=tv, and "display":"standalone"; "orientation": "portrait" on media=handheld

[marcoscaceres]

@stain, we are hoping to cover that in #168. That is, so authors can just create one manifest rather than putting this in the HTML. Doing so would allow manifests to be sync across multiple devices.

So like:

{
    "orientation": "any",
    "@media tv": {
        "display": "fullscreen",
        "orientation": "landscape"
    },
    "@media handheld": {
        "display": "standalone",
        "orientation": "portrait"
    }
}

[marcoscaceres]

@stain we are hoping to address that use case by supporting CSS media queries directly in manifest (#168). That would allow authors to only have to define a single manifest and would allow automatic synchronization of web applications across multiple devices.

[marcoscaceres]

(apologies for the double post - Fx Nightly crashed on me when I commented the first time... yet it managed to post my reply!)

[annevk]

Some of @ehsan's points (in particular CORS and media="") apply to HTML imports. It's not a problem there. We can decided based on the relation what type of fetch to initiate and whether to ignore media.

Multiple manifest links seems more annoying. Is there a future where that would make sense?

The events don't seem that problematic to me.

[marcoscaceres]

@annevk we were not able to come up with a use case for multiple link rel=manifest either. Right now, in the spec, we just take the first in tree order when needed.

So, screw it, I'm just going to copy what HTML imports does (including firing the events). Note, that HTML Imports doesn't seem to deal with the crossorigin attribute at all - which I think is a bug there.

So, the fetch request's mode will be CORS; and the ommit credentials will be "always" unless the crossorigin attribute says otherwise.

[ehsan]

I'm happy with this. Thanks a lot, Marcos! :-)