Notice that the background-origin and background-clip values are reversed.
Proposal
I'm not sure the background "shorthand" function saves much code, if any at all, compared to setting the constituent properties individually. At the same time, it doesn't offer much type safety and, as demonstrated, produces inaccurate results.
For the moment, I lean toward scrapping this API altogether.
Alternatively:
The function must produce accurate results, even if that means the API changes a bit.
Ideally, the API should provide meaningful type safety, for example preventing a <bg-size> in the absence of a <bg-position> (spec).
The font shorthand property should probably be reimplemented with a similar API at the same time to avoid inconsistent API design.
Describe the bug
The
background
"shorthand" function produces invalid CSS.To Reproduce
For example...
...is rendered as...
...even though the correct syntax, per the CSS Backgrounds and Borders Module Level 3 specification, is...
Another example relates to
background-origin
andbackground-clip
:...is rendered as (comment mine, per spec)...
Notice that the
background-origin
andbackground-clip
values are reversed.Proposal
I'm not sure the
background
"shorthand" function saves much code, if any at all, compared to setting the constituent properties individually. At the same time, it doesn't offer much type safety and, as demonstrated, produces inaccurate results.For the moment, I lean toward scrapping this API altogether.
Alternatively:
<bg-size>
in the absence of a<bg-position>
(spec).font
shorthand property should probably be reimplemented with a similar API at the same time to avoid inconsistent API design.