[Web API] Differentiate number values that can be integers vs real numbers

[hamishwillee]

Specs refer to properties as integers and floating-point (real) numbers of various sizes - long, double etc., while the web APIs use the JavaScript Number type for almost all these cases.

In MDN docs we use "integer" to refer things that are integers, and "number" for things that are defined in the spec as any kind of floating point (a defacto standard).

Is this reasonable for real numbers? Should we be explicit and refer to them as "real numbers" or "floating point numbers"?

The case that made me question this was a string:

A number indicating the round-trip time, in seconds, for the connection described by the pair of candidates for which this RTCIceCandidatePairStats object offers statistics.

This is a real number and under our rules it is not ambiguous (if it was an integer it would say so). But would a reader make that assumption if they did not know the convention. Does it matter?

[pransh15]

I believe it's reasonable and aligns well with common JS usage, where the number type can represent integers and floating-point numbers. This only works well if the rules are clear and consistently applied.

However, for cases like the "round-trip time," adding brief clarifications where ambiguity might arise could be beneficial. Since "number" can imply either integer or floating-point, specifying "a real number" or "a floating-point number" in situations where precision or expectations around decimals are crucial could bring clarity without altering your broader conventions. This way, readers unfamiliar with the convention would still understand when a decimal(as opposed to an integer) is intended.

Maybe we can also include a short note in the guidelines making this convention explicit to avoid confusion.