-
Notifications
You must be signed in to change notification settings - Fork 210
Add new category for typeable form controls with normalization #1910
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
P.S. I wasn't sure if I should group the common logic of non-typable and typeable or not. |
| A <dfn>typeable form control with normalization</dfn> | ||
| is an [^input^] element | ||
| whose [^input/type^] attribute state | ||
| requires that user-provided values be normalized before being assigned to the element's value attribute. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should probably be more specific and define how exactly the input values should be normalized for date types. Also I wonder if it could be made optional because I imagine some existing clients would want to keep the current non-normalized behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now the implementation accepts non-normalized values (MM-DD-YYYY format correctly), so we could keep the current implementation and just modify it to convert normalized values (YYYY-MM-DD or YYYYMMDD formats) to MM-DD-YYYY.
This way It would be techincally optional and require minmal implementation changes, but I'm not sure if this would be appropriate to add to the spec
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be something like this:
<p>
A <dfn>typeable form control with normalization</dfn>
is an [^input^] element
whose [^input/type^] attribute state
supports multiple input formats that should be converted to a consistent target format before being sent to the element.
This applies to <code>type="date"</code> and <code>type="datetime-local"</code> elements,
where both normalized (YYYY-MM-DD or YYYYMMDD) and traditional (MM-DD-YYYY) formats are accepted.
|
@sadym-chromium @whimboo @jgraham do you have a suggestion on how to best tackle input in the date fields? Should WebDriver require normalizing the input format? |
Gentle Reminder. |
| <li><p>If <var>element</var> is not <a>mutable</a> return | ||
| an <a>error</a> with <a>error code</a> <a>element not | ||
| interactable</a>. | ||
| <li><p>Normalize the <code>value</code> to conform to the expected input format of <var>element</var>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please define the "Normalize to the expected input format".
|
The approach LGTM, but the expected formats should be strictly defined. |
I was thinking of doing something like this: I chose to normalize to MM-DD-YYYY and MM-DD-YYYYTHH:MM:SS since that seems to be what Chromium expects as input, which keeps changes minimal, but I'm not sure if this is the correct approach. |
Does Chromium not support ISO 8601? I think that we should follow that format. |
No, I tried inputting a date in ISO format, but the output was garbage (e.g. '2025-10-06' → '51006-02-02'). |
|
@whimboo I believe the accepted format is dependent on the user locale. |
|
@Holo-xy I wonder if using locale overrides https://www.w3.org/TR/webdriver-bidi/#command-emulation-setLocaleOverride works around this issue? I imagine if you the locale is fixed, there could be no need for additional normalization? |
I don't think so, as I tested with different locales (US, UK, CH, which cover the three formats) and it didn't seem to make a difference. |
There looks to be a popular demand for normalized date and datetime-local as seen in 1470 and 42322342.
This introduces a new category to make the expected behavior explicit.
Preview | Diff