W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2008

[whatwg] [WebForms2] custom form validation notifications

From: Eduard Pascual <herenvardo@gmail.com>
Date: Thu, 23 Oct 2008 23:02:00 +0100
Message-ID: <6ea53250810231502t3b516187qf08edbed55cc736e@mail.gmail.com>
This are just my thoughts, however I feel they are worth sharing:

On Thu, Oct 23, 2008 at 4:40 PM, Ian Hickson <ian at hixie.ch> 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).
Received on Thursday, 23 October 2008 15:02:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:44 UTC