Mvc: Support new HTML5 input types

[jbagga]

The following HTML5 input types are currently not handled

• [ ] 1. color
• [ ] 2. number (with input restrictions like min, max, required etc.) - @dougbu Can you confirm that this is the case?
• [ ] 3. range
• [ ] 4. search

[dougbu]

@jbagga exactly what type of support were you looking for? Many datatypes map to type="number" already.

type="color" is probably not supported because .NET Core lacked System.Drawing.Color. Not sure if that datatype is included in .NET Standard 2.0. If it's now included, we should fix that gap compared to MVC 5.x.y.

Not sure what .NET datatypes could or should be mapped to type="range" or type="search". Do you have suggestions?

Separately, input restrictions on type="number" can be added easily by passing htmlAttributes into Html.TextBox[For](...) or adding the HTML attributes to an <input/> tag helper.

[jbagga]

cc @Eilon

[Eilon]

Indeed, the question ultimately is "How can MVC provide additional value with respect to these HTML5 input type." For example, one type of value-add is that when MVC sees you're using a System.DateTime or System.DateTimeOffset, it automatically renders <input type="datetime-local">, and sets the value= attribute to the correct format.

So, for the 4 input types above, what, if anything, can MVC do to provide added value?

[dougbu]

So, for the 4 input types above, what, if anything, can MVC do to provide added value?

MVC 5.x.y automatically used type="color" and a custom format for the Color datatype. Since Color is available in .NET Standard 2.0 (according to apisof.net), we could do the same in ASP.NET Core.

What we've got for type="number" seems fine. But, I guess we could treat type="range" almost identically to type="number" and type="search" the same as type="text".

(I've crossed out earlier comments about not knowing what to do with those last two types.)

[jbagga]

There are some new input restrictions in HTML5 like max, min, required, pattern and step. Maybe number should support those

[dougbu]

@jbagga I mentioned the following above:

Separately, input restrictions on type="number" can be added easily by passing htmlAttributes into Html.TextBox[For](...) or adding the HTML attributes to an <input/> tag helper.

What type of support are you proposing? Why is the current support for those attributes aka restrictions insufficient?

[Rabadash8820]

@jbagga @dougbu I can confirm the issues with type="number" inputs. I made a comment on the Tag Helper docs topic back in September saying as much:

It appears that adding a RangeAttribute to a numeric property and using the asp-validation-for tag helper generates the jQuery Validate attributes (data-val-range-min and -max), but does not add HTML5 min and max attributes. This is kind of silly, as users can then enter invalid values just by clicking the little arrows in the input. What's worse, if I manually add min and/or max, then the ErrorMessage from my RangeAttribute is replaced by the default jQuery Validate message. Is there no built-in tag helper that will add both the validation AND html5 attributes?

Glad to see that there is now an issue open for this. Consider this my +1 :)

[mkArtakMSFT]

@danroth27, should this go into 2.2 milestone?

[danroth27]

Yes I think so.

[mkArtakMSFT]

@danroth27, moved this out to Backlog. Please let me know if you believe this should be part of 2.2.

[veikkoeeva]

@Eilon

Indeed, the question ultimately is "How can MVC provide additional value with respect to these HTML5 input type."

I recorded some ideas at https://gitter.im/aspnet/Home?at=5b54e9969ddf5f4aad00002b, quoting

I was just dabbling around with Razor Pages and came to wonder if there's been discussion about the validation framework more fully embracing HTML5 style, e.g. https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation and especially the Constraint Validation API? I'm wondering this since I didn't find anything (maybe I just have wooden eyes) specifically besides aspnet/Mvc#7035 (which I linked to other issues at https://github.com/aspnet/Mvc/issues/6024#issuecomment-406893635). It looks like I could add things to label asp-for, input asp-for, span asp-validation-for, but it also feels like it'd be more useful to bake this in the framework. Further, it'd look useful to bake in things such as https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions.

Originally I had trouble with localization and numbers and it led me to aspnet/Mvc#6024. Then I thought that OK, maybe I could inherit/reimplement _Tag Helper_ to work so that if the parent locale is en, then use input type numeric -- and it escalated as written. Now I'm thinking if I should record and issue or if there's been discussion already I'm just unable to spot.

The motive here is that this is linked to localization and mobile usage, both of which are quite essential and as-is, the built-in _Tag Helpers_ could help more. :)

<edit: I'll add here that I found https://github.com/aspnet/jquery-validation-unobtrusive/ too and tried to see if there's something about, say, setCustomValidity(message) (see https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation -> _Validating forms using JavaScript_), but I didn't find anything. In any event, in the mobile-first world it appears (I'm not an expert developer) this stuff enhances user experience appreciably.

Partially I'm thinking this also from the perspective of annotating DTOs as much as possible and sharing things through OpenAPI/Swagger docs, not only in Razor Pages (or ASP.NET MVC Core).

<edit 2: A related issue implementing HTML5 validation handling: https://github.com/aspnet/Mvc/issues/8097.

<edit 3: I'll link to the roadmap for version 2.2, which seems to be metadata generation and use. See at https://github.com/aspnet/Announcements/issues/307#issue-335571873.

The 'north star' for this version is to generate better metadata about your app and use that data to make your dev experience better and more productive. This is the main focus for 2.2.

I'd say this would be squarely that too, though MVC and not API. I'll stop adding edits now. :)

[Eilon]

@veikkoeeva thanks for the additional info. I've moved this out of the Backlog so that the team can re-consider it for a future release (no guarantees!).

[veikkoeeva]

@Eilon Much appreciated. I just amended the issue (it's still poorly phrased, but maybe the intention comes through) with few further notes. A bit of a grain of salt here, I'm not a web development expert so what I'm considering might be a bit too much, but I really would like to have especially better mobile experience (mobile first and all that) and it looks like the HTML5 tech is the way to go there. Then comes accessibility things, and that could also, in fact, be useful on physical world (as in work site, cyber-physical setting), where the attention cannot be fully in the device and the device is more just helping. For this the accessibility stuff could be useful, and useful to get something just out-of-the-box.

[veikkoeeva]

Here's a brilliant take on native form validation (conclusion: it doesn't work): https://medium.com/samsung-internet-dev/native-form-validation-part-3-8e643e1dd06. The article has several other good points that could be useable for MVC Core. If nothing else, gives well argumented reasons to actions.

[Rabadash8820]

@mkArtakMSFT what does super-triage mean?? sounds dangerous

[Eilon]

@Rabadash8820 not too dangerous 😄 It's just a marker label for us that we need to review it again soon.

[mkArtakMSFT]

Closing this for now as we have no plans to cover this in the near future.

[Rabadash8820]

@mkArtakMSFT I read that as "we have no plans to follow standards in the near future".

There's been a lot of good discussion here about how supporting HTML5 input types _should_ be implemented, and how that implementation could be done. Are you really going to kill that conversation by saying Microsoft has "no plans to cover this"? Isn't the point of the "needs design" label that this Issue requires design and may need to remain open for some time?

I can accept that there are no tangible implementation plans in place _right now_, and that this Issue may remain open for a while longer, but closing the Issue now makes it feel like the ASP.NET Core team isn't even talking about this feature. If that's not the case, then this Issue needs to remain open, or another one should be opened and put on the backlog, and linked from here. If that _is_ the case, and the team isn't talking about supporting HTML5 input types...well...that needs to not be the case lol. Standards _have_ to be supported, in my opinion, otherwise we developers end up stuck in ASP.NET world, unable to use any other modern, standards-compliant tools/libraries.

TL;DR I love ASP.NET Core and don't mean to insult you or your team. I want to see this product be the best it can be, and I think you're sending the wrong message by closing this Issue.

[danroth27]

@Rabadash8820 We also believe that supporting open standards is important and we certainly didn't mean to indicate otherwise by closing this issue. When we looked at this issue we concluded that there wasn't anything additional that we needed to do in MVC to support these input types. As far as we know there isn't anything that blocks you from using these input types and there didn't seem to be anything of sufficient value that we could do in MVC to make it easier to use these input types, so we closed the issue. If you think there is something significant that we could do here we would be happy to review your proposals and reconsider. At the same time please understand that our team has limited resources and we often have to choose where to focus our efforts.

[Rabadash8820]

@danroth27 It's true that we can manually set <input> type and validation attributes in our *.cshtml files, so I guess it's true that MVC _does_ currently support HTML5 input types, as it would any future HTML tag. However, the above issues with certain input type (e.g., color) and validation attributes (e.g., min and max) not being automatically generated by asp-for tag helpers are still outstanding, requiring a lot of duplication between ValidationAttributes and client-side validation rules. Perhaps a new Issue should be opened since, according to this Issue's title, this Issue has been closed, but most of the actionable requests within this Issue have not.

[hubekpeter]

@danroth27 I'm new to .net and C#, but if I understand this correctly, this is just a simple extension to the RangeAttributeAdapter's AddValidation method. It simply doesn't make sense to implement custom validation attribute if there's one already in place which works perfectly but missing one minor thing.
Something like this:
MergeAttribute(context.Attributes, "min", _min);
MergeAttribute(context.Attributes, "max", _max);

[https://github.com/aspnet/Mvc/blob/release/2.2/src/Microsoft.AspNetCore.Mvc.DataAnnotations/Internal/RangeAttributeAdapter.cs]