[css-pseudo] highlights and decoration propagation

[delan]

When selecting the following (demo):

<style>
.example1::selection { text-decoration: blue underline; }
.example1 sup::selection { text-decoration: green overline; }
.example2::selection { text-decoration: #66339980 underline; }
.example3::selection { text-decoration: underline; }
style>
<span class="example1">Hello, <sup>worldsup>!span>
<span class="example2">Goodbye, <span>spacespan>!span>
<span class="example3">On my way, <sup>coresup>!span>

1. Should “world” have (a) green overline and blue underline, or (b) green overline only? The underlying question is… do highlights support something like decoration propagation?
2. Should “space” be (a) underlined twice yielding a darker line, (b) underlined once yielding the same line colour, or (c) not underlined at all? The underlying question is… if highlights do propagate decorations, wouldn’t that interact poorly with highlight inheritance treating all properties as inherited?
3. Should “core” appear to have underlines on (a) superscript baseline and normal baseline, (b) superscript baseline only, or (c) normal baseline only? The underlying question is… if highlights don’t propagate decorations, with text instead relying on inheritance to still be decorated in descendants, wouldn’t that be inconsistent with how decorations should generally render in descendants?

We want to be careful not to inadvertently favour the incorrect decoration impl in Blink^ and WebKit, where descendants paint propagated decorations as if they were specified directly — equivalent to 3(b) in non-highlight content.

(cc @frivoal, @fantasai, @mrego, @MatsPalmgren)

^ fixed for underlines in Chromium 105

[delan]

@frivoal, @fantasai, any thoughts? We are starting to implement this in Blink (e.g. CL:3344847), but it would be good to agree on how this should work before we enable it everywhere.

[css-meeting-bot]

The CSS Working Group just discussed highlights and decoration propagation, and agreed to the following:

• RESOLVED: Highlight pseudos continue to inherit the text-decor properties, but do not propagate decorations the normal document.

The full IRC log of that discussion

Topic: highlights and decoration propagation
github: https://github.com//issues/6829
delan: some background, text-decs have this thing called decoration propagation
delan: which is normally how descendants ensure they're also decorated
delan: the text-dec props aren't inherited normally, they use this propagation instead
delan: however, with highlight pseudos, we've saying all properties are inherited, even if they're not normally defined to inherit
delan: So how do these two things interact? Do we still have decor propagation anyway?
delan: If we do, it seems like you'd get a second underline, which might not be desirable
delan: on the other hand, if we say no, then we'll be relying on inheritance to ensure children are decorated, which also has negative side effects
delan: So: do decorations propagate into highlight pseudos?
ack fantasai_
fantasai: I think when decors propagate it's from one element to another, and for highlight pseudos, each piece of a highlight pseudo is applying decors on its own
fantasai: so i think they don't propagate if they're set above the highlight pseudo
fantasai: say you ahve a

with an
fantasai: If you decor the

if propagates to the
fantasai: if you highlight across it, there'll be two pieces, inside and outside the em
what is the interaction when highlights come across an inline which is a stacking-context?
fantasai: each one will have an underline decl, you don't want it to be twice. you don't want to propagate since each piece takes care of the underline itself
fantasai: I think that's what happens, but might give different results.
fantasai: Propagation and inheritance can give different thickness
fantasai: but we probably want it to look like a normal underline, so we *do* want it to propagate...
delan: for example, a ^{insdie the}

. Normally there's a single underline that doesn't jump up. (Blink does jump up, but we do it wrong.)
delan: We don't actually do the decorating box, we do an inheritance hack.
fantasai: I think what you want is to render as if it's propagated, but the existence of the underline is based on inheritance, but then......
fantasai: Dunno if this makes sense. Inherits like every other property, but instead of each part drawing its own, they look up to see if they would propagate from their parent.
q+
fantasai: I think that would get us the results we want.
ack florian
florian: I agree in general. I wonder if it's that bad in the case of highlight pseudos if we do jump up and down.
florian: In a whole paragraph with some ^{you do want something continuous and homogenous.
florian: But in highlights it might depend on hwo you get there. If you highlight the whole para, yeah you might want it to be the same. But if you start within the sup, maybe you do want it to be up. And as you drag out to the normal text, maybe the whole highlight moves down, or just the part in the normal text.
florian: it's not hierarchical.
florian: So if we don't fix the inconsistency for highlights, maybe that's fine, unlike in the normal case.
delan: If we rely on inheritance, wouldn't we...
delan: Now that I think about it, I'm not sure that saying there's not propagation is really all that feasible.
delan: Becuase the parent will draw its decoration, and there will have to be additional work done to ensure that it stops painting its decor when there's a child. that would still require changes to impls.
astearns: Ian had a question about fi there's anything interesting in the interaction with stacking contexts?
iank_: if you've got an inline which is self-painting, a stacking context, is there any interesting interaction there?
delan: It sounds like if we relied on inheritance to "propagate", then that would cause problems.
delan: Is how it's supposed to work normally that when you have a stacking context propagation doesn't happen?
iank_: Unsure, is why I was asking.
q+
iank_: Is it possible to have inlines that paint independenty from the rest of the inline content, and if there ar eimplications.
iank_: Fine if we don't have an answer.
fantasai: When you're doing hihglighting normally, if you're hilighting the para and there's an inline-block inside, i don't think you highlight the inline-block, you just skip it or run the line across it, depending.
(all the "highlight"s mean underlines)
fantasai: So maybe it just makes sense to use the inheritance model even if it doesn't work as well for sups.
florian: One thing I wanted to ask - is the worry you have actually going to pan out like this?
florian: Unlike the normal text-decor we're not applying to the whole para.
fantasai^: because in the case of highlights, we'd want to go into the inline block to indicate what's highlighted
florian: If we highliht from the start of the para, thru a superscript, to the end of the para, we actually have three highlight pseudos, right?
specificially thinking about inlines which are self painting, e.g.}

text self
painting
q+
florian: You're not highlighting the parent "behind" the sup, you're highlighting three adjacent chunks
ack florian
delan: That's how we do it in Blink, we paint chunks.
delan: Not sure if that's correct.
iank_: at the IFC level we have a data structure that determines where to paint decoarations for the whole IFC
iank_: We can chat offline about this.
astearns: So what I heard was, there is a reason for text-decors in highlights to render differently than in normal elements
astearns: At first I thought this was wrong, but the scenario about starting a highlight in a sup and then dragging out of it, means the highlight decors change as you drag. I think that's wrong, they should be stable as you do the highlight gesture.
astearns: So that suggests to me we should only be using inheritance, no propagation.
delan: Not sure I follow, that's not a problem outside of highlight land
astearns++
astearns: Outside of highlights you have the decor set on an element, and it propagates to the children, and there's a stable rendering of that
astearns: In the highlighting gesture you can get an unstable decoration state if you're using propagation painting rules
delan: Agree that's not desirable. What if we went the other way and said they do have propagation, but the decoration properties aren't inherited?
q+
ack astearns
delan: Everything else continues inheriting, so things like background-color works. But not text-decor props. Would that work?
astearns: I think that might still ahve problems. Say I start a highlight within a sup. How do you assess the propagation rules? You don't know how far up the parent chain to go, so you just propagate from the sup. Now you drag it out, you've got a shared parent, the propagation changes?
delan: I think we could use the same rules as for originating elements.
delan: Whether you've highlighted something determines whether we actualy paint the decor there.
delan: But we actually figur eit out as if highlighted
ack astearns
florian: Abspos example - if you highlight something that's been absposed elsewhere.
florian: Classically, when you underline a para, the abspos child doesn't get underlined.
florian: Here if you start the selection in the abspos you want to see the highlight styles in the abspos, and if you drag into the para text you don't want it to suddeny change.
florian: In general we're just not highlighting one span of text, we're highlighting lots of bits.
s/At first I thought this was wrong/At first I thought the answer was no/
delan: That makes sense
q-
astearns: So I think we can get a resolution to have text-decor properties in highlight pseudos inherit only, not propagate any decorations?
delan: Sounds good.
RESOLVED: Highlight pseudos continue to inherit the text-decor properties, but do not propagate decorations the normal document.