Keystone-classic: Render HTML 5 aware input element types
For example, given:
email: {type: Types.Email},
Then the Admin UI rendered input field should be:
<input autocomplete="off" name="fieldA" value="" type="email" class="FormInput" data-reactid=".1.$=10.0.0.3.1:$fieldA.1:0.0">
Where it is currently:
<input autocomplete="off" name="fieldA" value="" type="text" class="FormInput" data-reactid=".1.$=10.0.0.3.1:$fieldA.1:0.0">
This issue should probably enumerate all other fields that should be HTML 5 type aware and handle them all. See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
DEV NOTE
This should be pretty easy to do. Field types use the elemental's FormInput component to render input fields. You can pass it the type as a prop. For example, for email inputs update EmailField.js as follows:
<FormInput type="email" ...
webteckie
All 21 comments
I added a property type: this.props.type to props in renderField() (Field.js) which looks to have set input types to email, color, and URL fields. Adding type="email" to EmailField.js did not do anything since those values are only rendered when noedit is true. Unless you're suggesting adding renderField to EmailField?
Should it also be rendering element types that aren't supported on certain browsers? Date and time inputs are not supported on Firefox.
pll33
on 1 Apr 2016
@pll33 is there any adverse behavior when a browser (e.g., firefox with Date/time) encounters the HTML 5 valid types? Or does it behave properly? @JedWatson not sure what direction to give here. I'm incline to say that if there's no adverse behavior (i.e., browser falls back to some reasonable HTML 4 type value like type="text") then I'd say just add the support. But it's your call!
webteckie
on 2 Apr 2016
One thing I did notice is that the browser might be giving hints about
incorrect email addresses before the form handler had a chance to add an
error. If you care a lot about look&feel, that may not be desired, but I
think that in the case of the Keystone admin UI it's fine.
On Sat, Apr 2, 2016 at 2:53 PM Carlos Colon [email protected]
wrote:
@pll33 https://github.com/pll33 is there any adverse behavior when a
browser (e.g., firefox with Date/time) encounters the html 5 valid types?
Or does it behave properly? @JedWatson https://github.com/JedWatson not
sure what direction to give here. I'm incline to say that if there's no
adverse behavior (i.e., browser falls back to some reasonable HTML 4 type
value like type="text") then I'd say just add the support. But it's your
call!—
You are receiving this because you are subscribed to this thread.Reply to this email directly or view it on GitHub
https://github.com/keystonejs/keystone/issues/2535#issuecomment-204709805
Wout.
(typed on mobile, excuse terseness)
wmertens
on 2 Apr 2016
@wmertens can the browser's validation somehow be preempted?
webteckie
on 2 Apr 2016
Yes, set the type to text :-D
On Sat, Apr 2, 2016, 3:24 PM Carlos Colon [email protected] wrote:
@wmertens https://github.com/wmertens can the browser's validation
somehow be preempted?—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/keystonejs/keystone/issues/2535#issuecomment-204716140
Wout.
(typed on mobile, excuse terseness)
wmertens
on 2 Apr 2016
Come to think of it, I think it's better NOT to do this, and instead implement awesome input fields for each type. Then you get a consistent cross-browser experience.
wmertens
on 2 Apr 2016
We can close it if doesn't make sense...@JedWatson / @jossmac any comments on this before we do so?
webteckie
on 2 Apr 2016
…or the in-between solution would be to put the html5 type on all the
fields that we don't have a custom input for yet.
On mobile, this might result in a numbers-only keyboard where appropriate,
not sure how that is picked by the browser
On Sat, Apr 2, 2016, 7:21 PM Carlos Colon [email protected] wrote:
We can close it if doesn't make sense...@JedWatson
https://github.com/JedWatson / @jossmac https://github.com/jossmac
any comments on this before we do so?—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/keystonejs/keystone/issues/2535#issuecomment-204760905
Wout.
(typed on mobile, excuse terseness)
wmertens
on 2 Apr 2016
@webteckie I did a quick test between Chrome 49 and Firefox 45: Firefox treats unsupported input types as text, and it happens to do some sort of validation on email and URL inputs by adding a CSS pseudo-class. Chrome will do the same thing and falls back to a text input for datetime.
pll33
on 2 Apr 2016
I think we should add input types, we can still improve them but I'm pretty sure having them there helps a11y.
mxstbr
on 3 Apr 2016
This should be done, however you will want to add the novalidate attribute to each field as as mentioned above, you dont' want the browsers native client side validation to kick in. a) Because its difficult to style consistently cross browser and b) because you probably wan to handle that logic within the client side app anyway.
Its advantageous to use these correct types though -- for one, it brings up the best keyboard on mobile devices.
adamscybot
on 6 Apr 2016
@adamscybot that's great! PR anyone?
webteckie
on 6 Apr 2016
@webteckie Been working on a few things. Are there any HTML5 input types that shouldn't be added if they change how the current custom field works?
When I added type="time", I had to change the input and parse formats from h:mm:ss a to HH:mm:ss (valid W3 examples). type="color" changes the entire text field into a color picker button (pic) which makes picker next to it redundant. Date doesn't have any adverse effects since it looks like the format is already correct.
pll33
on 10 Apr 2016
The "correct" way to handle form field validation is with the HTML5 constraints API and setCustomValidity(); see the MDN article. You can embrace the native error popup tips, or add the novalidate attribute to the form tag. The validation API is still available, it is just a way of disabling the native error tips so you can display your own. We were able to remove a lot of complexity in a recent project by using this simple API and the CSS :invalid state.
jaydenseric
on 11 Apr 2016
@pll33 the following is what I suggest since it seems that we may have to do a lot more work to support with HTML 5 aware types. If anyone has comments on this approach then please shout :-)
- [ ] Add the novalidate attribute to all forms.
- [ ] Add any relevant type attribute to all form input fields. If doing so causes unexpected side effects then do not add the type attribute for such fields, yet. Instead, let's create a new issue to address those independently. Reference such issues in this one.
- [ ] Add support for custom field validation messages and/or invalid field state. The flash message would probably already contain enough information about any validation issues but it may make sense to still flag the fields which failed validation for easier.
webteckie
on 11 Apr 2016
I highly recommend using redux-form, it allows specifying both sync and
async validation, and makes it all very easy.
The Html5 validation API is pretty useless, it doesn't work in my phone on
recent Chrome, for example.
On Mon, Apr 11, 2016, 3:26 AM Carlos Colon [email protected] wrote:
@pll33 https://github.com/pll33 the following is what I suggest since
it seems that we may have to do a lot more work to work with HTML 5 aware
types. If anyone has comments on this approach then please shout :-)
- [] Add the novalidate attribute to all forms.
- [] Add any relevant type attribute to all form input fields. If
doing so causes unexpected side effects then do not add the type attribute
for such fields, yet. Instead, let's create a new issue to address those
independently. Reference such issues in this one.- [] Add support for custom field validation messages and/or invalid
field state. The flash message would probably already contain enough
information about any validation issues but it may make sense to still flag
the fields which failed validation for easier.—
You are receiving this because you were mentioned.Reply to this email directly or view it on GitHub
https://github.com/keystonejs/keystone/issues/2535#issuecomment-208109479
Wout.
(typed on mobile, excuse terseness)
wmertens
on 11 Apr 2016
@wmertens so perhaps replace the 3rd task above with redux-form? Does it also make sense to wait until the admin UI refactoring is done before tackling this redux-form task? I think the first two tasks can still be done, right? @JedWatson @mxstbr can you weigh in on this?
webteckie
on 11 Apr 2016
The third one is definitely not possible, as the flash messages don't exist anymore in the form they used to before – that will highly likely need to wait. Same goes for redux-form, which I'm not 100% convinced we should use, depends on if we decide to integrate Redux. (probably)
Adding relevant types to the inputs should be good to go!
mxstbr
on 11 Apr 2016
@pll33 do you have or can you take ownership of this issue and carry on support for the first two tasks above? The 3rd task we will evaluate further. If you can't please let us know so someone else can take it on. Thanks!
webteckie
on 14 Apr 2016
@webteckie Yeah no problem, I can take ownership on this. I'll reference issues with the color and time fields later today.
pll33
on 14 Apr 2016
Closing this for now, as the basic ones are done. More advanced ones discussed in #2636!
mxstbr
on 29 Apr 2016
Related issues
jacqueslareau
·
5Comments
stennie
·
5Comments
Twansparant
·
5Comments
celiao
·
4Comments
josephg
·
4Comments
Most helpful comment
This should be done, however you will want to add the
novalidateattribute to each field as as mentioned above, you dont' want the browsers native client side validation to kick in. a) Because its difficult to style consistently cross browser and b) because you probably wan to handle that logic within the client side app anyway.Its advantageous to use these correct types though -- for one, it brings up the best keyboard on mobile devices.