Mark 4 text properties at risk

[ewilligers]

Test web-platform-tests/wpt#14111 is detecting that no browsers are shipping support for:-

• shape-inside
• shape-subtract
• text-decoration-fill
• text-decoration-stroke

Do we have implementations?

[dirkschulze]

It should have been already. So yes, at-risk is minimum.

[Tavmjong]

We implement all four properties.

[css-meeting-bot]

The SVG Working Group just discussed Mark 4 text properties at risk, and agreed to the following:

• RESOLVED: Put shape-inside and shape-subtract at risk.
• RESOLVED: SVG-specific text decoration color definition should move to a CSS module. Follow up with CSSWG.
• RESOLVED: Remove text-decoration-fill and text-decoration-stroke from SVG. Suggest to SVGWG to move their definitions to CSS fill and stroke or CSS text decoration
• RESOLVED: Remove text-decoration-fill and text-decoration-stroke from SVG. Suggest to CSSWG to move their definitions to CSS fill and stroke or CSS text decoration

The full IRC log of that discussion

<myles> Topic: Mark 4 text properties at risk
<myles> AmeliaBR: these are text properties that are a mixed bag of properties. Two are about shape, two are about text decorations.
<myles> krit: Let's discuss with shape-inside and shape-subtract.
<myles> AmeliaBR: We already agreed that anything to do with wrapping text will be at-risk?
<myles> krit: it might make sense to make a resolution to put shape-inside and shape-subtract at-risk.
<myles> AmeliaBR: That's part of the previous decision. They should be at-risk.
<myles> RESOLVED: Put shape-inside and shape-subtract at risk.
<myles> krit: Next two properties: text-decoration-fill and text-decoration-stroke. Why did we add them?
<AmeliaBR> https://github.com//issues/610#issuecomment-445965272
<myles> AmeliaBR: They are added to be equivalent to be text-decoration-color which is in regular CSS. SVG text doesn't use color, it uses fill and stroke, so we need some way to explain it. I commented on this issue ^^^ I think it's appropriate to defer them. They are still being discussed as part of the fill and stroke spec. Even if we defer them we still need some text somewhere that explains how to use text-decoration-color in SVG. Does it override fill and
<myles> stroke? Does it work together?
<myles> krit: Fill and stroke spec was created to fill and stroke in HTML. Why do we have separate text-decoration-fill and text-decoration-stroke at all?
<myles> AmeliaBR: It's for styling the underline separately from the text it's attached to.
<myles> AmeliaBR: the fill and stroke spec will take over this issue by making it a universal issue, not svg issue.
<myles> AmeliaBR: until that spec is stable, we still have browsers that are shipping text-decoration-color, i don't know whether we have consistent behavior in browsers about whether or not it affects SVG text.
<myles> Tavmjong:
<myles> tav
<myles> tab?
<myles> Tavmjong: Do we have any implementations?
<myles> Tavmjong: inkscape supports color.
<myles> Tavmjong: do any browsers support text-decoration-color in SVG?
<myles> myles: I think we do but I haven't checked
<myles> AmeliaBR: it doesn't work in Chrome
<myles> krit: the text-decoration-color property is part of CSS Text Decoration module. Shouldn't we move this issue there?
<myles> krit: We should move it there. Many other modules have SVG-specific text.
<myles> Tavmjong: I'm reluctant to agree with you because we don't have representation there.
<myles> krit: Yes, but everyone is free to contribute or participate on those specifications.
<myles> myles: ::mumble mumble mumble::
<myles> krit: The CSS WG should decide.
<myles> krit: If we have any text describing text decoration color in SVG, can we move it to the text decoration module in CSS?
<AmeliaBR> https://svgwg.org/svg2-draft/text.html#TextDecorationProperties
<myles> AmeliaBR: Yes, we have a whole section about it, to try to describe how it should interact.
<myles> AmeliaBR: it's a big wall of text. I don't know how much would persist.
<myles> myles: this isn't an SVG problem, it shouldn't go in SVG
<myles> AmeliaBR: <missed>
<myles> krit: Let's move the text out of SVG
<myles> AmeliaBR: Who wants to actually do the work?
<myles> AmeliaBR: this is about text decoration and new properties, so someone will have to go through the specs to figure out what the changes should be
<myles> krit: Someone should do it with fantasai, she will know what to do.
<myles> krit: I can take an action if no one else wants to
<myles> Tavmjong: It's been 4 years since CSS said they were going to fix this. We should push them
<myles> krit: It's well defined in CSS but we need to mention SVG. Is there agreement that it should go into CSS?
<myles> krit: SVG-specific text decoration color definition should move to a CSS module. Follow up with CSSWG.
<myles> Tavmjong: We don't define text decoration color already.
<myles> AmeliaBR: Because we don't use it, we use these new ones.
<myles> AmeliaBR: It might be as simple as saying that text decoration color does not directly apply to SVG text.
<myles> AmeliaBR: And then teh fill and stroke module can define which properties work instead
<myles> krit: It's up to the CSSWG about where it should go.
<myles> krit: Both fill and stroke and this spec are part of CSSWG. We can give guidance.
<myles> AmeliaBR: Text-decoration module is candidate rec, so they'll not want to make too many changes.
<myles> krit: It's up to the CSSWG.
<myles> krit: objections?
<myles> RESOLVED: SVG-specific text decoration color definition should move to a CSS module. Follow up with CSSWG.
<myles> krit: Let's talk about text-decoration-fill and text-decoration-stroke. Should we do the same?
<myles> RESOLVED: Remove text-decoration-fill and text-decoration-stroke from SVG. Suggest to SVGWG to move their definitions to CSS fill and stroke or CSS text decoration
<myles> RESOLVED: Remove text-decoration-fill and text-decoration-stroke from SVG. Suggest to CSSWG to move their definitions to CSS fill and stroke or CSS text decoration
<myles> s/RESOLVED: Remove text-decoration-fill and text-decoration-stroke from SVG. Suggest to SVGWG to move their definitions to CSS fill and stroke or CSS text decoration//

[css-meeting-bot]

The CSS Working Group just discussed Move SVG text-decoration features to a CSS draft, and agreed to the following:

• RESOLVED: text decoration fill and stroke goes into fill and stroke. Shapes properties go into Shapes L2. Both with notes they're at risk and looking for impl interest

The full IRC log of that discussion

<dael> Topic: Move SVG text-decoration features to a CSS draft
<dael> github: https://github.com//issues/591
<dael> Rossen: request to move text decoration features into css WD
<dael> Rossen: Sounds like we took all resolutions last week about moving
<dael> Rossen: We have resolution for text-decoration-fill and -stroke. What's asked now?
<dael> astearns: Resolutions are from SVG WG
<dael> Rossen: You're correct. I was remembering the resolution frenzy a week or 2 ago
<dael> Rossen: So SVG group is more then happy if we can take text decor related prop back into CSS
<dael> Rossen: Since there are already resolutions on this in the issue we can do one to accept them all
<dael> Rossen: Comments or objections?
<dael> florian: Would this be text decoration L4?
<dael> Rossen: That would be my expectation unless there's a reason to put anywhere else
<tantek> are they implemented outside of SVG?
<dael> AmeliaBR: fill and stroke module is other logical place. We're rec to move to CSS b/c fill and stroke is taking basic fill and stroke properties which these line up with. They're eq. of text decoration color but if you're using fill and stroke you need to continue that
<dael> AmeliaBR: They're in SVG2 right now, but not stable enough for impl to stay there. Fill and stroke module is also called CSS Paints
<tantek> q?
<dael> AmeliaBR: It's in FXTF repo
<tantek> q+
<dael> florian: Is there a resolution to move these to CSS Repo?
<AmeliaBR> https://drafts.fxtf.org/paint/
<dael> AmeliaBR: All FXTF specs are full responcibility of CSS
<dael> florian: Yes, but did we resolve to move them
<dael> Rossen: Yes, I'm pretty sure we have resolutions
<Rossen> ack tantek
<dael> tantek: Are these impl yet? Or are they things impl said they want to impl?
<dael> AmeliaBR: No impl yet which is why we can't keep in SVG2
<dael> tantek: Makes sense for moving them out.
<dael> tantek: Do we have any positive noises or statements about intent to experiment or implement from any implementors?
<dael> AmeliaBR: In SVG we've had positive statements of the type where if anyone else impl we'll impl too. Nothing beyond that
<dael> Rossen: Shape properties were discussed at length. Only impl at time interested was inkscape. Browser impl weren't interested at the time
<dael> Rossen: I remember a couple years ago consensus was we will move and use css shapes L2 and go from there. See how much impl interest that takes
<dael> Rossen: text decoration fill/stroke I don't recall. I trust AmeliaBR.
<dael> Rossen: If the leading question is if they should go to WICG instead that's a good point
<dael> fantasai: I think these properties are quite straight forward to what is in fill and stroke already. Question on if they should exist is more interesting. We can add and say at risk and point out we're not sure this is high priority to have fill and stroke sep. I don't think WICG makes any sense b/c analogous to what we have
<dael> TabAtkins: Agree. At bare min we're adopting the definitions as exist. We can put in an appendix and note they may not make it.
<fantasai> s/straight forward/straight forwardly analogous/
<dael> tantek: I'm okay incubating these in WG b/c we've shown good practice in the past. If we don't have impl with interest I'd ask we note in the spec we're looking for impl interest so we're transparent. Other then that fine with where group puts this
<dael> fantasai: We can put this in an appendix with that note
<astearns> https://drafts.fxtf.org/fill-stroke/#text-decor
<tantek> concern with appendix is that indicates informative intent, whereas I think I am hearing normative intent
<dael> AmeliaBR: There's a placeholder section already in fill and stroke and it even says they should be at risk, jsut doesn't have actual definitions. Can slot in neatly there right now
<myles> i'd like to implement these
<fantasai> tantek, appendices are normative unless otherwise noted
<tantek> since when? lol
<dael> Rossen: Sounds like we're taking text docration fill/stroke into Fill and Stroke spec and shapes into Shapes L2 with a note calling for impl interest
<dael> Rossen: Reasonable?
<tantek> +1
<fantasai> tantek, since as long as I've been working with W3C specs? :)
<fantasai> tantek, https://www.w3.org/TR/CSS2/zindex.html#q23.0
<dael> Rossen: Objections to adopting text decoration fill and stroke into text decoration with a note calling for impl interest. Same for shaping into Shape L2?
<tantek> fantasai, not since css 2.1 for sure - those were 100% informative / non-normative :P
<dael> AmeliaBR: Fill and stroke spec is what we talked about.
<dael> Rossen: Sorry, text decoration fill and stroke goes into fill and stroke. Shapes properties go into Shapes L2
<fantasai> tantek, I can't tell if you're joking or if you just completely forgot what was in the CSS2 appendices :)
<dael> RESOLVED: text decoration fill and stroke goes into fill and stroke. Shapes properties go into Shapes L2. Both with notes they're at risk and looking for impl interest