You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that attr()'s syntax expands to attr(<qname> <syntax>? [, <fallback-value>]?) where <syntax> has a fairly complex grammar, I was wondering if we need a divider between the two in case we ever want to expand the first argument?
(That said, I do like having the symmetry with var(), which delineates the variable as the variable before a comma, and the fallback value as everything after.)
The text was updated successfully, but these errors were encountered:
Not just for forwards compat, but this could help for things like
display:attr(foo block | flex | grid)
As per the rules in https://drafts.csswg.org/css-values-4/#component-combinators, visually it looks like there are 3 alternatives: foo block, flex and grid. Sure, I could use this for clarity (assuming we allow it, seems @property doesn't):
display:attr(foo [block | flex | grid])
But separating the attr name from the syntax may be better.
Yeah, I think just putting a comma there is what we need, similar to how we use commas to separate calculations (even when not strictly required for ambiguity, just because it makes things easier to read).
This does mean that we'll have to make the type required in order to supply a fallback (we can't otherwise tell a type and a fallback apart), but that's fine I think.
Now that
attr()
's syntax expands toattr(<qname> <syntax>? [, <fallback-value>]?)
where<syntax>
has a fairly complex grammar, I was wondering if we need a divider between the two in case we ever want to expand the first argument?(That said, I do like having the symmetry with
var()
, which delineates the variable as the variable before a comma, and the fallback value as everything after.)The text was updated successfully, but these errors were encountered: