- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 12 Nov 2008 01:15:45 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 11 November 2008 17:15:45 UTC