(In reply to Jonathan Kew [:jfkthame] from comment #4) > Shouldn't the position component be omitted from the serialization altogether in this case, as it's the default? Per https://drafts.csswg.org/cssom/#serialize-a-css-value: "If component values can be omitted or replaced with a shorter representation without changing the meaning of the value, omit/replace them." Yeah, that seems reasonable too. We seem to match that principle for `radial-gradient` -- here's a testcase: ``` data:text/html,<!DOCTYPE html> <body style="background: radial-gradient(circle at center, red, blue)"> <script>alert(document.body.style.backgroundImage)</script> ``` Firefox and WebKit[1] report `radial-gradient(circle, red, blue)` Chrome reports `radial-gradient(circle at center center, red, blue)` Notably: * The `radial-gradient` grammar uses the exact same `at <position>` syntax that `clip-path` does, so it's reasonable to expect that they behave consistently. * Firefox and WebKit are serializing it with the position omitted, as the spec asks for (per jfkthame's comment 4) * Chrome is serializing it with `center center`, the same way that Firefox is serializing `clip-path` (and differently from how Chrome serializes `clip-path`). [1] (Note: my local WebKit is `epiphany` which doesn't like the newlines or script in my above data-URI, so I tested it there by removing the newlines and inspecting the serialization using devtools console)
Bug 1823475 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Jonathan Kew [:jfkthame] from comment #4) > Shouldn't the position component be omitted from the serialization altogether in this case, as it's the default? Per https://drafts.csswg.org/cssom/#serialize-a-css-value: "If component values can be omitted or replaced with a shorter representation without changing the meaning of the value, omit/replace them." Yeah, that seems reasonable too. We seem to match that principle for `radial-gradient` -- here's a testcase: ``` data:text/html,<!DOCTYPE html> <body style="background: radial-gradient(circle at center, red, blue)"> <script>alert(document.body.style.backgroundImage)</script> ``` Firefox and WebKit[1] report `radial-gradient(circle, red, blue)` Chrome reports `radial-gradient(circle at center center, red, blue)` Notably: * The `radial-gradient` grammar uses the exact same `at <position>` syntax that `clip-path` does, so it's reasonable to expect that they would serialize consistently. * Firefox and WebKit are serializing `radial-gradient` with the `<position>` omitted, as the spec asks for (per jfkthame's comment 4) * Chrome is serializing `radial-gradient` with the `<position>` explicitly spelled out with keywords -- `center center` -- the same way that Firefox is serializing `clip-path` (and differently from how Chrome serializes `clip-path`). [1] (Note: my local WebKit is `epiphany` which doesn't like the newlines or script in my above data-URI, so I tested it there by removing the newlines and inspecting the serialization using devtools console)