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

The CSS Working Group just discussed `mod() mode`, and agreed to the following:

* `RESOLVED: the mod() and rem() functions are to be added to CSS, one with math behavor, the other with JS behavior`

<details><summary>The full IRC log of that discussion</summary>
&lt;fremy> Topic: mod() mode<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/2513<br>
&lt;TabAtkins> https://en.wikipedia.org/wiki/Modulo_operation#In_programming_languages<br>
&lt;fremy> TabAtkins: I was thinking about this, and looking at the wikipedia article...<br>
&lt;fremy> TabAtkins: there is a lot of divergence<br>
&lt;fremy> TabAtkins: but there is one constant<br>
&lt;fremy> TabAtkins: if a language has a pair, mod works like Math and % works like JS<br>
&lt;fantasai> s/%/rem/<br>
&lt;fremy> TabAtkins: in particular, &lt;&lt;&lt;&lt;>>>> language does this, because they came to the same conclusion<br>
&lt;heycam> q+<br>
&lt;fremy> TabAtkins: so my proposal, is to add the two functions<br>
&lt;fantasai> s/&lt;&lt;&lt;>>>>/Web Assembly/<br>
&lt;fremy> leaverou: why are we adding functions and not an operator<br>
&lt;fremy> TabAtkins: more complex<br>
&lt;leaverou> s/why are we adding functions and not an operator/why are these functions and not operators?/<br>
&lt;fremy> TabAtkins: and also it's not an operator in all languages anyway<br>
&lt;fantasai> I support Tab's proposal fwiw<br>
&lt;fremy> myles: why dont' we want mod to be like js?<br>
&lt;florian> +1<br>
&lt;florian> s/+1/+1 to tab's proposal/<br>
&lt;fremy> TabAtkins: javascript doesn't have a function, just an operator that works like rem<br>
&lt;fremy> myles: but then we make CSS more powerful than JS, while JS was intended to be math-complete while CSS is not<br>
&lt;fremy> hober: I think the point of this exercise was to reduce differences in differences between the platform languages<br>
&lt;fremy> hober: I'm confused why we want to introduce inconsistencies<br>
&lt;RossenF2F> q?<br>
&lt;fremy> hober: It might be reasonable to ask somebody from TC39 to consider adding the other function, and mimick their response<br>
&lt;fremy> TabAtkins: I don't believe it's correct to say that we want to minimize the difference between the two languages<br>
&lt;fremy> TabAtkins: our goal is to give designers the functions they need to get the layouts they want<br>
&lt;fremy> TabAtkins: which is why we didn't add the hyperbolic functions because there are no known use case<br>
&lt;fremy> TabAtkins: and to reply to the "more powerful question", we already do that<br>
&lt;fremy> TabAtkins: for instance, we have a more complex round function, and that is useful because rouding is important to us<br>
&lt;fremy> TabAtkins: so I don't want to say we should not innovate beyond JS<br>
&lt;fremy> TabAtkins: but we should only do it if there's an use case<br>
&lt;astearns> ack heycam<br>
&lt;astearns> Zakim, close queue<br>
&lt;Zakim> ok, astearns, the speaker queue is closed<br>
&lt;fremy> heycam: If we really wanted to match JS, we would do an operator, not a mod function in the first place<br>
&lt;fremy> heycam: but I was on the queue to say something else<br>
&lt;fremy> heycam: it's confusing to have an unit called rem, and a function called rem<br>
&lt;fremy> heycam: I would like to avoid it<br>
&lt;fremy> myles: an author might think it gives you the size of a rem<br>
&lt;fremy> TabAtkins: it would not work, and authors would realize that<br>
&lt;astearns> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to point out that JS doesn't have a mod function, it has a % operator, so either way we have to pick a name, picking rem() as that name is perfectly fine<br>
&lt;fremy> fantasai: also, I want to point out that log doesn't do console.log<br>
&lt;fremy> fantasai: also, I agree, % is not a function in JS, not a function<br>
&lt;myles> q?<br>
&lt;fremy> fantasai: so, if we add a mod() function we don't have to match JS, we can do something useful<br>
&lt;fremy> myles: log is a very different example, because we just cannot console.log in JS<br>
&lt;fremy> myles: but here we are doing the same thing<br>
&lt;fremy> TabAtkins: we have functions that can absorb css timing resolutions from houdini<br>
&lt;fremy> TabAtkins: the paint api when it gets called gives you timing information<br>
&lt;fremy> astearns: I don't think this is gonna get narrowed down today<br>
&lt;fremy> TabAtkins: but, we want to check if we can ship this<br>
&lt;fremy> TabAtkins: so can we strawpoll or record objections?<br>
&lt;fremy> &lt;debate on the options between people><br>
&lt;fremy> RossenF2F: the new option is that we have both mod and rem<br>
&lt;fremy> florian: I think we should just have a decision yes or no on the adoption of this approval<br>
&lt;fremy> astearns: yeah, let's do this<br>
&lt;fremy> hober: I am worried about the form of this strawpol<br>
&lt;fremy> hober: because we are not agreeing on an alternative<br>
&lt;fremy> astearns: yes, but if we say no, we don't do anything and defer for another day<br>
&lt;TabAtkins> 1. Resolve to add mod() (math behavior) and rem() (JS behavior)<br>
&lt;TabAtkins> 2. Continue thinking about the desired mod-ish behavior in the issue, resolve sometime later.<br>
&lt;fantasai> 1<br>
&lt;florian> 1<br>
&lt;TabAtkins> 1<br>
&lt;faceless> 1<br>
&lt;leaverou> 1<br>
&lt;hober> 2<br>
&lt;dbaron> 1<br>
&lt;RossenF2F> 1<br>
&lt;fremy> 1<br>
&lt;tantek> 1 because YOLO<br>
&lt;stantonm> 1<br>
&lt;rachelandrew> 1<br>
&lt;astearns> abstain<br>
&lt;jfkthame> 1<br>
&lt;heycam> 1<br>
&lt;fremy> 15/22 said 1<br>
&lt;RossenF2F> mod(15/22)<br>
&lt;fremy> astearns: proposed resolution is thus to add both mod() and rem()<br>
&lt;fremy> astearns: does anybody object?<br>
&lt;TabAtkins> It's 13 for option 1, 1 for option 2<br>
&lt;fremy> RESOLVED: the mod() and rem() functions are to be added to CSS, one with math behavor, the other with JS behavior<br>
&lt;TabAtkins> ScribeNick: TabAtkins<br>
&lt;leaverou> Chris can't vote due to lack of connectivity, but he votes 1<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-578158390 using your GitHub account

Received on Friday, 24 January 2020 14:42:54 UTC