Skip to content

Add new category for typeable form controls with normalization#1910

Open
Holo-xy wants to merge 1 commit into
w3c:masterfrom
Holo-xy:typeable-normalization
Open

Add new category for typeable form controls with normalization#1910
Holo-xy wants to merge 1 commit into
w3c:masterfrom
Holo-xy:typeable-normalization

Conversation

@Holo-xy

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

Copy link
Copy Markdown

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


This change is Reviewable

@Holo-xy

Holo-xy commented Jul 6, 2025

Copy link
Copy Markdown
Author

P.S. I wasn't sure if I should group the common logic of non-typable and typeable or not.

Comment thread index.html
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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

OrKoN commented Sep 11, 2025

Copy link
Copy Markdown
Contributor

@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

Holo-xy commented Nov 10, 2025

Copy link
Copy Markdown
Author

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

Comment thread index.html
<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
Copy Markdown
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
Copy Markdown
Contributor

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

@Holo-xy

Holo-xy commented Nov 13, 2025

Copy link
Copy Markdown
Author

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

whimboo commented Nov 13, 2025

Copy link
Copy Markdown
Contributor

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

Holo-xy commented Nov 13, 2025

Copy link
Copy Markdown
Author

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

OrKoN commented Nov 13, 2025

Copy link
Copy Markdown
Contributor

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

@OrKoN

OrKoN commented Nov 13, 2025

Copy link
Copy Markdown
Contributor

@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

Holo-xy commented Nov 13, 2025

Copy link
Copy Markdown
Author

@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