- From: Erik Dahlström <ed@opera.com>
- Date: Wed, 10 Dec 2014 17:11:07 +0100
- To: www-svg@w3.org
On Tue, 09 Dec 2014 12:43:39 +0100, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> wrote: > Amelia Bellamy-Royds: > >> On 8 December 2014 at 11:44, Robert Longson <longsonr@gmail.com> wrote: >> >>> I did not mean using fragment identifiers to set a view, I mean >>> something >>> like #svgView(transform(scale(2))) >>> >>> >> Apologies, I was forgetting that option. >> >> The SVG 1.1 specs don't have any implementation details about what is >> *supposed* to happen. > > See: > http://www.w3.org/TR/2003/REC-SVG11-20030114/linking.html#SVGFragmentIdentifiers This is an orthogonal and IMHO less important issue to the one about transform attributes on the <svg> itself. I think we should clarify in SVG2 that the CSS Transforms spec is normative for how 'transform' works. > Especially: > 'in the case of transform(...), the same meaning as the corresponding > attribute has on a 'g' element).' > > If we have for example: > <svg width="6cm" height="4cm" viewBox="-3 -2 6 4" version="1.1" > xmlns="http://www.w3.org/2000/svg"> > <title>Transform example</title> > <circle r="3" /> > </svg> > > #svgView(transform(rotate(20))) > corresponds clearly to: > <svg width="6cm" height="4cm" viewBox="-3 -2 6 4" version="1.1" > xmlns="http://www.w3.org/2000/svg"> > <title>Transform example</title> > <g transform="rotate(20)"> > <rect x="-2" y="-1" width="4" height="2" /> > </g> > </svg> > (there is no meaningful other way to add a g element with the intended > effect). I agree that the spec implies that's how #svgView(transform(...)) works, but it's too hand-wavy IMHO. Sidenote: the SVGViewAttributes grammar also allows #svgView(transform(...);transform(...);viewBox(...);viewBox(...);transform(...)). How that should work is currently undefined. > This ensures: > 'This form of addressing specifies the desired view of the document > (e.g., the > region of the document to view, the initial zoom level) completely > within the > SVG fragment specification.' > > If we assume, that a transform applied to the root svg element should > have > the same effect than such an SVG fragment identifier, clearly CSS has > nothing > to to with this. An svgView transform could very well differ in how it's applied compared to being as an attribute directly on the <svg> element, assuming that's how we want to define it. We could keep the "as if the transform was applied on a <g> element" rule by saying that the svgView transform is applied as a supplemental transform on <svg>. The alternative is to handle it just like #svgView(viewBox()) i.e it just overrides the given attribute on the <svg>, which means that it gets applied using the normal presentation attribute rules. Amelia seems to favor this approach. -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Received on Wednesday, 10 December 2014 16:12:07 UTC