W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2010

[whatwg] :invalid

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 31 Dec 2010 01:13:17 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1012310038520.28593@ps20323.dreamhostps.com>
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?

On Thu, 23 Sep 2010, Boris Zbarsky wrote:
> 
> I was actually thinking about this the other day...  We could add a new 
> pseudo-class for matching form controls that have their default value 
> (or that don't, depending on how we expect this to be used).  then you 
> could style :invalid:not(:has-default-value) specially, say....
> 
> Or I suppose we could just add a new pseudo-class that means the above.

On Fri, 24 Sep 2010, Simon Pieters wrote:
> 
> That wouldn't get the right UX if the user tabs through a required field 
> or tries to submit a form without touching a required field.
> 
> I was thinking of :invalid:dirty where :dirty matches form controls that 
> have received and lost focus or its form has been tried to be submitted, 
> or some such.

It's not entirely clear to me what the intended UI is here. If the goal is 
to only style form elements for (in)validity after they've lost focus or 
after their form is submitted, it seems a couple of scripts on <form> 
would be the way to go:

   <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 { ... }


On Thu, 23 Sep 2010, Boris Zbarsky wrote:
> 
> Are there cases when pages would set invalid default values and want 
> them flagged as such in UI?

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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 30 December 2010 17:13:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:02 UTC