implement HTMLInputElement stepUp, stepDown,valueAsDate, valueAsNumber, list

[pshaughn]

https://html.spec.whatwg.org/multipage/input.html#htmlinputelement defines these and corresponding WPT tests under html/semantics/forms/the-input-element test them.

Servo also has commented-out IDL for valueHigh and valueLow; these were at one time proposed for use in <input type="range" multiple>, but the spec now says multiple doesn't apply to range and they can be removed entirely.

[pshaughn]

I need guidance about something to make sure I'm not reinventing a wheel or adding a needless dependency: Several of these algorithms want to convert a parsed time to time-since-1970 (in milliseconds and in months), and I'm guessing something Servo already has a dependency on can do that, but I don't know what.

Dates also have another wrinkle; https://html.spec.whatwg.org/multipage/input.html#time-state-(type=time):concept-input-value-string-number wants to be able to invoke "parse a time string" on a DOMString, which isn't defined at all, and https://html.spec.whatwg.org/multipage/input.html#date-state-(type=date):concept-input-value-string-number wants to invoke "parse a date string", which is defined but isn't public. DOMString is going to need some new public methods to accommodate these (and "parse a time string" is going to be a bit complicated, since a "time component" can have either two or three fields instead of the exact three a "date component" has).

[pshaughn]

stepUp, stepDown, and valueAsNumber are sort of working for non-chronological values in pshaughn@494dd76 but not in PR-worthy shape yet.

@Eijebong's idea in cb87025 got past a problem that seems like it could be a spec issue: https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token step 8 defines no order-of-operations for appending attributes, and browser/WPT behavior seems to assume all attributes are appended "simultaneously" and then can see each other during their setter side effects, so that for example <input type="range" min=1 value=2 max=3> sees both min=1 and max=3 while it's setting value to 2.

[pshaughn]

pshaughn@eab3398 is much closer on getting the non-chrono steppable types (number and range) working.

I am having one problem where if min=0.1 and step=0.1 I end up resolving the stepping to a string value of 0.6000000000000001 (fourteen zeroes) instead of the test-expected 0.6. I'm not sure yet if this is because of:

• Rust f64 significand rounding direction differing from Javascript
• Rust f64 stringification differing from Javascript
• a subtle algorithmic error that's letting in a rounding error that a better algorithm would prevent
• a test expecting floating-point equality where the reality of floating-point handling means no such equality is guaranteed

[pshaughn]

On the chronological front, I see script is already importing https://docs.rs/chrono/0.4.10/chrono/ for week-of-year computations and media-fragment timestamp parsing; this crate seems like it probably includes what we need for the necessary back-and-forth between milliseconds and datetimes to make chronological value stepping and valueAsDate work.

[pshaughn]

valueAsDate wasn't hard to get to compile once I figured out how to get Date objects in and out of jsapi code, but the only tests in WPT about it are for error conditions and basic IDL binding status. I'm going to have to add more tests to know it actually runs. (web-platform-tests/wpt#20960)

[pshaughn]

pshaughn@6eb8e2a I've added a test for valueAsDate; do I just check it in here and let upstreaming to WPT happen that way, or should I make a PR at wpt/wpt about it?

[jdm]

Upstreaming as part of PRs that do the implementation work is the preferred mechanism.