Skip to content

Conversation

@Holo-xy
Copy link

@Holo-xy Holo-xy commented Jul 6, 2025

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

@Holo-xy
Copy link
Author

Holo-xy commented Jul 6, 2025

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.
Copy link
Contributor

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.

cc @whimboo @jgraham @sadym-chromium

Copy link
Author

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

Copy link
Author

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.

@OrKoN OrKoN requested review from sadym-chromium and whimboo July 30, 2025 06:56
@Holo-xy Holo-xy requested a review from OrKoN August 20, 2025 09:25
@OrKoN
Copy link
Contributor

OrKoN commented Sep 11, 2025

@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?

@Holo-xy
Copy link
Author

Holo-xy commented Nov 10, 2025

@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>.
Copy link
Contributor

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".

@sadym-chromium
Copy link
Contributor

The approach LGTM, but the expected formats should be strictly defined.

@Holo-xy
Copy link
Author

Holo-xy commented Nov 13, 2025

The approach LGTM, but the expected formats should be strictly defined.

I was thinking of doing something like this:

     <li><p>Normalize the <code>value</code> to conform to the expected input format of <var>element</var>.
      <ul>
        <li><p>For <code>type="date"</code> inputs, the <code>value</code> may be provided in <code>YYYY-MM-DD</code>, <code>YYYYMMDD</code>, or <code>MM-DD-YYYY</code> formats,
        and must be normalized to <code>MM-DD-YYYY</code>.
        <li><p>For <code>type="datetime-local"</code> inputs, the <code>value</code> may be provided in <code>YYYY-MM-DDTHH:MM:SS</code> or <code>MM-DD-YYYYTHH:MM:SS</code> formats,
        and must be normalized to <code>MM-DD-YYYYTHH:MM:SS</code>.
      </ul>
     <li><p><a>Set a property</a> <code>value</code> to <var>text</var>

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.

@whimboo
Copy link
Contributor

whimboo commented Nov 13, 2025

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.

@Holo-xy
Copy link
Author

Holo-xy commented Nov 13, 2025

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').

@OrKoN
Copy link
Contributor

OrKoN commented Nov 13, 2025

@whimboo I believe the accepted format is dependent on the user locale.

@OrKoN
Copy link
Contributor

OrKoN commented Nov 13, 2025

@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?

@Holo-xy
Copy link
Author

Holo-xy commented Nov 13, 2025

@whimboo I believe the accepted format is dependent on the user locale.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants