[whatwg] :invalid
Ian Hickson
ian at hixie.ch
Mon May 2 15:41:12 PDT 2011
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list