Re: [csswg-drafts] [css-variables-2] Custom units as simple variable desugaring (#7379)

The CSS Working Group just discussed `custom units as variables`, and agreed to the following:

* `RESOLVED: Start new draft of variables-2 and add custom units as described here`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: custom units as variables<br>
&lt;TabAtkins> github:<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7379<br>
&lt;fantasai> TabAtkins: A week or two ago Jonathan Neal had a suggestion in Twitter, just doing on pre-processor side, about a way to finally address custom units<br>
&lt;fantasai> TabAtkins: where you want to set some length and use multiples of it<br>
&lt;fantasai> TabAtkins: used all over design systems, but doing today with variables is awkward<br>
&lt;fantasai> TabAtkins: have to explicitly use a calc and multiply, quite a lot of writing for what is ~3ch for pre-defined units<br>
&lt;fantasai> TabAtkins: suggestion is to treat custom units just as variables<br>
&lt;fantasai> TabAtkins: so if have number with --unit, this is a variable reference<br>
&lt;fantasai> TabAtkins: triggers same stuff, but resolve it into the appropriat ecalc<br>
&lt;fantasai> TabAtkins: so 3--unit would become calc(3 * var(--unit))<br>
&lt;fantasai> TabAtkins: can set up lengths with @property rule<br>
&lt;fantasai> TabAtkins: can have some control about whether absolute links are resolved as time of use or ?? by setting as &lt;length> or not<br>
&lt;fantasai> TabAtkins: seems to solve most problems of custom units<br>
&lt;fantasai> TabAtkins: but doesn't prevent us from doing something more complicated using registration<br>
&lt;fantasai> TabAtkins: later<br>
&lt;fantasai> TabAtkins: This allows more readable usage for design systems, not complicated on implementation side<br>
&lt;fantasai> TabAtkins: one of our implementers was looking for implementations problems and couldn't find any<br>
&lt;fantasai> TabAtkins: Thoughts?<br>
&lt;bramus> q+<br>
&lt;dbaron> +1, sounds simple and valuable<br>
&lt;fantasai> astearns: ?? comment that they didn't find it particularly readable<br>
&lt;florian> haven't spent much time thinking about it, but seems reasonable (and terse)<br>
&lt;astearns> s/??/faceless/<br>
&lt;fantasai> astearns: and hides complexity that maybe should be expressed<br>
&lt;fantasai> faceless: [...]<br>
&lt;astearns> ack bramus<br>
&lt;fantasai> faceless: but no objection<br>
&lt;miriam> q+<br>
&lt;fantasai> ???: Would allow ability to polyfill new units as well, e.g. define --brm and use your new custom unit code to polyfill it<br>
&lt;fantasai> ???: seems really nice<br>
&lt;dbaron> s/???/bramus/<br>
&lt;dbaron> s/???/bramus/<br>
&lt;fantasai> astearns: For browsers that do not support the new unit, what happens when you use the custom property<br>
&lt;fantasai> bramus: browser would support the real unit, which you have just made your custom unit as an alias, and for browsers that don't support it you can give them the fallback<br>
&lt;astearns> q?<br>
&lt;fantasai> TabAtkins: if we had ability to do parse-time rejection of declared properties... but need JS for that<br>
&lt;astearns> ack miriam<br>
&lt;fantasai> miriam: I think this would help solve cases where we would need to remove units from a value, e.g. viewport width ppl want to use them in a unitless place like line-height, but this wouldn't help with that case, right?<br>
&lt;jensimmons> q+<br>
&lt;fantasai> TabAtkins: Right, that wouldn't help. What you need is the unit math in the spec to be implemented.<br>
&lt;astearns> ack jensimmons<br>
&lt;fantasai> jensimmons: I really love this, just wish the -- doesn't need to be there<br>
&lt;fantasai> jensimmons: I do think it would be helpful to get some feedback, can think of 2-3 ppl working on responsive typography be good to get their feedback<br>
&lt;fantasai> jensimmons: they're using mix of absolute and relative sizing in setting type sizes etc.<br>
&lt;fantasai> jensimmons: could be very powerful<br>
&lt;fantasai> TabAtkins: That's one of the major use cases, so would be great to get their feedback<br>
&lt;lea> I love how general this is, +1 from me too<br>
&lt;fantasai> astearns: Sounds like this is something we should pursue<br>
&lt;fantasai> TabAtkins: Where to put it? Variables 1 is fairly mature, so suggest starting Variables 2<br>
&lt;fantasai> astearns: Makes sense to me<br>
&lt;lea> +1 for variables-2<br>
&lt;fantasai> +1<br>
&lt;fantasai> astearns: Proposed resolution is to start variables-2, with this as the feature to add<br>
&lt;fantasai> astearns: any objections?<br>
&lt;fantasai> RESOLVED: Start new draft of variables-2 and add custom units as described here<br>
&lt;fantasai> astearns: Let's keep this issue open for a little bit, so Jen you can get some additional people to give feedback<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7379#issuecomment-1170229274 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 29 June 2022 16:47:06 UTC