[go: nahoru, domu]
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.

Sign up for GitHub

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

Jump to bottom

[css-contain-3] Container Queries and pseudo elements #6711

Closed
lilles opened this issue Oct 4, 2021 · 4 comments
Closed

[css-contain-3] Container Queries and pseudo elements #6711

lilles opened this issue Oct 4, 2021 · 4 comments
Labels
Closed Accepted by CSSWG Resolution css-contain-3
Projects
Container Queries [css-contain]

Comments

@lilles
Copy link
Member
lilles commented Oct 4, 2021

How do we find the container for pseudo elements?

<div id="outer" style="container-type: inline-size">
  <div id="inner" style="container-type: inline-size"></div>
</div>
@container (min-width: 200px) {
  #inner::before {} /* is #inner or #outer the container? */
  #inner::after {} /* is #inner or #outer the container? */
  #inner::first-letter {} /* is #inner or #outer the container? */
  #outer::first-letter {} /* is #inner, #outer, or an ancestor of #outer the container? */
  #inner::first-line {} /* is #inner or #outer the container? */
  #outer::first-line {} /* is #inner, #outer, or an ancestor of #outer the container? */
}

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?
@mirisuzanne
Copy link
Contributor
mirisuzanne commented Oct 4, 2021 •
edited
Loading

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 #inner::before and #inner::after are inside the #inner container. That would also cover ::marker, ::placeholder, and ::file-selector-button.

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:

This would expose details of where in the tree the non-tree-abiding pseudos are, which seems bad

(I think ::backdrop is similarly not tree-abiding, but there's not much detail in the spec. I don't think there is any use for it responding to containers other than the viewport, since it's always full-screen.)

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 #inner::first-letter responds to #inner, while #outer::first-letter responds to #outer?

@lilles lilles mentioned this issue Nov 1, 2021
Open
blueboxd pushed a commit to blueboxd/chromium-legacy that referenced this issue Nov 26, 2021
[@container] Setup StyleRecalcContext for ::first-letter
c753ccc 
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}
@lilles
Copy link
Member Author
lilles commented Jan 18, 2022 •
edited
Loading

Tests based on having the originating element as the closest possible query container:

https://wpt.live/css/css-contain/container-queries/pseudo-elements-001.html
https://wpt.live/css/css-contain/container-queries/pseudo-elements-002.tentative.html
https://wpt.live/css/css-contain/container-queries/pseudo-elements-003.tentative.html
https://wpt.live/css/css-contain/container-queries/top-layer-dialog-backdrop.html
https://wpt.live/css/css-contain/container-queries/top-layer-dialog-container.html
https://wpt.live/css/css-contain/container-queries/top-layer-dialog.html
https://wpt.live/css/css-contain/container-queries/top-layer-nested-dialog.html

@lilles lilles added the Agenda+ label Jan 18, 2022
@tabatkins
Copy link
Member

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.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-contain-3] Container Queries and pseudo elements, and agreed to the following:

  • RESOLVED: Accept proposal to in all cases use originating element
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

@mozilla-apprentice mozilla-apprentice mentioned this issue Feb 3, 2022
Open
@mirisuzanne mirisuzanne moved this from To do to Needs Edits in Container Queries [css-contain] Feb 3, 2022
lilles pushed a commit to lilles/csswg-drafts that referenced this issue Feb 7, 2022
[css-contain-3] Pseudo elements and shadow DOM w3c#5984 w3c#6711
86271a8 
Per resolution for issues w3c#5984 and w3c#6711:

w3c#5984 (comment)
w3c#6711 (comment)
@lilles lilles mentioned this issue Feb 7, 2022
Merged
lilles pushed a commit to lilles/csswg-drafts that referenced this issue Feb 7, 2022
fixup! [css-contain-3] Pseudo elements and shadow DOM w3c#5984 w3c#6711
87e67ed
lilles added a commit that referenced this issue Feb 7, 2022
@lilles
Merge pull request #7019 from lilles/rune/cq-originating-20220207
4a65f42 
[css-contain-3] Pseudo elements and shadow DOM #5984 #6711
@lilles lilles removed the Needs Edits label Feb 7, 2022
@lilles lilles moved this from Needs Edits to Done in Container Queries [css-contain] Feb 7, 2022
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
[@container] Setup StyleRecalcContext for ::first-letter
45d6acf 
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted by CSSWG Resolution css-contain-3
Projects
Container Queries [css-contain]
Done
Milestone
No milestone
Development

No branches or pull requests
4 participants
@mirisuzanne @tabatkins @lilles @css-meeting-bot