- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 15 Feb 2022 23:00:54 +0000
- To: public-css-archive@w3.org
Yes, tab-size is currently a number. It's *terrible*, and I'm going to push very strongly against spreading this precedent any further. It's currently contained to exactly two properties and I don't want it going any further when there's no reason for it. In other words, the goodness of (very vague) precedent is overwhelmed by the practical badness of it. It is *absolutely bad* to have a length-ish value that can't be combined with other length-ish values. If vague precedent is the only reason for doing this I'm going to strongly object to it. > Please note that while in tab-size this always refers to the space character, in word-spacing it can apply to a variety of different characters, and is applied as a multipler per character. In other words, even its used value is not a singular length value that can be applied to the whole element. So this means that the precedent of tab-size is *even less* applicable. > Mint a new unit, e.g. pr or whatever, define `<length-percentage-proportion>` or whatever No need for this, we can still call it a `<length>`, because it is. It just resolves at a different time; we already have lengths that resolve at multiple different times, so this isn't anything special in that regard, and the fact that it has to resolve at *actual value* time is just a new wrinkle, not a fundamental difference. The unit would just be context-sensitive, and probably, uh, resolve to 0 in any other property I guess? Or perhaps resolve relative to `ch`. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3232#issuecomment-1040882674 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 15 February 2022 23:00:56 UTC