On Tue, May 20, 2025 at 10:47 AM Yoav Weiss (@Shopify) < [email protected]> wrote:
> > > On Wed, May 14, 2025 at 6:10 PM Philip Jägenstedt <[email protected]> > wrote: > >> On Wed, May 14, 2025 at 5:21 PM Rune Lillesveen <[email protected]> >> wrote: >> >>> On Tue, May 13, 2025 at 9:20 AM Rune Lillesveen <[email protected]> >>> wrote: >>> >>>> On Tue, May 13, 2025 at 8:34 AM Rune Lillesveen <[email protected]> >>>> wrote: >>>> >>>>> On Tue, May 13, 2025 at 7:43 AM Domenic Denicola <[email protected]> >>>>> 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? > I added Agenda+ in March, but haven't pushed hard. Asked the chairs to put it on the agenda now. > 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? > Adding a separate flag for @container here: https://chromium-review.googlesource.com/c/chromium/src/+/6563296 I'm fine with shipping support in @container later in a separate intent, when the issue is resolved, too. -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeRdhFBtyRGpV7eXSBzn6Dx1TLUqbGFuur0aRCN8pydhkQ%40mail.gmail.com.
