Add support for HTML5 input types
Please add support for html5 input types such as:
type=datetime, email, number, tel, url, etc
Currently, the kentico textboxes only support single-line, multi-line and password. Trying to create form controls that utilize any of the other textmode types (such as phone, email, number, datetime, url etc, etc) does not work.
This will improve UX, particularly when filling out forms on mobile platforms, and is requested more and more often.
The email, password, datetime-local and tel input types are all supported, but the submit and reset types are not.
Adam Harvey commented
You're not going to include email, password, datetime-local or tel? Those are the the ones we need the most!
Hello all, we are currently working on this one. I will keep you updated via this comment feed.
Nothing was mentioned about this at the 404 conference, but I really hope it made its way silently into Kentico 10 :(
Dimitris Rakopoulos commented
I would accept some sort of temporary solution from Kentico. Or a way of doing this.
It is unacceptable that this is not there out of the box.
For example placeholders are so commonly used....
As a workaround yes a custom control can be created but I believe it may create risk if anything changes on the kentico front.
If kentico provides the facility for the most basic of types for example email fields should use type=email then it's a start. However, I do think the different types should be provided by default.
Maybe some sort of override of the type to insert some custom markup to give flexibility to the form control. At the moment, anything we do, the type just turns into text so there's no other option to go down the custom control route.
It's really difficult to even explain this to clients who want an AA website let alone an AAA one in terms of accessibility and UX side of things. They're probably thinking really?! The most basic types turning into type=text.
Currently, the best practice for the HTML5 ready web part and form control is to write the custom one and use the preferable markup. I believe this is how you deal with this issue right now, is that correct?
Our current form controls render only a few input types from the list, but you can find there the basics.
I'm wondering whether it would be a solution to create a set of form controls (e.g. date-input form control, week-input form control) with the rest of the types and put them on our marketplace. This way you can use those form controls also in older versions of Kentico.
The best practice for the web parts is still to write a custom one.
Dave Nelson commented
All of the input types should be supported and kept up-to-date. Here is the W3C page that contains all of the types.
Ralph Spandl commented
2016: Now we also bumped into this wall. As many times mentioned here before, it is required for AA and even more for mobile devices, when offering application forms on mobile devices.
Suneel Jhangiani commented
Personally I think at least the 'placeholder' can be added quickly and easily. However, I would also like to see this integrated into BizForms (ie. the Form Builder).
Jonathan Ballinger commented
Just to clarify, this is mainly a front end issue. When you deliver a website using a mobile friendly theme, the lack of html 5 controls really jumps out on devices. Fields that should be number only are showing the entire keyboard, and email addresses also show the full keyboard instead of the email input field.
I work for a disability charity so, as you can imagine, the lack of HTML 5 controls is causing us issues, as the HTML 5 controls have been flagged up as being more disability friendly, yet we're unable to use what should be a simple piece of functionality.
Thanks for the update.
The big issue here is Accessibility. Especially, for clients who specialise in accessibility where they're expecting different layouts for different types of fields. This helps both users who have a disability but also businesses too.
When we tell this to the client, they're not very impressed. Purely because it should be available right from the start especially with a platform this large and complex. Regardless if you're using a tablet, phone or desktop. I believe it should be available everywhere but obviously I understand its not as easy it sounds.
The most important areas, for me and others, are the forms and webparts. I say webparts because at times custom dev is needed. To be honest, the foundations of the cms controls should be updated to allow the control to be HTML5 compatible. This will hopefully enable us to use it wherever we like.
Lastly, I hope this gets implemented asap since it is quite important for many websites but again I understand it takes time. Like everything else!
where do you miss the inputs the most? Kentico web parts? Which ones? Kentico forms? Administration?
Please help us to find the most important parts of the system.
I totally agree with W Lin and Jonathan. It wasn't as straightforward for me either when it was requested.
Since more and more people are using touch devices, it becomes quite imperative to display the correct keyboard layouts. Obviously, this depends on the input type in the markup.
This would be really helpful especially for when a user is filling out forms as W Lin has mentioned.
Jonathan Ballinger commented
Agreed. This is something we've been asked to implement and it's not as straightforward as it should be. In this day and age, HTML5 inputs should be commonplace.
Jason Sherrill commented
The ability to correctly designate field types would be the highest priority I would assign to this in this era of responsive design and forms that should be mobile optimized.
The html5 stuff is a requirement even for yesterday's CMS. The markup-related stuff is simply a convenience as the current table-based markup is completely useless.
We sure plan to go with new technologies, including HTML5, we just need to prioritize. Could you please comment on order in which you would say these should be addressed ...?
Oh, yeah... and AJAX support which doesn't use an update panel.
Option to render HTML5 form elements, types (date, url, tel, etc), placeholder text, required attribute, etc.
Markup configuration options - affects behavior of "Generate Default Layout" behavior
Form wrapper (e.g. NONE, DIV, FIELDSET)
Form input/label group wrapper
Form label wrapper
Form input wrapper
- Render a hidden blank text field... which must ALWAYS be blank