search

w3c / manifest

Manifest for web apps
https://www.w3.org/TR/appmanifest/
Other
652 stars 156 forks source link

Should load/error events fire when manifest is loaded? #188

Closed marcoscaceres closed 10 years ago

marcoscaceres commented 10 years ago

When the manifest is loaded using link rel="manifest" href="whatever", should a load/error events fire when manifest is loaded?

marcoscaceres commented 10 years ago

... or fails to load

anssiko commented 10 years ago

onload/onerror "must be supported by all HTML elements other than body and frameset elements, as both event handler content attributes and event handler IDL attributes" as per the HTML spec.

We get this for free by using the link element. The default descriptions for the events seem appropriate too: load event is "fired at an element containing a resource (e.g. img, embed) when its resource has finished loading", the error event is "fired when unexpected errors occur (e.g. networking errors, script errors, decoding errors)".

Unless we opt out from this behavior (that would need to be spec'd), one of the events would be fired upon fetching the manifest (assuming the UAs will not speculatively try to fetch the manifest):

<link rel="manifest" href="manifest.json"
      onload="console.log('success!')"
      onerror="console.log('error!')">

If it is not a concern that these events may reveal that the user initiated "bookmarking" I suggest we fire these events similarly to other link elements.

WDYT?

mounirlamouri commented 10 years ago

The <link rel=manifest> such as <link rel=icon>, are merely hints to the UA. The UA might or might not fetch those resources and the moment when they are fetched is UA-specific. As long as the specification doesn't require the manifest to be fetched ASAP, I think we should not fire a load event. Exposing a UA-specific behaviour sounds like a foot gun for interoperability. We could easily require those events to be fired later if it makes more sense.

marcoscaceres commented 10 years ago

I agree with @mounirlamouri. Lets hold for now and not fire any events. However, we should leave this open till we get more review. It might be something we specifically ask feedback on from other people who might know better (e.g., @darobin).

anssiko commented 10 years ago

Sounds good to me. Needs review.

marcoscaceres commented 10 years ago

Added NEEDS REVIEW label. We can use that for things we need wider input on.

Hixie commented 10 years ago

The way the HTML spec is written, the idea is that you'd have a generic function in place to handle things like rel=icon or rel=stylesheet or rel=manifest, etc, that automatically handles all the logic of firing load/error events, progress events, handling media="" attributes, etc. So you would get all the logic for free, essentially, and authors would be able to rely on a consistent interface for all these features. The alternative is that for each of these keywords, we have to reimplement the logic we want, we have to separately spec the logic we want, we have to document it all separately, and authors never know what to expect.

marcoscaceres commented 10 years ago

So, after much back and forth and some internal discussions seems that killing the events is the right thing to do for now. There doesn't appear to be any use case for them, and their dispatching is non-deterministic.