<rdar://problem/5616982> The attached html uses an SVG with width and height 100% as an <img>. The <img> gets the appropriate "default" size of 300 x 150, but the SVG never draws inside the space. This default size may be a problem too -- certainly it differs from Opera. But it seems like a more pressing problem that SVG doesn't render at all.
Created attachment 17567 [details] test case
Created attachment 17568 [details] SVG with width and height 100%
The right fix for this is bug 12095. It requires implementing an interinsicWidth() and intrinsicHeight() call which return Length objects instead of floats. I think that's all discussed in bug 12095, certainly in one of the bugs around here. I'm happy to discuss what little more I might know over IRC if you like.
I talked with Hyatt about this, and we think that the approach of new size-negotiation functions on Image will be too low-level a fix. We think this will need to be fixed separately in the background size code, the border code (for border-image) and the <img> rendering code.
Part of this support was landed with: http://trac.webkit.org/projects/webkit/changeset/28856 Still need support for background: and border-image: however.
Support was added for background in r28637, and for border-image in r28778. This is fixed.
I have to reopen the bug. Attached test case doesn't work in the latest Webkit r31132 on Mac OS X 10.5
(In reply to comment #0) > <rdar://problem/5616982> > > The attached html uses an SVG with width and height 100% as an <img>. The <img> gets the appropriate "default" size of 300 x 150, but the SVG never draws inside the space. This default size may be a problem too -- certainly it differs from Opera. But it seems like a more pressing problem that SVG doesn't render at all. Heh I hope you did not mean that the square is black when you said "it doesn't render at all". The ballon.svg has a failure in it: It uses the non-existant <def> element. Inside that block no renderer is created at all -- Opera just ignores this, which is wrong. If you do s/def/defs/ the balloon.svg (standalone) looks and animates just as in Opera. If you embed balloon.svg (with the s/def/defs/ fix) in your test html document, you'll now see a turquoise part of the image. You will _not_ see the balloon.svg scaled to fit in the <img>, this would be wrong. Compare to Opera. Anyhow, I'm testing this with my local SVG-as-image-rewrite-patch, but it was correct before as well.
Note that using: div { width: 100px; height: 100px; } <div> <img src="someImgWithNoViewBoxAndWidthHeight100p.svg"> </div> That renders fine, but "img, div { width: 100px; height: 100px; }" disables rendering at the moment, so the bug is still valid, but in a different form. I'm working on it.
(In reply to comment #9) When fixing the attached balloon.svg like I described in an older post - we're now matching the Opera behavior 1:1. FF is different it sizes the image to 300x150, but this is not correct. The <img> should be sized 100x100. If you want the SVG image with width/height 100% to fit into the 100x100 box of the <img>, you need to supply a viewBox on the embedded <svg>, as percentage values do NOT define an intrinsic size. Currently this image has neither an intrinsic size, nor an intrinsic ratio, so the rendering from trunk is absolutely correct. This is already covered by existing tests, so we can close this bug report now! -- I'm going to file another bug report for balloon.svg, it makes use of SVGSVGElement.viewport which we currently don't implement - that's why the background doesn't look as intended (viewport size is 0,0). (Note that this balloon.svg is already checked in LayoutTests/svg/as-background-image/resources, so it's fine to close this bug).