Romain Menke

> However, defining the syntax of the shorthand like this could be problematic as it can create disambiguation issues that are not present in the individual shorthands. E.g. consider property...

> The only way to make it not ambiguous is by not allowing multipliers in the syntax definitions. This creates a fixed number of values that can be declared. (ignoring...

> The logic for expanding it into longhands The core of this proposal is a simple system of "slots". - 3 properties (3 times `"anything"`) - 2nd property takes 3...

@LeaVerou said : > It is also quite a burden on authors to have to match CSS property syntax. What if they don't need the entire possible range of syntaxes?...

@LeaVerou I didn't fully grasp this example before. Having the ability to encode transforms for the values passed to the shorthand seems really handy and powerful but I am unsure...

> In the former, if anything, even with the tiniest specificity overrides padding, no amount of setting --foo to anything will affect the padding. I fail to see the issue...

@Loirooriol Do you see another way this feature is implementable? I don't think it solves enough author cases to warrant entirely new grammar/syntax that enables expanding at parse time. Especially...

I don't think that is worth it. I think that rules out using `@property` and the custom property syntax (`--foo`) as a way to implement custom shorthands.

Thank you for that @tabatkins, interesting read! Also thank you for the feedback and insights @Loirooriol @LeaVerou 🎉 Going to close this because of expected implementation hurdles.

@Loirooriol said : > Just realized there is a big problem with shorthands: they must expand into longhands at parse time. But @property doesn't affect the parsing, as explained in...