[css-display] should display:contents on SVG textPath compute to none?

[heycam]

https://drafts.csswg.org/css-display/#unbox-svg

I found #2118 which resulted in display: contents being allowed on <textPath>.

In the note, the rationale for computing display:contents to none for particular SVG elements is explained as preventing display:contents from working on elements that change the "context" for their children. But what should happen with:

<text>
  <textPath style="display: contents">
    <textPath>should I render?</textPath>
  </textPath>
</text>

Normally, a <textPath> that is not a direct child of a <text>, ignoring <a>, should not render (I believe -- filed w3c/svgwg#580 to clarify that).

Similarly:

<text>
  <tspan style="display: contents">
    <textPath>should I render?</textPath>
  </tspan>
</text>

Here, <tspan> does affect the context for its children, since it causes <textPath>s to no longer work. But does that mean we should really make display: contents compute to none for <tspan> too? That seems a bit restrictive.

/cc @emilio @lilles @AmeliaBR

[tabatkins]

For your first example, this is identical to <rect style="display:contents"><rect /></rect>; we don't consider it reasonable to render the inner rect there, so we shouldn't render the inner textPath here.

For your second, I wasn't aware that tspan caused textPath to not render. That's an odd and unfortunate detail. The fact that you can put tspan inside of textPath validly, but not outside, seems weird.

Also, textPath is categorized as a "text content child element", which says that it's allowed as a descendant of another "text content element", of which tspan is one. I see you've opened 580 to ask about that.

[heycam]

For your first example, this is identical to <rect style="display:contents"><rect /></rect>; we don't consider it reasonable to render the inner rect there, so we shouldn't render the inner textPath here.

That seems reasonable to me.

For your second, I wasn't aware that tspan caused textPath to not render. That's an odd and unfortunate detail. The fact that you can put tspan inside of textPath validly, but not outside, seems weird.

<textPath> really should have been a top level element, rather than being required to be a child of a <text>. That you can't wrap a <textPath> with a <tspan> is probably because it doesn't make sense to apply the <tspan>'s positioning attributes to the <textPath>, but then again you can have positioning attributes on the <text> too. Oh well.

[fantasai]

OK, so are edits needed to css-display-3 or no? If so, what edits? @tabatkins ?

[AmeliaBR]

I think you can leave the display: contents text as is, and the specific case @heycam brought up could be handled under the general rule of SVG elements that are in invalid locations in the DOM tree are not rendered. So the <textPath> that is inside another text content element would continue to be not rendered because of DOM invalidity, separate from the layout on the parent element being ignored or not.

[AmeliaBR]

Correction: if my interpretation above is accepted, I don't think you need to change the normative text, but we should probably tweak this sentence in the note:

In contrast, any content inside a tspan or textPath is also valid content inside the parent text formatting context, so the hoisting behavior applies for these elements.

Make “any content inside” → “any valid content (plain text or tspan or a elements) inside".

[AmeliaBR]

PS, while you're making edits, might want to also drop this sentence in light of w3c/fxtf-drafts#245:

(Also, authors cannot override the display property on these elements: it is forced to none by an !important user agent style rule.)

[fantasai]

Alright, done. Thanks @AmeliaBR !!!