- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Apr 2022 16:30:24 +0000
- To: public-css-archive@w3.org
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.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: highlights and decoration propagation<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6829<br> <TabAtkins> delan: some background, text-decs have this thing called decoration propagation<br> <TabAtkins> delan: which is normally how descendants ensure they're also decorated<br> <TabAtkins> delan: the text-dec props aren't inherited normally, they use this propagation instead<br> <TabAtkins> delan: however, with highlight pseudos, we've saying all properties are inherited, even if they're not normally defined to inherit<br> <TabAtkins> delan: So how do these two things interact? Do we still have decor propagation anyway?<br> <TabAtkins> delan: If we do, it seems like you'd get a second underline, which might not be desirable<br> <TabAtkins> 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<br> <TabAtkins> delan: So: do decorations propagate into highlight pseudos?<br> <astearns> ack fantasai_<br> <TabAtkins> 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<br> <TabAtkins> fantasai: so i think they don't propagate if they're set above the highlight pseudo<br> <TabAtkins> fantasai: say you ahve a <p> with an <em><br> <TabAtkins> fantasai: If you decor the <p> if propagates to the <em><br> <TabAtkins> fantasai: if you highlight across it, there'll be two pieces, inside and outside the em<br> <iank_> what is the interaction when highlights come across an inline which is a stacking-context?<br> <TabAtkins> 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<br> <TabAtkins> fantasai: I think that's what happens, but might give different results.<br> <TabAtkins> fantasai: Propagation and inheritance can give different thickness<br> <TabAtkins> fantasai: but we probably want it to look like a normal underline, so we *do* want it to propagate...<br> <TabAtkins> delan: for example, a <sup> insdie the <p>. Normally there's a single underline that doesn't jump up. (Blink does jump up, but we do it wrong.)<br> <TabAtkins> delan: We don't actually do the decorating box, we do an inheritance hack.<br> <TabAtkins> 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......<br> <TabAtkins> 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.<br> <florian> q+<br> <TabAtkins> fantasai: I think that would get us the results we want.<br> <astearns> ack florian<br> <TabAtkins> 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.<br> <TabAtkins> florian: In a whole paragraph with some <sup> you do want something continuous and homogenous.<br> <TabAtkins> 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.<br> <TabAtkins> florian: it's not hierarchical.<br> <TabAtkins> florian: So if we don't fix the inconsistency for highlights, maybe that's fine, unlike in the normal case.<br> <TabAtkins> delan: If we rely on inheritance, wouldn't we...<br> <TabAtkins> delan: Now that I think about it, I'm not sure that saying there's not propagation is really all that feasible.<br> <TabAtkins> 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.<br> <TabAtkins> astearns: Ian had a question about fi there's anything interesting in the interaction with stacking contexts?<br> <TabAtkins> iank_: if you've got an inline which is self-painting, a stacking context, is there any interesting interaction there?<br> <TabAtkins> delan: It sounds like if we relied on inheritance to "propagate", then that would cause problems.<br> <TabAtkins> delan: Is how it's supposed to work normally that when you have a stacking context propagation doesn't happen?<br> <TabAtkins> iank_: Unsure, is why I was asking.<br> <florian> q+<br> <TabAtkins> iank_: Is it possible to have inlines that paint independenty from the rest of the inline content, and if there ar eimplications.<br> <TabAtkins> iank_: Fine if we don't have an answer.<br> <TabAtkins> 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.<br> <TabAtkins> (all the "highlight"s mean underlines)<br> <TabAtkins> fantasai: So maybe it just makes sense to use the inheritance model even if it doesn't work as well for sups.<br> <TabAtkins> florian: One thing I wanted to ask - is the worry you have actually going to pan out like this?<br> <TabAtkins> florian: Unlike the normal text-decor we're not applying to the whole para.<br> <fantasai_> fantasai^: because in the case of highlights, we'd want to go into the inline block to indicate what's highlighted<br> <TabAtkins> 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?<br> <iank_> specificially thinking about inlines which are self painting, e.g. <div>text <span style="position: relative; z-index: 2; opacity: 0.5; background: lime;">self<br>painting</span><br> <astearns> q+<br> <TabAtkins> florian: You're not highlighting the parent "behind" the sup, you're highlighting three adjacent chunks<br> <astearns> ack florian<br> <TabAtkins> delan: That's how we do it in Blink, we paint chunks.<br> <TabAtkins> delan: Not sure if that's correct.<br> <TabAtkins> iank_: at the IFC level we have a data structure that determines where to paint decoarations for the whole IFC<br> <TabAtkins> iank_: We can chat offline about this.<br> <TabAtkins> astearns: So what I heard was, there is a reason for text-decors in highlights to render differently than in normal elements<br> <TabAtkins> 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.<br> <TabAtkins> astearns: So that suggests to me we should only be using inheritance, no propagation.<br> <TabAtkins> delan: Not sure I follow, that's not a problem outside of highlight land<br> <fantasai_> astearns++<br> <TabAtkins> 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<br> <TabAtkins> astearns: In the highlighting gesture you can get an unstable decoration state if you're using propagation painting rules<br> <TabAtkins> 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?<br> <florian> q+<br> <astearns> ack astearns<br> <TabAtkins> delan: Everything else continues inheriting, so things like background-color works. But not text-decor props. Would that work?<br> <TabAtkins> 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?<br> <TabAtkins> delan: I think we could use the same rules as for originating elements.<br> <TabAtkins> delan: Whether you've highlighted something determines whether we actualy paint the decor there.<br> <TabAtkins> delan: But we actually figur eit out as if highlighted<br> <astearns> ack astearns<br> <TabAtkins> florian: Abspos example - if you highlight something that's been absposed elsewhere.<br> <TabAtkins> florian: Classically, when you underline a para, the abspos child doesn't get underlined.<br> <TabAtkins> 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.<br> <TabAtkins> florian: In general we're just not highlighting one span of text, we're highlighting lots of bits.<br> <astearns> s/At first I thought this was wrong/At first I thought the answer was no/<br> <TabAtkins> delan: That makes sense<br> <florian> q-<br> <TabAtkins> astearns: So I think we can get a resolution to have text-decor properties in highlight pseudos inherit only, not propagate any decorations?<br> <TabAtkins> delan: Sounds good.<br> <TabAtkins> RESOLVED: Highlight pseudos continue to inherit the text-decor properties, but do not propagate decorations the normal document.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6829#issuecomment-1098255113 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 April 2022 16:30:25 UTC