Confirm, emeritus
969
edits
Changes
no edit summary
<h2>SVG width/height vs. CSS width/height</h2>
The affect of the CSS properties is reasonably well defined. An important question to answer is, what part do the SVG 'width', 'height' and 'viewBox' attributes play, and how do they interact with the CSS properties? It has [http://www.w3.org/TR/SVGMobile12/coords.html#InitialViewport become clear] that SVG is to be treated as a [http://www.w3.org/TR/CSS21/conform.html#replaced-element replaced element] in CSS contexts. It has also become clear that the intrinsic dimensions that the SVG must pass to the [http://www.w3.org/TR/CSS21/visudet.html CSS replaced element algorithms] are to [http://www.w3.org/TR/SVGMobile12/coords.html#IntrinsicSizing come from the SVG 'width', 'height' and 'viewBox' attributes]. However, current implementations (e.g. Opera 9.23) seem appear to treat the 'width' and 'height' attributes as [http://www.w3.org/TR/SVG11/styling.html#AlternativesForStyling presentation attributes] and map them into style (i.e. [http://www.w3.org/TR/CSS21/cascade.html#preshint translate them directly to CSS 'width' and 'height' properties]). As it turns out, there are problems with both these approaches, and unfortunately the new text specifying SVG as a replaced element creates some horrible authoring gotchas (as currently worded).
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).
