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
Suppose an author sets various <image> properties to gradients with color keywords, e.g. linear-gradient(45deg, blue, orange) . Should getComputedStyle() results show gradients with color keywords or rgb functions?
Should we change the "Computed value" text for shape-outside
..., the <image> with its URI made absolute, otherwise as specified.
=>
..., the <image> with its URI made absolute and colors computed, otherwise as specified.
background-image and border-image-source would need a similar change if they referenced the CSS Images 3 definition of <image>, but they currently don't.
I would expect the color format to be serialized in the same form as <color> types in other properties.
Rather than define this every time a property includes an <image> type, it would be nice if we could define the computed/serialized form for a gradient function itself. And then use the "computed value of the <image>" wording for properties.
This also affects lengths (radial-gradient, conic-gradient). Firefox and Edge make lengths absolute, Blink and Safari do not (e.g. getComputedStyle() gives results with ex).
Activity
AmeliaBR commentedon Jun 19, 2019
I would expect the color format to be serialized in the same form as
<color>types in other properties.Rather than define this every time a property includes an
<image>type, it would be nice if we could define the computed/serialized form for a gradient function itself. And then use the "computed value of the<image>" wording for properties.tabatkins commentedon Jun 20, 2019
Yeah, we just need a definition for "computed
<image>" that can be reused, it's silly to copy boilerplate like this that gets out of sync.ewilligers commentedon Jun 21, 2019
This also affects lengths (radial-gradient, conic-gradient). Firefox and Edge make lengths absolute, Blink and Safari do not (e.g. getComputedStyle() gives results with ex).
[css-lists] Parsing list-style
[css-images] Negative radii are invalid
[css-images] Negative radii are invalid
[css-lists] list-style-image computed value
[css-images] Radii are clamped non-negative
[css-lists] list-style-image computed value
[css-lists] list-style-image computed value (#17441)
[css-images] Radii are clamped non-negative (#17442)
AmeliaBR commentedon Jul 9, 2019
Agenda+ to get a resolution, unless @ewilligers would rather we wait until the next APAC-friendly meeting?
ewilligers commentedon Jul 9, 2019
No need to wait. I expect there is simply a browser bug in Blink, Edge 18 and Safari. There appears to be consensus about adding computed image.
9 remaining items
Bug 1564660 [wpt PR 17442] - [css-images] Radii are clamped non-negat…
Bug 1564659 [wpt PR 17441] - [css-lists] list-style-image computed va…
Bug 1564660 [wpt PR 17442] - [css-images] Radii are clamped non-negat…
[css-lists] list-style-image computed value (web-platform-tests#17441)
[css-images] Radii are clamped non-negative (web-platform-tests#17442)
Bug 1564659 [wpt PR 17441] - [css-lists] list-style-image computed va…
Bug 1564660 [wpt PR 17442] - [css-images] Radii are clamped non-negat…
Bug 1564659 [wpt PR 17441] - [css-lists] list-style-image computed va…
Bug 1564660 [wpt PR 17442] - [css-images] Radii are clamped non-negat…
Bug 1564659 [wpt PR 17441] - [css-lists] list-style-image computed va…
Bug 1564660 [wpt PR 17442] - [css-images] Radii are clamped non-negat…
Update computed value lines to reference computed <image>. #4042
Update computed value lines to reference computed <image>. #4042
Bug 1564659 [wpt PR 17441] - [css-lists] list-style-image computed va…
Bug 1564660 [wpt PR 17442] - [css-images] Radii are clamped non-negat…