Skip to content

[css-values-5] Disallow mix/random/tree-counting functions in some contexts #10982

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

Open
cdoublev opened this issue Oct 1, 2024 · 10 comments
Open

Comments

@cdoublev
Copy link
Collaborator

cdoublev commented Oct 1, 2024

Based on comments in #10879, any value defined in CSS Values and Units should be valid in any context other than a property value, unless otherwise specified.

mix, random, tree couting functions, need an element, but are not explicitly disallowed in other contexts.

I would say they should be invalid in media queries and any descriptor value, and valid in the prelude of keyframe and @container rules. (It seems easier to find use cases in the prelude of keyframe rules.)

Perhaps defining the concept of element-dependent (substitution) value could help clarifying this: such value would be invalid in all contexts except those "associated" to an element, or that do not need to resolve its value (feature queries). var(), attr(), toggle(), <whole-value>, would be element-dependent subsitution values.

I do not know if any of these substitution functions should/can be valid in the HTML srcset attribute (to replace <length>), but invalid in the media attribute. I guess none is currently accepted, not even math functions.

@fantasai
Copy link
Collaborator

fantasai commented Oct 8, 2024

Some types of mix functions are reasonable to allow anywhere, they just represent the interpolation between two values and that's fine. We could also define something reasonable for random() outside of an element context. Agree with defining some kind of concept for element-dependent functions, though, and making such invalid (if they don't have a reasonable fallback behavior).

@cdoublev
Copy link
Collaborator Author

cdoublev commented Oct 9, 2024

Allowing them anywhere would require making some arguments (<'animation-timeline'>, per-element) invalid in these other contexts.

@lilles
Copy link
Member

lilles commented Mar 14, 2025

I was thinking they should be allowed in container queries, evaluating against the container element, but then the size query container may fall back to the viewport which is not an element.

@lilles
Copy link
Member

lilles commented Mar 14, 2025

@tabatkins @emilio @nt1m Any opinions on whether tree-counting functions like sibling-index() should be valid parse time in:

  • @page properties
  • descriptors for @font-face and other at-rules which do not apply directly to elements
  • @container queries (this is particularly interesting since the container element can be a natural choice most of the time)
  • @media queries

And if such functions are valid, what should they evaluate to.

aarongable pushed a commit to chromium/chromium that referenced this issue Mar 14, 2025
Tree-counting functions such as sibling-index() do not have a useful
interpretation in contexts where there are no elements involved. For
instance in @media queries and @font-face descriptors.

This is currently not per any specification, but there is an open issue
for it:

w3c/csswg-drafts#10982

We still allow sibling-index() in @page properties with this CL.

Bug: 40282719

Change-Id: I10b939d1981e9eb3347f18a7ef292cdd425b3cbc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6352179
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1432625}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Mar 14, 2025
Tree-counting functions such as sibling-index() do not have a useful
interpretation in contexts where there are no elements involved. For
instance in @media queries and @font-face descriptors.

This is currently not per any specification, but there is an open issue
for it:

w3c/csswg-drafts#10982

We still allow sibling-index() in @page properties with this CL.

Bug: 40282719

Change-Id: I10b939d1981e9eb3347f18a7ef292cdd425b3cbc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6352179
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1432625}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Mar 14, 2025
Tree-counting functions such as sibling-index() do not have a useful
interpretation in contexts where there are no elements involved. For
instance in @media queries and @font-face descriptors.

This is currently not per any specification, but there is an open issue
for it:

w3c/csswg-drafts#10982

We still allow sibling-index() in @page properties with this CL.

Bug: 40282719

Change-Id: I10b939d1981e9eb3347f18a7ef292cdd425b3cbc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6352179
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1432625}
@emilio
Copy link
Collaborator

emilio commented Mar 14, 2025

I think it makes sense to disallow them to begin with...

Only container queries really have something resembling a sensible behavior IMO, and what should the fallback behavior be is not particularly clear...

Disallowing it gives us more leeway to decide on what the right behavior should be once there are concrete use cases for it...

@tabatkins
Copy link
Member

Yeah, I'm fine with starting with them all disallowed, parse-time invalid. We can turn them on as requested.

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Mar 18, 2025
…element contexts, a=testonly

Automatic update from web-platform-tests
Disallow tree-counting functions in non-element contexts

Tree-counting functions such as sibling-index() do not have a useful
interpretation in contexts where there are no elements involved. For
instance in @media queries and @font-face descriptors.

This is currently not per any specification, but there is an open issue
for it:

w3c/csswg-drafts#10982

We still allow sibling-index() in @page properties with this CL.

Bug: 40282719

Change-Id: I10b939d1981e9eb3347f18a7ef292cdd425b3cbc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6352179
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1432625}

--

wpt-commits: ec3fe6dd156fe077571b3219eae3d7e49f1e9025
wpt-pr: 51353
@lilles lilles added the Agenda+ label May 5, 2025
aarongable pushed a commit to chromium/chromium that referenced this issue May 12, 2025
Tentatively drop tree counting functions at parse time for descriptors.

See: w3c/csswg-drafts#10982

Bug: 416634198
Change-Id: I6eba67987f1b7058655391f9c5c3f24cbca23ed9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6532345
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1458692}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 12, 2025
Tentatively drop tree counting functions at parse time for descriptors.

See: w3c/csswg-drafts#10982

Bug: 416634198
Change-Id: I6eba67987f1b7058655391f9c5c3f24cbca23ed9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6532345
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1458692}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 12, 2025
Tentatively drop tree counting functions at parse time for descriptors.

See: w3c/csswg-drafts#10982

Bug: 416634198
Change-Id: I6eba67987f1b7058655391f9c5c3f24cbca23ed9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6532345
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1458692}
lando-prod-mozilla bot pushed a commit to mozilla-firefox/firefox that referenced this issue May 14, 2025
…t-feature-values parsing,

Automatic update from web-platform-tests
Add sibling-index/count() tests for @font-feature-values parsing

Tentatively drop tree counting functions at parse time for descriptors.

See: w3c/csswg-drafts#10982

Bug: 416634198
Change-Id: I6eba67987f1b7058655391f9c5c3f24cbca23ed9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6532345
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1458692}

--

wpt-commits: 5276c6008202aaec267089b3fe3109f56761b257
wpt-pr: 52467

Differential Revision: https://phabricator.services.mozilla.com/D249361
i3roly pushed a commit to i3roly/firefox-dynasty that referenced this issue May 15, 2025
…t-feature-values parsing,

Automatic update from web-platform-tests
Add sibling-index/count() tests for @font-feature-values parsing

Tentatively drop tree counting functions at parse time for descriptors.

See: w3c/csswg-drafts#10982

Bug: 416634198
Change-Id: I6eba67987f1b7058655391f9c5c3f24cbca23ed9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6532345
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1458692}

--

wpt-commits: 5276c6008202aaec267089b3fe3109f56761b257
wpt-pr: 52467

Differential Revision: https://phabricator.services.mozilla.com/D249361
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue May 15, 2025
…t-feature-values parsing,

Automatic update from web-platform-tests
Add sibling-index/count() tests for @font-feature-values parsing

Tentatively drop tree counting functions at parse time for descriptors.

See: w3c/csswg-drafts#10982

Bug: 416634198
Change-Id: I6eba67987f1b7058655391f9c5c3f24cbca23ed9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6532345
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1458692}

--

wpt-commits: 5276c6008202aaec267089b3fe3109f56761b257
wpt-pr: 52467

Differential Revision: https://phabricator.services.mozilla.com/D249361
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue May 16, 2025
…-feature-values parsing,

Automatic update from web-platform-tests
Add sibling-index/count() tests for font-feature-values parsing

Tentatively drop tree counting functions at parse time for descriptors.

See: w3c/csswg-drafts#10982

Bug: 416634198
Change-Id: I6eba67987f1b7058655391f9c5c3f24cbca23ed9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6532345
Reviewed-by: Dominik Röttsches <drottchromium.org>
Commit-Queue: Rune Lillesveen <futharkchromium.org>
Cr-Commit-Position: refs/heads/main{#1458692}

--

wpt-commits: 5276c6008202aaec267089b3fe3109f56761b257
wpt-pr: 52467

Differential Revision: https://phabricator.services.mozilla.com/D249361

UltraBlame original commit: dc5a70bc8c1ecd8affafa9853c904e9546100498
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue May 16, 2025
…-feature-values parsing,

Automatic update from web-platform-tests
Add sibling-index/count() tests for font-feature-values parsing

Tentatively drop tree counting functions at parse time for descriptors.

See: w3c/csswg-drafts#10982

Bug: 416634198
Change-Id: I6eba67987f1b7058655391f9c5c3f24cbca23ed9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6532345
Reviewed-by: Dominik Röttsches <drottchromium.org>
Commit-Queue: Rune Lillesveen <futharkchromium.org>
Cr-Commit-Position: refs/heads/main{#1458692}

--

wpt-commits: 5276c6008202aaec267089b3fe3109f56761b257
wpt-pr: 52467

Differential Revision: https://phabricator.services.mozilla.com/D249361

UltraBlame original commit: dc5a70bc8c1ecd8affafa9853c904e9546100498
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue May 16, 2025
…-feature-values parsing,

Automatic update from web-platform-tests
Add sibling-index/count() tests for font-feature-values parsing

Tentatively drop tree counting functions at parse time for descriptors.

See: w3c/csswg-drafts#10982

Bug: 416634198
Change-Id: I6eba67987f1b7058655391f9c5c3f24cbca23ed9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6532345
Reviewed-by: Dominik Röttsches <drottchromium.org>
Commit-Queue: Rune Lillesveen <futharkchromium.org>
Cr-Commit-Position: refs/heads/main{#1458692}

--

wpt-commits: 5276c6008202aaec267089b3fe3109f56761b257
wpt-pr: 52467

Differential Revision: https://phabricator.services.mozilla.com/D249361

UltraBlame original commit: dc5a70bc8c1ecd8affafa9853c904e9546100498
@lilles
Copy link
Member

lilles commented May 20, 2025

Only container queries really have something resembling a sensible behavior IMO, and what should the fallback behavior be is not particularly clear...

Container queries should always be in an element context, right?

css-conditional-5 currently says:

"Relative length units (including container query length units) and custom properties in container query conditions are evaluated based on the computed values of the query container."

which could be extended to include evaluation of tree counting functions based on the container element.

@emilio
Copy link
Collaborator

emilio commented May 21, 2025

Yes, that's the "something resembling a sensible behavior" :)

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-values-5] Disallow mix/random/tree-counting functions in some contexts, and agreed to the following:

  • RESOLVED: Explicitly allow tree-counting functions in container queries
The full IRC log of that discussion <fantasai> futhark: Some functions are only possible in some contexts, e.g. property declarations or other places where we have an element context
<fantasai> futhark: descriptors, media queries, etc. don't have element context
<fantasai> futhark: For font-relative units we fall back to the default font, but no such fallback for sibling-index()
<fantasai> futhark: Conclusion is to drop such functions at parse-time as invalid where they don't make sense
<weinig> q+
<fantasai> futhark: we can add back case-by-case if something makes sense
<emilio> q+
<fantasai> futhark: One question is wrt container queries, which does have an element context: should we allow such functions in container values?
<Rossen8> ack weinig
<fantasai> weinig: These issues speak to a need, when defining CSS functions, to have a table that specifies how they operate and what contexts they're allowed in
<fantasai> weinig: Quite a matrix now, that each function needs to think about
<fantasai> weinig: like properties, standard set of questions to answer, would be helpful
<Rossen8> ack emilio
<TabAtkins> +1 to finding the set of constraints that we should formalize around
<fantasai> emilio: Agree this is an issue, and container queries is interesting
<fantasai> emilio: I suspect it might be annoying to invalidate on container queries, and I can't think of a good use case... not that ppl might not come up with one
<fantasai> emilio: So my preference would be to start by disallowing, and if people ask for it, we can enable later
<fantasai> emilio: but also ok if people think it's useful to hvae
<fantasai> futhark: For style queries, we currently parse as a non-registered property, so we don't know until we're finished parsing that it's not a property
<emilio> q+
<fantasai> futhark: if it's a registered query
<Rossen8> ack emilio
<miriam> q+
<fantasai> emilio: I was thinking about container queries like size container queries and such
<fantasai> futhark: That too. But wrt style queries specifically
<fantasai> emilio: For style queries... I am not sure I follow, can't you just disallow those functions while parsing?
<fantasai> emilio: That maybe presumes those functions wouldn't be part of the syntax
<fantasai> futhark: When you parse the property the first time, you don't have a registered property on the first pass. So you don't know if it's a sibling-index()
<fantasai> miriam: If we disallow any of these, we should consider one at a time in container queries
<fantasai> miriam: I do think there might be use cases, so I wouldn't want to take as a group
<Rossen8> ack miriam
<fantasai> miriam: because here they would have a meaning, so we'd disallow for some other reason
<weinig> q+
<Rossen8> ack weinig
<fantasai> weinig: Another way to think of this is to reverse it, and say, for each context where CSS values can be used, we should define what types of CSS values are allowed
<fantasai> weinig: For instance, if relative units aren't allowed, but you're using <<number>> a calc() with relative uits wouldn't be allowed
<fantasai> weinig: It's both these unique contexts, and these unique values, that have certain dependencies
<fantasai> weinig: Probably you want one or the other, but maybe both?
<fantasai> weinig: But need to figure out what the constraints are, to define that matrix
<fantasai> futhark: I'm fine with starting by disallowing these functions in contexts where you don't have an element
<weinig> q+
<fantasai> futhark: If I understood you , Mia, you're fine with not supporting anything and then bringing in each function that has a need?
<fantasai> miriam: Is there a good reason to start that way?
<fantasai> miriam: I think there are going to be use case for these, and we do have a context for them
<fantasai> miriam: so want to know if there are particular reasons not to support them
<emilio> q+
<fantasai> futhark: I've been working with sibling-index() and sibling-count(), we have an implementation, haven't found any problems
<Rossen8> ack weinig
<fantasai> weinig: I think just going and disallowing in some context is too simplistic
<fantasai> weinig: disallowing wholeheartedly, would disallow calc() with certain values
<fantasai> weinig: It's a more complicated question, which elements in which contexts
<TabAtkins> Yeah, math functions don't bring any context requirements *themselves*, just their contents
<fantasai> futhark: would it make sense to start with tree-counting functions, separately?
<fantasai> futhark: or would that be too wide
<fantasai> weinig: It's a problem to do one-off restrictions, rather than figuring out the system
<fantasai> weinig: We'd have to look at the whole landscape again
<fantasai> weinig: so now is the time to define these characteristics
<fantasai> futhark: Can we get a resolution on container queries to explicitly allow tree-counting functions for now?
<fantasai> weinig: sounds reasonable to me
<fantasai> weinig: we think CQ will have an element context, so seems reasonable to allow them now, and formalize more later
<fantasai> futhark: So we can extend the CQ spec, which currently talks about font-relative units. We can expand to include tree-counting functions
<miriam> +1
<fantasai> futhark: Then let's resolve that now, and continue the rest of the discussion
<Rossen8> ack emilio
<fantasai> emilio: I just wanted to note, regarding complexity, the one that's annoying is inserting an element in the DOM, assuming index of container ....
<fantasai> emilio: Right now :has() has this problem, too, needs to invalidate deeper to invalidate random elements in arbitrary parts of the tree
<fantasai> emilio: The usual stuff doesn't have this complexity
<fantasai> emilio: it's a lot more non-local than using it in property declarations
<fantasai> emilio: That said, it *can* be implemented, so I'm fine allowing it
<fantasai> futhark: similar issue with keyframe animations
<fantasai> futhark: so multiple cases of it
<fantasai> fantasai: If there are use cases, then it's worth doing the extra work; if not, it's not worth doing
<fantasai> futhark: I would expect there to be use cases for style queries in particular, because computed style can use sibling-index() so it would be natural to allow
<fantasai> Rossen8: So this is an academic expectation rather than a practical one
<fantasai> miriam: I'm trying to encourage expectation that things in CQ resolve based on the container, and the more that's true the easier that is to teach
<fantasai> miriam: Things can resolve because we have a container to resolve against
<fantasai> futhark: Proposed to explicitly allow tree-counting functions in CQ
<fantasai> PROPOSED: Explicitly allow tree-counting functions in container queries
<fantasai> Rossen8: any additional points or objections?
<fantasai> RESOLVED: Explicitly allow tree-counting functions in container queries

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants