30

HTML5 added in the ability to better define client-side validation in forms without needing to use JavaScript. The concept already existed with attributes such as "maxlength" and "minlength". It's been extended with attributes such as "required" and "pattern". However, HTML5 has also defined limits on these attributes and WebKit browsers have implemented these restrictions (likely with Firefox and Opera not far behind).

The restrictions in question have to do with a form control's visibility when hidden by CSS / JavaScript using the display: none or visibility: hidden CSS rules. The restrictions are defined as:

4.10.7.1.1 Hidden state

When an input element's type attribute is in the Hidden state [...] The input element represents a value that is not intended to be examined or manipulated by the user.

[Also,]

  • The value IDL attribute applies to this element and is in mode default.
  • The following content attributes must not be specified and do not apply to the element: accept, alt, autocomplete, checked, dirname, formaction, formenctype, formmethod, formnovalidate, formtarget, height, list, max, maxlength, min, multiple, pattern, placeholder, readonly, required, size, src, step, and width.
  • The following IDL attributes and methods do not apply to the element: checked, files, list, selectedOption, selectionStart, selectionEnd, selectionDirection, valueAsDate, and valueAsNumber IDL attributes; select(), setSelectionRange(), stepDown(), and stepUp() methods.
  • The input and change events do not apply.

At first glance, it makes sense to say that validation shouldn't need to be performed on form controls that the user has no control over. And, for form's built using default form control elements, these make sense. But now, an issue has arisen with building remote form controls.

Neither HTML5 nor CSS3 (nor the major browsers) has made it much easier to style form controls. <select> elements are still greatly restricted in terms of styling and both <input> and <button> elements have annoyingly different styling rules (and for non-IE browsers, near impossible CSS browser-targeting). As such, when my designers want "pretty" form controls, they may need to be rebuilt using HTML, CSS, and JavaScript. The simulated control will remotely control the real control which is hidden by CSS. This applies to <select>, <input type="checkbox"> and <input type="radio"> elements for me, all of which cause an issue in WebKit browsers when given the required attribute.

Since the HTML5 specification states that certain attributes, such as required, cannot exist on hidden form controls, browsers will be required to respond to invalid attributes. WebKit browsers are responding by not submitting the form at all (and not triggering JavaScript's submit event). I am running into the error right now with a <select> element.

Chrome fails with this error to the console:

An invalid form control with name='element-name' is not focusable.

Safari fails by showing a grey bar at the bottom of the window with the message:

Please select an item in the list

So, my concern is whether HTML5 is too restricting or I am approaching this issue incorrectly. Either:

  1. HTML5's specification is flawed and adds an extra restriction without another solution. HTML5 assumes that if a form control is not visible, the user should not be able to interact with it. This prevents developers from utilizing HTML5's validation attributes for elements that we control remotely while leaving the original form control hidden. We still don't have the ability to create our custom controls using only CSS which requires that we still build them ourselves.
  2. I am handling remote form controls incorrectly. as I am using an "old" technique to solve a problem that very well may have been redefined, it's possible that my approach is outdated. It's also possible that, since WebKit are the only one handling this restriction at the moment, WebKit has a workaround for this that I haven't found yet.

The only workarounds that I can think of at the moment are to

  • Remove the restricted attributes whenever I dynamically hide a form control with JavaScript, which would mean that I sacrifice HTML5's validation,
  • Temporarily display and immediately hide the offending form controls, though I'm unsure when this would be done since the submit event is never fired and it's possible to submit a form without firing the click event on the submission button, or
  • Use the novalidate attribute, though I'd still lose the HTML5 validation.

So am I looking at this correctly or am I missing something?

Improve this question
3
  • Not a very helpful answer, but I’d suggest that you either don’t agreeing to implement form control designs that you can’t achieve via CSS, or don’t use HTML5’s validation attributes on hidden fields. Commented Aug 4, 2011 at 17:46
  • @PaulD I feel that this is a choice that shouldn't have to be made. HTML5 took so long because it had to be defined to work with the web in it's current state. In this case, we are forced to either get rid of our custom form controls or go back to HTML4 form handling. Either way, we aren't moving the web forward. Commented Aug 4, 2011 at 19:44
  • you’re not really forced to “go back” though, are you? You just can’t take advantage of HTML5’s validation attributes if you use hidden form fields. Given that you’re already re-creating HTML’s built-in form fields via JavaScript, this is another part of that. Commented Aug 4, 2011 at 20:17

1 Answer 1

Reset to default
25

First you do mix up two things. If the HTML5 specification says hidden state, the specification only means an input element with an type attribute set to the value "hidden". In this case, the input is not validated, which means, the input can not be invalid. And the browser does not abort form submission.

Your problem is another one. You have a true invalid element, which is only visually hidden (using display: none) and replaced by another element (or by a set of other elements). In your case the problem is the following: By specification in case of interactive form validation the browser has to focus the first invalid element and show at least for this element a validation message.

The problem is that a browser can neither focus a hidden element nor show a validation message below this element. Which means that the browser stops form submission, but has an odd UI to show the validation problems.

Now to your question: Does this make sense? Yes, it does! If you change the UI of an form element you have to implement also UI for the validation message. (If you want to customize something, you have customize everything you want to use). HTML5 gives you an API to achieve exactly this.

You have to bind the invalid event of your select element, then prevent the default action (if it's the first invalid event of the form) and place your own validation tooltip to styled select element.

In my HTML5 form polyfill (webshims library), I'm already using code to link a native element (with API) with another element + generating simply validation tooltips.

I have created a simple jsfiddle, which mimics a select-replacement and shows how to achieve HTML5 form validation with custom form controls. You can find the example here and below:

HTML

<form class="example"> <div> <select name="test" required> <option value="">empty </option> <option>sdadsa</option> </select> </div> <div> <input type="submit" /> </div> </form> <p><a href="http://afarkas.github.com/webshim/demos/index.html" target="_blank">uses the webhsims library</a>

JavaScript

(function() { "use strict"; webshims.polyfill('forms dom-support'); $(function() { $('select').each(function(){ var visualReplacement = $('<span tabinde="0">replaced select</select>'); $(this).after(visualReplacement).hide(); // Bind the visual element to the API element webshims.addShadowDom(this, visualReplacement); }); $('form').on('firstinvalid', function(e){ webshims.validityAlert.showFor(e.target); // Remove native validation return false; }); }); })();
Improve this answer
Sign up to request clarification or add additional context in comments.

8 Comments

Ah, I did misread that. Would that make this a browser-issue and not an issue with the spec? Also, while the awesome example you've provided essentially does precisely what I'm after, it doesn't provide the (theoretical) speed increase of preventing the submit event from ever triggering.
Can you please explain, what you mean with "Also, while the awesome example you've provided essentially does precisely what I'm after, it doesn't provide the (theoretical) speed increase of preventing the submit event from ever triggering". My english isn't that good.
Basically, your code simulates the HTML5 feature with JavaScript, which means that the submit event triggers before the validation instead of the other way around. Skipping JavaScript with browser-level validation is potentially faster.
Oh no, my example uses the HMLT5 form validation API, which triggers a special event called invalid, before the submit. This is where my script hooks in to implement only the UI. Only in browser, which do not implement the HTML5 feature, the script polyfills this feature.
This is what I wanted to say: If you hide an element (to crate a custom styleable element), you can still use the API, but you have to create the UI fully. A simple example: FF5, Chrome 11 do load only so called form-core (the UI, some pseudoselectors and some extras), while IE6/8/9 have to load form-core and form-shim-extend (the constraint validation API).
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.