Skip to content
This repository has been archived by the owner on Jul 30, 2019. It is now read-only.

Shwetank 194 clarify input date onchange #1325

Merged
merged 5 commits into from
Apr 3, 2018

Conversation

shwetank
Copy link
Contributor

@shwetank shwetank commented Apr 2, 2018

Fixes issue 194

Clarifies how and when change event should fire to date input types.

@shwetank shwetank requested a review from chaals April 2, 2018 09:14
Copy link
Collaborator

@chaals chaals left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of editorial changes requested.

@@ -3761,6 +3761,8 @@
When the element is <a>suffering from a step mismatch</a>, the user agent may round the
element's <a for="forms">value</a> to the nearest <a for="dates">date</a> for which the element would not <a>suffer from a step mismatch</a>.

The <code>change</code> event is fired whenever the user has selected a new <a>valid date string</a> - which can be triggered when the user enters a new value. When a user changes a new <a>valid date string</a> or uses a stepping function to increment or decrement a part of the overall date string, user agents may apply a timeout to determine that the changed value is no longer intermediate. At the completion of such timeout, <code>change</code> must fire. Moving focus away from the date picker component or explicitly confirming with a button are unambigous triggers that the user wants the value changed, and <code>change</code> should fire on all such cases if the new date value is different than the previous one.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpicking: Can you please break up the line to around 100 characters? At the end of HTML elements is often a good spot.

I would move the "when the user changes, or is stepping though" clause to the end.

In that piece I don't think it should say that user agents must fire anything, just make it clear that it is possible they do so.

@chaals
Copy link
Collaborator

chaals commented Apr 3, 2018

You could tweak this a bit further, e.g. breaking lines into smaller chunks (the primary use case for that is for reading github diffs without horizontal scrolling).

But equally, feel free to merge as is if you don't have time for that now. It's not the highest priority issue :)

@shwetank shwetank merged commit 6c6a382 into master Apr 3, 2018
@@ -3761,6 +3761,13 @@
When the element is <a>suffering from a step mismatch</a>, the user agent may round the
element's <a for="forms">value</a> to the nearest <a for="dates">date</a> for which the element would not <a>suffer from a step mismatch</a>.

The <code>change</code> event is fired whenever the user selects a new <a>valid date string</a>.
Moving focus away from the date picker component or explicitly confirming with a button are unambigous triggers that the user wants the value changed.
The event should be fired on all such cases if the new date value is different than the previous one.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/should/must/

This is a real conformance requirement...

@edent edent deleted the shwetank-194-clarify-input-date-onchange branch October 18, 2018 09:17
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants