[css-display] textPath and SVG unboxing for display:contents

[lilles]

When implementing [1] in Blink, the following came up as a question during code review:

fs@opera.com: "I find it a bit odd that <tspan> gets this treatment, but not <textpath>, since they are both "inline level" text content elements - that's a spec issue though..."

@tabatkins

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

[fantasai]

I'm guessing it's a specification error, then. Probably should have made that a non-exhaustive list.

[tabatkins]

No, it's meant to be exhaustive, I just didn't realize that textPath existed. It should indeed be treated the same as tspan

[tabatkins]

All right, fixed in 1432231. I reviewed the Element Index in SVG2 and also added a and "unknown elements" (which are defined to render like g) to the list, along with an note explaining the reasoning for the groups.

[fantasai]

I'd prefer if we didn't put exhaustive lists of non-CSS constructs in our CSS specs. It's fine to be comprehensive if we can, but our lists should be written as being open-ended so that changes in the external technology don't automatically create errors in our specs.

[AmeliaBR]

Would it be better to link to SVG element-category definitions?

• Root <{svg}> would be "an <svg> element with CSS box layout" (in fact, I'd strongly argue against using the word "root" if you want this behavior to apply to <svg> that is a child of an HTML element, and is therefore not the root of its document.)

  ''display: contents'' behaves as ''display: none''.

• <{tspan}>, <{textPath}> would be text content child elements.

  Nested <{svg}>, <{a}>, <{g}>, and unknown elements would be all other SVG container elements that are also renderable elements.

  Only <{use}> (treated as a Shadow DOM container) would need to be called out separately

  ''display: contents'' strips the element from the formatting tree,
  and hoists its contents up to display in its place.

• any other SVG elements

  ''display: contents'' behaves as ''display: none''.

[fantasai]

@AmeliaBR Yes, I think that would be much better. Would you mind drawing up a pull request (or just committing against this issue number if you prefer)?

[AmeliaBR]

@fantasai, I'll try to get that for next week.

---

For anyone else reviewing this issue, there's some relevant background in #540

[css-meeting-bot]

The SVG Working Group just discussed [css-display] textPath and SVG unboxing for display:contents.

The full IRC log of that discussion

<AmeliaBR> Topic: [css-display] textPath and SVG unboxing for display:contents
<AmeliaBR> GitHub: https://github.com//issues/2118
<AmeliaBR> Proposed change: https://github.com//issues/2118#issuecomment-374802030
<BogdanBrinza> Resolution: No objection from the working group to the wording Amelia used in the proposed change for CSS display: contents

[css-meeting-bot]

The Working Group just discussed 'display: contents' on SVG elements, and agreed to the following resolutions:

• RESOLVED: We define how SVG elements inteact with display:contents based on SVG defined categories. We will add a new issue about what to do with attributes.

The full IRC log of that discussion

<dael_> Topic: 'display: contents' on SVG elements
<dael_> github: https://github.com//issues/2118
<dael_> TabAtkins: We've resolved on which SVG elements respond in which ways to display contents.
<dael_> TabAtkins: It was pointed out I made a mistake. That points to a larger issue that as SVG evolves the elements that are categorieze will evolve. Instead of cat explicitly we should use the element categories that SVG defines.
<dael_> TabAtkins: AmeliaBR suggested a particular grouping for each one. SVG WG did review and said tiw as fine. I think it's fine. If the rest of the group is okay switching to using SVG categories we can do that.
<dael_> ChrisL: I agree this is best and I like AmeliaBR categories
<dael_> AmeliaBR: Categories are appropriate. They weren't made with this use case, but by intersecting existing categories we can make it work.
<dael_> AmeliaBR: One thing, we haven't designed...would dsiplay:contents on a text-path override layout defined on an attribute?/
<dael_> AmeliaBR: t-span and text-path are ones we're saying text content works as an unboxing. They both involve layout with attributes not CSS properties. I had been assuming that a display:contents would mean ignore any layout specific to this element, but we should be explicit
<dael_> ChrisL: Agree.
<dael_> ChrisL: They're not presentation attributes?
<dael_> AmeliaBR: No.
<dael_> TabAtkins: I need to finally write up the explination for how SVG rendered into CSS box model. WE need to do this tap dance and we know ituses a reasonable concept of boxes. Then it'll all work out.
<fantasai> s/need to do/keep having to do/
<dael_> AmeliaBR: Can you do that by next week? ^-^ Elsewise a note saying it unboxes all layout regardless of syntax.
<dael_> florian: Follow up question on attributes. These presentational attributes on the element, can some be ddesc as inheriting to anon box witht he text? Or are they all clearly to the surpressed box?
<dael_> AmeliaBR: Good and complex question
<dael_> TabAtkins: There's no anon box around text, it's lifted to parent. ANything presentational that's CSS disappears. Anything which is just in SVG terms we'll for now put somethin in that says do the same.
<dael_> florian: So they just disappear? You bold a font in the style and display:contents on the span you get bold text. Do we have things like that in SVG where they need to apply to the text run?
<dael_> AmeliaBR: The bit where I said it was complex...the layout attributes inherit down in a way that doesn't quite match CSS because it's per character. But it's similar to inheritence.
<dael_> florian: It seems to me the thing we're about to resolve on it right but a bit incomplete. We need to talk per attribute. Or is there a well engouh defined thing in SVG.
<dael_> AmeliaBR: What's the spec status? Trying to get to CR and don't want an open issue?
<dael_> TabAtkins: It's not a big issue. We look at each and say if it's an inheriting property.
<dael_> fantasai: Next step is WD so it doesn't need fix today.
<dael_> AmeliaBR: I can try and write up something and perhaps a note about an open issue needing more review.
<dael_> fantasai: Sounds like we're going to accepth the changes. There is a followup issue on attributes that should be opened separately.
<dael_> astearns: Question on the categories. We're going to call out categoires that are not doing display:none and anything not called out is the display:none. If at some point SVG defines new things that might have something different then display:none we'll have to add it in the future. Is that the right approach?
<dael_> AmeliaBR: Yeah. Presumably most elements that are new would fit into one of these categories. This idea with these category names is they should be open ended.
<dael_> astearns: So a new thing would be classified as a renderable element it would be fixed.
<dael_> AmeliaBR: If we defined a new attribute as a renderable element it would auto-apply
<dael_> ChrisL: It would only be a problem if we needed a new category
<dael_> astearns: Prop: We define how SVG elements inteact with display:contents based on SVG defined categories. We will add a new issue about what to do with attributes
<florian> AmeliaBR, do you want to file that new issue? I believe you got my point, and you're more likely than me to phrase it right.
<dael_> astearns: Obj?
<dael_> RESOLVED: We define how SVG elements inteact with display:contents based on SVG defined categories. We will add a new issue about what to do with attributes.

[AmeliaBR]

@fantasai

I've pushed edits to a new branch. Three commits: the first one to address this issue, and then two for #2502 (new text and an inline issue pointing back to GitHub).

I haven't worked with Bikeshed before, and don't have a build system set up locally, so I'm not sure I've got the linking syntax correct. Please review that (& the text) and correct or merge if OK.