- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 23 Sep 2010 22:58:55 -0700
- To: Ryan Seddon <seddon.ryan@gmail.com>
- Cc: Mounir Lamouri <mounir.lamouri@gmail.com>, www-style@w3.org
On Thu, Sep 23, 2010 at 9:46 PM, Ryan Seddon <seddon.ryan@gmail.com> wrote: > Yes, yes, yes! > > I was actually drafting an email myself on this very subject for www-style. > I wrote an article [1] discussing the UX issues that stop this from being > really great. > > At the moment a field is invalid straight away if it has the required > attribute. > My idea was to have a third state that a required field can be > indeterminate. > The same state that radio and checkbox inputs have [2]. Basically a field > technically is neither valid nor invalid until it has a value to work with. > > Another potential solution, although probably more convoluted, was to change > the meaning of the :empty pseudo-class to also include empty inputs and not > just elements with no children. > > [1] http://www.alistapart.com/articles/forward-thinking-form-validation > [2] http://www.w3.org/TR/css3-selectors/#indeterminate Note that we (mozilla) have some pretty specific requirements as to when we want to render a form control as invalid. Currently we're planning on rendering a control as invalid if: User modifies the value of a control and then moves focus away from the control OR User attempts to submit the form which the control belongs to After this point the control will render as invalid as soon as it is invalid. So note that this doesn't only affect the behavior of required form controls. Consider for example a control like: <input type=tel pattern="\d\d\d-\d\d\d-\d\d\d\d" name=usertel> For such a control, we won't render the control as invalid as soon as the user starts typing the control, even though as soon as the first digit is typed the control will no longer match the pattern. Only once the user moves focus away from the control, if the value still doesn't match the pattern, will we render it as invalid. While we could try to come up with some set of selectors which can be combined together to accomplish this set of rules, I think this has a couple of problems. First of all it is somewhat inflexible. If we want to change the above rules we might need to invent even more selectors. Second, it makes it more cumbersome for authors to override the default UA stylesheet since that stylesheet might be different in different UAs. Instead we've been thinking of two different solutions: 1. Change the way :invalid works such that it is defined to only match when we want to *render* invalid UI, not anytime a form control doesn't match its constraints. 2. Introduce a new pseudo class :invalid-ui which only matches when we want to render invalid UI. (For now we'd -moz- prefix it of course) Both these solutions are flexible in that it allows us to adjust the rules for when we want to render UI without having to introduce additional complexity. And both these solutions allow authors to easily override the default style and introduce their own. The downside with solution 1 is that it affects non-styling uses of selectors. Such as the DOM functions querySelector/querySelectorAll. The downside with solution 2 is that it requires authors to know about and use :-moz-invalid-ui to override our default styling. Definitely interested to hear opinions on what people think about these solutions. / Jonas
Received on Friday, 24 September 2010 05:59:52 UTC