Skip to content
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

[css-contain-4] Define a range syntax for style container queries #8376

Open
mirisuzanne opened this issue Jan 30, 2023 · 23 comments
Open

[css-contain-4] Define a range syntax for style container queries #8376

mirisuzanne opened this issue Jan 30, 2023 · 23 comments

Comments

@mirisuzanne
Copy link
Contributor

The css-contain-3 spec provides a 'style container feature', allowing authors to query the computed value of a given property on the container. However, that query is currently limited to the declaration syntax, which provides a simple equality comparison:

@container style(--color-mode: dark) { … }

As discussed in #7068, there are also use-cases for range comparisons on container properties:

@container style(padding > 1em) { ... }
@container style(--primary-color-lightness > 80) { ... }

For custom properties, this might require a defined syntax using @property? Or would we want a way to define the value type on the query itself? Thoughts?

@LeaVerou
Copy link
Member

For syntax, we can just adopt the MQ operators.

I think it makes sense to require these properties to be registered as <integer>, <number>, <length>, <percentage>, or <length-percentage> (am I forgetting anything?), we can always expand later.

Or, crazy idea here, given this is fairly limited and these types can be detected syntactically, what if we don't require registration at all? Would that be possible? Is there any ambiguity I'm missing?

@SebastianZ
Copy link
Contributor

I think it makes sense to require these properties to be registered as <integer>, <number>, <length>, <percentage>, or <length-percentage> (am I forgetting anything?)

<angle>, <frequency>, <time> and their <*-percentage> counter-parts, <ratio> and maybe some more.

For syntax, we can just adopt the MQ operators.

I assume that includes the full range syntax, so one could write

@container style(1em < padding < 3em) { … }

Correct?

Sebastian

@tabatkins
Copy link
Member

There is indeed no ambiguity when limited to comparisons of this type - there's no keywords or similar that can be interpreted differently on context, just plain numbers and dimensions.

And math functions, which is the only thing that makes me slightly concerned, just due to the potential complexity. But I suspect it's fine.

@mirisuzanne
Copy link
Contributor Author

Another complexity: is it allowed to mention multiple properties? style(margin < 3em < padding) { … }

@LeaVerou
Copy link
Member

Another complexity: is it allowed to mention multiple properties? style(margin < 3em < padding) { … }

I'd suggest not, at first.

@SebastianZ
Copy link
Contributor

Another complexity: is it allowed to mention multiple properties? style(margin < 3em < padding) { … }

That syntax doesn't make sense to me. I'd say we should stick to the syntax defined for media queries. So that could be expressed as style(margin < 3em) and style(padding > 3em). This also makes it more readable, in my opinion.

Sebastian

@tabatkins
Copy link
Member

Yeah, agreed that we should stick to the MQ syntax for now - either a property compared to a literal, or a property sandwiched between two literal comparisons.

@mirisuzanne
Copy link
Contributor Author

I marked this for contain-4, but not sure if it needs to be deferred from l3? It doesn't seem like a big lift on the spec side, but may be a larger consideration for implementors?

@una
Copy link
Contributor

una commented Feb 2, 2023

I just mentioned this in the older thread, but this would be a very useful feature. And +1 to the MQ range syntax as a mechanism to query values by.

@una
Copy link
Contributor

una commented Feb 7, 2023

We would need to limit (and define the limitations) of the syntax options for range queries? I.e.

Valid:

  • <length>
  • <number>
  • <percentage>
  • <length-percentage>
  • <integer>
  • <angle>
  • <time>
  • <resolution>

Invalid:

  • <image>
  • <url>
  • <custom-ident>
  • <transform-function>
  • <transform-list>
  • <color>

@tabatkins
Copy link
Member

Yes, it would be all the numeric types. Not colors, tho.

@mirisuzanne
Copy link
Contributor Author

@lilles raised a question this morning about how to resolve <length-percentage> on custom properties - where it's not clear how percentages compare to numbers.

@tabatkins
Copy link
Member

Percents aren't comparable to lengths in contexts where they don't resolve against a length, so they'd just be false, I suppose? That is, --foo > 50% can be true if --foo: 75%, but if --foo: 75px it'll always be false. This should be the same behavior as comparing a <length> custom property to an angle; we can't tell at parse time whether the comparison is syntactically valid, so all we can do is say it's false when we actually make the comparison.

(Do we want to try and do syntax validation on known properties? Or should we just consider them the same way, where doing a nonsensical comparison like padding-left > 50deg is false?)

@mirisuzanne
Copy link
Contributor Author

I think it would be ok to do without parse-time syntax validation - but I would probably expect unknown rather than false in both cases.

@tabatkins
Copy link
Member

We don't use unknown for "this doesn't make sense", we use it for "this conceivably has a true/false answer, but we happen to not know what it is; a future browser might, tho". So nonsense comparisons are simply false, not unknown.

And in a custom property, %s do not resolve against anything, so they're incomparable with any other types, just as much as lengths and angles are incomparable.

@andruud
Copy link
Member

andruud commented Feb 7, 2023

Are we going with the idea that registration isn't required, but the custom property side is interpreted according to the type of the literal side?

@tabatkins
Copy link
Member

Right; registration doesn't add anything to the equation in this case. If we see --foo > 2em, we know that we're gonna be comparing the property value to a length, so we can interpret it that way immediately.

I mean, maybe registration lets you fast-path a false for nonsensical comparisons, but that's it.

Tho hm, do we ever want to allow something like --foo > --bar? In that case, registration would be useful.

@andruud
Copy link
Member

andruud commented Feb 7, 2023

Great, just wanted to clarify that so we know what to implement.

Tho hm, do we ever want to allow something like --foo > --bar? In that case, registration would be useful.

It could work without as well? We just try to parse a numeric thing on both sides, and check if they're compatible.

@tabatkins
Copy link
Member

We just try to parse a numeric thing on both sides, and check if they're compatible.

Yeah true.

@mirisuzanne
Copy link
Contributor Author

Does this logic seem like something we could add to css-contain-3, or would need to be deferred to L4?

@tabatkins
Copy link
Member

This also seems to have implications for the non-range syntax, yeah? Like, we'd want style(--x: 1.0) to match an --x: 1;, because the two are numerically equal. But style(--x: 1.0 foo) wouldn't match --x: 1 foo;, because the value isn't a single numerical value, so we'll instead use serialization matching.

(I think this is fine, fwiw.)

@andruud
Copy link
Member

andruud commented Mar 6, 2023

Should we consider making : always serialization-matching, and = only "recognized-type"-matching?

EDIT: It seems risky to always interpret things as <number> (when possible), with no way for the author to actually opt out of this behavior. It would mean e.g. style(--x:0100) would match --x:10e1, which might not be what the author wants at all.

Having multiple behaviors for the same operator also feels shaky. It would be better if : always did text matching, and = never did text matching.

@mirisuzanne
Copy link
Contributor Author

I like the consistency, and since authors have both options, they can opt into either behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants