I don't know. The <img> behaviour is pretty wacked. I agree that SVG and CSS probably want to use some common rules, but I don't know if <img> is where I'd take it from. Even <input type=image> doesn't reuse <img> logic.

There are other things in HTML that could reuse the same logic as SVG and CSS if there was common prose, e.g. icon="" (which is currently underdefined IIRC).

It seems type=image has a bug therefore. I'm pretty sure browsers have the "list of available images" hack in place there too.

Also, where did the text go about first checking if the image is SVG through its Content-Type header and then sniffing? That's no longer covered it seems and is something we want to share.

That's in mimesniff.spec.whatwg.org, I think.

It's quite possible that <input type=image> has bugs, yeah.

I'm not sure what to do for this bug. Do you have a concrete proposal?

I think some kind of wrapper for fetch named "image fetch" that takes into account "list of available images". Then some kind of shorthand for getting an image out of the retrieved resource and maybe an algorithm that wraps the whole thing if we don't need much variety among icons/notifications/CSS/SVG for this.

mimesniff does not seem to deal with Content-Type saying image/svg+xml at the moment.

The SVG MIME type is an XML type, so it is not treated specially.

Is there something you'd like me to change in mimesniff?

Well, in the image context you need to not pass the image to the bitmap decoders if that is the specified (not sniffed) MIME type. Otherwise the MIME type is ignored and it will be passed to the bitmap decoders. At some point that information was present in either HTML or MIME Sniffing.

(In reply to Anne from comment #7)
> Well, in the image context you need to not pass the image to the bitmap
> decoders if that is the specified (not sniffed) MIME type. Otherwise the
> MIME type is ignored and it will be passed to the bitmap decoders. At some
> point that information was present in either HTML or MIME Sniffing.

I'm not sure I understand what you're asking of me. Currently, mimesniff only dictates how to determine the type of a file; it doesn't say anything about how to parse the file once that determination is made. In the case of SVG, if a file is tagged as image/svg+xml, that is assumed to be correct and no further sniffing is done.

Can you point to a particular section of mimesniff that you think describes incorrect behavior?

So what are the places that should use the "list of available images" and related terminology? <input type=image> and <img>, and what else? What other specs have editors who are actually willing to reference this?

I'd rather punt on this for a while if nobody's actually going to use this.

As far as I know CSS and SVG need this. Notifications API needs this. Browsers have one code path for dealing with image loading and decoding as I understand it.

If they would not reference a central "image fetch & decode" algorithm those specifications would be telling lies.

So you're planning on using this in http://notifications.spec.whatwg.org/ ?

I entirely agree that this should happen eventually, I'm just trying to work out how to prioritise it.

Yes I would use it there. It's not high priority for me at all.

Anne has suggested to me that, in an image context, only "image/svg+xml" is treated as canonical; other XML types are sniffed for image-ness. (I haven't tested this to confirm.)

It seems that the lack of this distinction in the mimesniff spec is the result of a misunderstanding on my part of the original text.

The offending change is here (dated 2012-11-03):

https://github.com/whatwg/mimesniff/commit/24098021f526233ad5ba7f69eaf387b696b7032a#diff-1feda49b40370635faef8b655f144f64L1601

The original text read (using the terminology and context):

"""
  If the <var>official-type</var> is "image/svg+xml", then let the
  <var>sniffed-type</var> be the <var>official-type</var> (an XML type) and
  abort these steps.
"""

This got changed to the following when the pattern matching algorithm was factored out:

"""
   If the <span>supplied media type</span> is an <span>XML type</span>, the
   <span>sniffed media type</span> is the <span>supplied media type</span>.

   Abort these steps.
"""

This step currently reads:

"""
   If the <span>supplied MIME type</span> is an <span>XML type</span>, the
   <span>sniffed MIME type</span> is the <span>supplied MIME type</span>.

   Abort these steps.
"""

If I understand correctly, this should be changed to read something along the lines of the following:

"""
   If the <span>supplied MIME type</span> is "<code title>image/svg+xml</code>" (an <span>XML type</span>), the
   <span>sniffed MIME type</span> is the <span>supplied MIME type</span>.

   Abort these steps.
"""

Anne, is this the sort of change you are looking for?

I'm not Anne but that looks right to me.

The idea back when this was in the HTML spec was that image/* would be processed as image, and then I had to explicitly carve out image/*+xml. I don't recall ever having an explicit test for image/svg+xml. But I could be wrong.

Do the people who want to reuse this also want to reuse the <img> two-loads-in-parallel logic that browsers apparently do? (q.v. bug 24711 comment 20)

Is that logic used for CSS background-image, SVG <image>, etc. too? Because if so, yes.

I've no idea.

*** Bug 22422 has been marked as a duplicate of this bug. ***

zcorpan, sending this to you so you can keep this in mind when doing edits. Don't worry about it if you don't want to actually do it.

SVG/CSS makes this harder. They have some constructs (<feImage>, 'mask') where a URL either references an element or an image. This can be just a fragment identifier for the element case. But somehow they probably end up using most of the same image logic as we do elsewhere.

We might be able to refactor the cases in comment 21 to only do a fetch for an image (and handle external elements with different syntax).

From annevk
[[
SVG in general wants to use that algorithm also for masks and paint servers and such
so the basic algorithm should probably either return an XML tree or an image
or failure
and the XML tree is only when the MIME type is image/svg+xml
and with scripting disabled
]]

Hrm.  SVG paint server caching rules are not the same as image caching rules (e.g. the former is cached per display document but the latter is cached per document), no?  They also have different restrictions in terms of same-origin requirements, as I recall.  I'm not sure how similar the two cases really end up being.

We want e.g. 'mask' to support both images and SVG local and external <mask> elements without upfront distinction in code path.

I distinctly recall there being spec discussion about UAs needing to know before starting the load whether they're doing one that follows the image rules or the SVG external resource rules.  Did that actually get resolved?  Because in practice those rules are _very_ different.

Well, when I discussed it with roc yesterday we came to the same conclusion we came a year ago as to how to harmonize those rules. Of course, we could be missing something. But the idea was to apply the same restrictions to external elements as are applied to images today (e.g. we would start forbidding application/xml responses).

(In reply to Boris Zbarsky from comment #24)
> Hrm.  SVG paint server caching rules are not the same as image caching rules
> (e.g. the former is cached per display document but the latter is cached per
> document), no?  They also have different restrictions in terms of
> same-origin requirements, as I recall.  I'm not sure how similar the two
> cases really end up being.

Gecko currently implements them quite differently. I'm proposing we change that both in specs and implementation to always use the image load behavior. Given that Webkit/Blink don't implement external resource loads at all (not sure about IE) I don't think we need to worry much about compatibility.

Using the image load behavior (with per-document, not per-display-document caching) for external resources can easily lead to infinite load graphs when two external resource documents cross-reference each other.  Note that images don't have that problem, since we disallow external loads from SVG images.  Is the plan to forbid external loads from externally loaded paint servers as well, then?

If we don't plan to forbid that, we could move move to per-display-document caching for images and paint servers, which would help the cross-referencing situation, but then we can't share the same SVG image across multiple loading documents, since it needs to have a concept of unique "display document" it's associated with...

(In reply to Boris Zbarsky from comment #29)
> Using the image load behavior (with per-document, not per-display-document
> caching) for external resources can easily lead to infinite load graphs when
> two external resource documents cross-reference each other.  Note that
> images don't have that problem, since we disallow external loads from SVG
> images.  Is the plan to forbid external loads from externally loaded paint
> servers as well, then?

Yes, that is what we plan. The exact same fetching model for external SVG resources (element references) and images. Including a restriction on loading further external resources.

Does this address you concerns?

> 
> If we don't plan to forbid that, we could move move to per-display-document
> caching for images and paint servers, which would help the cross-referencing
> situation, but then we can't share the same SVG image across multiple
> loading documents, since it needs to have a concept of unique "display
> document" it's associated with...

Mostly, yes!

The only remaining concern I have is that the image cache, afaik, is a best-effort cache (in the sense that it can be cleared or just generally evicted) while the external resource thing is persistent over document lifetime (per spec and in Gecko's implementation).  I guess we could change that latter behavior, though.

(In reply to Boris Zbarsky from comment #31)
> The only remaining concern I have is that the image cache, afaik, is a
> best-effort cache (in the sense that it can be cleared or just generally
> evicted) while the external resource thing is persistent over document
> lifetime (per spec and in Gecko's implementation).  I guess we could change
> that latter behavior, though.

Yes, we'd change that too.

Created attachment 1626 [details]
Check this out

The content of attachment 1626 [details] has been deleted

https://github.com/whatwg/html/issues/4474