valueAsNumber for type=month should return the number of months since 1970-01?

[smaug----]

Per spec valueAsNumber should return milliseconds, but Chrome and Edge which support type=month seem to return number of months.
See also https://bugzilla.mozilla.org/show_bug.cgi?id=1278185#c6

I wonder why this was implemented against the spec in Chrome or has the spec changed accidentally after that or what. But anyhow, looks like we need to change the spec.

@tkent-google

[tkent-google]

AFAIK, this isn't an intentional violation. We might misread the specification, or the specification was changed after implementations.

https://www.chromestatus.com/metrics/feature/timeline/popularity/32
The usage of input[type=month] is very low. So,

• We can correct Blink implementation. I don't know about WebKit and Edge.
• We can change the specification.

[annevk]

The specification seemed to have this text at least as far back as 2009. Maybe Opera, which I suspect had the first implementation, did it wrong and others copied?

Changing the specification would be quite a bit of work, but returning the number of months might be more useful than returning a number of milliseconds. Especially since you can get the latter using valueAsDate.

[annevk]

Given that every browser that supports <input type=month>, including Mobile Safari, returns the same on https://dump.testsuite.org/html/input-month-valueasnumber.html we should just change the standard. It's not worth the churn at this point, although changing the standard will be annoying.

We should probably also check <input type=week> and such as they'll likely require similar changes.

[zcorpan]

In Presto I get 946684800000, FWIW.

[annevk]

Good old Rebel Opera doing the right thing and showing everyone how it's done from the grave. 😕

[annevk]

Okay, so actually, maybe this should be fixed. Mobile Safari and Chrome do return a millisecond number for type=week and type=date. That makes matters rather inconsistent. @hober, @tkent-google, what do you think?

[jessi3py-zz]

Note that, for type=week and type=date, the step scale factor is in milliseconds, only type=month is in months (no conversion needed), maybe that's why.

[annevk]

Yeah, that definitely does seem related (and somewhat weird). I asked @Hixie to weigh in.

[tkent-google]

I don't think we can change the behavior of input[type=date]. Its usage is much higher.

The usage of input[type=week] is very low. We can change its behavior. But I'm not sure we can make it similar to input[type=month] because the number of weeks in one year is not stable.

[annevk]

So I think the simplest way to fix this and align with contemporary implementations is to simply remove the "if the valueAsDate attribute applies" branch from the valueAsNumber getter and setter.

That seems to be what implementations are doing. I'll provide a PR. It's a little strange, but maybe as @tkent-google points out it's fine since only months are stable on a yearly basis. @Hixie also argued that the existing implementations were fine since you wouldn't typically use the controls together.