-
Notifications
You must be signed in to change notification settings - Fork 140
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-properties-values-api] Make all the descriptors optional #994
Comments
I seem to recall that, for the JS syntax, there was an explicit choice to make I also agree that In particular, it is very useful to support (This brings up another question: should there be an explicit way to indicate that the initial value is the guaranteed-invalid value, maybe |
All of these are required for good reasons. ^_^ As Amelia said, making Similarly, And finally, I'm open to allowing the guaranteed-invalid value as part of a custom property's value space; there's nothing wrong with |
Well, I disagree that making the syntax more verbose to force authors think is a good idea. If the intent was for authors to use non-inherited variables more — the default should have been But making authors write more when there is no real need is just an invitation for someone to come-up with shortcuts and extra build/runtime JS that would just do this. Add to this the possibility of a human error, where a typo in a “required, but not needed” part would end in everything not working. And — what are other places in CSS where there are required declarations like that? Overall, I strongly do not like the idea of guiding authors as if they were blind puppies — especially for this kinds of advanced features. It is awesome that we have them, but sometimes the “good intentions” can make the feature much harder to use than it should have been. We need to have more faith in developers, and if we want to enforce good practices, it is the tools like browsers and code editors that could be used. Browsers could add profiling for the CSS variables performance and suggest not inheriting them (maybe it could be also detected automatically — if the inheritance is never used for a certain custom property, for example). But maiming the syntax just so developers “would know better”? |
Requiring explicitness when there's not an obviously correct-most-of-the-time (or at least obvious-most-of-the-time) default choice is a pretty standard language design pattern. Pretending that it's insulting to authors is incorrect and not helpful to this discussion. |
Why have defaults anywhere then? Why gradients have a default direction? Borders — default thickness? backgrounds — default repeat? And so on? Or these were CSS design mistakes and if these would be designed today it would be different? What are other places in CSS that require explicitness, especially on the level of whole declarations? And not just one required declaration — the need to have four different ones, without a shorthand, just to enable any of these declarations? Right now custom properties registration can be used for these features:
These features are not connected, but we can't use any one of them without explicitly mentioning the others. In my this coupling is unnecessary and introduces an extra barrier for usage of any of these, and an extra potential for a mistake or a type, where a mistake in one declaration makes the whole thing incorrect, which kinda goes against what CSS is currently is. |
Because API design is a complex and nuanced process, and no approach is correct 100% of the time.
No, that sort of thing does occur at times in CSS. For example, @counter-style requires a 'system' descriptor, and either 'symbols' or 'additive-symbols', even tho we could theoretically default 'system' to, say, |
These are also longhand. And we can say But when registering property we cannot do this and need to mention all of them even for smaller cases. |
The CSS Working Group just discussed
The full IRC log of that discussion<TabAtkins> Topic: make P&V API descriptors optional<TabAtkins> github: https://github.com//issues/994 <fremy> AmeliaBR: with the at-property rule shipping, people started taking a look <fremy> AmeliaBR: there were complaints that all the fields have to be explicit <fremy> AmeliaBR: and this is not very css-y <fremy> AmeliaBR: in general, css does handle defaults better <fremy> AmeliaBR: and by making all these things be required, you remove some behaviors <fremy> AmeliaBR: reasons why people use this <fremy> AmeliaBR: - transition values <fremy> AmeliaBR: - prevent inheritance <fremy> AmeliaBR: - provide default value <fremy> AmeliaBR: you don't always want all three <fremy> AmeliaBR: and now you have to set all of them, which is not always useful <fremy> AmeliaBR: worse, you cannot say "this is a color or it is invalid" <fremy> TabAtkins: that default value thing is a different issue <fremy> TabAtkins: I agree we should fix this <fremy> TabAtkins: the other two cases <fremy> TabAtkins: the inheritance one is that in JS, true has a default value is not logical <fremy> TabAtkins: and we don't want to default to inheritance, because this is more costly <fremy> TabAtkins: but having the default be the revert of the normal choice is confusing <fremy> TabAtkins: so, we think forcing people to think about this is good <fremy> TabAtkins: I think that issue is well settled, we really want to keep this in <fremy> TabAtkins: for the syntax, we could use the unrestricted syntax "*" as a default <fremy> TabAtkins: but I don't think that this is what you want <fremy> TabAtkins: because it cannot do anything useful for you with this syntax <fremy> TabAtkins: if we make this required, authors get an error, and they learn about this <fremy> TabAtkins: and they realize they could have a better behavior <AmeliaBR> q? <fremy> TabAtkins: and "*" is not that common so I don't think it will be common enough to warrant the default <fremy> TabAtkins: and there are other places in css where we force people to specify a value even if we have an obvious default <fremy> TabAtkins: like for example fonts <fremy> TabAtkins: we force you to say "serif" as fallback <fremy> TabAtkins: even though it could be implied <fremy> TabAtkins: but we thought forcing people to think about the fallback is useful <fremy> AmeliaBR: you said that throwing an error makes more sense <fremy> AmeliaBR: but in the non-declarative syntax, this works differently <fremy> emilio: there are browsers where you can see CSS errors <fremy> emilio: ;-) <fremy> TabAtkins: I think this information is surfacable <fremy> TabAtkins: if some browsers have a less-than-useful way of surfacing this, we can fix <fremy> TabAtkins: but I still think "hey this doesn't work" is better than making it work less well <fremy> TabAtkins: AmeliaBR do you feel about this strongly? <fremy> AmeliaBR: not a huge deal I guess, won't object <fremy> AmeliaBR: however, I think that the solution to the other issue is very important <fremy> TabAtkins: yes, that's another issue, and there is another thread about that, and I think we are in agreement with what you wanted? <fremy> AmeliaBR: can you send a pointer? <fremy> TabAtkins: yes, issue ??? <astearns> https://github.com/w3c/csswg-drafts/issues/5370 <fremy> TabAtkins: so, it sounds like we should be able to resolve to close this issue no change for now <fremy> TabAtkins: any final objection? <fremy> RESOLVED: keep all fields in @Property required |
Come on folks, let's not pretend that |
https://drafts.css-houdini.org/css-properties-values-api-1/
For convenience I would talk about the CSS syntax, but the same could apply to the
registerProperty()
JS function as well.Currently, all the declarations inside the
@property
are required (https://drafts.css-houdini.org/css-properties-values-api-1/#at-property-rule), (with the exception ofinitial-value
, but only for universal syntax definition (*
).My suggestion: make all declarations optional, and if at least one descriptor is properly defined, the custom property should become registered.
Basically, each
descriptor
could have a “default”:syntax
should default to the universal syntax definition. This would allow to conveniently set a variable to be non-inherited without explicitly typing it or setting an initial value.inherits
should default totrue
, as this is the default for unregistered properties. There is no reason to require this descriptor to be explicitly required, and making it optional would allow to use the@property
to more conveniently register properties that could be transitioned.initial-value
should default to… not sure how it can be described, but basically, an “invalid” value. If the syntax is properly defined, then the property should still be able to be transitioned/animated, just both states should be defined, without a transition to or from the “invalid” value.Overall, making all these optional would make the API much easier to use and would reduce potential human errors when registering the custom properties, and would lead to a more readable code overall, as for a lot of cases the property definitions would be more concise and containing only the things developers want to explicitly set.
The text was updated successfully, but these errors were encountered: