- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 14 Sep 2010 18:02:13 -0700
- To: Jonathan Watt <jwatt@jwatt.org>
- CC: www-svg <www-svg@w3.org>
On 9/14/10 5:42 PM, Jonathan Watt wrote: > That's because<iframe> is not a "replaced element" (a CSS term), whereas<img>, > <object> and<embed> are. Actually.... <iframe> is in fact a "replaced element" in CSS terms. I believe browsers interpret <iframe> pointing to an SVG as a request to load the SVG as a separate document as opposed to an "embedding by reference" scenario in which it's really conceptually part of the same document but just happens to be in a separate file. Note that images do the same thing; <img src="img.gif"> and <iframe src="img.gif"> do completely different things. >> As an aside, there are a similar set of inconsistencies across browsers when the size is left off the containing OBJECT, EMBED, IFRAME, and IMG elements. > > Indeed. In the case that the referencing HTML element does not have its size > fixed purely by its own document, it should look at the document that it's > embedding and use the intrinsic dimensions or aspect ration of that document to > help in deciding its dimensions. (See the "replaced element" sections of chapter > 10 of CSS 2.1 for the exact mechanisms*.) That done, the overriding of the > width/height of the<svg> continues as normal - although after applying the CSS > rules to the dimensions of the<object> (or whatever) it will often then have > the same dimensions as the<svg>. They should be in all cases that don't involve max-width/height and min-width/height, if the SVG has a fixed size specified, right? Note that the other case that can be interesting is when percentage widths are used on the <img> in the parent document and its containing block shrink-wraps, and the SVG being loaded in that <img> has a fixed size set.... In that case the shrink-wrapping is supposed to depend on the intrinsic size of the SVG, but the final sizing will be determined by the final width of the container (which can depend on what other content is in it, and also on min/max stuff. Having some decently exhaustive tests for this stuff would be really good. ;) -Boris
Received on Wednesday, 15 September 2010 01:02:50 UTC