Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Lack of normalisation in date formats #1470
Comments
|
This means for <!doctype html>
<meta charset=utf-8>
<title>date</title>
<input type=date />
<script>
const date = document.querySelector("input");
date.value = "2019-12-11";
console.log(date.value); // prints "2019-12-11"
</script>To my big surprise we don’t seem to have any interoperability tests for this, which means the behaviour you are observing with chromedriver is likely a bug. |
|
Thanks @andreastt - I'll have a re-read of that part of the spec tomorrow (10pm here in Aus). Should I report this as a bug against chromedriver then? |
|
Unrelated to this issue, but I've noticed another missing case: sendKeys should accept NULL to clear modifiers, as discussed in php-webdriver/php-webdriver#693. |
|
I fixed the definition of which form controls we should bypass using actions for in #1471. That should help explain the intention of the spec. The NULL character breaking to clear modifiers will consequently not be applicable to those elements we don’t use actions for. |
|
I have raised:
|
|
@andreastt, it would be really helpful if we could finalise this issue and 1471, however I think that the language in the patch on 1471 could be improved further. This issue was specifically raised to discuss the date input type, but it has not been specifically mentioned in 1471, and the discussion in https://bugs.chromium.org/p/chromedriver/issues/detail?id=3274 suggests that the language is still unclear - so much so that the folks at chromedriver do not think that there is consensus that the date element should be treated as non-typeable. |
|
(I am currently between jobs and will not have the capacity to work on this until further notice.) |
This is a bit of a weird one, so apologies in advance.
In chapter E. Index:
The display format for the date, and local date and time, input types is left to be implementation specific, meanwhile the value attribute is always normalised to
dd-mm-yyyy.The lack of standardisation makes it difficult to set the value using the element-send-keys endpoint (https://www.w3.org/TR/webdriver/#dfn-element-send-keys) as the keys sent mimic the display format.
As an example, if I set the value of a
dateelement to2012-12-25I can do so successfully on Firefox, but Chrome uses a different date format ofdd/mm/yyyyfor display. As a result my attempt to set the value leads to a garbage result of1225-12-20.I feel that there should be some part of the spec which dictates that the accepted values must be normalised in some way.
In the current state it is not possible to write a cross-browser way of setting the date using the sendKeys endpoint.