W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2017

Re: [csswg-drafts] [css-transforms-2] `scale` property behavior differs from `scale()` function

From: Christoph Päper via GitHub <sysbot+gh@w3.org>
Date: Fri, 15 Dec 2017 10:18:09 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-351968458-1513333088-sysbot+gh@w3.org>
> Name: [scale](https://drafts.csswg.org/css-transforms-2/#propdef-scale)
> Value: none | \<number>{1,3}
>
> The `scale` property accepts 1-3 values, each specifying a scale along one axis, in order X, Y, then Z. Unspecified scales default to `1`.

In general, there are two *consistent* expansions of a single value for a property: either repeat it for all possible values (_a &rarr; a a a_) or set one to the explicit value and reset the rest to the default value (_a &rarr; a 1 1_). The more *useful* and, preferably, *intuitive* one of those choices should be specified, but *inconsistent* expansions are not unheard of if they are justified. In this case, resetting unspecified values is neither useful nor intuitively expected, while repeating them is useful and intuitively expected for only one of two scenarios, but that is still more than none. The inconsistent expansion _a &rarr; a a 1_ leads also to useful and expected results in only one of two scenarios, but it's the more common one.

| code | syntax | 2D context | 3D context |
| ---- | ---- | ---- | ---- |
| `scale: 2` = `scale: 2 2 2` | **consistent** | unintuitive + harmful | **intuitive + useful** |
| `scale: 2` = `scale: 2 1 1` | **consistent** | unintuitive + **harmless** | unintuitive + **harmless** |
| `scale: 2` = `scale: 2 2 1` | inconsistent | **intuitive + useful** | unintuitive + harmful |

That means, although all three choices are bad, they are not equally bad. Repetition is the least bad. However, we need also to consider the case where two out of three values have been set explicitly. There are (at least) four possible expansions for the third value: reset to default (_a b &rarr; a b 1_), repeat the first (_a b &rarr; a b a_) or the last (_a b &rarr; a b b_) value and set it to a calculated value(_a b &rarr; a b c_). Resetting is intuitively compatible with the less-favored option for the single-value case, whereas both repetition variants are consistent but arbitrary and hence not intuitive, and the derivation is neither consistent nor (generally) intuitive. 

| code | syntax | 2D context | 3D context |
| ---- | ---- | ---- | ---- |
| `scale: 2 3` = `scale: 2 3 1` | **consistent + systematic** | **intuitive + useful** | unintuitive + ambivalent |
| `scale: 2 3` = `scale: 2 3 2` | **consistent** + arbitrary | unintuitive + harmful | unintuitive + ambivalent |
| `scale: 2 3` = `scale: 2 3 3` | **consistent** + arbitrary | unintuitive + harmful | unintuitive + ambivalent |
| `scale: 2 3` = `scale: 2 3 2.5` | inconsistent + arbitrary | unintuitive + harmful | unintuitive + ambivalent |

That means, a choice needs to be made whether the expansions of a single value and of two values into three values should be consistent with each other or if there is enough reason to treat them differently. I believe there is. The most useful and still intuitive and somewhat consistent solution is to repeat a single value thrice, but to set the third value to `1` if only two values are provided.

> Value: \<'scale-x'> \<'scale-y'> \<'scale-z'>? | <number>
>
> The `scale` property accepts 1-3 values, each specifying a scale along one axis, in order X, Y, then Z. 
> If the last, Z value is left unspecified, it defaults to `1`.
> If only a single value is specified, all axis scale values are set to this same value.

| code | draft | proposed |
| ---- | ---- | ---- |
| `scale: 2` | `scale: 2 1 1` | `scale: 2 2 2` |
| `scale: 2 3` | `scale: 2 3 1` | `scale: 2 3 1` |


-- 
GitHub Notification of comment by Crissov
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2109#issuecomment-351968458 using your GitHub account
Received on Friday, 15 December 2017 10:18:27 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:26:44 UTC