[css-contain-3] Move style queries of standard properties to level 4

[anttijk]

Style queries for standard (non-custom) properties are currently severely underspecified and have many open questions in terms of behavior, implementability and usefulness.

Some examples:

How does style(width: calc(…)) behave?

Will authors understand why this (or any particular value syntax) is available with style() but not with the usual size query syntax () especially when feature and property names are the same?

As far as I know there is no definition of “equality” in general between the computed style and some arbitrary author property value. Engines have some internal notion of equality between two computed styles but that doesn’t seem sufficient here. This would need to be fully specified in all cases.

How about shorthand properties?

What happens with style(color:inherit) or say style(color:revert-layer)? Are we supposed to run full style resolution pipeline in middle of selector matching to determine the value being queried? Based on #7080 it sounds like there are plans to limit some but not all global values. How do authors know what is allowed?

Possible spec/implementation shortcuts for above (“just serialize and use string equality”) have major performance concerns.

Is this feature useful as specified? Exact equality is very limiting. Many interesting properties are numbers or multidimensional objects like colors. Size queries support ranges for a reason.

How does this interact with animations? Accelerated ones where style is not resolved for every frame?

There is a huge testing matrix for this with 600+ properties (and infinite amount of complex values).

It seems to me that this feature as specified adds a massive amount of complexity for very limited utility. A serious implementation effort would surely find way more questions.

Container queries without style queries (or style queries limited to custom properties/variables) offers a nice set of functionality. It seems unwise to delay those features in pursuit of this.

[andruud]

A serious implementation effort would surely find way more questions.

Agree with this. The scope of making this work (interoperably) for all ~600 properties is likely huge, and we should do what we can to split that up. Support for custom properties gives authors most of the power, and it's an easily explainable limitation.

I don't think standard property queries are impossible, but makes sense to me to split up this work when we can, especially if there's a natural boundary.

+1 to defer.

[tabatkins]

How does style(width: calc(…)) behave?

I don't understand the question - what do you think is undefined about this?

As far as I know there is no definition of “equality” in general between the computed style and some arbitrary author property value. Engines have some internal notion of equality between two computed styles but that doesn’t seem sufficient here. This would need to be fully specified in all cases.

Transitions already rely on the concept of equality between computed values; this uses the exact same concept. (To the extent that Transitions is underdefined, this is too, but that's a decade+ old issue that we've muddled thru so far.)

How about shorthand properties?

Recently answered in 2e215a0

What happens with style(color:inherit) or say style(color:revert-layer)?

As noted in #7080, 'inherit', 'initial', and 'unset' are allowed, as they don't require cascade resolution (and it's useful to be able to compare a property against its inherited value). 'revert' and 'revert-layer' are disallowed. (Specified now in bb594b7.)

Is this feature useful as specified? Exact equality is very limiting. Many interesting properties are numbers or multidimensional objects like colors. Size queries support ranges for a reason.

Ranges are a useful expansion of the feature that we can do in the future, but as it stands the feature is still useful; see the perennial use-case for "be italic, unless the surrounding text is italic in which case be normal", for example.

How does this interact with animations? Accelerated ones where style is not resolved for every frame?

Animations affect the computed value, so it'll check against those. Some frame delays in accelerated animations are quality-of-implementation and fine; this sort of lag is common to many features that interact with animations.

It seems to me that this feature as specified adds a massive amount of complexity for very limited utility. A serious implementation effort would surely find way more questions.

For the most part the difficult parts of this are already implicated by Transitions, as far as I can tell. If there are hard parts beyond that, we can def look at deferring those bits. But the spec at this point is pretty much complete, so while it might make sense to mark it at risk, there doesn't seem to be much benefit to pushing it to the next level just yet. If an implementer wants to take it on, it's as ready to implement as the rest of the spec.

[mirisuzanne]

If it makes sense for implementors to draw a line between custom & standard properties, and one is significantly easier than the other, I agree that custom properties are a useful first step on their own -- even if standard properties get marked as at-risk. I agree that I wouldn't want this to dramatically delay the release of size queries.

[RByers]

Note that chromium is proposing shipping support for custom properties now.

[lilles]

Chrome shipped style() queries for custom properties and Apple have update their standards position:

WebKit/standards-positions#57 (comment)

I am not convinced querying computed values is what authors want for standard properties. A lot of properties' values are computed as specified while the authors would expect to query the resolved or used value.

For instance, it is generally not possible to usefully query the computed color-scheme as color-scheme: light dark will have a computed value of light dark, while the author would typically want to query the used valule.

I'd prefer to defer standard property queries to next level and revisit, but at least marked as at-risk.

[mirisuzanne]

The proposal here is to defer style queries of standard properties to level 4, and consider if querying the computed value is actually what we want here. I think that makes sense, and we may be able to resolve on it async.

[astearns]

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: Defer style queries of standard properties to level 4 (to allow faster progress for style queries for custom properties

[astearns]

RESOLVED: Defer style queries of standard properties to level 4 (to allow faster progress for style queries for custom properties