This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23581 - The case when @src refers to a image without intrinsic width/height (SVG) is undefined.
Summary: The case when @src refers to a image without intrinsic width/height (SVG) is ...
Status: NEW
Alias: None
Product: CSS
Classification: Unclassified
Component: Image Values and Replaced Content (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Tab Atkins Jr.
QA Contact: public-css-bugzilla
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-21 12:38 UTC by contributor
Modified: 2016-02-05 08:02 UTC (History)
7 users (show)

See Also:


Attachments

Description contributor 2013-10-21 12:38:08 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html
Multipage: http://www.whatwg.org/C#dom-img-naturalwidth
Complete: http://www.whatwg.org/c#dom-img-naturalwidth
Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/

Comment:
The case when @src refers to a image without intrinsic width/height (SVG) is
undefined.

Posted from: 219.236.246.147 by kennyluck@csail.mit.edu
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Comment 1 Ian 'Hixie' Hickson 2013-10-21 16:14:25 UTC
Looks like I need to pass CSS Images a flag that says the default object size is 100% of the containing block width, or something. But it has to take into account margins and padding. 

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2575
   http://dev.w3.org/csswg/css-images-3/#concrete-object-size
Comment 2 Ian 'Hixie' Hickson 2013-10-21 21:08:18 UTC
This'll probably need changes to the HTML rendering section to set some flag or something, but for now, the CSS side of this needs to be adjusted first. Punting to Tab as per discussion on IRC for now. Please send it back when you're ready for something on the HTML side. Thanks!
Comment 3 Philip Jägenstedt 2016-02-04 18:08:39 UTC
David, what do implementations actually do?
Comment 4 David Vest 2016-02-05 07:31:48 UTC
What Blink (and WebKit unless they have changed it recently) does is
pretty broken.

For naturalWidth and naturalHeight, a default 300x150 size is
hard-coded in the svg specific <img> code (yes, separate from the
usual CSS mechanics) and used as a fallback size in case of missing
intrinsic width or height.

In general, the Blink code doesn't handle images with empty sizes well
(a legacy from raster-only images, empty sized images are null and
basically in error), so I presume that's why someone chose 300x150 as
a better size than nothing.

Also, post-fork, Blink has added resolving missing width and height
using the aspect ratio (from viewBox, if any) in a step towards the
default sizing algorithm. I'm not sure WebKit has that.

See
third_party/WebKit/LayoutTests/fast/dom/HTMLImageElement/image-natural-width-height-svg.html[1]
in chromium repo for an example how it manifests. I can only guess
what Firefox does, but they pass the mentioned test.

[1] https://chromium.googlesource.com/chromium/blink/+/72fef91ac1ef679207f51def8133b336a6f6588f/LayoutTests/fast/dom/HTMLImageElement/image-natural-width-height-svg.html
Comment 5 Philip Jägenstedt 2016-02-05 08:02:44 UTC
So, how should this all be spec'd ideally? Do we have use counters suggesting that it needs to do something sane? If not, could it be treated as an error so that not even people making 300x150 images can neglect to set up a viewBox?