| 02:36 | <sideshowbarker> | Question for any and all: When you want to copy the text of a particular algorithm from a spec and preserve the step numbers, what mechanism do you use? I mean specifically, how do you get around the problem that if you just select the text from the HTML version of the spec, and you try paste into some other place, the step numbers aren’t preserved. |
| 07:31 | <sideshowbarker> | For input type=number with a user-input value of +1, shouldn’t the expected result per-spec be 1, and not the empty string? |
| 07:32 | <sideshowbarker> | I’m looking at the tests at https://wpt.fyi/results/html/semantics/forms/the-input-element/number.html, and specifically at the {value: "+1", expected: "", testname: "value = +1"} and {value: "1.", expected: "", testname: "value ending with '.'"} tests in https://github.com/web-platform-tests/wpt/blob/master/html/semantics/forms/the-input-element/number.html |
| 07:34 | <sideshowbarker> | …and I’m looking at what the spec says at https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):valid-floating-point-number — which is:
|
| 07:37 | <sideshowbarker> | …where “best representation of the number representing the user's selection as a floating-point number” is: the string obtained from running the JS ToString(n) operation on the parsed number n. |
| 07:38 | <sideshowbarker> | So, given all that, it would seem like for the relevant WPT tests, the expected result for the input +1 would be 1 — and not the empty string. |
| 07:40 | <sideshowbarker> | …since 1 would seem like the “best representation” of +1 |
| 07:40 | <sideshowbarker> | And similarly for the input 1. — it seems like the test expectation for that should 1 |
| 07:42 | <sideshowbarker> | And similarly for all the other tests in lines 38–42 of https://github.com/web-platform-tests/wpt/blob/0cb2ae37c74f1509a03f3837fe80b2d7b5794e31/html/semantics/forms/the-input-element/number.html#L38-L42 that are checking for values with leading spaces |
| 07:45 | <sideshowbarker> | Or to put it in implementation terms, if the input string value isn’t a “valid floating-point number”, then the implementation should change the value to result of parsing/converting it into a double, and then running the JS ToString() operation on double. |
| 07:47 | <sideshowbarker> | But… that‘s not what the WPT tests expect, and that’s not what any of Gecko, Blink, or WebKit do — instead, the tests expect the empty string to be returned if the input value doesn’t match the “valid floating-point number” requirements, and Gecko, Blink, and WebKit do return the empty string. |
| 07:50 | <sideshowbarker> | And even just looking at it intuitively: What user benefit would there be to changing the user input +1 into the empty string, rather than just coercing it into 1? Who would find that behavior desirable? |
| 08:49 | <annevk> | sideshowbarker: I almost never copy a set of steps I think. So usually it's something like "and as step 3.23.1 says ..." |
| 08:49 | <annevk> | Domenic: is https://github.com/whatwg/html/pull/5841 back in your queue? |
| 08:52 | <annevk> | sideshowbarker: for the +1 case. Are you sure it's end user input? Because that would be up to the user agent. If it's something that ends up running through https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values that algorithm would explain why + leads to rejection. |
| 08:57 | <Ms2ger> | I guess you can/should read "the number representing the user's selection" as being UA-defined - that is, if I type "+1" into an input, "the number representing the user's selection" is 1 |
| 09:00 | <Ms2ger> | Note that the “best representation of the number representing the user's selection as a floating-point number” algorithm explicitly takes a number, not a string - so you can't pass it "+1" |
| 09:02 | <sideshowbarker> | Note that the “best representation of the number representing the user's selection as a floating-point number” algorithm explicitly takes a number, not a string - so you can't pass it "+1" ToString() operation |
| 09:06 | <sideshowbarker> | sideshowbarker: for the +, right? Instead it explicitly says to ignore the leading +, and not return an error, doesn’t it? |
| 09:14 | <sideshowbarker> | Note that the “best representation of the number representing the user's selection as a floating-point number” algorithm explicitly takes a number, not a string - so you can't pass it "+1" |
| 09:16 | <Ms2ger> | Possibly - or do something more lenient. Note that UAs aren't required to present this as a text field |
| 09:16 | <sideshowbarker> | Well more concretely maybe what the spec should instead do is to explicitly say, “…the number that results from applying the rules for parsing floating-point number values to the user’s selection” |
| 09:17 | <sideshowbarker> | But if any of this is UA-defined, then it seems like we should not have explicit WPT tests for it at all |
| 09:18 | <Ms2ger> | But wait, nothing in the wpt is actually testing what happens when a user inputs something |
| 09:19 | <Ms2ger> | It's just calling the HTMLInputElement.value setter |
| 09:19 | <sideshowbarker> | Ah, I see. Then I guess I need to look at the requirements for that intead |
| 09:21 | <sideshowbarker> | aha OK yeah |
| 09:21 | <Ms2ger> | Should have looked at the test first :) |
| 09:21 | <sideshowbarker> | sorry for the noise… the spec is actually very clear |
| 09:21 | <sideshowbarker> | https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):value-sanitization-algorithm |
| 09:21 | <sideshowbarker> |
|
| 09:22 | <Ms2ger> | Yeah, that's somewhat harsh |
| 09:28 | <sideshowbarker> | Seems so yeah — I don’t see what the benefit of that is to end users. But anyway, I will uncritically implement it as spec’ed |
| 09:53 | <Ms2ger> | No end users involved on this code path, though - just authors |
| 10:16 | <annevk> | sideshowbarker: oh you're right, it's just that it's not valid when serialized, which apparently is what the specification looks at? Not sure I'd have defined it this way |
| 10:27 | <sideshowbarker> | sideshowbarker: oh you're right, it's just that it's not valid when serialized, which apparently is what the specification looks at? Not sure I'd have defined it this way |
| 10:27 | <sideshowbarker> | But I guess the problem with that is, the relevant spec isn’t freely available |
| 11:30 | <annevk> | I could see us relying on JS, maybe. Not sure if that's been looked at closely. (Although I do vaguely recall this conversation happening every now and then.) |
| 13:12 | <Ms2ger> | annevk: ^ |
| 20:26 | <Richard Gibson> | Question for any and all: When you want to copy the text of a particular algorithm from a spec and preserve the step numbers, what mechanism do you use? ecmarkup manually adds hidden counter text to support this use case: https://github.com/tc39/ecmarkup/blob/main/js/listNumbers.js it would probably make sense to do something similar in bikeshed-based specs |