tc39
Existing decimal usage in the web platform
I stumbled across https://github.com/WebKit/WebKit/blob/main/Source/WebCore/platform/Decimal.cpp today. This is apparently used for <input>, see https://github.com/WebKit/WebKit/blob/main/Source/WebCore/html/InputType.cpp.
I think a goal of this effort needs to be that it can serve as a replacement of this existing Decimal class (or expose the existing class to script).
This relates to #4 but seemed different enough to warrant its own issue.
I didn't know about this use of decimal numbers inside WebKit -- thanks for the tip!
Interesting, looks like Chrome has this as well: https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:third_party/blink/renderer/platform/wtf/decimal.h
Looks like this operates with a 16-bit exponent and 64-bit mantissa. This probably continues the pattern that I noted in a decimal presentation a while ago: Everyone has different decimal details, and users don't run into these edge cases and don't care.
Oh, I guess Mozilla contains the same code, used in the same way for input elements! https://searchfox.org/mozilla-central/search?q=symbol:T_mozilla%3A%3ADecimal&redirect=false
Are these bits of the respective code bases under active development? It seems to me that this might be one of those things that one gets right once, and then it's good for a long time. I'd be happy to contact the developers to tell them about IEEE 754 Decimal128, which is the approach that we've settled on for proposal-decimal. I'd love it if there could be some tie-in between the JS engine world and the UI part of a browser. It seems possible.
(Relatedly, but adjacent:
Coming from the UI angle, one thing that occurs to me would be to have some built-in stepper functionality in the proposal-decimal. I.e. an API function that, starting with, say, the decimal 1.28, would yield 1.29, 1.30 (notice the trailing zero), 1.31, etc. Same for a step-down function. This is actually part of IEEE 754 Decimal128 that currently doesn't exist in the proposal-decimal API.)
<input type=number> is not actively undergoing changes. It's interesting that https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number) describes it in terms of floating-point, which is obviously not what implementations are doing. Not entirely sure how that mismatch came to be.