[whatwg] WebForms2 validity

It's proposed below to remove checkValidity() -- if people have an opinion 
on this, please do speak up.

On Tue, 28 Oct 2008, Eduard Pascual wrote:
> On Tue, Oct 28, 2008 at 8:09 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 9 Feb 2007, Sean Hogan wrote:
> >>
> >> Many textual input form-controls would begin in one or another 
> >> invalid state (valueMissing, patternMismatch) however authors would 
> >> typically want CSS validity styles to apply only after 
> >> checkValidity() - either a manual one or the automatic one performed 
> >> by form-submission.
> >
> > Why?
> 
> I agree with Sean's idea: at least on the initial state, controls 
> showing up with "invalid" styling can be quite confusing to many users. 
> It may depend a lot on the context, and even more on the user: although 
> the initial "" for a required text field would be invalid, and even 
> would make sense to visually convey that fact, many users may wonder 
> "What did I wrong if I didn't do anything yet?".

The only way that text field would be invalid is if it had required="" 
set; and in that case, one could disable the styling using :required to 
change the styling in some appropriate way.


> The best solution I can think of this would be an additional 
> pseudo-class, such as ":default", ":initial-value", ":non-modified", or 
> anything like that (I'm really bad at naming stuff, so please take those 
> only as *examples*, because that's what they are), which could be used 
> together depending on the needs of each site or application, like this:
>
> :valid {
> // code for "green" higlighting
> }
> :invalid {
> // code for "red" highlighting
> }
> :default {
> // overriding code to remove highlighting (or to apply "white" highlighting)
> }
> :default:invalid {
> // code for "yellow" highlighting
> }
> That's just an example. The idea is that an application may need to
> convey (through styling the validity pseudo-classes) the meanings "you
> have put something wrong here" and "you have to provide something
> here" as different concepts.

That would be interesting. It is, however, out of our scope. :-) If you 
want to follow up on this, I recommend bringing it up with the CSS working 
group at www-style at w3.org.


On Tue, 28 Oct 2008, Philipp Serafin wrote:
> 
> This seems to overlap with the "@placeholder" proposal. Maybe both 
> proposals could be merged somehow?
> 
> Ideas:
> a) Don't include :default but instead define :invalid so that it won't
> be set as long as the placeholder is visible;
> b) get rid of the placeholder attribute and use :default instead;

I don't really like the idea of making features interrelated in this way. 
It makes things really complicated to spec, implement, test, and use.


On Tue, 28 Oct 2008, Nils Dagsson Moskopp wrote:
>
> make an easy rule into a complicated one to cater to an unknown use
> case. yeah. way to go.
> </sarcasm>

Please don't be sarcastic on this list. :-)


> fact: invalid content is invalid. i'd use javascript to change the 
> element class from "never given focus" to "had focus" using onclick in 
> your case.

I agree that this seems like a better solution.


On Wed, 29 Oct 2008, Sean Hogan wrote:
>
> Ok. But what's the use of checkValidity() on form-control-elements?
> Isn't it just:
>  function() {
>    if (!this.validity.valid) this.dispatchEvent("invalid");
>    return this.validity.valid;
>  }

It's more like

   if (this.willValidate && !this.validity.valid)
     // dispatch invalid and return true
   else
     // return false

...but yes.

We could remove it, true. It's not that useful.

Do people want to keep it?


> > > Many textual input form-controls would begin in one or another 
> > > invalid state (valueMissing, patternMismatch) however authors would 
> > > typically want CSS validity styles to apply only after 
> > > checkValidity() - either a manual one or the automatic one performed 
> > > by form-submission.
> > 
> > Why?
>
> I would probably now agree that the default should be immediate 
> application of :valid / :invalid styling which can worked-around with 
> script. The opposing view (what I would have said a year ago) is...
> 
> I think that's the way it usually is now. More specifically:
> 1. It could be confusing to have :invalid styling on form-controls when the
> page first loads.
> 2. It could be distracting for the styling of a form-control to switch between
> :valid and :invalid while the user is typing into it.
> 3. It could be distracting for the :valid and :invalid styles to apply before
> the user tries to submit or explicitly requests the data to be checked.
> 
> #2 can be worked around using :focus. I can't see how #1 and #3 can be worked
> around without script.
> A :validated pseudo-class that applied after checkValidity() is called or
> form-submission has been attempted would give some extra flexibility in the
> noscript scenario.

Most controls will be valid unless they are required, as far as I can 
tell, so I'm not sure it's that big a deal.

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

Received on Tuesday, 11 November 2008 17:25:48 UTC