1953973 - [css-values] Add sibling-count() and sibling-index()

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, enhancement)

Description

[Mozilla Apprentice]

A resolution was made for csswg-drafts/#4559.

[css-values] Proposal: add sibling-count() and sibling-index()

• RESOLVED: Add sibling-count() and sibling-index() to css-values-5 ED

Discussion.

Comment 1

[David Shin[:dshin]]

(Moving WPT failures to "blocks" rather than "depends on")

Comment 2

[Sajid Anwar [:sajidanwar]]

Hey, I had some very early local changes for sibling-index() / sibling-count() a couple months back that I've finally had some time to close out (almost), so I'm expecting to post patches for review in the next few days. Most of the tree-counting WPTs and all of the demos that I've found online are working and I think I've got generally the right solution. But here's a quick summary before I'm ready to publish in case it's useful context (or to let me know I'm way off-base):

• Storing the calculation tree. I've converted the specified versions of multiple numeric types into enums with NoCalc and Calc variants, similar to what's already in place for Length. The Calc variants have the full calculation tree so that sibling-index() and sibling-count() can be applied at computed-value time.

  • I did think about whether it might have required fewer changes to implement them like var() / env() / substitutions, but I think the semantics wouldn't have been right. You wouldn't have been able to reject invalid declarations at parse time, like calc(1em + sibling-index()), for example.
  • One nice thing is that this prerequisite actually ends up fixing a lot of WPT failures where Firefox's handling of calc was too narrow, in particular tests that use sign and font/viewport/container units.
  • Downside is that all of these variants are no longer Copy and have to be cloned in some places. And since the types are slightly larger, there are a few property types that need to be boxed. Hopefully not catastrophic.

• Parsing/computing a new TreeCountingFunction type. This is separate from the types that support calc since these functions are distinct from math functions in the spec. The practical difference is that sibling-index() / sibling-count() can be used directly for <integer> and <number> properties without being part of a calc node, and they don't serialize to calc(...) like the other math functions.

• Computing and counting the element's siblings. This is where I'm less sure about whether I've gotten the specifics right. I've added an ElementSiblingData (just index and count integers) to the computed Context, but I'm computing and building this in the Context::new every time, which is definitely wrong and way too often. I could compute it the first time it's accessed (and recompute when siblings change), but I'm not sure where to store it, maybe on the element itself? I think I might also be able to do the rule cache keying and style sharing better/more granularly than I've got, too.

I'm working on getting the commits to a presentable state and going through WPT results, but hopefully should have some patches very soon!