- From: Guillaume via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Sep 2023 08:32:38 +0000
- To: public-css-archive@w3.org
I did an in-depth specific research on serialization of optional numeric values, or optional keyword values mapping to a numeric value, in Chrome and Firefox. They *usually* only seem to be omitted when they are strictly equal to a default value or an initial longhand value, without applying any resolution before the comparison (presumably with serialized strings): - canonicalizing dimensions - mapping percentages to absolute values - mapping keywords to numeric values (or vice-versa) - unwrapping resolved math functions - clamping or mapping degrees to `[0,360)` Two numerics with a value of `0` but of a different type or with a different unit are *usually* not considered equal, except `0px` and `0` when it matches `<length>` (it is presumably normalized to `0px` at parse time). <details> <summary>Exceptions (probably not exhaustive)</summary> - often Chrome and sometimes Firefox preserve optional initial longhand values in shorthands - color functions serialize without a default `<alpha-value>`: `100%`/`1`, `101%`/`2` `calc(101%)`, `calc(2)` - [`<conic-gradient()>`](https://drafts.csswg.org/css-images-4/#funcdef-conic-gradient) serializes with `from 0deg` as a default gradient line origin in Chrome - `<conic-gradient()>` serializes without `from calc(0deg)` as a default gradient line origin in Firefox - [`<linear-gradient()>`](https://drafts.csswg.org/css-images-3/#funcdef-linear-gradient) serializes without a default gradient line direction: `to bottom`, `180deg`, `calc(180deg)` - [`<filter-function>`](https://drafts.fxtf.org/filter-effects-1/#typedef-filter-function)s serialize with default values - [`font: normal normal 400 16px "family"`](https://drafts.csswg.org/css-fonts-4/#font-prop) serializes without `400` (equivalent to the initial `font-weight`: `normal`) in Firefox - [`font-style: oblique 14deg`](https://drafts.csswg.org/css-fonts-4/#font-style-prop) serializes with `14deg` in Chrome - [`hyphenate-limit-chars: auto 1 1`](https://drafts.csswg.org/css-text-4/#hyphenate-char-limits) serializes as is (even if the trailing `1` is strictly equal to the previous `1`) - [`transform-origin`](https://drafts.csswg.org/css-transforms-1/#transform-origin-property) serializes with the default offset: `0px` or `0` - [`scale: 1 100% 1`](https://drafts.csswg.org/css-transforms-2/#propdef-scale) serializes with `scale: 1` - `scale: 100% 1 100%` serializes with `scale: 1` - `scale: calc(100%) calc(1)` serializes with `scale: 1` in Chrome and `scale: calc(1)` in Firefox - [`translate: 1px 0em 0in`](https://drafts.csswg.org/css-transforms-2/#propdef-translate) serializes with `translate: 1px` - `translate: 1px calc(0em)` serializes without `calc(0em)` in Chrome - [`transform: scale(1, 1)`](https://drafts.csswg.org/css-transforms-1/#two-d-transform-functions) serializes with `, 1` in Chrome - `transform: translate(1px, 0px)` serializes with `, 0px` in Chrome - `transform: translate(1px, 0in)` serializes without `, 0in` in Firefox - `transform: skew(1deg, 0)` serializes with `, 0` in Chrome (invalid in Firefox) - `transform: skew(1deg, 0deg)` serializes without `, 0deg` in Firefox - `transform: skew(1deg, 0rad)` serializes without `, 0in` in Firefox - `transform: skew(1deg, calc(0deg))` serializes without `, calc(0deg)` in Firefox - `transform: skew(1deg, calc(0rad))` serializes without `, calc(0in)` in Firefox </details> -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5642#issuecomment-1717185053 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 September 2023 08:32:40 UTC