Re: [whatwg] [WebForms2] custom form validation notifications
On Wed, Nov 12, 2008 at 1:15 AM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 23 Oct 2008, Eduard Pascual wrote: [...] I don't really follow. Neither do I, and I wrote that :S Re-reading the conversation, I'm not really sure if I really understood Joao's issue and proposal correctly; and without him providing any clarification this doesn't turn any better... And, in addition, I couldn't have worded my ideas worse than I did. It seems that I got a 404 Brain not found while writting that message. Summarizing, my suggestion (a possible solution for what I thought to be the main use-case for this) was to *not* include the validation-related arguments in the markup (or use catch-all placeholders), but instead add them from a script upon the page's onload event. This way, when scripts are available, the javascript will do whatever it needs, customize everything, and so on; but when scripts are disabled or not supported, the client won't do anything, and all the validation will be delegated to the server (that's what is called *graceful* degradation, in contrast with grace-less stuff like noscriptYou have no scripting: your browser sux, get a new one/noscript :P ) OTOH, I think Joao's idea was more like to relying on visual hints (ie: marking the field as red) on cases where an error message popup would be redundant and annoying. I think that could be more elegantly handled with an empty attribute value for an hipothetical custom-error-message attribute (which is not the same as an absent attribute). I really don't follow this. Maybe some concrete examples showing the problem with the current spec solutions would help. The main point is that when a page already handless error-reporting via CSS (for example, marking valid fields in green and invalid ones in red), further notifications by the UA are redundant and sometimes (if they take the form pop-up messages) annoying to the user. The need would be to disable such messages even when scripts are not available. I don't really know if there is a way to do that with the current spec. Anyway, as long as browsers don't use pop-ups for this kind of notification, this shouldn't be an issue. Most browsers already provide pop-up blocking functionality, so I hope they won't add pop-ups of their own needlessly. In addition, a user that sees a field becomming red (or marked as invalid in some other way) isn't likely to hit the submit button before fixing it, so I don't think this is too much of an issue anyway. Maybe Joao had something else in mind, or some specific use-case, but unless he can provide more details, I think this discussion will lead nowhere. Greetings, Eduard Pascual
Re: [whatwg] [WebForms2] custom form validation notifications
On Thu, 23 Oct 2008, Eduard Pascual wrote: On Thu, Oct 23, 2008 at 4:40 PM, Ian Hickson [EMAIL PROTECTED] wrote: You can call setCustomValidity() to set a specific string. Joao explicitly asked for a way to achieve this **without scripting enabled**. I think it's quite obvious why setCustomValidity() doesn't solve that need. Granted, but it's not clear how one could do custom validity checking without script, and for the other cases there are declarative solutions (min= and max= are self-documenting, for instance; and title= can be used for pattern='s documentation.) Would having some sort of custom-error-message attribute hurt that much? (Of course, the name is just an example, and I wouldn't really suggest it). It would simply ignored by current UAs, and not really hard to implement (actually, it'd be trivial compared to implementing reg.exp. parsing). It's not clear to me what problem this would solve. If the UA has scripting disabled, trying to prevent the default action for an invalid event won't work. Too overcome this problem, there could be a new attribute which could be called 'notifyoninvalid=true|false' with a default value of true, for each control, or for the entire form. If the value is false, then the UA wouldn't notify the user in case of invalidity. This could then be delegated to some CSS using :invalid; If scripting is disabled, why would you not want the user notified? That would be pretty bad UI. :-) That'd be really useful if validation can be delegated to server-side scripting when no client-side scripting is available. You can do that today, just don't use the new constraint attributes. Anyway, I don't think such an attribute is needed: a page can be authored with a catch-all validation rule for the field, and then the Javascript could update that rule upon the page's loading: if scripts are dissabled, the rule wouldn't be updated and would stay as the catch-all. I don't really follow. OTOH, I think Joao's idea was more like to relying on visual hints (ie: marking the field as red) on cases where an error message popup would be redundant and annoying. I think that could be more elegantly handled with an empty attribute value for an hipothetical custom-error-message attribute (which is not the same as an absent attribute). I really don't follow this. Maybe some concrete examples showing the problem with the current spec solutions would help. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WebForms2] custom form validation notifications
On Wed, 4 Oct 2006, Joao Eiras wrote:
Although WebForm2 provides automatic validation of form content from the
UA side, the specification has a few gaps related to customizablility of
notifications, by web authors, without scripting enabled.
If the user fills a form in an improper way the UA should alert him of the
problems. Opera in the early days of its initial web forms support showed an
alert box stating that the information was invalid, now it flashes the input
field, and presents a message overlapped in the webpage.
However it presents a very generic error message like You must set a value!
(for required) or foo is not in the format this page requires (for pattern).
The author may want, in the case of an error, to present its custom error
message to the end user.
You can call setCustomValidity() to set a specific string.
If the UA has scripting disabled, trying to prevent the default action
for an invalid event won't work. Too overcome this problem, there could
be a new attribute which could be called 'notifyoninvalid=true|false'
with a default value of true, for each control, or for the entire form.
If the value is false, then the UA wouldn't notify the user in case of
invalidity. This could then be delegated to some CSS using :invalid;
If scripting is disabled, why would you not want the user notified? That
would be pretty bad UI. :-)
Now, to ease the authors work, there could be another css pseudo-classes, to
compliment :invalid, which is :valid
*:valid{border:thin solid green;}
This already exists:
http://www.w3.org/TR/css3-ui/#pseudo-validity
Regarding custom messages for pattern= (the case where making a good
message is hard), the spec suggests using title= for the message.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WebForms2] custom form validation notifications
This are just my thoughts, however I feel they are worth sharing: On Thu, Oct 23, 2008 at 4:40 PM, Ian Hickson [EMAIL PROTECTED] wrote: You can call setCustomValidity() to set a specific string. Joao explicitly asked for a way to achieve this **without scripting enabled**. I think it's quite obvious why setCustomValidity() doesn't solve that need. Would having some sort of custom-error-message attribute hurt that much? (Of course, the name is just an example, and I wouldn't really suggest it). It would simply ignored by current UAs, and not really hard to implement (actually, it'd be trivial compared to implementing reg.exp. parsing). If the UA has scripting disabled, trying to prevent the default action for an invalid event won't work. Too overcome this problem, there could be a new attribute which could be called 'notifyoninvalid=true|false' with a default value of true, for each control, or for the entire form. If the value is false, then the UA wouldn't notify the user in case of invalidity. This could then be delegated to some CSS using :invalid; If scripting is disabled, why would you not want the user notified? That would be pretty bad UI. :-) That'd be really useful if validation can be delegated to server-side scripting when no client-side scripting is available. Anyway, I don't think such an attribute is needed: a page can be authored with a catch-all validation rule for the field, and then the Javascript could update that rule upon the page's loading: if scripts are dissabled, the rule wouldn't be updated and would stay as the catch-all. OTOH, I think Joao's idea was more like to relying on visual hints (ie: marking the field as red) on cases where an error message popup would be redundant and annoying. I think that could be more elegantly handled with an empty attribute value for an hipothetical custom-error-message attribute (which is not the same as an absent attribute).
Re: [whatwg] [WebForms2] custom form validation notifications
Am Donnerstag, den 23.10.2008, 23:02 +0100 schrieb Eduard Pascual: Would having some sort of custom-error-message attribute hurt that much? (Of course, the name is just an example, and I wouldn't really suggest it). It would simply ignored by current UAs, and not really hard to implement (actually, it'd be trivial compared to implementing reg.exp. parsing). We already have @title and as section 2.6 of WF2 says: Authors should include a description of the pattern in the title attribute. User agents may use the contents of this attribute when informing the user that the pattern is not matched, or at any other suitable time, such as in a tooltip or read out by assistive technology when the control gains focus. That pretty much sweeps the issue, does it ? OTOH, I think Joao's idea was more like to relying on visual hints (ie: marking the field as red) on cases where an error message popup would be redundant and annoying. I think that could be more elegantly handled with an empty attribute value for an hipothetical custom-error-message attribute (which is not the same as an absent attribute). What's the problem with having :valid and :invalid CSS pseudo-classes ? Greetings -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] [WebForms2] custom form validation notifications
On Oct 9, 2006, at 01:32, Matthew Paul Thomas wrote: As UAs become more sophisticated, they can analyze the pattern attribute and present more context-sensitive error messages than any such attribute could. For example: * 410 is too much; this number must be 300 or less. * 178 is too small; this number must be 200 or more. * This field must start with a letter. UAs can also localize these error messages much more extensively than any Web site could (which will be even more of a benefit when the Web site is not in your preferred language). No offense intended, but As UAs become more sophisticated, they can analyze—— generally indicates a problem. I believe that the above can work for min and max. However, expecting user-friendly natural language descriptions of regular expressions (in multiple natural languages!) to emerge as UAs become more sophisticated is in the realm of expecting future AI-complete magic software to fix things. In general, that's not a good assumption to make. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] [WebForms2] custom form validation notifications
On Oct 4, 2006, at 4:05 PM, Brad Fults wrote: On 10/3/06, Joao Eiras [EMAIL PROTECTED] wrote: ... If the user fills a form in an improper way the UA should alert him of the problems. Opera in the early days of its initial web forms support showed an alert box stating that the information was invalid, now it flashes the input field, and presents a message overlapped in the webpage. However it presents a very generic error message like You must set a value! (for required) or foo is not in the format this page requires (for pattern). The author may want, in the case of an error, to present its custom error message to the end user. This could be achieved by declaring new custom attribute for the several controls, which could hold the message. The UA could then either pop up that message to the user or embed it in the page (like Opera does currently). The attribute could be named like requirederr, patternerr, or use some other sort of naming convention to easily associate the constraining property with the message attribute. As UAs become more sophisticated, they can analyze the pattern attribute and present more context-sensitive error messages than any such attribute could. For example: * 410 is too much; this number must be 300 or less. * 178 is too small; this number must be 200 or more. * This field must start with a letter. UAs can also localize these error messages much more extensively than any Web site could (which will be even more of a benefit when the Web site is not in your preferred language). Is the use of the title attribute inappropriate for this case? ... It has the same lack of context. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] [WebForms2] custom form validation notifications
Matthew Paul Thomas [EMAIL PROTECTED] escreveu: On Oct 4, 2006, at 4:05 PM, Brad Fults wrote: On 10/3/06, Joao Eiras [EMAIL PROTECTED] wrote: ... If the user fills a form in an improper way the UA should alert him of the problems. Opera in the early days of its initial web forms support showed an alert box stating that the information was invalid, now it flashes the input field, and presents a message overlapped in the webpage. However it presents a very generic error message like You must set a value! (for required) or foo is not in the format this page requires (for pattern). The author may want, in the case of an error, to present its custom error message to the end user. This could be achieved by declaring new custom attribute for the several controls, which could hold the message. The UA could then either pop up that message to the user or embed it in the page (like Opera does currently). The attribute could be named like requirederr, patternerr, or use some other sort of naming convention to easily associate the constraining property with the message attribute. As UAs become more sophisticated, they can analyze the pattern attribute and present more context-sensitive error messages than any such attribute could. For example: * 410 is too much; this number must be 300 or less. * 178 is too small; this number must be 200 or more. * This field must start with a letter. UAs can also localize these error messages much more extensively than any Web site could (which will be even more of a benefit when the Web site is not in your preferred language). Of course. Such features are very useful, although such behaviours are user-agent defined. But that's not the point: my original message is related to customizablility. Is the use of the title attribute inappropriate for this case? ... It has the same lack of context.
Re: [whatwg] [WebForms2] custom form validation notifications
Matthew Paul Thomas [EMAIL PROTECTED] escreveu: On Oct 4, 2006, at 4:05 PM, Brad Fults wrote: On 10/3/06, Joao Eiras [EMAIL PROTECTED] wrote: ... If the user fills a form in an improper way the UA should alert him of the problems. Opera in the early days of its initial web forms support showed an alert box stating that the information was invalid, now it flashes the input field, and presents a message overlapped in the webpage. However it presents a very generic error message like You must set a value! (for required) or foo is not in the format this page requires (for pattern). The author may want, in the case of an error, to present its custom error message to the end user. This could be achieved by declaring new custom attribute for the several controls, which could hold the message. The UA could then either pop up that message to the user or embed it in the page (like Opera does currently). The attribute could be named like requirederr, patternerr, or use some other sort of naming convention to easily associate the constraining property with the message attribute. As UAs become more sophisticated, they can analyze the pattern attribute and present more context-sensitive error messages than any such attribute could. For example: * 410 is too much; this number must be 300 or less. * 178 is too small; this number must be 200 or more. * This field must start with a letter. UAs can also localize these error messages much more extensively than any Web site could (which will be even more of a benefit when the Web site is not in your preferred language). Of course. Such features are very useful, although such behaviours are user-agent defined. But that's not the point: my original message is related to customizablility. Is the use of the title attribute inappropriate for this case? ... It has the same lack of context.
Re: [whatwg] [WebForms2] custom form validation notifications without scripting
On 10/3/06, Joao Eiras [EMAIL PROTECTED] wrote: Although WebForm2 provides automatic validation of form content from the UA side, the specification has a few gaps related to customizablility of notifications, by web authors, without scripting enabled. If the user fills a form in an improper way the UA should alert him of the problems. Opera in the early days of its initial web forms support showed an alert box stating that the information was invalid, now it flashes the input field, and presents a message overlapped in the webpage. However it presents a very generic error message like You must set a value! (for required) or foo is not in the format this page requires (for pattern). The author may want, in the case of an error, to present its custom error message to the end user. This could be achieved by declaring new custom attribute for the several controls, which could hold the message. The UA could then either pop up that message to the user or embed it in the page (like Opera does currently). The attribute could be named like requirederr, patternerr, or use some other sort of naming convention to easily associate the constraining property with the message attribute. Is the use of the title attribute inappropriate for this case? -- Brad Fults
Re: [whatwg] [WebForms2] custom form validation notifications without scripting
Na , Brad Fults [EMAIL PROTECTED] escreveu: On 10/3/06, Joao Eiras [EMAIL PROTECTED] wrote: Although WebForm2 provides automatic validation of form content from the UA side, the specification has a few gaps related to customizablility of notifications, by web authors, without scripting enabled. If the user fills a form in an improper way the UA should alert him of the problems. Opera in the early days of its initial web forms support showed an alert box stating that the information was invalid, now it flashes the input field, and presents a message overlapped in the webpage. However it presents a very generic error message like You must set a value! (for required) or foo is not in the format this page requires (for pattern). The author may want, in the case of an error, to present its custom error message to the end user. This could be achieved by declaring new custom attribute for the several controls, which could hold the message. The UA could then either pop up that message to the user or embed it in the page (like Opera does currently). The attribute could be named like requirederr, patternerr, or use some other sort of naming convention to easily associate the constraining property with the message attribute. Is the use of the title attribute inappropriate for this case? I believe title is used for a berief description, not for error messages, besides a control may not validate for more than one reason.
