rfc: use a big-number library for the NumberField component about fast

[rajsite]

Some thoughts:

• I don't know if it is captured explicitly, but conceptually my mental model of fast foundation is that the components should align well with the browser native elements. I should be able to swap an input type=number element with a web component extending NumberField and have it be compatible.
  • The proposal discussed here wouldn't be compatible (it's edge cases would behave different from a native input type=number since it is not based on doubles). I think it would be nice if it was opt-in / a superset of the NumberField api. Maybe a mode / format / numeric-type attribute that could be set to bignumber or a separate BigNumberField implementation.
• It would be nice to not need to depend on an external library if not needed. Could native BigInt be used instead? It is widely supported in browsers. If not for some reason could it be optional in some way to have the dependency added to applications? Some ideas:
  • separate base class BigNumberField
  • the compose method can take an implementation as an optional argument
• We are interested in having a much wider range of numeric representations. U8, U16, U32, U64, U128, I8, I16, I32, I64, I128, F32, F64, F128, FixedPoint, ComplexF32 (i.e. F32 + F32i), ComplexF64 (i.e. F64 + F64i), ComplexF128 (i.e. F128 + F128i). Is it possible to design a base class / method such that custom numeric implementations can be implemented?
• "very large numbers, exponential notation, and localization," we are interested in many different formatting options, i.e. hex views, octal views, binary views, localized units (currency, time), leading zeros, absolute / relative time formats. To a certain extent, essentially all printf style format codes.

[radium-v]

Addressing your points @rajsite:

• For new components, we define their specs to match parity with existing built-in components and other prior work or patterns (if any). Since NumberField already has its own spec, any modifications to the class must be fully compatible with that spec. For the most part, using an alternative number library within the internals of the component shouldn't change any functionality with regard to that spec or its public API. Any externally-facing API changes to a component's spec are considered to be major/breaking changes.
• I agree that using built-in JS would be better - BigInt could work but would require extra math, which I'm not particularly great at. Considering the maintainers of the TC39 decimal proposal acknowledge big.js as a source of inspiration (MikeMcl/big.js#207), we may just need to let that proposal bake for a while.
• Custom numeric representations might be beyond the scope of this particular RFC, but can definitely be considered for our NumberField. From the HTML Standard:

  If the user agent provides a user interface for selecting a number, then the value must be set to the best representation of the number representing the user's selection as a floating-point number.