Skip to content

[css-values-5] Does container-progress() really want the entire <size-feature> production for its progress value? #11120

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

Open
cdoublev opened this issue Oct 31, 2024 · 2 comments

Comments

@cdoublev
Copy link
Collaborator

cdoublev commented Oct 31, 2024

Similarly as requested in #10966, container-progress() should probably take a <mf-name> corresponding to a size feature, instead of a whole <size-feature>, which is the same as for a media feature: a feature name, a comparator, and a value (emphasize added on what is unexpected).

Perhaps you would like to use something like <size-feature-name> to avoid the confusion with media features.

@fantasai
Copy link
Collaborator

fantasai commented Nov 1, 2024

Fixed the error, tagging against relevant specs to give these things proper productions.

@cdoublev
Copy link
Collaborator Author

cdoublev commented Nov 3, 2024

Thank you. Related to "give these things proper productions": #10790. Basically, this proposal would now be <condition[ <feature-name> ]>. But I am not sure this would be an appropriate use of the new <type[ <subtype> ]> concept.


The specified <mf-name> must be a valid size feature

This does not explicitly require a "range" size feature, like for the media feature in media-progress(). However I am not sure if this is necessary because container-progress(orientation, 1px, 1px) would still be invalid since 1px is an invalid value for orientation. I think grid is the only feature that accepts numeric values but is not a range feature.

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

2 participants