[css-pseudo-4] Support for highlight pseudos declarations inside @container media queries

[schenney-chromium]

The interactions between CSS container queries and highlight pseudos are not discussed anywhere, as best I can tell. In chromium right now you cannot define and use a custom highlight pseudo defined inside an @container media query (I haven't checked ::selection or the others). I would like to disallow it due to implementation challenges.

If there's a compelling use case for changing custom highlights depending on containers queries please add it in the comments.

It's also not currently possible to use container based units in highlight declarations. The obvious thing would be to treat them like font units and resolve against the originating element and that's what seems to be said in the resolution to #7591. But that's also added implementation complexity.

On the one hand, the most likely thing to drive using container units is the font size which would be available, maybe, once #7591 is implemented. On the other hand, do we want the added complexity?

Thoughts?

[emilio]

Curious, what are the implementation challenges?

[emilio]

Generally these pseudo-elements can't affect layout, so they can be computed once layout is done and all containers are sized...

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo-4] Support for highlight pseudos declarations inside @container media queries, and agreed to the following:

• RESOLVED: Disallow the use inside container blocks

The full IRC log of that discussion

<dael> Rossen_: If we need emilio we may have to push
<dael> schenney: I think that was around impl complexity
<Rossen_> q?
<dael> schenney: Question in my mind is do we want to support declaration of new highlight styles inside @container MQs. Different highlight if container has 200px vs 500px? I think not. Then crossed my mind do we want different highlight styles in any MQ?
<dael> schenney: Particularly interested in use cases b/c I cna't think of where you would change highlights beyond printing
<dael> Rossen_: Even for print I'm struggling to justify that.
<fantasai> proposed resolution wfm
<dael> schenney: Maybe if your'e scaling font you want underlines to change, but that's covered in font units. Regardless of ease of implementation it requires a use case. I'd propose we do not allow new highlight styles to be defined
<dael> Rossen_: Sounds reasonable. Anyone have a use case?
<dael> dholbert: You said no MQ or just container?
<TabAtkins> I think MQ is too far, that's pretty static and widely applicable.
<dael> schenney: I would be happy to exclude from all MQ. If that's too far we can resolve on Container and I'll follow-up with other issue
<TabAtkins> I mean, just styling different colors into the highlights based on a MQ is important
<dael> dholbert: I can imagine mobile for different highlights. Maybe prefers-contrast as well
<dael> dholbert: Seems like there could be a case based on MQ. Restricting for container query seems reasonable
<dael> Rossen_: I'd argue for restricting for all and relax the restriction if a use case arises
<emeyer> +1 to Rossen_’s point
<dael> schenney: Let's resolve on container queries. I can open a new issue on all MQ and I'll take the time to go through them all and think about it more
<dael> Rossen_: Yeah. I really wish we could resolve on all MQ. Let's not invent solutions for problems we don't have. There's already enough complexity. Unless there's a strong use case and I didn't hear any
<dael> dholbert: I think reduce-contrast may want different colors
<dael> TabAtkins: The MQ case to have different colors based on color sceme are removed frrom dynamic styles enough that it doesn't seem reasonable to cut them out. In very rare cases MQ should be disallowed on a CSS Feature
<dael> Rossen_: Okay. Prop: Disallow the use inside container blocks. TBD on if further restrictions are needed
<dael> schenney: I'll follow up with an issue to confirm on other cases
<dael> Rossen_: Obj?
<dael> RESOLVED: Disallow the use inside container blocks

[mirisuzanne]

Is this specific to custom ::highlight(), or does it also apply to ::selection? I don't know about the former, but it seems like there would be clear use-cases for changing selection styles in a container.

[schenney-chromium]

Custom highlights are the concern. I'll be opening another issue real soon now for other media queries and also looking at the other highlights. For selection, do have any use case in mind for how selection would change based on a container query?

[mirisuzanne]

With style queries it's even more likely - but even with a size query I would expect text and background colors to change in many different situations. Any time text or background colors are changing, it would be very likely for ::selection to change as well - since selection styles are intended to stand out against a given background.

[lilles]

I don't understand what the implementation concern for Chrome is here. I think the current issues are just bugs.

I've reported https://crbug.com/1481068 and outlined what needs to be done to fix it and also landed two smaller changes that fixes a lot of the cases.

[mirisuzanne]

Given that – I'm adding agenda+ to revisit our resolution (and hopefully revert it). I believe there are clear use-cases for changing these styles in container queries, and there shouldn't be loop concerns.

[lilles]

I've fixed the chromium issues, fwiw.