Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
schenney-chromium opened this issue Aug 31, 2023 · 13 comments

Comments

@schenney-chromium
Copy link
Contributor

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
Copy link
Collaborator

emilio commented Sep 6, 2023

Curious, what are the implementation challenges?

@emilio
Copy link
Collaborator

emilio commented Sep 6, 2023

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Member

lilles commented Sep 13, 2023

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
Copy link
Contributor

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
Copy link
Member

lilles commented Oct 24, 2023

I've fixed the chromium issues, fwiw.

@fantasai fantasai added the Async Resolution: Proposed Candidate for auto-resolve with stated time limit label Dec 12, 2023
@schenney-chromium
Copy link
Contributor Author

There are still a few issues with the chromium implementation. I have tests that I can add to WPT later this week. But I agree we should revisit and in fact allow highlights inside media queries.

I also think this can be resolved async.

@astearns
Copy link
Member

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: Revert the previous resolution and allow highlight pseudos inside container queries

@astearns astearns added Async Resolution: Call For Consensus Resolution will be called after time limit expires and removed Agenda+ Async Resolution: Proposed Candidate for auto-resolve with stated time limit labels Dec 27, 2023
@astearns
Copy link
Member

astearns commented Jan 3, 2024

RESOLVED: Revert the previous resolution and allow highlight pseudos inside container queries

@lilles
Copy link
Member

lilles commented Jan 17, 2024

Close as the resolution is to keep the current spec.

@lilles lilles closed this as completed Jan 17, 2024
@mirisuzanne mirisuzanne moved this from In progress to Done in Container Queries [css-contain] Mar 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-pseudo-4 Current Work
Development

No branches or pull requests

7 participants