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-values] Define <'property-name'> notation to exclude listification #3146

Closed
fantasai opened this issue Sep 25, 2018 · 3 comments
Closed

[css-values] Define <'property-name'> notation to exclude listification #3146

fantasai opened this issue Sep 25, 2018 · 3 comments

Comments

@fantasai
Copy link
Collaborator

@fantasai fantasai commented Sep 25, 2018

The CSS property definition syntax has the handy <'property-name'> notation, which imports the entire value space of that property (aside from the CSS-wide keywords).

It's super useful, except a large number of places where we would use it (and did in CSS2) are places where we've listified the property value. This results in a lot of custom non-terminal grammar productions which are simply the entire value space of the property except without the listification, e.g. in css-backgrounds and css-animations.

I suggest we define <'property-name'> to just drop top-level listification. This would allow us to clean up our grammar productions, getting rid of these routine non-terminals and inlining a large number of simple productions into the property definition tables where they are easier to see and index.

@tabatkins
Copy link
Member

@tabatkins tabatkins commented Sep 28, 2018

I like this suggestion.

This would exclude things like <'background'>, which has a special last value and so isn't a simple listified value, right?

@dbaron
Copy link
Member

@dbaron dbaron commented Oct 3, 2018

I think this would let us avoid the following productions in css-animations: <single-animation-iteration-count>, <single-animation-direction>, <single-animation-play-state>, <single-animation-fill-mode>.

@css-meeting-bot
Copy link
Member

@css-meeting-bot css-meeting-bot commented Oct 10, 2018

The CSS Working Group just discussed Define <'property-name'> notation to exclude listification, and agreed to the following:

  • RESOLVED: Redefine <'property-name'> to strip off top-level # multiplier
The full IRC log of that discussion <dael> Topic: Define <'property-name'> notation to exclude listification
<dbaron> fantasai, does that handle stuff like repeating lists?
<dael> github: https://github.com//issues/3146
<fantasai> https://drafts.csswg.org/css-values-4/#combining-values
<fantasai> dbaron, yes
<dael> fantasai: This is an issue about our notation syntax.
<dael> fantasai: In CSS 2 we didn't have list valued properties of font-family. There was a convenience location where you could do name of property in quotes and a angle bracket and it ment use this whole property overthere.
<dael> fantasai: There's a ton of specs where in CSS2 we could use that notation. We have to creat non-termal terms that are identical to another property except they're not comma sep lists.
<dael> fantasai: Means property defintions are more obscure. When you look at table rather then listing color and then repeating there's a new type
<dael> fantasai: I think it would be nice to use this notation. We have to unlistify it in order to use it.
<dael> fantasai: I was thinking it might make sense to redefine as the property's value space but if it has a top level hash multiplier we remove it and take the value space within each item
<dael> fremy: Makes a lot of sense. Reasonable
<dael> fantasai: Notation change so it's editorial
<dael> florian: Makes sense to me as well
<dael> Rossen_: Other opinions?
<dael> Rossen_: Objections?
<tantek> +1
<fantasai> Redefine <'property-name'> to strip off top-level # multiplier
<dael> RESOLVED: Redefine <'property-name'> to strip off top-level # multiplier
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants