DefaultHtmlGenerator should attempt to properly format values for <input type="date"> and <input type="time">

[tuespetre]

When binding a DateTime model value to an <input type="date" /> element or an <input type="time"> element, one would expect the output to be a valid date string according to the HTML5 specification.

Likewise, when binding a DateTime or TimeSpan model value to an <input type="time" /> element, one would expect the output to be a valid time string according to the HTML5 specification.

[dougbu]

@tuespetre the formatting is done at a relatively low level without knowledge of the chosen type. So using the current culture makes sense in some cases.

Use Html5DateRenderingMode.Rfc3339 to unconditionally use "valid" date and time formats. Depending on the scope you need for the fix, set the following to this value:

• HtmlHelper.Html5DateRenderingMode (identical to the following)
• ViewContext.Html5DateRenderingMode
• MvcOptions.HtmlHelperOptions.Html5DateRenderingMode

[rynowak]

@Eilon @dougbu - is this something we want to consider making the default setting for this release?

[dougbu]

Might be nice.

I'm unsure about the cases where we generate <input type="text" value="{formatted date / time}" .../> e.g. for @Html.TextBox(). Though inconsistencies get hard to explain, might be better to limit this enhancement to the <input> tag helper, @Html.Display() and @Html.Editor() -- specifically where we know the type will be "date", "time" or similar.

[danroth27]

@javiercn Please test the behavior out on a bunch of browsers to see what the user experience will be like.

[javiercn]

@danroth27 @dougbu Here is the behavior with RFC3339 enabled on latest browsers

[dougbu]

@danroth27 FYI the type="text" cases look as they do because the <input> tag helper ignores the Html5DateRenderingMode when generating that type.

@javiercn which of the browsers show smart controls e.g. a calendar tool for some of the fields? Which fields for those browsers?

[javiercn]

@dougbu
Chrome for date and datetime-local
Edge date, datetime-local and time.
Firefox None
IE None

[dougbu]

Hmm, does that mean we're using the wrong format for type="datetime"?

---

More generally, it definitely appears we wouldn't uglify much if we made Html5DateRenderingMode.Rfc3339 the default for the <input> tag helper.

The same is mostly true for the default templates @Html.EditorFor() uses. The caveat there is users will get odd behaviour if they include { type = "text" } in additionalViewData's htmlAttributes key when generating HTML for (say) a DateTimeOffset field. We could make EditorFor() almost as careful about the final type value but that's a new complication. Suggest we ignore the corner case unless someone complains. (<input> has other reasons to be careful about the final type value.)

@Html.TextBox() and @Html.TextBoxFor() currently ignore the Html5DateRenderingMode completely. I suggest that's fine because this helper is intentionally low-level. Users can choose the format and the type attribute value explicitly.

Finally should we remove the Html5DateRenderingMode type completely? Or should we change the related HtmlHelper, HtmlHelperOptions and ViewContext properties to provide some way to turn off the new default?

[javiercn]

@dougbu I wouldn't think that adding type=text in extra HTML attributes is a common use case for Html.EditorFor. At that point a user would either:
a) write the input tag by hand
b) write a custom editor template to handle the rendering.

But what's more important, I think that the default implementation works for most of our users.

[javiercn]

@dougbu @danroth27 @rynowak So, what do we want to do here?

[dougbu]

I wouldn't think that adding type=text in extra HTML attributes is a common use case for Html.EditorFor.

What I said was that we should ignore the corner case. However we need buy-in from the @Eilon's of the world.

what do we want to do here?

I lean toward completely removing Html5DateRenderingMode. My questions are about the details if we go that route.