Re: [csswg-drafts] [css-values] Add round()/floor()/ceil() functions (#2513)

The CSS Working Group just discussed `VAlues and units round()/floor()/ceil()/mod() (tab)`, and agreed to the following:

* `RESOLVED: Adopt a round function with keywords detailing which behavior`
* `RESOLVED: add the mod function with an open issue about behavior`

<details><summary>The full IRC log of that discussion</summary>
&lt;bkardell_> topic: VAlues and units round()/floor()/ceil()/mod() (tab)<br>
&lt;bkardell_> TabAtkins:  As we knew would probably happen, as we started suggesting math functions, people wanted more math functions<br>
&lt;bkardell_> TabAtkins: problems in the past the prevented these, we have solved those - so this issue is specifically about adding round and mod functions - they are all similar under the hood<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/2513<br>
&lt;bkardell_> TabAtkins: the big question for me is whether we want to add these as 4 function names or 1 with a mode?<br>
&lt;bkardell_> chrisl: which will people be most familliar with<br>
&lt;bkardell_> TabAtkins: another concern is spelling, for me ceil or ciel is confusing to me - I suspect I am not the only one... my suggestion is we go with  round function<br>
&lt;bkardell_> TabAtkins: Any ideas, comments suggestions?<br>
&lt;fantasai> TabAtkins writes on the blackboard: round(keyword? calc, calc, ...)<br>
&lt;fantasai> s/, ...//<br>
&lt;bkardell_> TabAtkins: round(keyword?, calc, calc) -- the second being precision you want<br>
&lt;bkardell_> leaverou: is there any precedent of having a single function like this in any language?<br>
&lt;bkardell_> TabAtkins: we have several functions with optional keywords in css<br>
&lt;bkardell_> leaverou: fair enough<br>
&lt;chris> rrsagent, here<br>
&lt;RRSAgent> See https://www.w3.org/2020/01/22-css-irc#T09-34-34<br>
&lt;bkardell_> fremy: when does round function  happen<br>
&lt;bkardell_> TabAtkins: same time as all of the math functions<br>
&lt;bkardell_> jensimmons: it seems like we asked this on twitter and we are now seeming to go against their express intent in this, admittedly non-scientific poll<br>
&lt;chris> alias sky ceiling<br>
&lt;bkardell_> fantasai: people who come from a math/programming background get 'floor' and 'ceiling' but as someone coming new to programming you won't know that<br>
&lt;bkardell_> myles: it's a math term<br>
&lt;bkardell_> fantasai: i didn't learn it, I don't think a lot of us did. For discoverability of people who are not already familliar with these terms it is a better model<br>
&lt;chris> round-up | round-down | round-truncate<br>
&lt;Rossen__> q?<br>
&lt;bkardell_> leaverou: don't forget that there is limited value in asking people because they will always trend toward whatever they already know<br>
&lt;bkardell_> rachelandrew: people will trend toward the simplest things<br>
&lt;bkardell_> dbaron: is this proposal written in the issue? I didn't find it in these comments?<br>
&lt;bkardell_> fremy: one of them was from amelia, I thin<br>
&lt;bkardell_> s/thin/think<br>
&lt;fantasai> s/better model/better model, because all four functions that do almost the same thing with slight variations are under the same feature. With the 4 separate functions, you have to now that they exist, and it's harder to find them unless you already know their names/<br>
&lt;bkardell_> jensimmons: consistency in css is a strong argument<br>
&lt;fantasai> i/jensimmons/rossen?: Could bake the keywords into the function name, like round-up(), round-down(), etc./<br>
&lt;bkardell_> Rossen__: it sounds like we all are agreeing that one function with an optional keyword...<br>
&lt;jensimmons> (uh, that’s not what I said.) I said — it makes sense to me what fantasai said, that it is basically one function / one feature — with several different ways to do it.<br>
&lt;bkardell_> florian: I was just looking and ruby has this pattern actually, the one we're suggesting<br>
&lt;dbaron> you can get to 8 functions with up|down|towards-zero|away-from-zero|nearest-half-goes-up|nearest-half-goes-down|nearest-half-goes-away-from-zero|nearest-half-goes-towards-zero<br>
&lt;florian> https://ruby-doc.org/core-2.5.3/Float.html#method-i-round<br>
&lt;bkardell_> Rossen__: prior art, agreement in the room, any objections<br>
&lt;fantasai> i/jensimmons/fantasai: There's no typing benefit to doing that, should just follow the CSS pattern we have in gradients, cross-fade(), etc. to put the keyword in the parens/<br>
&lt;dbaron> and I think the comment pointed to was https://github.com/w3c/csswg-drafts/issues/2513#issuecomment-565736728<br>
&lt;bkardell_> Rossen__: ok resolved<br>
&lt;bkardell_> RESOLVED: Adopt a round function with keywords detailing which behavior<br>
&lt;bkardell_> TabAtkins: mod() same deal - it's similar to mod() anywhere else, but I suggest we don't match javascript here<br>
&lt;bkardell_> myles: there is value in matching js here<br>
&lt;dbaron> Tab is suggesting that the sign of the result should match the sign of the second argument, not the first<br>
&lt;bkardell_> TabAtkins:  from what I can tell, most of the time people want the sign of the modulus, not the sign of the first arg<br>
&lt;bkardell_> myles: I don't have a strong opinion, I think there is a strong case to match JavaScript though<br>
&lt;Rossen__> q?<br>
&lt;bkardell_> TabAtkins: I feel mathematical mod is more sensible, how you probably learned in school - not as done in js as adopted from Java as adopted from C<br>
&lt;bkardell_> jensimmons: I think matching JavaScript is valuable<br>
&lt;astearns> +1 to jensimmons<br>
&lt;bkardell_> Rossen__:  breaking the relationship to JavaScript seem to be a bad default - people use JavaScript to create CSS<br>
&lt;fantasai> fantasai: what are the use cases for modding negative numbers?<br>
&lt;bkardell_> dbaron: if I am imagining some step pattern or some kind of thing you would create here - it does seem like what TabAtkins is saying is going to be more natural<br>
&lt;fantasai> +1<br>
&lt;bkardell_> TabAtkins: there seems to be good argument both ways<br>
&lt;bkardell_> fantasai: I would lean toward dbaron argument<br>
&lt;fantasai> fantasai: people who use JS are going to be more comfortable mucking about with mod functions to get the behavior they want<br>
&lt;dbaron> I was arguing that if you're using mod() to generate step patterns or something like that, if we use the JS mod(), you'll have to be careful to avoid inputting negative numbers (or, as Tab said, using multiple-mod() workarounds for that).<br>
&lt;fantasai> s/both ways/both ways; and you can use mod + add + mod calc pattern to switch behaviors if needed/<br>
&lt;bkardell_> bkardell_: Lots of preprocessors have functions like this -- which do they have, does it matter?<br>
&lt;bkardell_> TabAtkins: they don't seem to have an example<br>
&lt;bkardell_> TabAtkins: they don't seem to have an example in sass<br>
&lt;fantasai> fantasai: but this way the people who are just trying to get their CSS to work don't have to try so hard<br>
&lt;bkardell_> TabAtkins: just looking at the wikipedia page, you can see this problem demonstrated<br>
&lt;bkardell_> TabAtkins: it's very easy to just accidentally go negative and then you will have broken code, whereas the way I am suggesting here you have to be more intentional about it<br>
&lt;bkardell_> TabAtkins: good argument in general that matching js is good - but we have also agreed that it is maybe less intuitive<br>
&lt;bkardell_> TabAtkins: what do we want to do?<br>
&lt;bkardell_> Rossen__: straw poll for the initial thing, we can always change our minds<br>
&lt;bkardell_> Rossen__: 1) align with js 2) align with  'math'<br>
&lt;leaverou2> 2<br>
&lt;fremy> 2<br>
&lt;TabAtkins> 2<br>
&lt;heycam> 1<br>
&lt;bkardell_> 1<br>
&lt;jfkthame> 1<br>
&lt;iank_> 1<br>
&lt;Rossen__> 1<br>
&lt;stantonm> 1<br>
&lt;rachelandrew> 1<br>
&lt;emilio> 1<br>
&lt;florian> 2<br>
&lt;astearns> 1<br>
&lt;cbiesinger> 2<br>
&lt;jensimmons> on behalf of dbaron — 2<br>
&lt;bkardell_> myles: 1<br>
&lt;bkardell_> tess: 1<br>
&lt;bkardell_> bkardell_: 1<br>
&lt;bkardell_> TabAtkins: 11 to 10, I think we have to leave this as an open issue<br>
&lt;bkardell_> Rossen__:  any objections to adding the mod() function with an open issue about....what it actually does?<br>
&lt;fantasai> i/TabAtkins/[various people have lost connectivity]<br>
&lt;fantasai> s/connectivity/connectivity; Tab runs an offline poll/<br>
&lt;jensimmons> the vote in the room was 12 for Option 1 (align with JS) and 11 for Option 2 (align with math)<br>
&lt;bkardell_> RESOLVED: add the mod function with an open issue about behavior<br>
&lt;fantasai> It was 11 against 11 of the people in the room; myles claimed to vote for Tess, but she wasn't here for the oral arguments :p<br>
</details>


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

Received on Wednesday, 22 January 2020 09:59:01 UTC