transform property on <tspan> and <textPath>

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

transform property on <tspan> and <textPath>

Cameron McCormack-4
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.

--
Cameron McCormack ≝ http://mcc.id.au/

Reply | Threaded
Open this post in threaded view
|

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

Tavmjong Bah-2
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.

Tav



Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Fri, Jan 15, 2016 at 11:13 AM, Tavmjong Bah <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Amelia Bellamy-Royds
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


On 15 January 2016 at 18:08, Tab Atkins Jr. <[hidden email]> wrote:
On Fri, Jan 15, 2016 at 11:13 AM, Tavmjong Bah <[hidden email]> 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