On Wed, May 14, 2025 at 6:10 PM Philip Jägenstedt <foo...@chromium.org>
wrote:
> On Wed, May 14, 2025 at 5:21 PM Rune Lillesveen <futh...@chromium.org>
> wrote:
>
>> On Tue, May 13, 2025 at 9:20 AM Rune Lillesveen <futh...@chromium.org>
>> wrote:
>>
>>> 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)) {}
>>>
>>
>> I'll make my position clearer.
>>
>> I think we should ship with support for tree counting functions
>> in @container because
>>
>> 1. @container queries are currently always in a (container) element
>> context and there are valid use cases
>> 2. Supporting tree counting functions in @container does not break with
>> the current spec
>> 3. I don't think it's likely there will be a resolution that disallows
>> tree counting functions in @container
>> 4. In particular, disallowing tree counting functions in style() queries
>> would be inconsistent with e.g. relative units
>>
>
> I am recused on this one, but FWIW I agree with this reasoning.
> https://github.com/w3c/csswg-drafts/issues/10982 is already Agenda+
>
When is the discussion scheduled to take place?
> and if we're confident the right solution is to match how relative units,
> then we can proceed. Rune pointed out that it's already tested here:
>
> https://wpt.fyi/results/css/css-values/tree-counting/sibling-function-container-query.html
>
> To ship without this behavior only to add it a few milestones later would
> complicate the browser support story and require explanation on places like
> MDN and caniuse.com.
>
In case the CSSWG decision is made before 138 ships to stable and it does
not align with what you're proposing we ship, are you OK with disabling the
feature using its Finch flag? Or should we put @container support behind a
separate flag?
> --
> 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/CAARdPYeGZOOUNARmWS5myVqNq9c688p0%2Bte6LqWRGhpS3ta4Lw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeGZOOUNARmWS5myVqNq9c688p0%2Bte6LqWRGhpS3ta4Lw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAOmohSLNsdBo6m6CW0Xceg5h2PnODmfjY%2B6Jt7HRBvCaKwC4dA%40mail.gmail.com.
