- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jun 2024 11:21:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-syntax] Should numbers have type `integer` whenever the actual value is an integer?``. <details><summary>The full IRC log of that discussion</summary> <jarhar> TabAtkins: question was raised if syntax spec should - currently distinguish bettween tokens parsed as number and some as integer<br> <jarhar> TabAtkins: rule at the moment is if its just digits its an integer its ?, exponent its a number<br> <jarhar> TabAtkins: implications fo rproperties like z index, invalid to do z index of 1 e 3 instead of ?<br> <jarhar> TabAtkins: romain was asking if we should treat things as integers if they are an integer value<br> <jarhar> TabAtkins: ? large enough that we are doing an integer part, stuff after decimal was zero<br> <jarhar> TabAtkins: i suspect we cannot change ? after decimal point, thats been a number for a long time and we sohould keep that, clear that you want a float<br> <jarhar> TabAtkins: we should relax scifi rules because you cant integer scifi notation ever<br> <TabAtkins> rhttps://github.com/w3c/csswg-drafts/issues/10238#issuecomment-2080095998<br> <fantasai> s/rhttp/http/<br> <oriol> q+<br> <jarhar> TabAtkins: proposal is that a ? integer if you doesn't have a decimal or just digits, if it doesn't have a decimal or zero or positive scientific notation, or it has a decimal compoentn, or it has number of points after the decimal, so like 1.1e2 would be an integer because its 110, but 1.11e1 would not be because its 11.1<br> <jarhar> TabAtkins: that would also work for the serialization rules from that are already defined in scientific notation, for large integers numbers with decimal points and a big exponent<br> <jarhar> TabAtkins: and i think thats going to be safe. only case with giant integers is z index and we want serialization of z index to be usable<br> <jarhar> TabAtkins: might not round trip in some cases today<br> <jarhar> TabAtkins: if theres nothing that tries to indicate a less than one segment of the number, otherwise its a number, how does that sound<br> <fserb> q+<br> <astearns> ack oriol<br> <jarhar> oriol: i was wondering if its inconsistent that in one case we are comparing number of decimals vs exponent, on the other hand if the exponent is negative then we dont ? about trailing zeros. if we have 120e-1 then we get 12 but we do not consider this to be an integer according to proposal<br> <jarhar> TabAtkins: i have no opinion. nobody writes that, i simply dont care. if we want to go either direction on those<br> <astearns> ack fserb<br> <jarhar> fserb: you said that the only use case is this a problem is z index<br> <jarhar> TabAtkins: that is an integer value property that often has big numbers<br> <florian> q?<br> <jarhar> fserb: do we have a good reason to not allow 5.0? i konw its not an integer, we're creating a rule about numbers that feels arbitrary. if the case is just because z index 5.0 its a horrible thing then you should just let it slide and forget about the notion of an integer<br> <jarhar> astearns: its a compat thing, there is code that expects it to see 5.0<br> <jarhar> TabAtkins: and theres languages that distinguish between numberic types, they treat 5.0 as a non integer<br> <jarhar> fserb: yes but they also have ways to convert float<br> <astearns> s/see 5.0/see 5.0 as a number/<br> <jarhar> TabAtkins: css does too, wrap in calc<br> <jarhar> fserb: isn't that silly?<br> <jarhar> TabAtkins: it rounds its fine<br> <jarhar> fserb: shouldn't we just live with z index 5.0 and be happy?<br> <jarhar> fantasai: we can't do that for compat reasons, no need to debate whether its a good idea<br> <jarhar> fserb: on that proposal i just left a comment, yhou said the same thing you wrote. there is also the use case where you have more than one digit 50e-1 should also be an integer<br> <jarhar> TabAtkins: it doesn't follow. we can put it in, if not whatever<br> <astearns> q?<br> <astearns> ack fantasai<br> <jarhar> fantasai: i think theres two approaches we can go here. one is that you figure out whether the ifinal result of a ? the scientific notation has decimals or not. and then decide whether its an integer ot not or<br> <jarhar> fantasai: you can go from a more parsing perspetive of does it have a negative exponent or decimal and if its no its an integer. as oriol pointed out youre doing half an dhalf<br> <jarhar> TabAtkins: doesn't work serialization of large decimals produces a decimal point with a large expont<br> <jarhar> fantasai: i dont understand why<br> <jarhar> TabAtkins: once you start serializing with scientific notation, langagues serialize with ? decimal pointa nd then put everything behind the decimal point. js does it, we approved the serizliation rules, other ? you use serialize the same way. it uses one ? digit and a bunch of decimal digits<br> <astearns> ack dbaron<br> <jarhar> dbaron: i was on the queue to say why i like tabs proposal and i think that might help answer this concern. my undesrstanding of what tab proposed is that its just a parse time - im going to explain the same thing in a differnet way<br> <jarhar> dbaron: the way i understand it is that it is purely a parse time thing but youre asking did you write any digits in the number part not the exponent part whose maeaning after you apply thye exponent is that they go in a less than one position<br> <jarhar> dbaron: its purely syntactic. the qeustion is did you write any digits after the decima. point, except that we mean where the logical decimal point is after the exponent. when you use a negative exponent, it is impossible to write ? after the digits? if your exponent is negative 1, the lst digit is after the decimal point digit<br> <jarhar> dbaron: my way of thinking what tabs proposing, its an integer if theres no digits at the .1 position or the .01 position, if ? ten position or hundred position or higher<br> <jarhar> dbaron: did you write any digits at those positions ? only thing that makes this ?<br> <jarhar> TabAtkins: that is the logic behind the rules yes<br> <florian> q?<br> <fserb> q+<br> <jarhar> dbaron: maybe you could think of it as its aparsing thing on the number before the thing but a logical thing about the number after the e<br> <jarhar> florian: ? equal to 1.0 and thats not an integer<br> <astearns> ack fserb<br> <TabAtkins> s/?/10e-1/<br> <jarhar> florian: problem by serializing with scientific notation in the first place, tabs proposal makes sense to me given thats the case<br> <jarhar> fantasai: alternative would be to not serialize with scientific notation?<br> <jarhar> TabAtkins: we already have widepsread usage of that<br> <jarhar> fantasai: but it doesn't rountrip right?<br> <florian> s/problem by serializing/we got into this problem by serializing<br> <jarhar> TabAtkins: its broken right now but we produce scientific notation. very easy to get scientific notation into your css by accident via cssom methods. it will string them into that if theyre big<br> <jarhar> TabAtkins: thats why we need sign nodes anywya, but its easy to produce it via js and hard to avoid doing that<br> <TabAtkins> s/sign nodes/scinot/<br> <jarhar> astearns: proposed resolution is to add this parse time evaluation of scientific notation as integers<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10238#issuecomment-2165368549 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 June 2024 11:21:43 UTC