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

[mediaqueries-4] Lift parens to <media-in-parens> #6806

Merged
merged 1 commit into from
Nov 9, 2021

Conversation

andruud
Copy link
Member

@andruud andruud commented Nov 9, 2021

For container queries (css-contain-3), it would be convenient to
be able to reference paren-less <media-feature>, since that grammar
wants to wrap the value in a function rather than plain parentheses.

As far as I can tell, <media-feature> is only used by <media-in-parens>,
so this should be safe.

For container queries (css-contain-3), it would be convenient to
be able to reference paren-less <media-feature>, since that grammar
wants to wrap the value in a function rather than plain parentheses.
@tabatkins
Copy link
Member

Yeah, I like that organization a little better too, keeping all the parens up in the same production.

@tabatkins tabatkins merged commit 1af56e0 into w3c:main Nov 9, 2021
@andruud andruud deleted the lift_media_feature_parens branch November 9, 2021 19:36
Copy link
Contributor

@mirisuzanne mirisuzanne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks great

blueboxd pushed a commit to blueboxd/chromium-legacy that referenced this pull request Nov 25, 2021
In order to make it easier to define the grammar of container queries,
there was a change in the spec regarding where parens enclosing
a <media-feature> are handled. Previously, the parens were part
of <media-feature> itself, but as of [1] they were lifted to the
<media-in-parens> production.

This CL represents the corresponding change in our parser, as a
preparation for implementing the container queries syntax.
MediaQueryFeatureExpNode now represents the "bare" <media-feature>,
without any parens in its serialization. The parens are added
explicitly as a MediaQueryNestedExpNode wrapped around the
MediaQueryFeatureExpNode.

[1] w3c/csswg-drafts#6806

Bug: 1214810
Change-Id: I69c0082fac02d18623beed06228be57a91e7c282
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3301699
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/main@{#945339}
@frivoal frivoal added the mediaqueries-4 Current Work label Dec 2, 2021
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this pull request Oct 14, 2022
In order to make it easier to define the grammar of container queries,
there was a change in the spec regarding where parens enclosing
a <media-feature> are handled. Previously, the parens were part
of <media-feature> itself, but as of [1] they were lifted to the
<media-in-parens> production.

This CL represents the corresponding change in our parser, as a
preparation for implementing the container queries syntax.
MediaQueryFeatureExpNode now represents the "bare" <media-feature>,
without any parens in its serialization. The parens are added
explicitly as a MediaQueryNestedExpNode wrapped around the
MediaQueryFeatureExpNode.

[1] w3c/csswg-drafts#6806

Bug: 1214810
Change-Id: I69c0082fac02d18623beed06228be57a91e7c282
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3301699
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/main@{#945339}
NOKEYCHECK=True
GitOrigin-RevId: 80c8bb264c8128885bf486e818129c4d2ecd5f47
cdoublev added a commit to cdoublev/csswg-drafts that referenced this pull request Mar 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
mediaqueries-4 Current Work
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants