1283023 - Implement the step attribute for <input type=month>

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Comment 1

[Jessica Jong [:jessica] (inactive)]

I find our implementation of input type=date's step attribute a little bit confusing when step is not an integer. In our current implementation, we 'round' the step to the LCM of step and the scale factor to avoid a step mismatch. So, for example, if step=0.9, the actual step used 9 days [1], but if step=1.5, the actual step used is 3 days. I think this is not very trivial for users.

I tested Chrome and it seems that they just round the step value, if step=1.2, the actual step used is 1 day, if step=1.5, the actual step used is 2 days.

The spec just says: "When the element is suffering from a step mismatch, the user agent may round the element's value to the nearest date for which the element would not suffer from a step mismatch." [2]


[1] http://hg.mozilla.org/mozilla-central/file/711963e8daa3/dom/html/test/forms/test_step_attribute.html#l204
[2] https://html.spec.whatwg.org/multipage/forms.html#date-state-(type=date)

Comment 2

[Jessica Jong [:jessica] (inactive)]

Olli, may I know your comment about comment 1? Thanks.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Jessica Jong [:jessica] from comment #1)
> So, for example, if step=0.9, the actual step used 9 days [1], but
> if step=1.5, the actual step used is 3 days. I think this is not very
> trivial for users.
I don't quite understand how we get these results, but if so, sounds really weird and changing it to be closer to what Chrome does is totally fine.

Bug 769359 doesn't explain why things have been implemented the way they have.

Comment 4

[Jessica Jong [:jessica] (inactive)]

(In reply to Olli Pettay [:smaug] from comment #3)
> (In reply to Jessica Jong [:jessica] from comment #1)
> > So, for example, if step=0.9, the actual step used 9 days [1], but
> > if step=1.5, the actual step used is 3 days. I think this is not very
> > trivial for users.
> I don't quite understand how we get these results, but if so, sounds really
> weird and changing it to be closer to what Chrome does is totally fine.
> 
> Bug 769359 doesn't explain why things have been implemented the way they
> have.

From the comment [1], it says:
      // In case this is a date and the step is not an integer, we don't want to
      // display the dates corresponding to the truncated timestamps of valueLow
      // and valueHigh because they might suffer from a step mismatch as well.
      // Instead we want the timestamps to correspond to a rounded day. That is,
      // we want a multiple of the step scale factor (1 day) as well as of step.

It's not wrong, it's just kind of confusing for users. What Chrome does is simpler, but it implies it does allow non-integer step, cause it's always rounded to an integer.

I'll file a separate bug for type=date step attribute if we are going to change it, type=month scale factor is 1 (month), so I think we won't be having this problem.

[1] http://hg.mozilla.org/mozilla-central/file/feaaf1af1065/dom/html/HTMLInputElement.cpp#l7507

Comment 5

[Jessica Jong [:jessica] (inactive)]

Actually, type=month does suffer from the same problem when step is not an integer, so I filed Bug 1289272 and will work on it first.

Comment 6

[Jessica Jong [:jessica] (inactive)]

Attachment: patch, v1.

Comment 7

[Jessica Jong [:jessica] (inactive)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=57d6acd3dbfc

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4ec3149b367b
Implement the step attribute for <input type=month>. r=smaug

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/4ec3149b367b