On Tue, May 13, 2025 at 8:34 AM Rune Lillesveen <futh...@chromium.org>
wrote:
> On Tue, May 13, 2025 at 7:43 AM Domenic Denicola <dome...@chromium.org>
> wrote:
>
>> I'm very slightly worried about the cases which we seem to accept, but
>> the latest on the CSSWG thread suggests we should disallow. Namely,
>> @container and @page. How sure are you that changing those to be invalid in
>> the future, to follow the latest CSSWG decisions, will not cause compat
>> problems?
>>
>
> For @page, I wouldn't be worried at all. It's unlikely someone will start
> using the feature and rely on a constant sibling-index()/sibling-count() in
> @page.
>
> For @container, I agree that it's safer to be conservative and wait for
> the resolution, since for @container there are clear use cases and and a
> more or less obvious behavior in that context.
>
Some more details below.
For @container, this is relevant for size queries and style() queries.
Size queries are currently always evaluated in an element context, although
falling back to viewport has been discussed, and container units fall back
to small viewport units. Relative units (like ems below) are evaluated
against the computed values of the container element:
@container (width > calc(sibling-index() * 50px)) {}
@container (width > 10em)) {}
For style queries, the right hand of the query is evaluated against the
container element and its computed styles for registered custom properties.
Note that for non-registered custom properties, sibling-index() would just
be part of the string/tokens without any specific meaning.
I think it would be inconsistent to reference relative units (like em
below) and resolve custom properties references (like var(--a) below), but
specifically throw away sibling-index() when evaluating the value against
the registered syntax:
@container style(--registered-length: calc(sibling-index() * 20px)) {}
@container style(--registered-length: 10em) {}
@container style(--registered-length: var(--a)) {}
On Tuesday, May 13, 2025 at 6:37:14 AM UTC+9 Mike Taylor wrote:
>>
>>> LGTM1
>>> On 5/9/25 9:47 AM, Rune Lillesveen wrote:
>>>
>>> Contact emails futh...@chromium.org, se...@chromium.org
>>>
>>> Explainer
>>> https://github.com/w3c/csswg-drafts/blob/main/css-values-5/tree-counting-explainer.md
>>>
>>> Specification https://drafts.csswg.org/css-values-5/#tree-counting
>>>
>>> Design docs
>>>
>>> https://github.com/w3c/csswg-drafts/blob/main/css-values-5/tree-counting-explainer.md
>>>
>>> Summary
>>>
>>> sibling-index() and sibling-count() can be used as integers in CSS
>>> property values to style elements based on their position among its
>>> siblings, or the total number of siblings respectively. These functions can
>>> be used directly as integer values, but more interestingly inside calc()
>>> expressions. Example: li { margin-left: calc(10px * sibling-index()); }
>>>
>>>
>>> Blink component Blink>CSS
>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22>
>>>
>>> TAG review https://github.com/w3ctag/design-reviews/issues/1068
>>>
>>> TAG review status Issues addressed
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>>
>>> *Gecko*: No signal (
>>> https://github.com/mozilla/standards-positions/issues/1194)
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/471)
>>>
>>> *Web developers*: Positive
>>>
>>> https://css-tricks.com/how-to-wait-for-the-sibling-count-and-sibling-index-functions/
>>> https://chriscoyier.net/2023/11/29/element-indexes/
>>> https://kizu.dev/tree-counting-and-random/
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> Basic support out-of-the box. With the value debugger (
>>> crbug.com/396080529) shipped, evaluating
>>> sibling-index()/sibling-count() into a <number> should work out-of-the-box.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, ChromeOS, Android, and Android WebView)? Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>> ? Yes
>>>
>>> https://wpt.fyi/results/css/css-values/tree-counting
>>>
>>>
>>> Flag name on about://flags #enable-experimental-web-platform-features
>>>
>>> Finch feature name CSSSiblingFunctions
>>>
>>> Rollout plan Will ship enabled for all users
>>>
>>> Requires code in //chrome? False
>>>
>>> Tracking bug https://crbug.com/40282719
>>>
>>> Sample links
>>> https://codepen.io/argyleink/pen/KwKXPYW
>>>
>>> Estimated milestones
>>> Shipping on desktop 138
>>> DevTrial on desktop 133
>>> Shipping on Android 138
>>> DevTrial on Android 133
>>> Shipping on WebView 138
>>>
>>> Anticipated spec changes
>>>
>>>
>>> There is an open issue[1] about what tree counting functions mean
>>> outside of element contexts. The plan is to handles tree counting functions
>>> like this for the relevant @-rules when shipping:
>>>
>>>
>>> - @font-face: invalid at parse time
>>>
>>> - @font-palette-values: invalid at parse time
>>>
>>> - @property: accepted at parse time (the values are strings), but since
>>> these values are not computationally independent when evaluated, they will
>>> be dropped as initial values.
>>>
>>> - @counter-style: invalid at parse time
>>>
>>> - @container: the container is in an element context and tree counting
>>> functions are evaluated as such
>>>
>>> - @page: accepted at parse time and evaluated against the root element
>>>
>>> - @media (in query value): invalid at parse time
>>>
>>>
>>> Shipping a different specified behavior for tree counting functions in
>>> these contexts (to what the issue is resolved to later) should be
>>> straightforward.
>>>
>>>
>>> [1] https://github.com/w3c/csswg-drafts/issues/10982
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/6225478530367488?gate=6089164107546624
>>>
>>> Links to previous Intent discussions Intent to Prototype:
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67c70d35.2b0a0220.36af1.0007.GAE%40google.com
>>>
>>> This intent message was generated by Chrome Platform Status
>>> <https://chromestatus.com/>.
>>> --
>>> Rune Lillesveen
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeTS2BYBs8yqpNXnJa5tAMwPar4X3jOPtLddMydRX0oEoA%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeTS2BYBs8yqpNXnJa5tAMwPar4X3jOPtLddMydRX0oEoA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>>
>
> --
> Rune Lillesveen
>
>
--
Rune Lillesveen
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeQk3zDO1Gsq6RH0zfQC1jrDko7C%3DLpUF4JdJDQDpcnnCA%40mail.gmail.com.
