- From: Guillaume via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Jan 2023 10:05:44 +0000
- To: public-css-archive@w3.org
I do not know if math functions generally fall into the "weird case" category but the SSP is currently applied inconsistently with them. For example, [*Serialization*](https://drafts.csswg.org/css-images-3/#serialization) in CSS Images 3 requires *omitting components when possible without changing the meaning*: > For example, a gradient specified as: > > `Linear-Gradient( to bottom, red 0%,yellow,black 100px)` > > must serialize as: > > `linear-gradient(red, yellow, black 100px)` (The [same section in CSS Images 4](https://drafts.csswg.org/css-images-4/#serialization) serializes `red`, `yellow`, `black`, to `rgb()`, which makes me wonder if it applies to specified values though.) Chrome/Firefox omit `to calc(180deg)` (same as `to bottom`) in `<linear-gradient()>` but not `to calc(-180deg)`. And they do not omit components in the color stop list. You cannot know `75%` can be omitted in `linear-gradient(red 50%, blue 0%, 75%, green)` without applying [*color stop "fixup"*](https://drafts.csswg.org/css-images-4/#color-stop-fixup), which is meant to resolve used values. Obviously color stop list is a "weird case" but I think there are many cases similar to the first. Eg. Chrome/FF do not serialize specified `border-radius: 1em calc(1em)` to `border-radius: 1em`. I guess browsers do not try too hard to resolve values until they know it is required for rendering, which makes me think that not applying the SSP for specified values (except for backward-compatibility) would be way more simple. -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5642#issuecomment-1403366347 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 January 2023 10:05:46 UTC