24055 2013-12-10 18:05:07 +0000 <img>: Making <img> processing model text reusable (see comment 5) 2019-03-29 20:36:51 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other All RESOLVED MOVED http://www.whatwg.org/specs/web-apps/current-work/#the-img-element blocked on <picture> P3 normal Unsorted 26144 26145 26734 1 contributor ian annevk bzbarsky d dschulze gphemsley ian jackalmage krit mike roc zcorpan contributor oldest_to_newest 97414 0 contributor 2013-12-10 18:05:07 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/ Multipage: http://www.whatwg.org/C#the-img-element Complete: http://www.whatwg.org/c#the-img-element Referrer: Comment: Can we make some of the text here reusable in some way? E.g. notifications need to support image fetching, including decoding and supporting SVG in the same manner and using the list of available images. I assume the same goes for CSS and SVG. Posted from: 207.218.72.65 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1729.3 Safari/537.36 97430 1 ian 2013-12-10 23:10:04 +0000 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). 97451 2 annevk 2013-12-11 14:42:54 +0000 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. 97454 3 ian 2013-12-11 17:01:18 +0000 That's in mimesniff.spec.whatwg.org, I think. It's quite possible that <input type=image> has bugs, yeah. 97533 4 ian 2013-12-12 21:04:22 +0000 I'm not sure what to do for this bug. Do you have a concrete proposal? 97585 5 annevk 2013-12-13 12:50:35 +0000 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. 97753 6 gphemsley 2013-12-17 18:28:56 +0000 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? 98138 7 annevk 2014-01-08 17:40:41 +0000 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. 98175 8 gphemsley 2014-01-09 03:01:32 +0000 (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? 98452 9 ian 2014-01-14 19:27:58 +0000 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. 98482 10 annevk 2014-01-15 09:36:01 +0000 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. 98527 11 ian 2014-01-15 22:21:25 +0000 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. 98562 12 annevk 2014-01-16 10:48:16 +0000 Yes I would use it there. It's not high priority for me at all. 98811 13 gphemsley 2014-01-21 03:02:23 +0000 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 supplied media type is an XML type, the sniffed media type is the supplied media type. Abort these steps. """ This step currently reads: """ If the supplied MIME type is an XML type, the sniffed MIME type is the supplied MIME type. Abort these steps. """ If I understand correctly, this should be changed to read something along the lines of the following: """ If the supplied MIME type is "<code title>image/svg+xml</code>" (an XML type), the sniffed MIME type is the supplied MIME type. Abort these steps. """ Anne, is this the sort of change you are looking for? 98817 14 zcorpan 2014-01-21 08:42:22 +0000 I'm not Anne but that looks right to me. 100046 15 ian 2014-02-07 18:25:42 +0000 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. 103710 16 ian 2014-04-10 22:06:26 +0000 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) 103725 17 annevk 2014-04-11 08:40:32 +0000 Is that logic used for CSS background-image, SVG <image>, etc. too? Because if so, yes. 103780 18 ian 2014-04-11 20:23:19 +0000 I've no idea. 104908 19 annevk 2014-05-01 12:53:51 +0000 *** Bug 22422 has been marked as a duplicate of this bug. *** 106951 20 ian 2014-05-28 22:14:09 +0000 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. 107924 21 annevk 2014-06-17 09:18:06 +0000 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. 107958 22 annevk 2014-06-17 17:49:08 +0000 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). 108058 23 zcorpan 2014-06-19 09:26:41 +0000 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 ]] 108071 24 bzbarsky 2014-06-19 12:48:44 +0000 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. 108072 25 annevk 2014-06-19 12:51:48 +0000 We want e.g. 'mask' to support both images and SVG local and external <mask> elements without upfront distinction in code path. 108073 26 bzbarsky 2014-06-19 12:54:29 +0000 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. 108074 27 annevk 2014-06-19 12:59:08 +0000 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). 108075 28 roc 2014-06-19 13:22:17 +0000 (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. 108076 29 bzbarsky 2014-06-19 14:10:59 +0000 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... 108077 30 dschulze 2014-06-19 14:32:41 +0000 (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... 108078 31 bzbarsky 2014-06-19 14:46:28 +0000 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. 108100 32 roc 2014-06-19 23:42:54 +0000 (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. 124081 33 1626 rycowman2015 2015-11-04 16:30:41 +0000 Created attachment 1626 Check this out 124147 34 mike 2015-11-10 01:14:32 +0000 The content of attachment 1626 has been deleted 129679 35 d 2019-03-29 20:36:51 +0000 https://github.com/whatwg/html/issues/4474 1626 2015-11-04 16:30:41 +0000 2015-11-04 16:30:41 +0000 Check this out widevinecdmadapter.dll text/plain 0 rycowman2015