Confirm, emeritus
969
edits
Changes
New page: <h2>Introduction</h2> This page is an in-progress attempt to make sense of the sizing of SVG content. You would think that with one 'width' attribute and one 'height' attribute this is a ...
<h2>Introduction</h2>
This page is an in-progress attempt to make sense of the sizing of SVG content. You would think that with one 'width' attribute and one 'height' attribute this is a simple issue. Unfortunately the interaction of multiple units, omitted attribute(s), the CSS width/height/min-width/max-width/min-height/max-height properties, the 'background-image' property, the viewBox attribute, intrinsic width/height, intrinsic aspect ratio, and whether the SVG is rendering standalone, inline, or embedded by reference all add to the fun.
The CSS width/height/etc. properties are fairly well defined. An important question is what part do the SVG width and height attributes play, and how do they interact with CSS? Currently there are two primary candidate approaches to sizing SVG content; (1) map the 'width' and 'height' attributes into style; (2) treat root 'svg' elements as "replaced elements" in CSS terms. The former approach would have the advantage of being the most intuitive for authors. The latter approach solves the problem of the 'display' property (i.e. [http://lists.w3.org/Archives/Public/www-svg/2005May/0022.html what you do with |display:inline;| on SVG]), and unless the user sets only one of the CSS properties 'width' and 'height' on the SVG while also having 'width' and 'height' attributes, they won't notice a difference to the former approach (well, as long as percentage attribute values are intrinsic).
<h2>Common ground</h2>
It's worth stating a few of my assumptions that everyone now seems to have agreed on:
1) The 'width' and 'height' attributes are the only source of intrinsic width and height values.
2) The 'viewBox' attribute specifies an intrinsic aspect ratio if it has a valid width/height component (we don't need to concern ourselves with the case where the aspect ratio defined by the 'width' and 'height' attributes is different from that defined by the 'viewBox' attribute since CSS only cares about aspect ratio in cases where an aspect ratio can't be determined from intrinsic width/height). XXX true?
<h2>Percentage intrinsic width and height</h2>
One of the key questions to answer is whether percentage values for the 'width' and 'height' attributes specify intrinsic dimensions or not. Clearly the understanding/intention of the author of the current wording in [http://www.w3.org/TR/SVGMobile12/coords.html#IntrinsicSizing the relevant section] of the SVG Tiny 1.2 CR is that the answer is [http://lists.w3.org/Archives/Member/w3c-svg-wg/2005JanMar/1296.html yes]. Just as clear is that the understanding/intention of the SVG WG chair is that the answer is [http://lists.w3.org/Archives/Public/www-svg/2006Feb/0047.html no] and [http://www.w3.org/TR/SVGMobile12/struct.html#SVGElementWidthAttribute the part of the spec on 'width' says no].
Problems with "no":
<ul>
<li>If SVG is treated as a replaced element when embedded inline or embedded by reference the 'width' and 'height' attributes will not have any effect if they have percentage values. The SVG will either render at the width of the containing block minus margin/padding/border if it has an intrinsic aspect ratio (so the height can be calculated), or it will render at 300x150 px. For example, confusingly, this snippet of SVG embedded inline in an XHTML document will render in a 300x150 px rectangle:
<pre>
<div ...fixed size>
<svg width="50% height="50%" viewBox="none">
...
</svg>
</div>
</pre>
On the other hand, if the width and height are moved into a 'style' attribute:
<pre>
<div ...fixed size>
<svg style="width:50%; height:50%;" viewBox="none">
...
</svg>
</div>
</pre>
the SVG will render in a rectangle that's 50% the width and height of its containing block, which would no doubt be what the authors would expect of either snippet. How's that for confusing?
</li>
</ul>
Problems with "yes":
* The CSS spec says intrinsic width/height are resolved as a percentage of the containing block's width/height. As a result, once again with CSS, you have the problem that none-zero values for border/padding/margin will cause the SVG to burst out of its containing block. (For inline SVG this may be what's expected since it's how things would behave if the attributes were mapped into style.)
* There is no way for some SVG content to say it wants to take up whatever space is available after borders, padding and margins have taken their share (there is no way to create SVG that does NOT have an intrinsic width/height since the 'width' and 'height' attributes default to 100%).
Does it actually make sense to have percentage intrinsic dimensions? In the general case, probably not. It does make sense to be able to say "take up all the room available", i.e. 100% width/height, but why would you want to take up some arbitrary percentage of some unknown area? The SVG knows nothing about what's outside it. It makes no sense.
<h2>Sizing of standalone SVG</h2>
SVG Tiny 1.2, [http://www.w3.org/TR/SVGMobile12/coords.html#InitialViewport The initial viewport], says "If there is no <nowiki>[containing]</nowiki> document, the SVG user agent must use the 'width' and 'height' attributes on the 'svg' element as the width and height for the viewport." For this scenario we could map the 'width' and 'height' attributes into style (width/height defaulting to 100% if not specified) which would make implementation much simpler in Mozilla (this is also what Opera does). Percentage values would then set the viewport of the SVG to a percentage of the client area as the user would expect.
Treating SVG as a replaced element in this context
In this scenario we don't care about intrinsic size/ratio (and hence, for the purposes of viewport sizing, the 'viewBox' attribute).
One note: we would want to make sure to force |display:block;| for such SVG and prevent content from changing this.
<h2>Sizing of SVG embedded inline</h2>
SVG Tiny 1.2, [http://www.w3.org/TR/SVGMobile12/coords.html#InitialViewport The initial viewport], says "If the <nowiki>[containing]</nowiki> document is styled with CSS, then the negotiation process must follow the CSS rules for replaced elements." To allow this, SVG Tiny 1.2 specifies [http://www.w3.org/TR/SVGMobile12/coords.html#IntrinsicSizing how the intrinsic width, intrinsic height and intrinsic aspect ratio are found] for SVG content. This information is used as specified in CSS 2.1, [http://www.w3.org/TR/CSS21/visudet.html Visual formatting model details] to determine the width and height occupied by the SVG content.
<h2>Sizing of SVG embedded by reference</h2>
This page is an in-progress attempt to make sense of the sizing of SVG content. You would think that with one 'width' attribute and one 'height' attribute this is a simple issue. Unfortunately the interaction of multiple units, omitted attribute(s), the CSS width/height/min-width/max-width/min-height/max-height properties, the 'background-image' property, the viewBox attribute, intrinsic width/height, intrinsic aspect ratio, and whether the SVG is rendering standalone, inline, or embedded by reference all add to the fun.
The CSS width/height/etc. properties are fairly well defined. An important question is what part do the SVG width and height attributes play, and how do they interact with CSS? Currently there are two primary candidate approaches to sizing SVG content; (1) map the 'width' and 'height' attributes into style; (2) treat root 'svg' elements as "replaced elements" in CSS terms. The former approach would have the advantage of being the most intuitive for authors. The latter approach solves the problem of the 'display' property (i.e. [http://lists.w3.org/Archives/Public/www-svg/2005May/0022.html what you do with |display:inline;| on SVG]), and unless the user sets only one of the CSS properties 'width' and 'height' on the SVG while also having 'width' and 'height' attributes, they won't notice a difference to the former approach (well, as long as percentage attribute values are intrinsic).
<h2>Common ground</h2>
It's worth stating a few of my assumptions that everyone now seems to have agreed on:
1) The 'width' and 'height' attributes are the only source of intrinsic width and height values.
2) The 'viewBox' attribute specifies an intrinsic aspect ratio if it has a valid width/height component (we don't need to concern ourselves with the case where the aspect ratio defined by the 'width' and 'height' attributes is different from that defined by the 'viewBox' attribute since CSS only cares about aspect ratio in cases where an aspect ratio can't be determined from intrinsic width/height). XXX true?
<h2>Percentage intrinsic width and height</h2>
One of the key questions to answer is whether percentage values for the 'width' and 'height' attributes specify intrinsic dimensions or not. Clearly the understanding/intention of the author of the current wording in [http://www.w3.org/TR/SVGMobile12/coords.html#IntrinsicSizing the relevant section] of the SVG Tiny 1.2 CR is that the answer is [http://lists.w3.org/Archives/Member/w3c-svg-wg/2005JanMar/1296.html yes]. Just as clear is that the understanding/intention of the SVG WG chair is that the answer is [http://lists.w3.org/Archives/Public/www-svg/2006Feb/0047.html no] and [http://www.w3.org/TR/SVGMobile12/struct.html#SVGElementWidthAttribute the part of the spec on 'width' says no].
Problems with "no":
<ul>
<li>If SVG is treated as a replaced element when embedded inline or embedded by reference the 'width' and 'height' attributes will not have any effect if they have percentage values. The SVG will either render at the width of the containing block minus margin/padding/border if it has an intrinsic aspect ratio (so the height can be calculated), or it will render at 300x150 px. For example, confusingly, this snippet of SVG embedded inline in an XHTML document will render in a 300x150 px rectangle:
<pre>
<div ...fixed size>
<svg width="50% height="50%" viewBox="none">
...
</svg>
</div>
</pre>
On the other hand, if the width and height are moved into a 'style' attribute:
<pre>
<div ...fixed size>
<svg style="width:50%; height:50%;" viewBox="none">
...
</svg>
</div>
</pre>
the SVG will render in a rectangle that's 50% the width and height of its containing block, which would no doubt be what the authors would expect of either snippet. How's that for confusing?
</li>
</ul>
Problems with "yes":
* The CSS spec says intrinsic width/height are resolved as a percentage of the containing block's width/height. As a result, once again with CSS, you have the problem that none-zero values for border/padding/margin will cause the SVG to burst out of its containing block. (For inline SVG this may be what's expected since it's how things would behave if the attributes were mapped into style.)
* There is no way for some SVG content to say it wants to take up whatever space is available after borders, padding and margins have taken their share (there is no way to create SVG that does NOT have an intrinsic width/height since the 'width' and 'height' attributes default to 100%).
Does it actually make sense to have percentage intrinsic dimensions? In the general case, probably not. It does make sense to be able to say "take up all the room available", i.e. 100% width/height, but why would you want to take up some arbitrary percentage of some unknown area? The SVG knows nothing about what's outside it. It makes no sense.
<h2>Sizing of standalone SVG</h2>
SVG Tiny 1.2, [http://www.w3.org/TR/SVGMobile12/coords.html#InitialViewport The initial viewport], says "If there is no <nowiki>[containing]</nowiki> document, the SVG user agent must use the 'width' and 'height' attributes on the 'svg' element as the width and height for the viewport." For this scenario we could map the 'width' and 'height' attributes into style (width/height defaulting to 100% if not specified) which would make implementation much simpler in Mozilla (this is also what Opera does). Percentage values would then set the viewport of the SVG to a percentage of the client area as the user would expect.
Treating SVG as a replaced element in this context
In this scenario we don't care about intrinsic size/ratio (and hence, for the purposes of viewport sizing, the 'viewBox' attribute).
One note: we would want to make sure to force |display:block;| for such SVG and prevent content from changing this.
<h2>Sizing of SVG embedded inline</h2>
SVG Tiny 1.2, [http://www.w3.org/TR/SVGMobile12/coords.html#InitialViewport The initial viewport], says "If the <nowiki>[containing]</nowiki> document is styled with CSS, then the negotiation process must follow the CSS rules for replaced elements." To allow this, SVG Tiny 1.2 specifies [http://www.w3.org/TR/SVGMobile12/coords.html#IntrinsicSizing how the intrinsic width, intrinsic height and intrinsic aspect ratio are found] for SVG content. This information is used as specified in CSS 2.1, [http://www.w3.org/TR/CSS21/visudet.html Visual formatting model details] to determine the width and height occupied by the SVG content.
<h2>Sizing of SVG embedded by reference</h2>
