[whatwg] :invalid

On Fri, 31 Dec 2010, Mounir Lamouri wrote:
> On 12/31/2010 02:13 AM, Ian Hickson wrote:
> > On Thu, 23 Sep 2010, Mounir Lamouri wrote:
> >>
> >> The current specification of :invalid is pretty simple: it matches all 
> >> invalid elements which are candidate for constraint validation.
> >>
> >> Today, Gecko betas, Presto and Webkit support :invalid (I didn't check 
> >> for IE). Unfortunately, :invalid is far from being perfect and most 
> >> UI/UX guys would tell you that the current :invalid behavior is really 
> >> bad. For example, having the invalid style applying as soon as you load 
> >> the page (ie. for <input required>) is not a good thing. There are few 
> >> UX rules like that that :invalid currently breaks.
> >>
> >> So, to improve the user experience while using web forms we would like 
> >> to fix that. However, we are wondering if :invalid (and :valid?) 
> >> specifications should be updated to take UX considerations or if a new 
> >> pseudo-classe should be created. Does anyone has an opinion about that?
> > 
> >    <form onblur="event.target.classList.add('examined')"
> >          onsubmit="for (var i = 0; i < elements.length; i += 1)
> >                      elements[i].classList.add('examined')">
> > 
> > ...along with CSS rules like:
> > 
> >    .examined:invalid { ... }
> >    .examined:out-of-range { ... }
> 
> Since then, we have implemented something you can try with Firefox
> 4.0b8: :-moz-ui-invalid and :-moz-ui-valid. By default, all element
> matching :-moz-ui-invalid have a red box shadow.
> 
> The rules for :-moz-ui-invalid are the following:
> a. When not focused (AND list)
>  1. The element has its default value changed OR the element is in a
> form that the user tried to submit (but was invalid) ;
>  2. The element is invalid (:invalid applies).
> b. When focused (OR list):
>  1. If the element had :-moz-ui-invalid before it was focused,
> :-moz-ui-invalid applies if the element is invalid (IOW, if the element
> was valid or no style was applying, the element will not be shown as
> invalid as long as the user do not blur the elemnet) ;
>  2. Otherwise, :-moz-ui-invalid will not apply as long as the element is
> focused.
> 
> :-moz-ui-valid is very similar to that.
> Note that we chose to have none of these pseudo-classes applying if the
> form has novalidate attribute and :-moz-ui-invalid always apply if
> .setCustomValidity() has been used to make the element invalid.
> 
> My description is probably not really clear because the UI rules are
> somewhat complicated but we hope this give a nice user experience.
> 
> We would welcome any feedback about these new pseudo-classes.

This seems reasonable. If authors like these, we should add them.


On Mon, 3 Jan 2011, Benjamin Poulain wrote:
> On 12/31/2010 02:13 AM, ext Ian Hickson wrote:
> > On Fri, 24 Sep 2010, Shiv Kumar wrote:
> > > 
> > > Typically, in large organizations, there are folks who clean up 
> > > data. So they will be presented with data that's already entered by 
> > > someone else and their job is to clean up the data. In fact I see 
> > > the new Form API to be a very good candidate for this use case.
> > 
> > Indeed.
> 
> Isn't that targeting the wrong audience?

Yeah, probably. I think it's a bit confusing to have a pseudo-class with a 
name as simple as ":invalid" not apply when a control is invalid, though.

An alternative is to add a pseudo-class for indicating the "ui" part of 
:-moz-ui-invalid... not sure exactly how that would work.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 2 May 2011 15:41:12 UTC