Re: [svg2] transform on <svg>

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.  There is one, draft test case in the 2011 test suite:
http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlSVGWeb/linking-frag-01-f.html

IE11 currently passes all three stages, Chrome/Opera fail on the case where
a semicolon is URL encoded but otherwise match the IE behaviour/pass
criteria, Firefox fails because of different application of the transform:
the test expects the transformation to be applied in user units within the
SVG coordinate system, Firefox is using CSS pixels.

If that test case is taken as definitive (again, note that it's currently
marked "draft" and there's nothing in the specs), then this would be
different from the way I was suggesting a transform should apply on a
top-level <svg> inline in HTML5.

Now, fragments don't apply to inline SVG in HTML5 (or nested SVGs), but
there should be a clear definition of how the fragment transformation
relates to a transform attribute or style on a root level SVG.

Options are therefore:

* Dump the draft test, and declare the way that Firefox handles transform
fragments correct: they should be evaluated at the viewport level, before
applying any scaling from the viewBox.  The same should happen for
transform attributes or styles on the root element, and for transforms on
nested/inline SVG.

* Keep the draft test rule, but define that transform fragments work
separately from transformations on the root element: transforms that are
part of a svgView() fragment are applied after scaling to the viewBox,
while root transformations are applied on the viewport.

* Keep the draft test rule, and also apply the same behaviour to transform
attributes or styles on the root element; the transformation gets applied
in user coordinates.  This would then mean that root elements have
different behaviour than nested/inline SVG, which could be confusing when
switching between inline SVG and SVG-as-image.

Other issues: if *both* a fragment and a transform attribute/style are
given, does the fragment take precedence (similar to how a viewBox fragment
overrides the default viewBox) or do they get added together (and if so, in
what order).


--ABR