Restructure ranged style query data

[ddbeck]

Summary

Restructure the ranged style query data newly added by #28510.

Test results and supporting details

There's no new information here, but I've restructured the data to be less surprisingly flat. When I was authoring web-platform-dx/web-features#3579, I predicted some keys that did not yet exist in BCD, but what I found was rather different and confusing. In particular, the ranged behavior is a peer to style queries, not a subfeature.

Here's the before:

• css.at-rules.container
  • css.at-rules.container.style_queries_for_custom_properties
  • css.at-rules.container.style_queries_range_syntax
• css.types.if
  • css.types.if.style_queries_range_syntax

And here's my after (new in bold, removed in strike):

• css.at-rules.container
  • css.at-rules.container.style_queries_for_custom_properties
  • css.at-rules.container.style_queries_for_custom_properties.range_syntax
  • css.at-rules.container.style_queries_range_syntax
• css.types.if
  • css.types.if.style_queries_range_syntax
  • css.types.if.style
  • css.types.if.style.range_syntax

This implies that we'd add some other keys at some point, namely:

• css.types.if.media
• css.types.if.scroll-state
• css.types.if.supports

Related issues

A follow up to:

• Chrome 142 adds range syntax for style queries #28510
• Range syntax for style container queries and if() web-platform-dx/web-features#3566
• Add feature for range syntax for style queries web-platform-dx/web-features#3579

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[chrisdavidmills]

Thanks, @ddbeck, this looks reasonable to me. I did wonder whether all the query types should have a data point in both files for consistency, so:

• container.json should have a "size queries" data point at the same level as scroll-state_queries and style_queries_for_custom_properties?
• if.json should have "size" and "scroll state" data points at the same level as style?

The main data point in each case kinda covers these, but it feels a little weird given that the support data for some of the existing sub-data is the same as for the main data point.

[ddbeck]

Thanks, @ddbeck, this looks reasonable to me. I did wonder whether all the query types should have a data point in both files for consistency, so:

• container.json should have a "size queries" data point at the same level as scroll-state_queries and style_queries_for_custom_properties?

I kinda expect named things to have keys, but size queries are anonymous. If I were creating this data from scratch today, I'd probably have structured it like this:

• css
  • at-rules
    • container (implicitly, size queries)
      • scroll-state
      • style
        • range_syntax

• if.json should have "size" and "scroll state" data points at the same level as style?

Honestly, I'm not quite sure how if() works size queries (if at all). Is there a size() notation, like style()?

The main data point in each case kinda covers these, but it feels a little weird given that the support data for some of the existing sub-data is the same as for the main data point.

Yeah, this happens often in CSS (e.g., you have some "basic" value for a property having the same support information as the parent property key), but does appear elsewhere (e.g., there's a key for the Intl built-in that does basically nothing). I think this is a consequence of being consistent, which is pretty useful downstream (in web-features, oddities feel… odd!) but does lead to some boring, obvious data appearing.

[chrisdavidmills]

Thanks, @ddbeck, this looks reasonable to me. I did wonder whether all the query types should have a data point in both files for consistency, so:

• container.json should have a "size queries" data point at the same level as scroll-state_queries and style_queries_for_custom_properties?

I kinda expect named things to have keys, but size queries are anonymous. If I were creating this data from scratch today, I'd probably have structured it like this:

* css
  
  * at-rules
    
    * container (implicitly, size queries)
      
      * scroll-state
      * style
        
        * range_syntax

• if.json should have "size" and "scroll state" data points at the same level as style?

Honestly, I'm not quite sure how if() works size queries (if at all). Is there a size() notation, like style()?

Duh, I'm being stupid here. if() does not do size queries — it does style, media, and supports queries. You can safely ignore this blip.

The main data point in each case kinda covers these, but it feels a little weird given that the support data for some of the existing sub-data is the same as for the main data point.

Yeah, this happens often in CSS (e.g., you have some "basic" value for a property having the same support information as the parent property key), but does appear elsewhere (e.g., there's a key for the Intl built-in that does basically nothing). I think this is a consequence of being consistent, which is pretty useful downstream (in web-features, oddities feel… odd!) but does lead to some boring, obvious data appearing.

Yeah, that makes sense.I think we are good to go.

[chrisdavidmills]

LGTM. Thanks, @ddbeck.