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

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.`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael_> Topic: 'display: contents' on SVG elements<br>
&lt;dael_> github: https://github.com/w3c/csswg-drafts/issues/2118<br>
&lt;dael_> TabAtkins: We've resolved on which SVG elements respond in which ways to display contents.<br>
&lt;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.<br>
&lt;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.<br>
&lt;dael_> ChrisL: I agree this is best and I like AmeliaBR categories<br>
&lt;dael_> AmeliaBR: Categories are appropriate. They weren't made with this use case, but by intersecting existing categories we can make it work.<br>
&lt;dael_> AmeliaBR: One thing, we haven't designed...would dsiplay:contents on a text-path override layout defined on an attribute?/<br>
&lt;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<br>
&lt;dael_> ChrisL: Agree.<br>
&lt;dael_> ChrisL: They're not presentation attributes?<br>
&lt;dael_> AmeliaBR: No.<br>
&lt;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.<br>
&lt;fantasai> s/need to do/keep having to do/<br>
&lt;dael_> AmeliaBR: Can you do that by next week? ^-^ Elsewise a note saying it unboxes all layout regardless of syntax.<br>
&lt;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?<br>
&lt;dael_> AmeliaBR: Good and complex question<br>
&lt;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.<br>
&lt;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?<br>
&lt;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.<br>
&lt;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.<br>
&lt;dael_> AmeliaBR: What's the spec status? Trying to get to CR and don't want an open issue?<br>
&lt;dael_> TabAtkins: It's not a big issue. We look at each and say if it's an inheriting property.<br>
&lt;dael_> fantasai: Next step is WD so it doesn't need fix today.<br>
&lt;dael_> AmeliaBR: I can try and write up something and perhaps a note about an open issue needing more review.<br>
&lt;dael_> fantasai: Sounds like we're going to accepth the changes. There is a followup issue on attributes that should be opened separately.<br>
&lt;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?<br>
&lt;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.<br>
&lt;dael_> astearns: So a new thing would be classified as a renderable element it would be fixed.<br>
&lt;dael_> AmeliaBR: If we defined a new attribute as a renderable element it would auto-apply<br>
&lt;dael_> ChrisL: It would only be a problem if we needed a new category<br>
&lt;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<br>
&lt;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.<br>
&lt;dael_> astearns: Obj?<br>
&lt;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.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2118#issuecomment-378779196 using your GitHub account

Received on Wednesday, 4 April 2018 23:45:15 UTC