Repository navigation
Allow transforms on textPath #210
Description
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>
Activity
nikosandronikos commentedon Jul 19, 2016
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 commentedon Jul 19, 2016
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
transformattribute is transformable, and SVG 2 says thattransformis 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 commentedon Jul 20, 2016
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 commentedon Jul 20, 2016
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 commentedon Jul 21, 2016
Firefox and Chrome apply transforms to the path element:
http://codepen.io/Tavmjong/pen/rLdGdK
karip commentedon Jul 21, 2016
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 commentedon Jul 21, 2016
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 commentedon Jul 21, 2016
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 commentedon Jul 21, 2016
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.
5 remaining items
nikosandronikos commentedon Jul 22, 2016
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:
Tavmjong commentedon Jul 22, 2016
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 commentedon Jul 22, 2016
Spec updated in commit 98808bf
nikosandronikos commentedon Jul 29, 2016
Did we mean to say that
aas a child of text is treated as an inline element or that allaelements are inline elements?The note in 10.2. The ‘text’ and ‘tspan’ elements says the former.
nikosandronikos commentedon Jul 29, 2016
Filed issue on CSS Transforms for definition of transformable elements - w3c/csswg-drafts#358
AmeliaBR commentedon Jul 29, 2016
aas a descendent oftextis inline. It's still transformable as a graphics container. The text chapter looks OK.nikosandronikos commentedon Jul 29, 2016
Yeah the other sections are good, it's just the note that wasn't as specific.
Text chapter: Review & edits
progers commentedon Feb 9, 2021
This recently came up in Chromium (see: https://crbug.com/1175868) and we noticed the SVG2 spec still lists
tspanandtextpathas inheriting from SVGGraphicsElement which supports transforms. The class hierarchy in the SVG2 draft spec fortspanis: SVGTSpanElement -> SVGTextPositioningElement -> SVGTextContentElement -> SVGGraphicsElement.textpathis similar. Implementations seem to agree thattspanandtextpathdo not support transforms, whereastextdoes. 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 commentedon Aug 12, 2024
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?