[Editorial] Simplify the ends-in-a-number checker

[karwa]

I believe this should be functionally identical to what exists already.

IMO it's more intuitive, because it means the "ends in a number" checker first checks to see if the label is all digits (which obviously means it is a number), and then checks to see if it's a number containing non-digit characters (i.e. just hex numbers). I think it's clearer and more obvious than the current wording, which first invokes the more expensive IPv4 number parser and then adds a second check because of particular failure conditions.

Writing it this way in the spec gives implementors assurance that this is a safe optimisation.

---

Preview | Diff

[karwa]

@annevk Do you think this is reasonable?

[achristensen07]

FWIW, this is how I implemented it. Calling the IPv4 parser is too slow. I just checked for all digits and 0x or 0X and hex digits.

[annevk]

Yeah this seems fine, modulo some formatting nits. I would like some way to preserve the 09 example, but perhaps the way to do that is to have an example table for hosts similar to what we have for URLs at https://url.spec.whatwg.org/#urls, at https://url.spec.whatwg.org/#hosts-(domains-and-ip-addresses).

[annevk]

Now that I created #661 I feel more comfortable landing this. I'll address the nits.

[annevk]

Looking at this again this basically means deferring when "09" is handled. This seems okay, but I'd like @domenic or @TimothyGu to weigh in.

[domenic]

Tested in whatwg-url and works, modulo the ambiguity with the note.

[annevk]

Looking at this again this basically means deferring when "09" is handled.

FWIW, I realized this is wrong as the former text does the same as the new text (the first step would get failure and then the second step would return true). Fortunately the new notes are correct despite this misunderstanding with regards to the implications.

[karwa]

Thanks very much for landing this @annevk!