-
Notifications
You must be signed in to change notification settings - Fork 656
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-contain-3] Container Queries and pseudo elements #6711
Comments
It seems to me as though the tree-abiding pseudo-elements should behave like any other element when finding their containers. That would mean both My instinct was to treat the typographic pseudo-elements also as though they are nested inside a block - but as @tabatkins pointed out on Twitter:
(I think If we don't want to place typographic pseudo-elements more specifically in the tree, I hope we could at least treat them as "inside" the element they are defined on? That would mean |
This CL implements the originating element as the closest possible container for container queries for ::first-letter pseudo elements. This behavior is not yet described in the specification. There is an open issue on github which needs to be resolved [1]. [1] w3c/csswg-drafts#6711 Bug: 1217976 Change-Id: I42521ef35404564b2cd1a4ed9c55ed7669aaa8b1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3297972 Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org> Commit-Queue: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#945432}
Yes, just using the originating element seems to be the right answer. It matches the obvious intuition for tree-abiding pseudos, and provides an unambiguous answer for the non-abiding ones that doesn't expose implementation details we want to remain hidden. |
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: [css-contain-3] Container Queries and pseudo elements<dael> github: https://github.com//issues/6711 <dael> rune: I wanted to take issues 4 & 6 at same time. Hvae prop for both <dael> rune: Easy to explain for psuedo elements. When on selectors the originating element is closest query container <dael> rune: Spec currently doesn't say anything about pseudo elements <dael> rune: For issue with shadow dom prop is establish query container as the shadow including and having the originating element of the select be the first one poss to query <dael> rune: Prop is in the shadow dom issue for that <dael> rune: There's the explaination for how this fits with slotted, before, after, etc <miriam> this comment: https://github.com//issues/5984#issuecomment-980694443 <dael> rune: TabAtkins do you have a better way to explain? <dael> TabAtkins: All in all 3 cases to worry about. first is ordinary tree abiding before and after. That's simple, originating element. Act like they're children already <Rossen_> s/rune/futhark/ <Rossen_> q? <dael> TabAtkins: 2nd is shadow dom like ::part. Refers to element in shadow, but originates in host. If there are query containers between them will they be seen? We believe no b/c would expose internal details of the shadow. <dael> TabAtkins: If users want to query on the dom they see, they won't get that <dael> TabAtkins: Again use originating element <dael> TabAtkins: Final is non-tree like first-line and first-letter. <dael> TabAtkins: Example where div for first-letter is used. Actual markup is a <p> that's a query container. I think again this is not seen b/c otherwise exposes where in the tree the non-abiding pseudo is. We've keep them away from answering for various reasons <dael> TabAtkins: By saying for purpose of query containers we use the originating element and skip the <p> it's nice and simple <dael> TabAtkins: IN all cases use originating element. Straightforward and easy to understand <dael> fantasai: I think proposal makes sense. <dael> futhark: one thing not sure about is multiple pseudo. What's the originating. div before marker. Is the originating of the marker before? <dael> futhark: Attempted to spec final originating element <dael> fantasai: Yes. Term is ultimate originating element <dael> TabAtkins: And agree that's what we want to use <dael> Rossen_: Hearing agreement <dael> Rossen_: Anything we're missing here? Other opinions? <dael> Rossen_: Obj to accept this proposal? <dael> RESOLVED: Accept proposal to in all cases use originating element |
Per resolution for issues w3c#5984 and w3c#6711: w3c#5984 (comment) w3c#6711 (comment)
This CL implements the originating element as the closest possible container for container queries for ::first-letter pseudo elements. This behavior is not yet described in the specification. There is an open issue on github which needs to be resolved [1]. [1] w3c/csswg-drafts#6711 Bug: 1217976 Change-Id: I42521ef35404564b2cd1a4ed9c55ed7669aaa8b1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3297972 Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org> Commit-Queue: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#945432} NOKEYCHECK=True GitOrigin-RevId: c753cccfb9e9c72e475528d1cb4de7ea715d790d
How do we find the container for pseudo elements?
More cases like ::marker and ::backdrop.
::slotted() and ::part() would match the same flat tree ancestor container as they would have when styled with normal selectors in their own tree scopes, right?
The text was updated successfully, but these errors were encountered: