[whatwg] [WebForms2] custom form validation notifications

[Ian Hickson]

On Thu, 23 Oct 2008, Eduard Pascual wrote:
>
> 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.

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.   `._.-(,_..'--(,_..'`-.;.'