Re: [whatwg] Form validation against invisible controls
On Wed, 04 Aug 2010 23:32:46 +0200, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Jun 2010, TAMURA, Kent wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) The problem with that is that they still get submitted, so it seems weird to not validate them. It seems authors should be careful not to make the hidden controls be invalid. On Thu, 3 Jun 2010, Tab Atkins Jr. wrote: Adding @hidden to the list of things that skip validation is good. I considered it, but really we should also also stop submission in that case, and that seems like it's starting to make things a little less intuitive than I'd like. It's really up to the author to make sure that something that's irrelevant (hidden=) is not part of a form that is user-submittable. Adding display:none is not. That's a big layering violation that we authors have to suffer through with screen readers already. I'd greatly prefer not muddying the waters there. Indeed. On Fri, 4 Jun 2010, TAMURA, Kent wrote: Oh, I'm sorry. I have found a sentence about visibility in the draft. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being rendered (e.g. it has the hidden attribute set) then user agents may report a script error. This sentence is about process against controls of which validation result is invalid. I think UA doesn't need to validate such controls. I think, as the sentence above suggests, it's better to report this as a page error than to not validate the control. Chrome already reports this problem in the console. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 The bug there is that Chrome is filling in a control that isn't visible, and, even worse, that it is filling it with a value that the user couldn't himself enter manually. That's a bug (two bugs in fact), but it has nothing to do with reporting validation errors -- the error should not be able to occur. On Thu, 3 Jun 2010, Peter Kasting wrote: I posted this on the Chromium bug, but I take the sentence Kent quotes to affect only the UI shown on a validation failure, not the actual results of validation. That is, if a control fails validation and has the hidden attribute, validation still fails, but the UA may display a message indicating the page has an error in addition to/instead of the normal validation failure message. Indeed. On Mon, 14 Jun 2010, TAMURA, Kent wrote: There are some objections against omitting invisible controls from form validation. However, it is a real issue with existing sites and users can't submit such forms at all though they can submit it with non-HTML5 browsers. My conclusion is it's better to disable interactive form validation for existing sites as possible. e.g. disabling interactive form validation for documents without !DOCTYPE html. Just don't autofill controls with invalid values, and don't autofill hidden controls. :-) On Mon, 14 Jun 2010, Ola P. Kleiven wrote: The following sites have workarounds in Opera's browser.js to allow form submit: airgreenland.com (using required on hidden elements) site has now changed. barnesandnoble.com (using required on visible elements that are supposed to be empty on submit...) https://cart4.barnesandnoble.com/account/request.aspx?stage=mainStage - click Create an Account. Will fail unless you fill in the fields in the form to the left (which is really unrelated) bookryanair.com (using required=false - this usage has also been found in JS libraries) site changed ingdirect.com.au (using required on a visible field, but then emptying the field with JS before submit) https://www.ingdirect.com.au/client/index.aspx - type any client number and a 4 digit access code. Click log in. The client number field is then emptied by js before submitting but has required=true, causing error usairways.com (using required on hidden elements) The original issue seems to be gone (unable to search for flights from front page), but there is another one also related to WF2. Enter jfk in from or to fields, wait for the autocompletion and select New York, NY (JFK) (John F. Kennedy International Airport) by hitting enter. Then you will get a maxlength error. Most of these have been using it for several years and have not responded to change requests from our
Re: [whatwg] Form validation against invisible controls
On Fri, 4 Jun 2010, TAMURA, Kent wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) The problem with that is that they still get submitted, so it seems weird to not validate them. It seems authors should be careful not to make the hidden controls be invalid. On Thu, 3 Jun 2010, Tab Atkins Jr. wrote: Adding @hidden to the list of things that skip validation is good. I considered it, but really we should also also stop submission in that case, and that seems like it's starting to make things a little less intuitive than I'd like. It's really up to the author to make sure that something that's irrelevant (hidden=) is not part of a form that is user-submittable. Adding display:none is not. That's a big layering violation that we authors have to suffer through with screen readers already. I'd greatly prefer not muddying the waters there. Indeed. On Fri, 4 Jun 2010, TAMURA, Kent wrote: Oh, I'm sorry. I have found a sentence about visibility in the draft. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being rendered (e.g. it has the hidden attribute set) then user agents may report a script error. This sentence is about process against controls of which validation result is invalid. I think UA doesn't need to validate such controls. I think, as the sentence above suggests, it's better to report this as a page error than to not validate the control. Chrome already reports this problem in the console. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 The bug there is that Chrome is filling in a control that isn't visible, and, even worse, that it is filling it with a value that the user couldn't himself enter manually. That's a bug (two bugs in fact), but it has nothing to do with reporting validation errors -- the error should not be able to occur. On Thu, 3 Jun 2010, Peter Kasting wrote: I posted this on the Chromium bug, but I take the sentence Kent quotes to affect only the UI shown on a validation failure, not the actual results of validation. That is, if a control fails validation and has the hidden attribute, validation still fails, but the UA may display a message indicating the page has an error in addition to/instead of the normal validation failure message. Indeed. On Mon, 14 Jun 2010, TAMURA, Kent wrote: There are some objections against omitting invisible controls from form validation. However, it is a real issue with existing sites and users can't submit such forms at all though they can submit it with non-HTML5 browsers. My conclusion is it's better to disable interactive form validation for existing sites as possible. e.g. disabling interactive form validation for documents without !DOCTYPE html. Just don't autofill controls with invalid values, and don't autofill hidden controls. :-) On Mon, 14 Jun 2010, Ola P. Kleiven wrote: The following sites have workarounds in Opera's browser.js to allow form submit: airgreenland.com (using required on hidden elements) barnesandnoble.com (using required on visible elements that are supposed to be empty on submit...) bookryanair.com (using required=false - this usage has also been found in JS libraries) ingdirect.com.au (using required on a visible field, but then emptying the field with JS before submit) usairways.com (using required on hidden elements) Most of these have been using it for several years and have not responded to change requests from our side. Do you have more specific URLs I could look at for these? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Form validation against invisible controls
The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 The bug there is that Chrome is filling in a control that isn't visible, and, even worse, that it is filling it with a value that the user couldn't himself enter manually. That's a bug (two bugs in fact), but it has nothing to do with reporting validation errors -- the error should not be able to occur. Please look at the original report and Comment #4. It is not an auto-fill issue. Comment #2 is an auto-fill bug and it was moved to another bug entry. Regardless of the auto-fill bug, we still have compatibility issues and we can't force authors to update their web pages. I'm wondering UA should show a dialog with The web page has invisible invalid form fields. Do you want to submit the form? [Yes] [No]. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Form validation against invisible controls
I remember an article that stated that required was used 29 times more often than mandatory in instructions and specifications (WWWeb pages were mentioned as being part of the search source). Mandatory implies that there may be reprisals for failure to comply, because, and, secondarily, such failures could lead to loss of sovereign integrity. Required has no connotation that failure to comply will result in loss of integrity and, while cooperation may be conditional, certainly, does not intimate retribution. === On 2010-06-14 07:04, Michelangelo De Simone wrote: Il giorno 14/giu/2010, alle ore 12.40, Ian Hickson ha scritto: Incorrect use of required in HTML4-era documents also seems to be the common problem Chrome ran into -- at the risk of starting a bikeshed discussion, does anyone have any good suggestions for alternative names? I believe mandatory would keep the same semantic and clarity required does. -- Bye, Michelangelo
Re: [whatwg] Form validation against invisible controls
On Sun, Jun 13, 2010 at 10:41 PM, Peter Kasting pkast...@google.com wrote: On Sun, Jun 13, 2010 at 10:16 PM, TAMURA, Kent tk...@chromium.org wrote: There are some objections against omitting invisible controls from form validation. However, it is a real issue with existing sites and users can't submit such forms at all though they can submit it with non-HTML5 browsers. How many existing sites? What sites are asking for form validation but then not actually working with it? If this isn't a large number, I would prefer to stay as-is and let the sites fix themselves. My conclusion is it's better to disable interactive form validation for existing sites as possible. e.g. disabling interactive form validation for documents without !DOCTYPE html. I think this is a mistake. Agreed on both accounts. Both these suggestions add a lot of complexity to the platform and we should avoid it if at all possible. To the extent that if there is lots of broken sites out there because they happen to use attribute names that collide with HTML5, but only partially match the HTML5 behavior, then we should consider renaming those attributes in HTML5. / Jonas
Re: [whatwg] Form validation against invisible controls
On Mon, 14 Jun 2010 07:41:40 +0200, Peter Kasting pkast...@google.com wrote: On Sun, Jun 13, 2010 at 10:16 PM, TAMURA, Kent tk...@chromium.org wrote: There are some objections against omitting invisible controls from form validation. However, it is a real issue with existing sites and users can't submit such forms at all though they can submit it with non-HTML5 browsers. How many existing sites? What sites are asking for form validation but then not actually working with it? If this isn't a large number, I would prefer to stay as-is and let the sites fix themselves. The following sites have workarounds in Opera's browser.js to allow form submit: airgreenland.com (using required on hidden elements) barnesandnoble.com (using required on visible elements that are supposed to be empty on submit...) bookryanair.com (using required=false - this usage has also been found in JS libraries) ingdirect.com.au (using required on a visible field, but then emptying the field with JS before submit) usairways.com (using required on hidden elements) Most of these have been using it for several years and have not responded to change requests from our side. We have also seen a couple of instances of wrong input types (number where text expected etc.), but the usage of required is the biggest problem in my experience. My conclusion is it's better to disable interactive form validation for existing sites as possible. e.g. disabling interactive form validation for documents without !DOCTYPE html. I think this is a mistake. PK -- Ola P. Kleiven, Core Compatibility, Opera Software
Re: [whatwg] Form validation against invisible controls
On Mon, 14 Jun 2010, Ola P. Kleiven wrote: The following sites have workarounds in Opera's browser.js to allow form submit: airgreenland.com (using required on hidden elements) barnesandnoble.com (using required on visible elements that are supposed to be empty on submit...) bookryanair.com (using required=false - this usage has also been found in JS libraries) ingdirect.com.au (using required on a visible field, but then emptying the field with JS before submit) usairways.com (using required on hidden elements) Most of these have been using it for several years and have not responded to change requests from our side. We have also seen a couple of instances of wrong input types (number where text expected etc.), but the usage of required is the biggest problem in my experience. Incorrect use of required in HTML4-era documents also seems to be the common problem Chrome ran into -- at the risk of starting a bikeshed discussion, does anyone have any good suggestions for alternative names? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Form validation against invisible controls
Il giorno 14/giu/2010, alle ore 12.40, Ian Hickson ha scritto: Incorrect use of required in HTML4-era documents also seems to be the common problem Chrome ran into -- at the risk of starting a bikeshed discussion, does anyone have any good suggestions for alternative names? I believe mandatory would keep the same semantic and clarity required does. -- Bye, Michelangelo
Re: [whatwg] Form validation against invisible controls
On Jun 14, 2010, at 3:40 AM, Ian Hickson wrote: On Mon, 14 Jun 2010, Ola P. Kleiven wrote: The following sites have workarounds in Opera's browser.js to allow form submit: airgreenland.com (using required on hidden elements) barnesandnoble.com (using required on visible elements that are supposed to be empty on submit...) bookryanair.com (using required=false - this usage has also been found in JS libraries) ingdirect.com.au (using required on a visible field, but then emptying the field with JS before submit) usairways.com (using required on hidden elements) Most of these have been using it for several years and have not responded to change requests from our side. We have also seen a couple of instances of wrong input types (number where text expected etc.), but the usage of required is the biggest problem in my experience. Incorrect use of required in HTML4-era documents also seems to be the common problem Chrome ran into -- at the risk of starting a bikeshed discussion, does anyone have any good suggestions for alternative names? A few suggestions: required-field value-required Regards, Maciej
Re: [whatwg] Form validation against invisible controls
On Mon, 14 Jun 2010 08:44:09 +0100, Jonas Sicking jo...@sicking.cc wrote: Agreed on both accounts. Both these suggestions add a lot of complexity to the platform and we should avoid it if at all possible. To the extent that if there is lots of broken sites out there because they happen to use attribute names that collide with HTML5, but only partially match the HTML5 behavior, then we should consider renaming those attributes in HTML5. I don't agree that there are lots of broken sites. My main browser is Opera and I haven't noticed that problem yet. The fact that there are some sites using 'required' attribute proves that it's a good, intuitive name. HTML5 is likely to outlive those broken sites. I think it would be shame to change to worse name for HTML's lifetime just to avoid temporary problem with some sites. -- regards, Kornel Lesiński
Re: [whatwg] Form validation against invisible controls
There are some objections against omitting invisible controls from form validation. However, it is a real issue with existing sites and users can't submit such forms at all though they can submit it with non-HTML5 browsers. My conclusion is it's better to disable interactive form validation for existing sites as possible. e.g. disabling interactive form validation for documents without !DOCTYPE html. On Fri, Jun 4, 2010 at 00:16, TAMURA, Kent tk...@chromium.org wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. -- TAMURA Kent Software Engineer, Google -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Form validation against invisible controls
On Sun, Jun 13, 2010 at 10:16 PM, TAMURA, Kent tk...@chromium.org wrote: There are some objections against omitting invisible controls from form validation. However, it is a real issue with existing sites and users can't submit such forms at all though they can submit it with non-HTML5 browsers. How many existing sites? What sites are asking for form validation but then not actually working with it? If this isn't a large number, I would prefer to stay as-is and let the sites fix themselves. My conclusion is it's better to disable interactive form validation for existing sites as possible. e.g. disabling interactive form validation for documents without !DOCTYPE html. I think this is a mistake. PK
Re: [whatwg] Form validation against invisible controls
I would also go with not using the visual state of an element as an indication of whether it needs to be validated or not but rather an additional attribute link the @hidden attribute proposed earlier. I do see though that one might ask the question, how will I indicate an error on a specific field if that field is visually hidden? Good question but, that should be left up to the developer to handle and not the UA. Currently I reckon this is a problem as the UA decides where to place its validation, hoping there will be a way to override this behavior, if desired, in future. Schalk -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Tab Atkins Jr. Sent: Thursday, June 03, 2010 5:55 PM To: João Eiras Cc: TAMURA, Kent; whatwg; Ian Hickson Subject: Re: [whatwg] Form validation against invisible controls On Thu, Jun 3, 2010 at 8:42 AM, João Eiras jo...@opera.com wrote: On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent tk...@chromium.org wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) You'd need to check the visibility or display also of all ancestors, that opacity is not 0, that the bounding box has enough size to render the form to the user and etc. That's quite complicated to specify. Would be easier to tell that user agents might chose to ignore form controls that they do not *paint* if that is possible for the UA to implement. That's even worse - that defeats the time-honored trick to hide something visually without hiding it in any other way of absolutely positioning it off the screen. It might even mean that elements currently off the screen (but that can be scrolled to) wouldn't validate. ~TJ
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 10:30 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 6/3/10, TAMURA, Kent tk...@chromium.org wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being renderedrendering.html#being-rendered (e.g. it has the hidden editing.html#the-hidden-attribute attribute set) then user agents may report a script error. That's about input type=hidden No, it's not. Look at the definition of being rendered: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#being-rendered It gives the hidden *attribute* (not type) as an example.
[whatwg] Form validation against invisible controls
An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 8:16 AM, TAMURA, Kent tk...@chromium.org wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. Adding @hidden to the list of things that skip validation is good. Adding display:none is not. That's a big layering violation that we authors have to suffer through with screen readers already. I'd greatly prefer not muddying the waters there. ~TJ
Re: [whatwg] Form validation against invisible controls
On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent tk...@chromium.org wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) You'd need to check the visibility or display also of all ancestors, that opacity is not 0, that the bounding box has enough size to render the form to the user and etc. That's quite complicated to specify. Would be easier to tell that user agents might chose to ignore form controls that they do not *paint* if that is possible for the UA to implement. I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls.
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 8:42 AM, João Eiras jo...@opera.com wrote: On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent tk...@chromium.org wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) You'd need to check the visibility or display also of all ancestors, that opacity is not 0, that the bounding box has enough size to render the form to the user and etc. That's quite complicated to specify. Would be easier to tell that user agents might chose to ignore form controls that they do not *paint* if that is possible for the UA to implement. That's even worse - that defeats the time-honored trick to hide something visually without hiding it in any other way of absolutely positioning it off the screen. It might even mean that elements currently off the screen (but that can be scrolled to) wouldn't validate. ~TJ
Re: [whatwg] Form validation against invisible controls
On Thu, 2010-06-03 at 08:54 -0700, Tab Atkins Jr. wrote: On Thu, Jun 3, 2010 at 8:42 AM, João Eiras jo...@opera.com wrote: On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent tk...@chromium.org wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) You'd need to check the visibility or display also of all ancestors, that opacity is not 0, that the bounding box has enough size to render the form to the user and etc. That's quite complicated to specify. Would be easier to tell that user agents might chose to ignore form controls that they do not *paint* if that is possible for the UA to implement. That's even worse - that defeats the time-honored trick to hide something visually without hiding it in any other way of absolutely positioning it off the screen. It might even mean that elements currently off the screen (but that can be scrolled to) wouldn't validate. ~TJ But we really shouldn't be positioning things 'off screen' anyway. You should be considering people who aren't viewing the site through the traditional computer web browser. What about people who are using a speech or Braille browser? What about search engines (most of which specify in their terms that what you give them should equal the user experience) and basically any service that legitimately scrapes content (think web snippets, etc that some browsers are implementing) Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Form validation against invisible controls
Oh, I'm sorry. I have found a sentence about visibility in the draft. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being renderedrendering.html#being-rendered (e.g. it has the hidden editing.html#the-hidden-attribute attribute set) then user agents may report a script error. This sentence is about process against controls of which validation result is invalid. I think UA doesn't need to validate such controls. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 2010/6/4 TAMURA, Kent tk...@chromium.org An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. -- TAMURA Kent Software Engineer, Google -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Form validation against invisible controls
On 6/3/10 11:42 AM, João Eiras wrote: Would be easier to tell that user agents might chose to ignore form controls that they do not *paint* if that is possible for the UA to implement. Gecko doesn't necessarily paint form controls that are outside the viewport, yet ignoring those seems wrong. -Boris
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 12:11 PM, TAMURA, Kent tk...@chromium.org wrote: Oh, I'm sorry. I have found a sentence about visibility in the draft. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being rendered (e.g. it has the hidden attribute set) then user agents may report a script error. This sentence is about process against controls of which validation result is invalid. I think UA doesn't need to validate such controls. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 I think this isn't a feasible strategy to pursue. You'd have to carefully define what's not being rendered, and it will violate layering massively. CSS should not be able to override constraints set in HTML. The latter are part of the semantics of the form, and the former is supposed to only control presentation. If the user can't actually change the form to match requirements, that's a bug in the page. The browser should not try to guess what the page really meant using some inevitably complicated heuristic. It should respect what the page says, and make it not work. If the browser has a UI for form validation errors, it can use that to tell the user what the problem is in terms that the page author can understand, so the user can report it and the page can be fixed.
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 3:48 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Thu, Jun 3, 2010 at 12:11 PM, TAMURA, Kent tk...@chromium.org wrote: Oh, I'm sorry. I have found a sentence about visibility in the draft. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being rendered (e.g. it has the hidden attribute set) then user agents may report a script error. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 I think this isn't a feasible strategy to pursue. You'd have to carefully define what's not being rendered, and it will violate layering massively. CSS should not be able to override constraints set in HTML. The latter are part of the semantics of the form, and the former is supposed to only control presentation. If the user can't actually change the form to match requirements, that's a bug in the page. The browser should not try to guess what the page really meant using some inevitably complicated heuristic. It should respect what the page says, and make it not work. If the browser has a UI for form validation errors, it can use that to tell the user what the problem is in terms that the page author can understand, so the user can report it and the page can be fixed. I posted this on the Chromium bug, but I take the sentence Kent quotes to affect only the UI shown on a validation failure, not the actual results of validation. That is, if a control fails validation and has the hidden attribute, validation still fails, but the UA may display a message indicating the page has an error in addition to/instead of the normal validation failure message. I agree that it would be a mistake to exclude invisible elements from validation, as that would be a rathole (and seems conceptually wrong to me). PK
Re: [whatwg] Form validation against invisible controls
On 6/3/10, TAMURA, Kent tk...@chromium.org wrote: Oh, I'm sorry. I have found a sentence about visibility in the draft. Where? http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being renderedrendering.html#being-rendered (e.g. it has the hidden editing.html#the-hidden-attribute attribute set) then user agents may report a script error. That's about input type=hidden This sentence is about process against controls of which validation result is invalid. I think UA doesn't need to validate such controls. You lost me on that one. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 That bug is describing an error when validating a control that cannot have focus. That's more specific from a control that is not visible. Is the issue in defining what is and what isn't focusable? 2010/6/4 TAMURA, Kent tk...@chromium.org An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. -- TAMURA Kent Software Engineer, Google -- TAMURA Kent Software Engineer, Google
