Need to specify client of image objects when fetching #465
Comments
|
Moving @annevk's comments from #443 here...
Not necessarily. The perhaps short-sighted view is that "installation" and downloading of the icons is based on a single active Document...
If the Document vanishes, then the installation process would stop (this is not currently captured in the spec).
It uses the Document's security principle, respecting |
|
A manifest is only useful when you "install"? Oh my. We wouldn't use it for favicons and such? |
Probably not, no. They are only really useful for representing a larger grouping of URLs ("an app" or "a site"). On a page-by-page basis, it seems fine to keep using favicons and link rel=icon. |
|
It just sounds so... pointless. And a bit of a pain from a security perspective if it's anchored neither here nor there. Though maybe document-that-linked-to-it-first is good enough. |
FWIW in Firefox OS 2.5 we use icons from a manifest in the URL bar without installation. We assume the manifest icon applies to the whole site whereas a link rel=icon applies to a single page. We fall back to a page icon if a site icon isn't provided. |
Will that make it a useful part of the platform?
|
|
Maybe, I think a big problem is that the delivery is late and cannot be relied upon when interpreting a document. If we had something that was guaranteed to be available we could put CORS information in there, CSP, and other things. But the late-binding approach kills it I think. |
|
(To be clear, I'm pretty sure I mentioned that to you before, though maybe not in specific enough terms.) |
The benefit of the manifest is it's fetched when it's needed, which may be "never" in most visits. Previously we had a big ol' dump of meta-crap sitting in the |
|
@jakearchibald except you need icons and such each visit. |
|
Yeah, so that stuff is still needed in the head. So theme color & an icon (if it isn't |
|
Still seems rather pointless to have a whole new resource for just that including all the complexity it brings. Might as well insert some additional icons later in the main document. Especially given that we need something manifest-like for origins that is available straight away. |
|
Also, you're assuming an awful lot about the particular UI of a user agent. What if browsers with more room for the favicon return? What if the user agent supports higher resolution there? All those would require the icon to be available together with the main resource. |
|
Fair, it would need to be downloaded earlier in that case, but at least it's cachable and doesn't need to block content render. |
|
Can you really say that a couple of extra elements in |
|
https://github.com/h5bp/mobile-boilerplate/blob/master/index.html it was starting to get pretty bad. |
|
So once you hit 11 icons it's time for a new format that lists 10 of them? |
marcoscaceres
changed the title
|
Talked to @annevk. Reopened so we have a correct reference to an environment settings object (one that maps to a concrete thing in the implementation). Gecko does not currently implement actual acquisition of image objects from the manifest - so I don't have a concrete example of what we do... (I had a WIP patch that used a |
marcoscaceres
changed the title
|
@marcoscaceres Should this move over with |
|
Yes, it should be specified as part of the fetching model. |
|
Closing as fetching an image resource is specified in terms of fetch. If there are specific bugs or clarifications needed (e.g., #851), then can deal with them separately. |
@annevk wrote, re: obtaining image objects:
The text was updated successfully, but these errors were encountered: