Better labelling for Date time form select elements

This actually looks more like a usability bug than a feature reqest. We may be able to get this in a 8.0.1 bug fix I think.

The screenshots posted so far are for the Seven theme.

Bartik looks like this...

Which component should this be filed under? It's not theme specific.

Maybe Field UI is the right component for this.

Actually providing the option to have select lists for this may be the acual bug because this doesn't seem useful to me at all. But I'm sure we can come up with a use case where this is what you want.

What about removing the option to not have a default value for these? Another option is to have "Year", "Month", "Day", etc. as the first values in each list and show those as selected when no default date is specified.

Don't think I agree that a blank canvas is clearer than a prefilled date. They’d be equally "wrong", but with a default date you can at least recognize the pattern.

Adding values of -Year-, -Month- on top of each list seems like the quickest reasonable fix indeed.

This could be a dup of #1918994: Improve Datetime and Daterange Widget accessibility.

Changing to 8.1.x since we will be adding strings, so this can't be in a patch update.

I think adding -Year-, -Month-, etc is a good solution here (IS should be adjusted). Likely also need to adjust the validation on these, and add some test coverage to make sure the validation doesn't break in the future.

Here's a fix that uses the #empty_option property for Select elements to address this issue. It doesn't add the - as suggested, but here's what it looks like just using the element title:

The IS seems up-to-date.

I'm not sure if we need to write a test for this, unless we just want to verify that the #empty_option is properly used for each date part?

The fail is unrelated.

Moving back to NR b/c #2724871: Random failure in \Drupal\migrate_drupal_ui\Tests\d7\MigrateUpgrade7Test.

I think I like this approach. That class is really weird, though. It's hard to read that w/o noting all of the quirks.

Core is pretty inconsistent about '- Foo -' vs 'Foo' for #empty_option; there may be more uses with the hyphen. Personally, I think the UX is better here without (since they are all in a row). @yoroy, what do you think?

Not seeing coverage for #empty_option anywhere else, but it couldn't hurt to add to DateTimeFieldTest::testDatelistWidget() if the xpath isn't that difficult.

I think the pattern is to have the added hyphens, but I'm fine with leaving them out here. The labels are already wider than most of the acutal values, so I prefer compactness over consistency here.

This adds a test for the labels. I also added a new method to the AssertContentTrait for finding select options via their text rather than their value.

Played with this applied. Nice simple approach that leverages the FAPI for what it is meant for. We are not introducing new strings, so this should be eligible for 8.1.x under https://www.drupal.org/core/d8-allowed-changes per

- non-disruptive bug fixes, where the bug is under the "Incorrect or misleading user interface text" category

Setting RTBC, assuming this will also pass under 8.1.x.

Nice bug fix. Committed 7d3ab5a and pushed to 8.1.x and 8.2.x. Thanks!