Allow transforms on textPath

[karip]

The 'tspan' and 'a' element already have the transform property. It would be nice if textPath would also have it, to make all text element children behave similarly. The use cases are the same as for tspan: jiggling animations etc.

Currently, one has to resort to a wrapper a element:

<text>Hello <a transform="rotate(45)"><textPath path="..">rotated text on path</textPath></a> !!</text>

[nikosandronikos]

This has come up before, with no outcome to the discussion:
https://lists.w3.org/Archives/Public/www-svg/2016Jan/0010.html

I think it should be fine to add transform to these elements. With the transform applying to the region returned by getBBox() as described by Amelia.

[AmeliaBR]

Yes, if transforms are valid for <tspan> they should be valid for <textPath>. If anything, it's easier to define the transform for <textPath>, because it has a self-contained geometry.

In contrast, <tspan> may use simple inline layout, and may be wrapped to a new line (in SVG 2 text layout). For CSS/HTML layout, the Transforms spec doesn't allow wrapping inline text to be transformed, so it doesn't define how it behaves.

My preference is to just allow transformations on all of them, with the transformation applied after all other text layout. That's actually how it's currently specced, although it's a bit of an unintentional intersection of two different specs: CSS Transforms says that any SVG element that accepts a transform attribute is transformable, and SVG 2 says that transform is a valid presentation attribute on any SVG element.

If there is an implementation difficulty with transformations on wrapping SVG text spans, we can consider exceptions.

But as is, @karip, feel free to file user agent bug reports on anyone that doesn't support transforms on <tspan> and <textPath>.

[Tavmjong]

Having gone through the algorithm section, I am against allowing transforms on <tspan>s. It breaks the model of having CSS treat these as inline objects when doing layout inside a region and then applying the SVG specific attributes afterwards to the resulting typographic character positions. It adds quite a bit of complexity to the layout algorithm. It is easier to handle transforms on <textPath> since that means transforming the entire output... but then one can just transform the referenced path so I don't really see the necessity.

[AmeliaBR]

but then one can just transform the referenced path so I don't really see the necessity.

No, that has no effect. The path data is used, not the actual path element. It is always interpretted in the coordinate system of the <textPath> element.

[Tavmjong]

Firefox and Chrome apply transforms to the path element:

http://codepen.io/Tavmjong/pen/rLdGdK

[karip]

Seems like implementers are against adding transforms to inline elements. It might be difficult to get two implementations for this, so perhaps this shouldn't be added, or at least marked as “at-risk”.

[Tavmjong]

IIRC, the original argument for adding transform to <tspan> was that it was already on the <a> element. No browser seems to support this.

How do you handle <tspan>s that span more than one line? How do they interact with the SVG positioning attributes?

[AmeliaBR]

Firefox and Chrome apply transforms to the path element

Interesting. We should spec that more clearly one way or the other. However, it's still not the same as the textPath itself getting transformed, as is obvious when you apply a scaling transform.

[Tavmjong]

That is just weird! But it seems to be an artifact of CodePen. Look at:

http://tavmjong.free.fr/SVG/text_on_path_transform.svg

This doesn't exhibit the strange behavior.

[AmeliaBR]

The "strange behavior" is what you want if you apply a scale transform to a <textPath> element. I created it by scaling the <text> element.

But I do agree that it might sometimes be nice to fit text to a transformed path without transforming the text itself, which is why we should spec the Chrome/Firefox behavior. Note that Edge currently behaves differently: the text glyphs don't get stretched, but they are stretched out along the path, proportional to the scaling factor.

Edge:

Chrome:

[fsoder]

FWIW, what Chrome/Blink (and FF; and Presto) implements is an interpretation of:

https://www.w3.org/TR/SVG/text.html#TextPathElementHrefAttribute

(still roughly the same at https://svgwg.org/svg2-draft/text.html#TextPathElementHrefAttribute)

Well, I guess Edge does too, but they seem to compute the positions on the path before applying the path transform (or something.)

[AmeliaBR]

Thanks @fsoder.

I'd remembered the first half of that paragraph (coordinates interpretted in the text element's coordinate system), but not the second (transform specified directly on the path still applies).

But yes, still need to clarify the details of what it means to transform the path that a textPath uses, versus transforming the textPath (and/or parent text element) itself.

[nikosandronikos]

We resolved on this morning's call that text and tspan are treated as inline elements and inline elements can't have transform.

https://www.w3.org/2016/07/21-svg-minutes.html#item03

Actions:

• Nikos to file bug on CSS Transforms
• Tav to make the edits to SVG 2

[Tavmjong]

Just to clarify. Browsers do support transforms on <a> when <a> is acting as a container for graphics elements (e.g. shapes). They do not support transforms on <a> when <a> is acting like an inline element (i.e., inside a <text> element).

[Tavmjong]

Spec updated in commit 98808bf

[nikosandronikos]

Did we mean to say that a as a child of text is treated as an inline element or that all a elements are inline elements?

The note in 10.2. The ‘text’ and ‘tspan’ elements says the former.

[nikosandronikos]

Filed issue on CSS Transforms for definition of transformable elements - w3c/csswg-drafts#358

[AmeliaBR]

Did we mean to say that a as a child of text is treated as an inline element or that all a elements are inline elements?

a as a descendent of text is inline. It's still transformable as a graphics container. The text chapter looks OK.

[nikosandronikos]

Yeah the other sections are good, it's just the note that wasn't as specific.

[progers]

This recently came up in Chromium (see: https://crbug.com/1175868) and we noticed the SVG2 spec still lists tspan and textpath as inheriting from SVGGraphicsElement which supports transforms. The class hierarchy in the SVG2 draft spec for tspan is: SVGTSpanElement -> SVGTextPositioningElement -> SVGTextContentElement -> SVGGraphicsElement. textpath is similar. Implementations seem to agree that tspan and textpath do not support transforms, whereas text does. Can the spec be updated to reflect this? One path would be to revert back to SVGTextContentElement inheriting from SVGElement instead of SVGGraphicsElement (see: SVG11), though this would require either duplication or multiple inheritance for SVGTextElement to support both SVGTextPositioningElement and SVGTextContentElement.

[Fasteroid]

I find it upsetting that the spec was changed to do the opposite of what this issue was requesting. I'm in a tough situation right now where I need custom slanted text on a circular path, and I can't do that without being able to transform <tspan>. Such use-cases were even acknowledged and yet the decision was still to remove them.

Do I have any options here?