/cc @fantasai @astearns @therealglazou

@fantasai any chance you can share your thoughts? Questions 1 through 5 represent everything I was directly unsure about with that part of the spec, while questions 6 and 7 might just reflect my poor understanding of explicit defaulting (sorry). Thanks!

1. Does “use” mean used value?

Hmm, I guess this is underdefined. It could even affect the computed value without causing any problems. Probably the answer here should be whatever seems convenient to implementers.

2. Does “highlight colors” refer to a set of properties, and if so, which properties?

It was intended to refer to using the UA's chosen values for selection foreground and background (its “highlight colors”) as color and background-color, matching the set of properties of question 4.

(This should probably say that the UA uses Highlight and HighlightText, actually, now that we have defined these colors as their own keywords.)

3. Do we really mean “for ::selection” only, or did we intend this for all highlight pseudos? The note suggests this rule exists for compatibility with existing ::selection impls, but ::target-text often has a default background-color too.

Currently, we do mean ::selection only. It's a very weird behavior, from the perspective of the cascade. If you and @emilio both think it should be extended to ::target-text, we can consider it.

4. Do we really mean “neither color nor background-color” only, or any of the applicable properties?

Yes. Only if 'color' or 'background-color' is set, specifically and intentionally. There was a discussion about how this doesn't match current implementations earlier... we run into problems as new properties are introduced unless we restrict it thus. Suppose, for example, implementation A supports text-shadow on ::selection and implementation B does not. If implementation B cancels its highight colors when it sees the text-shadow declaration, then when an author specifies text-shadow as the only highlight indication, then the highlights will be visible in implementation A and invisible in implementation B.

5. What does “specified by the author” mean? My best guess is that “specified by the author” means “cascaded value exists, and its origin was not the user agent”. Not specified as in specified value, which iiuc always exists due to defaulting (to transparent for background-color).

Right, this is the intent. Again, we have this weird cascading behavior because of compat. If you have suggestions on how to simplify without breaking compat, I'd be happy to spec such changes.

6. How do we reconcile that with unset and revert? I feel like initial and inherit count as “specified by the author”, because the cascaded and specified values clearly exist for both, but for unset and revert, doesn’t it depend on whether we’re looking “before” or “after” they take effect?

I think if the author wrote

p::selection { background: red; }
p::selection { background: revert; }

they're looking for the behavior that would have resulted from not writing anything, and it would be good if we can provide that.

7. Do all properties become inherited for the purposes of deciding if unset should mean initial or inherit?

I think they would have to, for 'unset' to have the expected effect of erasing any previous declaration.

Thanks for the good questions...

1. Does “use” mean used value?

Hmm, I guess this is underdefined. It could even affect the computed value without causing any problems. Probably the answer here should be whatever seems convenient to implementers.

I'm not sure. I think it should be used value. One reason is that the UA could decide to paint something fancier than what you could achieve with ordinary values. Using computed values would mean that we need to figure out what that means for animations. If we're in used-value land, that's not a concern.

Even if you're not using fancy things that cannot be represented as a color value, transitions might still be tricky, as I suspect we'd need some special-case code to handle this pair of properties that change value when either of them is asigned something, and that doesn't seem important enough to be worth handling.

Shoving all that to used value means we don't get transitions, and we don't have to deal with any of that.

Thanks @fantasai + @frivoal for the thorough answers! So to remind myself when I get back into my impl work:

1. either could be ok, or maybe used value
2. color and background-color
3. ::selection only (for now)
4. color and background-color
5. cascaded value exists, and its origin was not the user agent (or maybe just author)
6. unset truly erases, rather than yielding an inherit/initial “specified by the author”
7. unset truly erases, so it should always be like inherit here, not like initial

I’ve just realised that there’s a third origin between author and UA: the user origin. While it might be possible to extend paired cascade so that it applies to both legs of the cascade (UA-to-user and user-to-author), what I’ve seen of Blink’s impl makes me instead prefer to change “specified by the author” to “specified by other origins”. I think this would also make revert behave more consistently with the idea of rolling back the cascade.

If you and @emilio both think it should be extended to ::target-text, we can consider it.

I can’t speak for Emilio, but I’m leaning slightly towards extending it to all highlights. To me it depends on which inconsistency will annoy authors more: all highlights (effectively ::selection and ::target-text with typical UA defaults) having paired cascade but nothing else, or ::selection having paired cascade but nothing else.

The impl for Blink won’t be much harder either way, and while the rule itself provides a non-zero benefit (making it harder to accidentally create illegible highlight colors), I think I’m not alone in saying that the benefit wouldn’t have been big enough for us to put this in the spec if it weren’t for compat.

So yeah, I would say extend it?

6. unset truly erases, rather than yielding an inherit/initial “specified by the author”

A bit of work went into cleaning up the previous "specified/modified by the author" mess we had related to disabling of appearance:auto. We have sane behavior there now which is basically: any value except revert (but including unset) counts as "specified by the author". We should stick to the same here.

What does inherit mean in highlight pseudo-elements? The spec says

When multiple styles conflict, the winning style is determined by the cascade. When any supported property is not given a value by the cascade, it’s value is determined by inheritance from the corresponding highlight pseudo-element of its originating element’s parent element

So if the cascaded value is inherit, then it doesn't inherit from the parent highlight? It inherits from the originating element?

I would probably expect it to instead use the custom inheritance chain, i.e. inherit from the corresponding highlight pseudo-element of its originating element’s parent element.

A bit of work went into cleaning up the previous "specified/modified by the author" mess we had related to disabling of appearance:auto. We have sane behavior there now which is basically: any value except revert (but including unset) counts as "specified by the author". We should stick to the same here.

To expand on this, after discussing it with @andruud: in Blink, we decided to treat unset as author-specified when rendering non-disregarded properties for widgets with native appearance (auto), at least in part because it gives authors the option of setting something to inherit-or-initial, which might be different to the UA stylesheet and/or native appearance. This is distinct from revert, where we would roll back to UA defaults (or user styles, if any).

While none of that is really specified behaviour, we thought the choice made more sense there, and we’re primarily trying to avoid a situation where we have two different concepts of “specified by the author/non-UA” with subtle differences.

(Context for revert reverting to native UA rendering: #4777 (comment))

So if the cascaded value is inherit, then it doesn't inherit from the parent highlight? It inherits from the originating element?

Interesting @Loirooriol, that didn’t even cross my mind. I agree that inherit should use the parent highlight just like we do for defaulting, I guess this is worth clarifying in the spec.

(Context for revert reverting to native UA rendering: #4777 (comment))

Thanks for that! So from reading that, in appearance, both Blink and Gecko treat unset as specified and revert as not-specified, and andruud argues that this was a good choice there. As for specified by whom, Gecko does author or animation or transition, while Blink currently does author only (but we intend to align with Gecko). No one has said anything about the user origin.

Of course, none of these details about appearance are really specified, but ultimately we want to figure out how to avoid having two concepts of “native/UA-default if specified” in our impl.

To recap without the “uncontested” stuff, we’re left with these opinions so far:

1. used value or computed value? fantasai says either, frivoal says used.
3. ::selection only or all highlights (spec says ::selection)? fantasai defers to impls, i say all (weakly), @emilio?
5. specified by whom (spec says author)? i say all, appearance impls converging on author/animation/transition.
6. should unset count as specified (in css-cascade terms, yes means “treated as inherit/initial” wins, no means “effectively erases” wins)? fantasai says no, andruud says yes.
8. should revert count as specified? fantasai says no, andruud says no.

(hopefully i haven’t misrepresented anyone, if so please correct me)

1. used value or computed value? fantasai says either, frivoal says used.

I think right now this is a used-value time operation in Gecko, it's not only theoretical. e.g. the selection background might be inverted based on contrast with the closest non-transparent background color. That's something pretty hard to do at computed value time, if possible at all.

3. ::selection only or all highlights (spec says ::selection)? fantasai defers to impls, i say all (weakly), @emilio?

I think conceptually all, but same concerns about performance apply to this approach (to ::selection as well).

5. specified by whom (spec says author)? i say all, appearance impls converging on author/animation/transition.

Wdym with "all" here? "author/animation/transition"? Or something else? I think that makes the most sense.

6. should unset count as specified (in css-cascade terms, yes means “treated as inherit/initial” wins, no means “effectively erases” wins)? fantasai says no, andruud says yes.
7. should revert count as specified? fantasai says no, andruud says no.

I agree with @andruud here, I think. unset is a value specified by the author. It's the same as the author specifying the initial value for non-inherited properties, or inherit for inherited ones. revert explicitly reverts to the previous origin.

Wdym with "all" here? "author/animation/transition"? Or something else? I think that makes the most sense.

@delan clarified that she meant "all" as "user/author/animation/transition". I guess that may make some sense for highlights as opposed to appearance, but if possible I'd like to keep just one concept for this.

I think right now this is a used-value time operation in Gecko, it's not only theoretical. e.g. the selection background might be inverted based on contrast with the closest non-transparent background color.

Good point, that makes the spec lawyer in me wonder if “UA must use its own […] only when” forbids UA changes to the author’s highlight colors, like Gecko inverting selection backgrounds or Safari on macOS making opaque selection backgrounds translucent (demo). Blink (and previously WebKit) invert selection backgrounds too, just based on foreground similarity rather than surrounding backgrounds, which is starting to create problems for reftests (cc @mrego).

I believe the spec didn’t intend to forbid these, but I think that’s something worth making more explicit after this issue.

I think conceptually all, but same concerns about performance apply to this approach (to ::selection as well).

Yeah, performance is definitely something I’m still unsure about. For example, my initial Blink impl won’t make Select All slower, but it will make element style recalc slower, and there could be a big penalty for existing content with universal ::selection rules (looking into mitigations soon). I suppose this issue (except q7) is independent of the inheritance stuff though.

I guess that may make some sense for highlights as opposed to appearance, but if possible I'd like to keep just one concept for this.

Maybe we should think about which to keep based on how that will affect stylesheets at each origin. I tried to reason about this but didn’t get very far, because I couldn’t figure out how to play with user origin styles in any of the browsers I use.

5. What does “specified by the author” mean? My best guess is that “specified by the author” means “cascaded value exists, and its origin was not the user agent”. Not specified as in specified value, which iiuc always exists due to defaulting (to transparent for background-color).

Right, this is the intent. Again, we have this weird cascading behavior because of compat. If you have suggestions on how to simplify without breaking compat, I'd be happy to spec such changes.

I’ve never made substantive spec changes before, but I’ve proposed a way to explain this behaviour (and edits for the other points discussed in this issue) in #6665. I ended up using a cascaded-value-based model like my guess above, but I’ve since found a stronger reason (than the one above) not to use a specified-value model: inherit and initial don’t exist as specified values, which would make them impossible to explain.

Good point, that makes the spec lawyer in me wonder if “UA must use its own […] only when” forbids UA changes to the author’s highlight colors, like Gecko inverting selection backgrounds or Safari on macOS making opaque selection backgrounds translucent (demo). Blink (and previously WebKit) invert selection backgrounds too, just based on foreground similarity rather than surrounding backgrounds, which is starting to create problems for reftests (cc @mrego).

It seems there's a nice mess about all this, see more details at: #6150 (comment)

So here’s a recap of this issue in its entirety, including the current state of my proposed edits (#6665). Note that only items 3 and 5 below would be normative changes, the rest were previously unspecified (or just needed rewording for clarity).

That patch also clarifies @Loirooriol’s comment about ‘inherit’, clarifies that UAs are still allowed to tweak highlight colors (pending #6150), and eliminates the overloading of “specified” for a complex concept that’s more or less unique to highlights (and ‘appearance’ impls).

1. used value or computed value? no conflicts, spec doesn’t say. spec doesn’t say, fantasai says either, frivoal says used, emilio says used, 6665 says used.
2. what are highlight colors? no conflicts, spec doesn’t say. fantasai says ‘color’ + ‘background-color’ only (no ‘{stroke,fill}-color’), 6665 says the same.
3. ‘::selection’ only or all highlights? no conflicts, spec says ‘::selection’. fantasai defers to impls, i say all, emilio says all, 6665 says all.
4. which properties disable UA defaults? no conflicts, spec says ‘color’ + ‘background-color’ only. fantasai says the same, 6665 clarifies it.
5. which origins disable UA defaults? currently has conflicts, spec says author. fantasai says author, andruud says author/animation/transition for consistency with ‘appearance’ impls, emilio says the same, 6665 says the same.
   • note that no one has expressed an opinion on the user origin. i wanted to play around with user stylesheets in a real impl before forming my own opinion, but at the time i couldn’t find one (things like devtools and greasemonkey/stylus actually inject styles in author origin). i think epiphany (webkit) or old opera (presto) might be able to actually, but either way, i don’t think we should bloat this issue any further.
6. should unset and/or revert disable UA defaults?
   a. should ‘revert’ disable UA defaults, if the result after reverting no longer has any values in the origins above (see q5)? no conflicts, spec doesn’t say. fantasai says no, andruud says no, emilio says no, 6665 says no.
   b. should ‘unset’ disable UA defaults? no conflicts yet, spec doesn’t say. not sure fantasai had a position on this, andruud says yes, emilio says yes, 6665 says yes.
7. should ‘unset’ mean ‘inherit’ for all properties? no conflicts, spec doesn’t say. fantasai says yes, 6665 says yes.

@fantasai could you please take another look at questions 5 and 6b, as well as my edits?

@delan Wrt which origins disable UA defaults, I'm OK with @emilio's answer as well. Though including the Transitions origin seems weird to me, what if the UA rules want to transition between two styles? That'll still end up in the Transitions origin. Wrt unset/revert, the logic proposed makes sense to me.

wonder if “UA must use its own […] only when” forbids UA changes to the author’s highlight colors, like Gecko inverting selection backgrounds or Safari on macOS making opaque selection backgrounds translucent (demo)

UA cannot do these weird things when the author has specified colors. They have to use the author-specified colors with no modification. But when using UA-chosen colors, they can choose anything.

I couldn’t figure out how to play with user origin styles in any of the browsers I use.

Run a search for "Firefox userContent.css".

@delan Wrt which origins disable UA defaults, I'm OK with @emilio's answer as well. Though including the Transitions origin seems weird to me, what if the UA rules want to transition between two styles?

So reading these few comments, I think the same choice was made for ‘appearance’ because neither Gecko nor Blink are able to tell the difference between a UA transition and an author transition, they are both just transitions? But like ‘appearance’, making transitions suppress UA defaults here improves the experience for authors at the expense of breaking UA transitions? Not sure if I’ve understood that correctly, maybe @andruud and @emilio can correct me.

Wrt unset/revert, the logic proposed makes sense to me. […] Run a search for "Firefox userContent.css".

Thanks! I’ll play around with the user origin, then see if I can make a case for one or the other.

UA cannot do these weird things when the author has specified colors. They have to use the author-specified colors with no modification. But when using UA-chosen colors, they can choose anything.

That would definitely make the reftest story easier, but I don’t think we can allow Safari to paint ::selection as a translucent “wash” and forbid Safari from making opaque ::selection backgrounds translucent.

@mrego pointed out that the Gecko example actually only happens under UA-chosen highlight colors, so no worries there. Let’s discuss Safari in #6853 to avoid making this issue even longer.

@delan Wrt which origins disable UA defaults, I'm OK with @emilio's answer as well. Though including the Transitions origin seems weird to me, what if the UA rules want to transition between two styles?

Paired cascade affects used values only, while transitions (and animations) operate in computed value space, so regardless of whether the transition (and/or animation) origin is included, UA transitions (and animations) will behave as if UA default highlight colors were suppressed while interpolating. If anything, including the transition origin allows UA transitions to work, because if the transition origin didn’t suppress default highlight colors, we would use default highlight colors during any UA transition.

@andruud says there are potentially still some problems with treating UA/user-originating transition and animation styles as “author specified” for native appearance, so if that ends up changing again, we might want to change it here accordingly, but otherwise I don’t think this is a problem for highlight paired cascade.

So reading these few comments, I think the same choice was made for ‘appearance’ because neither Gecko nor Blink are able to tell the difference between a UA transition and an author transition, they are both just transitions? But like ‘appearance’, making transitions suppress UA defaults here improves the experience for authors at the expense of breaking UA transitions? Not sure if I’ve understood that correctly, maybe @andruud and @emilio can correct me.

Yeah, currently in Blink we have no way to tell if some {transition,animation}-origin styles are the result of author transition or UA transition, though we also have no need to do so, as long as our UA stylesheets don’t use any affected transitions/animations.

Run a search for "Firefox userContent.css".

Thanks! I’ll play around with the user origin, then see if I can make a case for one or the other.

So there’s no concept of user default highlight colors, only the UA has default highlight colors, and I don’t expect that to change. But the user stylesheet can set highlight colors, so the main question is, should user highlight colors suppress UA defaults?

If they don’t (as currently proposed), user styles can change one highlight color while leaving the other one as the default highlight color. This is how Firefox currently works. For example, if the default highlight colors are white on blue, and userContent.css says ::selection has a green background, an unstyled page would have white-on-green selections, not initial-on-green, because the default highlight foreground ‘color’ would not be suppressed.

If they do, user styles that change one highlight color will make the other one default to initial. Using the example above (default white-on-blue, plus user background of green), an unstyled page would have initial-on-green selections (typically black-on-green), because the default white foreground ‘color’ would be suppressed.

I don’t really have an opinion on which of those behaviours is better.

However! Either way, setting either of the highlight colors in user styles “splits” paired cascade for authors. Using the example above (default white-on-blue, plus user background of green), if the author also only sets ‘background-color’, then ‘color’ is ‘initial’ as usual. But otherwise, ‘background-color’ is green, regardless of whether the author sets ‘color’. This is again how Firefox currently works. This smells kinda awkward, but I’m not sure if it’s actually problematic.

(summary for meeting)

Highlights have special logic for the UA’s default ‘color’ and ‘background-color’, where setting one suppresses the default for the other at used value time. This is for compatibility with pre-spec ::selection.

In this issue, I had several questions about the way this was worded, but we’ve since reached consensus on everything except what origins should suppress the UA’s default highlight colors. So the ones in question are the animation/transition origins, and the user origin. Should we talk about one at a time?

For animation/transition, I believe suppressing UA defaults is good, if only for consistency with the similar concept of “specified by the author” in ‘appearance’. But ‘animation’ and ‘transition’ aren’t even applicable properties for highlights, so I’m actually not sure it matters? Do we put them in the spec, or comment them out like we’ve done for ‘outline’, or...?

For user origin, we basically want to decide whether the user can set one highlight color and keep the other as the default, or whether setting one highlight color makes the other one default to initial. But either way, doing so also makes things a bit weird from the author’s perspective, so I also want to make sure we’re ok with that.

The CSS Working Group just discussed Paired Cascading of Highlight color/bgcolor, and agreed to the following:

• RESOLVED: Author origin rules, and not user-origin rules, trigger paired cascade fallback

#6665 includes the answers to these questions in the spec. Thanks everyone!