- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Jan 2020 10:41:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `the rest of the JS Math functions`, and agreed to the following: * `RESOLVED: add these 5 - abs, log, exp, and the two constants e and pi` <details><summary>The full IRC log of that discussion</summary> <bkardell_> topic: the rest of the JS Math functions<br> <bkardell_> TabAtkins: I went through all of the Math functions and reviewed for consistency...<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4688<br> <bkardell_> TabAtkins: in the issue I listed out the functions and constants - I just dumped the object in chrome, I assume everyone has the same thing...<br> <bkardell_> TabAtkins: I seprated them into categories<br> <bkardell_> TabAtkins: a handfull of algebra stuff - abs, cube root<br> <bkardell_> TabAtkins: you can do these yourself if you know how, but it's fine with me to just go ahead and match for parity/consistency<br> <bkardell_> TabAtkins: low value, but reasonable<br> <bkardell_> heycam: if we have this goal of 'if it is on the math object and there is no reason to not include it here'... it seems even more odd to me that round would devitate from this<br> <bkardell_> TabAtkins: exact correspondance is not my goal, we already can't match exactly because we have to include precision<br> <bkardell_> fantasai: If we aren't going for exact correspondance, we should maybe not add cube root<br> <dbaron> +1 for adding 'abs' and not adding 'cbrt'<br> <florian> +!<br> <bkardell_> fantasai: I do think we should add abs() because people are unlikely to understand there is anothe way to do that, it's not as intuitive<br> <fantasai> s/cube root/cube root right now; if there's demand for it later, we can add it later/<br> <RossenTheReal> q?<br> <bkardell_> dbaron: I think there is a small chance that it applies here, one reason some of the weird functions exist in JS might be because they can be made faster than the non-weird version<br> <bkardell_> TabAtkins: is that an argument for doing it or not ?<br> <bkardell_> dbaron: it might be an argument for someone to look into it<br> <bkardell_> fantasai: you could optimize it anyway<br> <bkardell_> dbaron: it would be harder<br> <bkardell_> (oriol demonstrates math the scribe couldn't understand)<br> <dbaron> Oriol was pointing out that cbrt(-8) is -2 whereas pow(-8, 1/3) is NaN<br> <dbaron> And, particularly, fractions 1/N where N is odd are not representable exactly unless N is 1 or -1.<br> <bkardell_> TabAtkins: next up - hyperbolic trig functions... I don't know use cases here in CSS?<br> <bkardell_> TabAtkins: can skip this entire category unless someone needs to object?<br> <bkardell_> fremy: if you have the exponent function you should be good<br> <bkardell_> TabAtkins: next - the family of e related functions -- log(), log 2, log 10<br> <bkardell_> in JavaScript it was like this - I suggest we just pass in instead of 2, 10<br> <dbaron> TabAtkins: log() is 2 argument with base defaulting to e<br> <bkardell_> TabAtkins: suggesting we just add log() and possibly exp()?<br> <bkardell_> fantasai: I think I agree with your basic take, I think we just do log() now and exp later<br> <bkardell_> TabAtkins: next is rounding, we already discussed<br> <dbaron> Ah, Mercator projection drawing math uses asinh().<br> <bkardell_> TabAtkins: the last thing is constants...<br> <bkardell_> TabAtkins: I can see you wanting to use some of these - Pi, E ..<br> <bkardell_> TabAtkins: should we add these as single argument functions? it seems like there's a challenge with globally reserved keywords<br> <dbaron> TabAtkins: Would break animation-names of e and pi<br> <bkardell_> heycam: can you not make it global, just in calc?<br> <chris> maybe make them ε and π (the greek letters) to avoid conflicts<br> <bkardell_> TabAtkins: ... maybe, probably<br> <fantasai> +1 to heycam's suggestion<br> <bkardell_> RossenTheReal: do we need them for now?<br> <bkardell_> TabAtkins: no non-ascii things please<br> <bkardell_> florian: keeping the parser non-breaking seems useful<br> <bkardell_> fantasai: we have an intent to use them anywhere -- as long as it is not a great complication to the parser it seems like a win<br> <dbaron> could we add them in a function like const(pi)?<br> <florian> env(pi)<br> <fantasai> s/use them anywhere/add keywords to calc() someday anyway/<br> <bkardell_> TabAtkins: actually, the units thing is not a terrible idea<br> <fantasai> s/a win/a usability win/<br> <bkardell_> dbaron: one thing that is painful about e is its interaction with exponential notation<br> <heycam> Tab there is responding to my /me joke to make pi and e be units<br> <bkardell_> dbaron: we already support things like 1e<br> <cbiesinger> s/1e/1e1/<br> <bkardell_> dbaron: I saw a suggestion - what if we stuck these inside of some other function?<br> <bkardell_> TabAtkins: we want this to be short is the counter argument I guess, but const is not bad<br> <dbaron> 1e1e is pretty ugly (in terms of having pi and e be units)<br> <bkardell_> myles: it could be math.e to match javascript<br> <bkardell_> fantasai: that would change the parser<br> <bkardell_> TabAtkins: which of these 3 options do we like?<br> <TabAtkins> 1. "e" and "pi" allowed in calc() as keywords<br> <TabAtkins> 2. e() and pi() available everywhere<br> <leaverou> const(e) might be more clear than e for people reading others' code<br> <TabAtkins> 3. const(e) and const(pi) available everywhere<br> <fremy> 2<br> <fantasai> 1<br> <florian> 1<br> <leaverou> 3<br> <fantasai> Note that 1 allows calc(e) everywhere<br> <dbaron> could also be math(pi) rather than const(pi)<br> <faceless2_> 2<br> <astearns> 1 or 3<br> <iank_> not 3<br> <chris> 3<br> <fantasai> dbaron, let's take that as a variant of 3<br> <jensimmons> `grid-template-layout: 100px 1fr calc(2pi);`<br> <jensimmons> `grid-template-layout: 100px 1fr const(pi);`<br> <jensimmons> `grid-template-layout: 100px 1fr pi();`<br> <chris> 3 > 2 > 1<br> <emilio> 1<br> <RossenTheReal> option 1: 13 votes<br> <RossenTheReal> option 2: 3<br> <jensimmons> oh I wanted to vote for 2<br> <jensimmons> option 2: 2<br> <RossenTheReal> option 3: 5 vites<br> <bkardell_> TabAtkins: we will take the strawpoll as evidence for now and use option 1<br> <jensimmons> `grid-template-layout: 100px 1fr calc(2*pi);`<br> <TabAtkins> Chris: This'll let us close the long-running issue that 'rad' is useless without pi?<br> <TabAtkins> TabAtkins: Yes<br> <bkardell_> TabAtkins: final bits "stuff we probably don't want"... random ... seems impossible<br> <bkardell_> TabAtkins: clz32 -- it's... complicated<br> <bkardell_> myles: it's used in video codecs<br> <bkardell_> TabAtkins: which you probably shouldn't be doing in css<br> <bkardell_> tess: I love the idea of someone trying tho<br> <bkardell_> TabAtkins: last one is imul()<br> <bkardell_> chris: what is that for even<br> <bkardell_> TabAtkins: we don't want it<br> <bkardell_> TabAtkins: pow with an e argument - I don't know if there is something here with speed<br> <bkardell_> fantasai: the pow function takes two args -- what if you give on?<br> <bkardell_> fantasai: the pow function takes two args -- what if you give one?<br> <bkardell_> TabAtkins: it would be invalid<br> <bkardell_> fantasai: maybe we should make it consistent with others?<br> <chris> make second argument to pow optional, defaulting to 1<br> <iank_> The other way to make it consistent is to not have the default arg for, log(), and add ln()<br> <fantasai> s/with others/with log by making it default to e/<br> <TabAtkins> Notes that exp(x) == pow(e, x)<br> <iank_> log(val, base), ln(val), pow(val, pow), exp(val)<br> <myles> TabAtkins: that isn't quite true to to precision (which CSS doesn't care about)<br> <chris> pow(foo) == pow(foo, 1) == foo<br> <myles> TabAtkins: but it's almost true!<br> <bkardell_> dbaron: so is anyone going to be annyoed by log in css being math log and not console log<br> <jfkthame> calculators I have known typically have a dedicated e^x key (=exp), although they also have x^y (=pow)<br> <bkardell_> fantasai: do you have a different suggestion dbaron ?<br> <bkardell_> dbaron: ln?<br> <fantasai> fantasai: for log of base 10?<br> <bkardell_> RossenTheReal: any more comments or objections on adding these 5: abs, log, exp, and the two constants e and pi<br> <fantasai> s/constants/keyword constants/<br> <bkardell_> RESOLVED: add these 5 - abs, log, exp, and the two constants e and pi<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4688#issuecomment-577120674 using your GitHub account
Received on Wednesday, 22 January 2020 10:41:24 UTC