A block based (not a global setting) toggle which provides the possibility to disable CSS shorthands on applicable properties.
An example is the transition property.
Simple use case:
Submenu items which are shown on hover of a menu element by transitioning from opacity of 0 to 1.
A staggered transition-delay now overrides the transition property, because I can’t set a transition-delay property, it’s always transition.
This requires to setup in addition the transition-duration, transition-property and transition-timing-function on every single submenu item to not override the initial rule.
The real pain starts when editing the rules or have different transition-delays set for default and hover state.
It’s just a very basic example, but there are tons of other use cases where this limitation kicks in.
It was already mentioned that it is planned to review the CSS parsing and I can imagine that this might be on the list as well.
An alternative could be to apply shorthands only when all related properties are filled out. The ones which are not required needs to be nulled then by the user. That wouldn’t be the perfect solution, but I could live with that.
Shorthands should always be the default, as in most cases this is what’s desired.
I second this request. I would actually prefer not to have shorthand for any of the CSS output. I understand this might cause an impact on the size of the CSS generated, but the way that browsers handle shorthand properties vs single properties makes it difficult to apply styles locally.
Kevin Powell has a video explaining why using shorthand is not so good.
For padding and margin for example, Cwicly uses the shorthand, and it means that it overrides my normalize with special padding and margins I’ve set for spacing between some elements (for example paragraphs). Even if we don’t add a value to one of the fields, since Cwicly uses the shorthand, it essentially sets the value that is defined elsewhere to initial, breaking the design.
I would rather prefer that this approach was completely avoided. Instead always using a single value for each property.
I think this is incorrect.
Shorthand margin/padding properties are only used in Cwicly when all 4 values are specified by the user, and only then.
Can you share an example of what you experienced?
Another use case I’m constantly facing: use multiple transition-property values.
It’s currently only possible by duplicating whole transitions property (so duplicating duration, delay, timing) either with standard fields or free input.
One can get around this with vars and calcs, which currently isn’t an option for me due to the missing variable manager and the input field “limitation”.
But you are right with your example, which, as described in the initial post, is also my main pain point that covers at least 80% of my use cases.
It should be achievable with GUI inputs.
