An input/textarea which is not displayed, e.g. nested in a block-element with display:none, generates a console error: "An invalid form control with name='input_or_text_area_name_attribute_value' is not focusable.", which is vague at best. While it may be sufficient as far as the error message is concerned, from a user accessibility view point, it would be nice to force the element in question to become visible and/or at least give the user some kind of feedback. No feedback is given in the case where the element is visible either (on OSX 10.6), which is also mentioned here https://bugs.webkit.org/show_bug.cgi?id=40520
It might be possible to show a warning to users, like "The page has HTML5 compatibility issue. Please contact the page author." I posted this issue to WHATWG some week ago.
I disagree. It's not the job of a Web browser to enlist users as evangelists, or to shift the blame on HTML5 and authors. My instinct is that we should ignore the required attribute if there is no way for the user to fix the problem. It's tricky though, as the input may be invisible for other reasons (e.g. behind an opacity:0.99 layer).
Is there any evidence of authors doing this?
Link to WHATWG discussion: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-June/026591.html (In reply to comment #2) > I disagree. It's not the job of a Web browser to enlist users as evangelists, or to shift the blame on HTML5 and authors. > > My instinct is that we should ignore the required attribute if there is no way for the user to fix the problem. It's tricky though, as the input may be invisible for other reasons (e.g. behind an opacity:0.99 layer). This would have to be specced -- currently the spec doesn't permit it. (See linked discussion.) It's not likely that you'd be able to catch all the corner cases easily . . . there are all sorts of devious ways to hide things. Worse, it makes HTML-level semantics ("this input must match criteria X Y Z") dependent on CSS. As an author, if I say username is required on my login form, I do *not* want the browser sometimes deciding that it's not actually required. If the input is required, that might mean that it makes no sense to submit without the input being filled. This is a bug in the page and it needs to be fixed by the page author; the browser can't reliably guess what to do here. (In reply to comment #3) > Is there any evidence of authors doing this? MediaWiki formerly did this by mistake (until we turned off form validation due to WebKit's bug 40747). If you're logged in and have JS enabled, the page http://en.wikipedia.org/wiki/Special:Preferences uses JS to break the page into tabs. If you filled out something incorrectly, switched to another tab, and tried to submit, the invalid input wouldn't be focusable. However, this is just an authoring bug, no different from misusing a script library. If it's not possible for the browser to do the right thing here automatically, it needs to push it off onto the author. There will be problems as authors adopt the technology too soon and write broken pages, but these will go away when enough browsers implement the features.
These are all good points. On the other hand, the idea behind "required" is pretty much "just do the right thing for me". Well, and work with disabled JavaScript, but that's less interesting IMO. The problem is about matching author expectations for "the right thing", and it seems that silently failing isn't it.
Failure shouldn't be silent -- that's bug 40747. With proper UI, I don't think you'd have seen so many complaints to WebKit. It should fail with a clear error. The error should give enough info for the user to figure out how to fix it if that makes sense, otherwise it should report a page error and give enough info for the author to fix it. I'm far from being a UI person, but maybe something like: 1) If the current value was actually set by the user (not the default value or a script): Report the same error as usual. Since the user set the value in the first place, they can probably figure out how to change it -- maybe it's a set of controls that got collapsed. At worst, they can refresh. So for <label>Volume: <input type=number step=1 min=1 max=10></label>, maybe like "You entered '11' for 'Volume:', but it must be between 1 and 10." (This shouldn't come up much if the error is reported onchange, which seems best anyway.) 2) If the current value is default, or was set by a script: Let's say <input required name="foo" style="display:none">. Then report something like "The page has an error and won't let you submit. Tell the author that the input 'foo' is required, but cannot be displayed." This is not ideal, but then, the page is buggy, and ignoring the requirements if the input's not visible isn't sane. In this test case, Opera fails silently: data:text/html,<!doctype html> <form action=about:blank> <input required name=foo style=display:none> <button type=submit>Submit</button> </form>
(In reply to comment #4) > (In reply to comment #3) > > Is there any evidence of authors doing this? > > MediaWiki formerly did this by mistake (until we turned off form validation due to WebKit's bug 40747). If you're logged in and have JS enabled, the page http://en.wikipedia.org/wiki/Special:Preferences uses JS to break the page into tabs. If you filled out something incorrectly, switched to another tab, and tried to submit, the invalid input wouldn't be focusable. A thought that hit me is that a change in the spec in the form submit algorithm, http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-form-submit, would make this js-tabbed approach work, by changing the order of item 3 and 4. Since js was enabled in the first place in this case, js could also deal with validation by making the proper (set of) controls visible, if the cancelable submit event is allowed to run before browser form validation. I believe it also goes along the lines of using js to enhance user experience. Any thoughts on this? I'm not involved in browser development, so I lack insights in these matters.
(In reply to comment #7) > A thought that hit me is that a change in the spec in the form submit algorithm, http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-form-submit, would make this js-tabbed approach work, by changing the order of item 3 and 4. > > Since js was enabled in the first place in this case, js could also deal with validation by making the proper (set of) controls visible, if the cancelable submit event is allowed to run before browser form validation. I believe it also goes along the lines of using js to enhance user experience. > > Any thoughts on this? I'm not involved in browser development, so I lack insights in these matters. This is probably best discussed on the whatwg or public-html lists. It's not really relevant to this bug, since WebKit will still have to deal with authors who don't do this. (FWIW, your proposed change is unnecessary. You could emulate the effect using novalidate, onsubmit, oninvalid, and checkValidity() pretty easily.)
I think there is a seemingly valid use case for this. HTML5 allows fieldsets to be disabled: "The disabled attribute, when specified, causes all the form control descendants of the fieldset element, excluding those that are descendants of the fieldset element's first legend element child, if any, to be disabled." So if you had something like this: data:text/html,<!doctype html> <form action=about:blank> <fieldset disabled style=display:none> <input required name=foo> </fieldset> <button type=submit>Submit</button> </form> It should not throw the error, because the required input should be disabled. But it does.
Can you explain, what you want to do about this? I don't really think, that this is a browser problem. It is a page/developer problem. There are a lot of custom stylable checkbox/radiobutton/select element scripts out there. The common technique to do this, is to hide the native input-element, create a better stylable element and delegate user/developer inputs from the custom widget to the native input-widget and vice versa. An HTML5 aware script would delegate the invalid event from the native widget to the custom widget. If you would show an error to the user, it would break these scripts or would make custom styleable datepicker-widgets, range-widgets etc. on top of html5-inputs impossible/more difficult. The only thing you could/should do, is to print a console log (for the developer), if a) an invalid event occurs, b) the invalid-event is unhandeled (no preventDefault/return false) and c) the element is not focusable. Everything more would break the web. Don't do too much. If a developer has used his own attributes (i.e. required="no/false", it is his fault). Due to the fact, that FF4 also adds the required attribute, these bugs will simply fixed by the page authors. Simply change the status to invalid/wontfix. (can you explain why bug 44436 isn't invalid) BTW.: Aptanas code assists suggests true/false as values for the disabled attribute. It would be ridiculous, if I would fill a bug here to make disabled="false" work. Although, there are more developers using aptana than sites using hidden elements with required-attribut / required="please don't validate".
(In reply to comment #10) > Due to the fact, that FF4 also adds the required attribute, these bugs will simply fixed by the page authors. This is optimistic. Firefox doesn’t have that kind of market power.