- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Dec 2021 18:02:43 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Highlights and currentcolor`, and agreed to the following: * `RESOLVED: 'color: currentColor' on a highlight takes the next *active* highlight color, so that text is drawn as if highlight weren't taking effect` * `RESOLVED: getComptuedStyle() with a highlight pseudo takes color as if that highlight applied and no other highlight applied` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Highlights and currentcolor<br> <fantasai> delan: Started discussing this issue last week, but only got partway through<br> <fantasai> delan: about special case of setting 'color: currentColor'<br> <fantasai> delan: outside of highlights, it means 'color: inherit'<br> <fantasai> delan: for highlights, actually means something else<br> <fantasai> delan: there were 2 questions originally, now 3<br> <fantasai> delan: 1st question, double-checking, spec says when setting to currentColor, do we want to grab color from next highlight layer below regardless, or only active highlight layers<br> <fantasai> delan: fantasai said it only makes sense to use active highlight layer, and I think everyone agrees on that<br> <fantasai> florian: I'm a little unsure, agree with that assessment, but discussion last time suggested maybe there was a whole different way to think about this<br> <fantasai> delan: that's the 3rd question, whether this is the right way to solve the problem that it solves<br> <fantasai> delan: 2nd question is, if it is the next active highlight specifically, then what happens when you getComputedStyle?<br> <fantasai> delan: getComputedStyle needs to return resolved colors, so has to return an actual color<br> <TabAtkins> q+<br> <fantasai> delan: if you have an element with multiple underlying colors, what do you do<br> <fantasai> delan: currntly a few ideas on how to address that<br> <fantasai> delan: 3rd question, which emilio brought up, this exceptional behavior of currentColor for highlights is odd and complicated<br> <fantasai> delan: wondering if this was the right way to solve the problem, or if better way to solve the problem<br> <fantasai> delan: To clarify, best example of a use case for this, is the spelling and grammar error pseudo-elements<br> <fantasai> delan: a typical styling for that would be to add a red or green squiggly line to the text<br> <fantasai> delan: but you're just adding the decoration, you don't want to change the color of the text<br> <fantasai> delan: if you spell a word, still want to have the same text color<br> <cpn> s/cpn/chcunningham/<br> <fantasai> delan: but given way highlight painting works, if we didn't have this rule for currentColor, then there would be no way to highlight something without changing the color to 'initial' (black)<br> <fantasai> delan: it's complicated and an odd exception, but we need some solution to this problem<br> <fantasai> florian: one extra bit, suggestion last time is that this might be similar to ::first-line<br> <fantasai> florian: we don't redefine how currentColor works, we redefine what inherits from what<br> <fantasai> florian: if you set currentColor on first line, it'll get its color from ::first line<br> <emilio> q+<br> <Rossen_> ack TabAtkins<br> <fantasai> TabAtkins: I'm not certain about best way to handle property itself, but for purpose of getComputedStyle I think it's reasonable to say "pretend it's not selected at all", so just get underlying style<br> <delan> q+<br> <fantasai> TabAtkins: that seems the most straightforward, and doesn't leak info about spelling/grammar errors<br> <TabAtkins> scribe+ TabAtkins<br> <florian> q+ to ask clarification from Tab<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: WE also have to consider that when you set the - we have paired cascading, and it sets to "the color it would have already been" it sets the background, so this behavior needs to represent that as well<br> <Rossen_> ack emilio<br> <fantasai> emilio: does this really only apply to currentCOlor? seems applies to inherited properties applied to highlights<br> <fantasai> emilio: maybe color is the only one atm<br> <fantasai> emilio: seems you'd have the same problem with text-fill and other things<br> <fantasai> emilio: so, in general, I think the right fix would be inheritance, but that might be annoying to implement<br> <Rossen_> q?<br> <Rossen_> ack delan<br> <fantasai> delan: Tab, is it true that you mean same thing as emilio, wrt Q2, my understanding is that if you ask for getComputedStyle for ::selection, we pretend everything is selected and no other highlights apply<br> <fantasai> TabAtkins: no opinion on pretending selected or pretending not selected, defer to impl on that question<br> <fantasai> TabAtkins: but ignoring any other highlights is the important bit<br> <fantasai> delan: sounds like a straightforward solution to that, I agree<br> <fantasai> delan: wrt Q3, inheritance and possible parallels with ::first-line<br> <fantasai> delan: I'm not that fresh on ::first-line and ::first-letter<br> <fantasai> delan: can someone explain how it would work for us to sometimes inherit from another highlight (grab color from ancestor highlight) while still inheriting within this inheritance tree for ???<br> <Rossen_> q?<br> <florian> q-<br> <fantasai> emilio: I think that's the hard part<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/6818<br> <fantasai> emilio: My selection styles inherit from my parent selection styles<br> <Rossen_> q?<br> <fantasai> emilio: E.g. selection style inherits from other highlight which inherits from regular text which inherits from parent selection style<br> <fantasai> delan: ...<br> <fantasai> delan: ::target-text inherits from ::selection style??<br> <fantasai> emilio: whichever order we decide on...<br> <fantasai> emilio: for simplicity, say we have ::selection and ::spelling-error<br> <fantasai> emilio: say ::selection inherits from ::spelling-error, and ::spelling-error inherits from parent ::spelling-error<br> <fantasai> emilio: I think that would get you the right behavior<br> <Rossen_> q?<br> <TabAtkins> fantasai: It would not, because if ::selection inherits from ::spelling-error, and that inherits from parent ::spelling-error, it'll never inherit from the parent selection<br> <fantasai> emilio: ::spelling-error inherits from ::selection<br> <TabAtkins> fantasai: Why would spelling-error inerit from selection?<br> <fantasai> emilio: ::spelling-error inherits from ::selection<br> <fantasai> fantasai: that doesn't work<br> <TabAtkins> fantasai: can you give me an example of the zigzag?<br> <TabAtkins> fantasai: there's two pseudos - selection paints over spelling-error - what's the inheritance chain?<br> <fantasai> delan: So you go in a zigzag, our ::selection inherits from our ::spelling error, and our ::spelling-error inherits from our parent's ::selection, which inherits from parent's ::spelling-error, etc.<br> <TabAtkins> child selection -> child spelling error -> parent selection -> parent spelling-error<br> <fantasai> fantasai: Why would it make sense for ::spelling-error to inherit from parent's ::selection?<br> <TabAtkins> fantasai: Why would it make sense for spelling error to inherit from the parent's selection?<br> <fantasai> emilio: I guess it doesn't quite...<br> <fantasai> delan: when you jump back in the zigzag, you have a lower layer inheriting from a higher layer<br> <fantasai> delan: it's hard for me to imagine this<br> <TabAtkins> fantasai: imagine spelling was red, seleciton was blue<br> <TabAtkins> fantasai: you highlight some things<br> <Rossen_> q?<br> <TabAtkins> fantasai: the zigzag means you'll get red text when you highlight, if the parent has an spelling error<br> <tantek> This (special inheritance across pseudo-elements) seems confusing enough to the WG that I can't imagine authors actually coming up with a predictive mental model for what is going on.<br> <TabAtkins> fantasai: seems weird<br> <fantasai> Rossen_: Seems work to do here, need to decide if we are going to rethink through inheritance or to tweak existing model<br> <delan> q+<br> <fantasai> delan: This is a valid conversation, about solving via other mechanism<br> <fantasai> delan: but wondering if we can resolve Q1 and Q2, based on assumption that things work the way specified now using currentColor<br> <fantasai> delan: and later if we want to solve a different way, we can do that?<br> <fantasai> Rossen_: Makes sense to me<br> <florian> q+<br> <dbaron> I *think* one of he goals here is that which of grammar-error/spelling-error/target-text/selection's styles wins does *not* depend on which elements are associated with the selectors (and how they nest), but rather on a spec-defined order of the pseudos.<br> <Rossen_> ack florian<br> <delan> q+<br> <fantasai> florian: I support doing this. Earlier Tab suggested that you put either everything selected or nothing is, suggest assuming everything because otherwise no point in querying ::selection<br> <Rossen_> ack delan<br> <fantasai> delan: I thought question was between nothing or pretending that just the pseudo you asked for<br> <fantasai> florian: that's the one<br> <fantasai> florian: answering that just the pseudo you asked for is everywhere and nothing else<br> <fantasai> florian: It's not useful to assume no highlights at all<br> <fantasai> emilio: I think that's the current behavior<br> <fantasai> emilio: I'm moderately sure that querying ::selection will get you the ::selection styles<br> <fantasai> delan: pretendign everything else not selected also solves, what happens if ::selection leaks a color from ::spelling-error or ::grammar-error, which we made it forbidden for privacy reasons so this solves that problem<br> <fantasai> emilio: it's also simpler, fixes privacy leak<br> <fantasai> florian: alternative we mentioned last time was to fragment things, and answer question about first one, but overkill for no good reason<br> <fantasai> delan: don't think anyone needs that answer<br> <fantasai> florian: if we really needed that answer, we'd need an API to reply on each individual fragment<br> <fantasai_> delan: For Q1, proposing that we say that when you say 'color: currentColor' on a highlight pseudo, you grab the next active highlight's color<br> <fantasai_> delan: so that color is as if this highlight wasn't applying<br> <fantasai_> emilio: ...<br> <fantasai_> fantasai_: currentColor computes to itself<br> <fantasai_> emilio: except in 'color' property<br> <fantasai_> emilio: I'll double-check<br> <fantasai_> emilio: anyway, seems fine<br> <fantasai_> RESOLVED: 'color: currentColor' on a highlight takes the next *active* highlight color, so that text is drawn as if highlight weren't taking effect<br> <fantasai_> scribe+<br> <fantasai_> delan: For Q2, when you call getComputedStyle() with a highlight pseudo, the color of the result should behave as if the pseudo you passed in is highlighted, but all other highlight pseudos are not highlighting<br> <fantasai_> delan: we pretend<br> <florian> +1<br> <fantasai_> RESOLVED: getComptuedStyle() with a highlight pseudo takes color as if that highlight applied and no other highlight applied<br> <fantasai_> Rossen: we'll take Q3 back to the issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6818#issuecomment-995033957 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 December 2021 18:02:45 UTC