Intent to Implement and Ship: Reversed range support for <input type=time>

[Joey Arhar]

Contact emails

jar...@chromium.org

Explainer

see summary below

Spec

https://html.spec.whatwg.org/C/#has-a-reversed-range

Skipping tag review because this is already specced.

Summary

According to the HTML spec, <input type=time>, which allows users to input time in hours, minutes, and seconds, should support reversed ranges because it has a defined maximum of "23:59:59". A reversed range is when the input has a min and max attribute where the max is less than the min, and in this state, the input should allow values which are less than the min or greater than the max, but not in between them.

This functionality has been described in the specification for many years, but has not been implemented in Blink.

Link to “Intent to Prototype” blink-dev discussion

none

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Demo link
https://input-reversed-range.glitch.me/

https://chromium-review.googlesource.com/c/chromium/src/+/2005372

Debuggability

DevTools currently has no features regarding form validation. This change in validation logic will not make form validation harder to debug. I added a custom validation message for the reversed range case to help users understand easier.

Risks

Interoperability and Compatibility

WebKit doesn't have <input type=time> implemented, and this small change to our implementation will not change that. Should they choose to implement <input type=time> someday, then I'd imagine they would follow this new logic.

Firefox now has an open bug for this feature and there are no signs that they won't implement it as well: https://bugzilla.mozilla.org/show_bug.cgi?id=1608010

Edge: No signals

Firefox: In development https://bugzilla.mozilla.org/show_bug.cgi?id=1608010

Safari: No signals - WebKit hasn't implemented <input type=time>

Web / Framework developers: https://github.com/web-platform-tests/wpt/pull/21103

Ergonomics

I don't know of any APIs that this feature will be used in tandem with.

This API will not have any impact on performance.

Activation

The use counter for the <input type=time> element is quite low, about 0.015%. I think it would be a good idea to update the MDN article for <input type=time> to include an explanation of this validation logic, especially since there is already a "Validation" section: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time#Validation

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

wpt coverage was added in this PR: https://github.com/web-platform-tests/wpt/pull/21103

https://wpt.fyi/results/html/semantics/forms/constraints/form-validation-validity-rangeOverflow.html

https://wpt.fyi/results/html/semantics/forms/constraints/form-validation-validity-rangeUnderflow.html

Entry on the feature dashboard

I don't think this feature needs an entry because it is a small change.

[Jeffrey Yasskin]

On Mon, Jan 27, 2020 at 12:28 PM Joey Arhar <jar...@chromium.org> wrote:

Contact emails

jar...@chromium.org

Explainer

see summary below

Spec

https://html.spec.whatwg.org/C/#has-a-reversed-range

Skipping tag review because this is already specced.

Summary

According to the HTML spec, <input type=time>, which allows users to input time in hours, minutes, and seconds, should support reversed ranges because it has a defined maximum of "23:59:59". A reversed range is when the input has a min and max attribute where the max is less than the min, and in this state, the input should allow values which are less than the min or greater than the max, but not in between them.

This functionality has been described in the specification for many years, but has not been implemented in Blink.

It looks like it hasn't been implemented anywhere. Should the specification be fixed instead of the implementations?

Link to “Intent to Prototype” blink-dev discussion

none

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Demo link
https://input-reversed-range.glitch.me/

https://chromium-review.googlesource.com/c/chromium/src/+/2005372

Debuggability

DevTools currently has no features regarding form validation. This change in validation logic will not make form validation harder to debug. I added a custom validation message for the reversed range case to help users understand easier.

Risks

Interoperability and Compatibility

WebKit doesn't have <input type=time> implemented, and this small change to our implementation will not change that. Should they choose to implement <input type=time> someday, then I'd imagine they would follow this new logic.

Firefox now has an open bug for this feature and there are no signs that they won't implement it as well: https://bugzilla.mozilla.org/show_bug.cgi?id=1608010

Edge: No signals

Firefox: In development https://bugzilla.mozilla.org/show_bug.cgi?id=1608010

This bug doesn't show anyone actually working on a patch or saying the project would accept a patch if offered, so it doesn't count as "In development".

 

Safari: No signals - WebKit hasn't implemented <input type=time>

Web / Framework developers: https://github.com/web-platform-tests/wpt/pull/21103

I only see one person supporting this on that issue. Has anyone else noticed?

 

Ergonomics

I don't know of any APIs that this feature will be used in tandem with.

This API will not have any impact on performance.

Activation

The use counter for the <input type=time> element is quite low, about 0.015%. I think it would be a good idea to update the MDN article for <input type=time> to include an explanation of this validation logic, especially since there is already a "Validation" section: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time#Validation

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

wpt coverage was added in this PR: https://github.com/web-platform-tests/wpt/pull/21103

https://wpt.fyi/results/html/semantics/forms/constraints/form-validation-validity-rangeOverflow.html

https://wpt.fyi/results/html/semantics/forms/constraints/form-validation-validity-rangeUnderflow.html

Entry on the feature dashboard

I don't think this feature needs an entry because it is a small change.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwLjwpEneW5fhJo4DF32G%3DxVdTzQQNtoiE6mV0s0v_%2B5nw%40mail.gmail.com.

[Mounir Lamouri]

Like Jeffrey, it's unclear that Mozilla is actually working on this from the bugzilla entry and whether web developers are asking for this change. Even if having Mozilla on records supporting the change would be better, it seems unlikely to be controversial. It may just be a matter for them to come around to do this and having WPT will help.

Something I'm curious about is whether we do anything special for min/max on time elements on mobile and whether this would be compatible. In other words, do we tell Android that the time widget should only allow values from `min` to `max` and, if we do, whether the widget would allow `min` > `max`.

Finally, given the size of the change, an Intent to Implement and Ship may be appropriate?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnHph6Ro%2BYHFTY81aJoS0NMafzRKmk7eg0mA7i6b6yyjA%40mail.gmail.com.

[Joe Medley]

"I don't think this feature needs an entry because it is a small change."

Actually you do. And if you'd used Chrome Status to generate your intent, as is the current practice, you'd have gotten an entry for free.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B-LeH-G9k4DvN2HFwQrbc9%3DrUR%3DQA9i9zwGC2Fo_xqqtuDgig%40mail.gmail.com.

[Joe Medley]

Also, do you have a tracking bug I can follow?

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Mathias Bynens]

The tracking bug is linked to from the CL Joey mentioned: https://bugs.chromium.org/p/chromium/issues/detail?id=1040344

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG-ZKUZo4csx2erCWkfw92gK-oX--0TdYBppj2YzvqqtsA%40mail.gmail.com.

[Joey Arhar]

Thanks for the feedback everyone! It sounds like there is more interest in removing this from the spec than implementing it, so I made a spec issue to consider doing so: https://github.com/whatwg/html/issues/5240

[Mounir Lamouri]

I do not know if I would characterise the received feedback as suggesting to drop the change entirely. And actually, I just realise that I misread the Intent and it's actually Implement & Ship and not just Implement.

I would be interested to see how Android widgets are impacted per my question before but it otherwise lgtm. It's a small and reasonable change with WPT that anyone can easily implement if they implemented support for <input type=time>.

-- Mounir

[Joey Arhar]

I briefly did some testing on an Android device with my WIP patch, and it looks like there are two native time pickers: one that includes seconds, and another that doesn't. The one that includes seconds is used when you specify a step attribute like this: <input type=time step=1>.

The one that doesn't have seconds, which looks like an analog clock, doesn't seem to prevent you from choosing any values when you have any min and max.

The one that does have seconds does account for the min and max by not displaying invalid values. With my WIP patch, it lets you pick any value when using a reversed range, so its not unusable for reversed ranges but should be updated for reversed ranges.

[Jeffrey Yasskin]

Since I have little imagination ... what's a reversed range useful for? Why would it be something other than a bug in a site?

Thanks,

Jeffrey

[Mounir Lamouri]

My understanding is that because time range is from 00:00 to 23:59, a min-max range cannot cross midnight. By allowing min > max, you allow websites to express that a time can be for example between 19:00 to 01:00 which wouldn't otherwise be possible because min=19:00 and max=01:00 is reversed.

-- Mounir

[Jeffrey Yasskin]

Thanks! That makes sense.

[Boris Zbarsky]

On 1/27/20 8:22 PM, Joey Arhar wrote:
> Firefox: In development https://bugzilla.mozilla.org/show_bug.cgi?id=1608010

Fwiw, the bug was not filed by anyone actively working on this code and
the prioritization triage assigned it to "backlog" (which is one step
above "won't work on this, but would accept a patch", and does not imply
any concrete plans to work on it).

So "in development" is not really accurate; "no signals" is closer.

-Boris

[Joey Arhar]

Thanks for the feedback everyone!

> It looks like it hasn't been implemented anywhere. Should the specification be fixed instead of the implementations?

I filed a spec issue here https://github.com/whatwg/html/issues/5240 which was only met with support for implementing the feature.

> This bug doesn't show anyone actually working on a patch or saying the project would accept a patch if offered, so it doesn't count as "In development".

> "in development" is not really accurate; "no signals" is closer.

I agree that Firefox has no signals. I will reflect this in the chromestatus.com entry.

> what's a reversed range useful for?

As Mounir mentioned, it is useful to have a time range that crosses midnight. More context in the original spec bug here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=7688

> if you'd used Chrome Status to generate your intent, as is the current practice, you'd have gotten an entry for free.

I created a chromestatus.com entry: https://www.chromestatus.com/feature/5347108783652864

I would like to move forward with this intent and ask for API owner approval.

[Chris Harrelson]

Thanks for these updates!

LGTM1

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2BMRm9yf4HjUR-kWYQdyF7xBJefnWtqDTQbfF1F3-tYTQ%40mail.gmail.com.

[Yoav Weiss]

On Mon, Feb 3, 2020 at 2:08 PM Joey Arhar <jar...@chromium.org> wrote:

Thanks for the feedback everyone!

> It looks like it hasn't been implemented anywhere. Should the specification be fixed instead of the implementations?

I filed a spec issue here https://github.com/whatwg/html/issues/5240 which was only met with support for implementing the feature.

> This bug doesn't show anyone actually working on a patch or saying the project would accept a patch if offered, so it doesn't count as "In development".

> "in development" is not really accurate; "no signals" is closer.

I agree that Firefox has no signals. I will reflect this in the chromestatus.com entry.

What would be the compat impact of a developer setting a min that's larger than the max on Firefox users?

 

> what's a reversed range useful for?

As Mounir mentioned, it is useful to have a time range that crosses midnight. More context in the original spec bug here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=7688

> if you'd used Chrome Status to generate your intent, as is the current practice, you'd have gotten an entry for free.

I created a chromestatus.com entry: https://www.chromestatus.com/feature/5347108783652864

I would like to move forward with this intent and ask for API owner approval.

On Thu, Jan 30, 2020 at 3:45 PM Boris Zbarsky <bzba...@mit.edu> wrote:

On 1/27/20 8:22 PM, Joey Arhar wrote:
> Firefox: In development https://bugzilla.mozilla.org/show_bug.cgi?id=1608010

Fwiw, the bug was not filed by anyone actively working on this code and
the prioritization triage assigned it to "backlog" (which is one step
above "won't work on this, but would accept a patch", and does not imply
any concrete plans to work on it).

So "in development" is not really accurate; "no signals" is closer.

-Boris

--

[Joey Arhar]

Firefox currently will say all values are invalid when min > max.

I have also found that Safari on iOS implements <input type=time>, and would need its validation to be updated as well, as opposed to Safari/WebKit on desktop which has not implemented <input type=time>.

[Yoav Weiss]

On Tue, Feb 4, 2020 at 2:06 PM Joey Arhar <jar...@chromium.org> wrote:

Firefox currently will say all values are invalid when min > max.

I have also found that Safari on iOS implements <input type=time>, and would need its validation to be updated as well, as opposed to Safari/WebKit on desktop which has not implemented <input type=time>.

I see. In that case, what's our developer story around that?

Is there some way for developers to feature detect support or lack thereof?

[Joey Arhar]

It requires several lines of javascript, but here's a way to detect support:

const input = document.createElement('input');
input.type = 'time';
input.min = '23:00';
input.max = '01:00';
input.value = '23:59';
if (input.validity.valid && input.type === 'time') {

  // <input type=time> reversed range supported

} else {

  // <input type=time> reversed range unsupported

}

I don't currently have a developer story for this. Do you have any recommendations?

[Yoav Weiss]

LGTM1

On Tue, Feb 4, 2020 at 3:27 PM Joey Arhar <jar...@chromium.org> wrote:

It requires several lines of javascript, but here's a way to detect support:

const input = document.createElement('input');
input.type = 'time';
input.min = '23:00';
input.max = '01:00';
input.value = '23:59';
if (input.validity.valid && input.type === 'time') {

  // <input type=time> reversed range supported

} else {

  // <input type=time> reversed range unsupported

}

I don't currently have a developer story for this. Do you have any recommendations?

That seems like a reasonable approach. We should document it, to encourage developers to use this pattern. Places for that documentation could be on the relevant MDN value or a self-answered question on stack overflow (or both!).

Feel free to ping me (on or off list) if you feel like you'd need help on that front.

[Chris Harrelson]

On Wed, Feb 5, 2020 at 3:04 PM Yoav Weiss <yo...@yoav.ws> wrote:

LGTM1

LGTM2 actually, I took LGTM1. :)

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEg-EBT6SSwKZks%3DHh3RzcoKV1RK2X8-CRAz9%2BYAomWUdg%40mail.gmail.com.

[Daniel Bratell]

LGTM3 - but please make sure developers are aware of the Mozilla situation and the workaround so people don't go around and write pages that won't work at all in other browsers. You can use the chrome status entry to at least get information to the beta blog post.

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2BMRm9yf4HjUR-kWYQdyF7xBJefnWtqDTQbfF1F3-tYTQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[Joey Arhar]

Thanks for the LGTMs!

>That seems like a reasonable approach. We should document it, to encourage developers to use this pattern. Places for that documentation could be on the relevant MDN value or a self-answered question on stack overflow (or both!).

> Feel free to ping me (on or off list) if you feel like you'd need help on that front.

I'd love to update the MDN article for <input type=time>. How do I update it?

Could you show me an example of a self-answered question on stackoverflow or provide any more guidance?

> LGTM3 - but please make sure developers are aware of the Mozilla situation and the workaround so people don't go around and write pages that won't work at all in other browsers. You can use the chrome status entry to at least get information to the beta blog post.

Is this the beta blog you're referring to? https://chromereleases.googleblog.com/

How do I use chromestatus to get the information to the blog post?

[Yoav Weiss]

On Thu, Feb 6, 2020 at 4:37 PM Joey Arhar <jar...@chromium.org> wrote:

Thanks for the LGTMs!

>That seems like a reasonable approach. We should document it, to encourage developers to use this pattern. Places for that documentation could be on the relevant MDN value or a self-answered question on stack overflow (or both!).

> Feel free to ping me (on or off list) if you feel like you'd need help on that front.

I'd love to update the MDN article for <input type=time>. How do I update it?

It's a wiki, so once you log-in, you should be able to edit it. (I'm not sure if there's an approval process or not)

 

Could you show me an example of a self-answered question on stackoverflow or provide any more guidance?

https://stackoverflow.com/help/self-answer

 

> LGTM3 - but please make sure developers are aware of the Mozilla situation and the workaround so people don't go around and write pages that won't work at all in other browsers. You can use the chrome status entry to at least get information to the beta blog post.

Is this the beta blog you're referring to? https://chromereleases.googleblog.com/

How do I use chromestatus to get the information to the blog post?

+Joe Medley can probably help you with that.

[Joey Arhar]

Some updates:

• I have merged the patch, which will launch in M82.
• I updated the MDN article for <input type=time>, explaining what the current support is and how to do feature detection in a new "Making min and max cross midnight" section: https://wiki.developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time$revision/1608939
• I contacted Joe Medley about the beta blog post
• I updated the chromestatus entry to say it will be enabled by default in M82
• A comment was added to the firefox bug showing that a code review has been started in firefox.
  I should probably update the firefox status in the chromestatus entry from "no signals" to "in development", right?

[Boris Zbarsky]

On 2/27/20 4:39 PM, Joey Arhar wrote:
> * A comment was added to the firefox bug
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1608010> showing that

> a code review has been started

> <https://phabricator.services.mozilla.com/D64416> in firefox.

> I should probably update the firefox status in the chromestatus
> entry from "no signals" to "in development", right?

Yes, that would makes sense.

-Boris

[Yoav Weiss]

Awesome work, thank you! :)