Re: :invalid

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