Re: transform property on <tspan> and <textPath>

Thanks for that clarification Tab. The lack of a single reference box was
my guess for why the CSS restriction existed, but I wasn't sure.

With that in mind, this issue is therefore related to the getBBox issue we
discussed on the call for tspan and textPath. If we're fine with making
"the bounding box of all glyphs' em-boxes" the reference box for these
elements, regardless of how those glyphs ended up where they are, then
there shouldn't be a problem transforming that box.

Furthermore, since the default reference box for transforms in SVG is the
nearest viewBox, not the bounding box of the element itself, an author
would have to opt in (by setting the transform-box property[1]) to get any
weird behavior from wrapped text.

~ABR

[1]: https://drafts.csswg.org/css-transforms/#transform-box

On 15 January 2016 at 18:08, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Fri, Jan 15, 2016 at 11:13 AM, Tavmjong Bah <tav.w3c@gmail.com> wrote:
> > On Fri, 2016-01-15 at 14:35 +1100, Cameron McCormack wrote:
> >> In the SVG 2 draft, we allow transform on <tspan> and <textPath>.  I
> >> realise now however that this is inconsistent with what CSS allows in
> >> non-SVG documents, and if we are defining SVG text layout in terms of
> >> CSS text layout (plus an additional layer of SVG glyph positioning),
> >> then we might want to reconsider.
> >>
> >> Specifically, the transform property is defined to apply only to
> >> “transformable elements”:
> >>
> >>   https://drafts.csswg.org/css-transforms/#transformable-element
> >>
> >> Notably this doesn’t include inline elements, which is what we are
> >> considering <tspan> and <textPath> to be.
> >>
> >> As far as I know nobody has implemented this.
> >
> > Actually, rsvg seems to support transforms on tspan elements!
> >
> > I would have thought that transform on tspan elements would be treated
> > as part of the post CSS layout step. However, I don't have a strong
> > opinion on keeping transforms on tspan and textPath elements.
>
> CSS's issues are mostly with inlines broken across a line, as there's
> no good answer for what coordinate space the transforms should operate
> in (particularly rotates/skews).  Thus our restriction to blocks and
> atomic inlines (like display:inline-block elements).
>
> SVG's text model is a little different, but putting the restriction on
> <tspan> amounts to the same thing.  A <text> can span multiple lines,
> but it in itself is a reasonable "container", like a block in CSS.  A
> <tspan> can contain text split across different lines, tho, which runs
> into the issues we had.
>
> (There is no "post-CSS layout step". Transforms are part of CSS
> layout, and SVG is just using an unspecified CSS layout mode which
> resembles forced absolute positioning.)
>
> ~TJ
>
>