Changes

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 algorithm 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 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).

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).