-
Notifications
You must be signed in to change notification settings - Fork 717
[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
Comments
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 |
Allowing them anywhere would require making some arguments ( |
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. |
@tabatkins @emilio @nt1m Any opinions on whether tree-counting functions like sibling-index() should be valid parse time in:
And if such functions are valid, what should they evaluate to. |
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}
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}
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}
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... |
Yeah, I'm fine with starting with them all disallowed, parse-time invalid. We can turn them on as requested. |
…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
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}
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}
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}
…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
…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
…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
…-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
…-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
…-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
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. |
Yes, that's the "something resembling a sensible behavior" :) |
The CSS Working Group just discussed
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 |
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 themedia
attribute. I guess none is currently accepted, not even math functions.The text was updated successfully, but these errors were encountered: