W3C home > Mailing lists > Public > www-svg@w3.org > December 2014

Re: [svg2] transform on <svg>

From: Erik Dahlström <ed@opera.com>
Date: Wed, 10 Dec 2014 17:11:07 +0100
To: www-svg@w3.org
Message-ID: <op.xqntwtindhsuf5@gnorps>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:38 UTC