[whatwg] Constraint validation feedback (various threads)

[Jesse McCarthy]

On Tue, 10 Aug 2010, Jesse McCarthy wrote:
>> I consider it highly desirable to have some way to differentiate between 
>> SELECT values explicitly selected by the user and values that were 
>> selected by default and unchanged by the user.

> I have a note in the spec to add a feature at some point to track what 
> controls have been changed and what haven't, but that doesn't seem to have 
> the need for urgency that Jonas describes required="" as having, so I 
> still think we should keep delaying that one until browsers have caught 
> up.

Allow me to clarify.  What I'm referring to is having @required for SELECT 
and some way to include a label, so that the user must deliberately select 
something in order for the form to be submitted.

My comment was a response to comments you made (see below) that suggested 
that @required is not important for SELECTs without @size or @multiple, and 
that an initial label option, e.g. <option value="">Choose One</option>, is 
"invalid".

Not having @required for SELECT and simply omitting an initial "label" 
OPTION would make the first OPTION (whatever it is) selected by default, 
which would make it impossible to differentiate between the user 
deliberately selecting that OPTION and simply leaving the default.

Having @required for SELECT and some way to specify a label (as you've just 
described), so that the user must deliberately select something in order for 
the SELECT to not suffer from being missing, satisfies the need I described.


Regarding how to implement @required & a label for SELECTs, some people have 
resisted the idea of implementing it so that empty string would make it 
suffer from being missing.  Tab Atkins Jr. said this in response:

> Yes?  And when that's valid, you should just *not use @required*, same as 
> when an empty string is a valid value for an <input type=text>.

I've been wondering if someone can present a use case where that logic is 
not sufficient.  I haven't thought of any yet, but I'm not sure there aren't 
any.

Since these specifications have a huge impact on developers for years to 
come, it's probably better to be on the safe side and just provide some 
explicit way of marking up a label, such as the means you described.

Is the logic that an OPTION is "special" if it's first and has value="" 
preferable to using an attribute to indicate that?  E.g. <option 
dummy>Label</option> (not suggesting that as an actual attribute name, just 
using it for illustration).  Or perhaps @placeholder could be a boolean 
attribute on OPTION?


Jesse


On Mon, 9 Aug 2010 Ian Hickson  wrote:

> It's impossible to submit a <select> element (without a size="" attribute 
> or multiple="" attribute) without it having a value -- essentially, 
> required="" is already implied.


> On Thu, 22 Jul 2010, Mounir Lamouri wrote:
>> 1. A typical use case of <select> is to have <option value=''>Choose an 
>> option</option> as a default value. Having @required would prevent 
>> authors to write any js check when they are using <select> like that.

> That seems like an invalid use of <option> to me. It would be better as:

>   <label> Choose an option: <select> ... </select> </label>


> Currently you can do this just by not providing empty values and not using 
> multiple="" or size="".



----- Original Message ----- 
From: "Ian Hickson" <ian at hixie.ch>
To: <whatwg at whatwg.org>
Sent: Wednesday, August 11, 2010 6:03 PM
Subject: Constraint validation feedback (various threads)


On Tue, 20 Jul 2010, Mounir Lamouri wrote:
>
> At the moment, three form elements are barred from constraint
> validation: object, fieldset and output. I can understand why object and
> fieldset are barred from constraint validation but I think output could
> use the constraint validation.

The user can't edit the value of <output>, so the only time this would be
helpful is when you have script, with the script setting the validity
using setCustomValidity(). But then the script can just as easily set it
on the control that's actually making the output be invalid. That would
also be better UI -- having the user agent point out the <output> control
is invalid would likely just infuriate users who couldn't tell what they
had to do to change the value.


On Tue, 20 Jul 2010, Mounir Lamouri wrote:
>
> I'm wondering why there is no categories for elements candidate for
> constraint validation. In the current state of the specs, all listed
> elements are candidate for constraint validation except when they are
> barred from constraint validation. Barring an element from constraint
> validation when it is in a certain state seems good but having elements
> always barred from constraint validation seems a bad idea. It makes them
> having the entire constraint validation API for nothing.

Not quite nothing -- they have it so that you can iterate through
form.elements and use the constraint validation API on all of them.


On Tue, 20 Jul 2010, Simon Pieters wrote:
>
> I believe some elements have the API but are barred because it makes it
> easier to loop through form.elements and do the validation stuff without
> checking if the validation stuff is available on the element. (Same
> reason <textarea> has .type.)

Right.


On Fri, 23 Jul 2010, Mounir Lamouri wrote:
>
> But <keygen>, <object>, <fieldset> and <output> are barred from
> constraint validation and <textarea>, <button>, <input> and <select> are
> not [1]. Half of the elements have a useless API, that sounds too much
> for me. I think it's not so complicated to loop through the form
> elements and checking if it implements a part of the constraint
> validation api or checking the tag name.

I don't understand. Why does it matter?


On Fri, 23 Jul 2010, Jonas Sicking wrote:
>
> It probably results in less code if a handful of implementations have to
> add a few stubbed functions, than if millions of pages all will have to
> check if constraint validation is there before using it.
>
> Not to mention that I trust you (a implementor) to get this right, a lot
> more than I trust thousands of webauthors to get this right.

Indeed.


On Thu, 22 Jul 2010, Aryeh Gregor wrote:
>
> maxlength predates all the other form validation attributes by many
> years.  Historically, browsers would prohibit users from entering text
> beyond the maxlength of an input or textarea, but would not prohibit
> form submission.  HTML5 changes this:

It only changes this in theory. In practice the result is the same as far
as I can tell.


> """
> Constraint validation: If an element has a maximum allowed value
> length, and its dirty value flag is true, and the code-point length of
> the element's value is greater than the element's maximum allowed
> value length, then the element is suffering from being too long.
> """
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#limiting-user-input-length
>
> If I read it correctly, this means that pages that previously worked
> no longer will, if a script sets the value of the input to something
> longer than the maxlength.

The script setting the value doesn't set the dirty flag. The only way this
could be a problem is if the user edits the control and _then_ the script
sets the value to an overlong value.


> These two test cases show that Opera maintains the legacy behavior (not
> compatible with the spec) and submits the forms regardless of maxlength
> violations, while WebKit (Chromium) blocks submission as required by the
> spec:
>
> data:text/html,<!doctype html><body
> onload="document.getElementById('a').value='foo'"><form><input id=a
> maxlength=2><input type=submit></form>Try to submit the form
>
> data:text/html,<!doctype html><form><input id=a><input
> type=submit></form><a href=""
> onclick="document.getElementById('a').maxLength = 2; return
> false">Enter "foo" into the input, click here, then try to submit</a>
>
> Should the spec (and WebKit) be changed here, or should Opera change?

WebKit is wrong here. Opera matches the spec as far as I can tell. The
submission should only be blocked if the user edits the value before
onload in these examples.

On Wed, 28 Jul 2010, Mounir Lamouri wrote:
>
> At the moment, to suffer from a pattern mismatch an element needs a
> non-empty value and a specified pattern (and the pattern should not
> match the entire value) [1]. So, if, for any reason, an author write
> <input pattern=''>, the element would be always suffering from a pattern
> mismatch except when value=''.

Indeed. The same occurs if the author writes <input pattern=' '> -- it
will only work if the user types in a single space.


> I do not imagine an author would like to make its element always invalid
> and even if it is, I think most people will try to write pattern='' to
> reset the pattern.

Presumably they would find pretty quickly that they were wrong to think
that would work. :-)


> If someone wants to make the element invalid when the value is not
> empty, he/she can use setCustomValidity or even have a pattern that is
> not empty but can't match the value (like '[]').
>
> So, to prevent any undesirable behavior with this edge case, I propose
> to change:
> [[
> If the element's value is not the empty string, and the element's
> pattern  attribute is specified and the attribute's value, when [..]
> ]]
> to:
> [[
> If the element's value and the element's pattern attribute are not the
> empty string and the attribute's value, when [..]
> ]]

I'm generally not a fan of doing such magic... for every author who will
find it works as they expect, I think there'll be another author wondering
why his attribute is ignored. However, as always, I may be wrong about
this! Has anyone here tried using pattern="" to disable the attribute?


On Thu, 5 Aug 2010, Ola P. Kleiven wrote:
> > On Mon, 14 Jun 2010, Ola P. Kleiven wrote:
> > > barnesandnoble.com (using required on visible elements that are
> > > supposed to be empty on submit...)
>
> https://cart4.barnesandnoble.com/account/request.aspx?stage=mainStage -
> click "Create an Account". Will fail unless you fill in the fields in
> the form to the left (which is really unrelated)

> > > ingdirect.com.au (using required on a visible field, but then
> > > emptying the field with JS before submit)
>
> https://www.ingdirect.com.au/client/index.aspx - type any "client
> number" and a 4 digit access code. Click log in. The client number field
> is then emptied by js before submitting but has required=true, causing
> error

> > > usairways.com (using required on hidden elements)
>
> Enter jfk in from or to fields, wait for the autocompletion and select
> "New York, NY (JFK) (John F. Kennedy International Airport)" by hitting
> enter. Then you will get a maxlength error.

This is very useful, thanks.

We could work around the last one by having a script-set value clear the
"dirty" flag. The other two are harder short of using another attribute
than required="".

I haven't changed anything yet. If this becomes untenable, let me know.


On Mon, 9 Aug 2010, Jonas Sicking wrote:
>
> There is another reason to introduce @required on select now, rather
> than in v2. We're already seeing a small amount of complexity in
> introducing @required because it's preventing existing sites from
> working due to sites already having elements with a 'required'
> attribute. And this is in a situation where @required has never been
> part of any specificiation.
>
> It is likely that if @required gains traction, which I think we're all
> hoping for, that sites will use 'required' attributes on <select>
> elements. This might work just fine as long as browsers ignore this
> attribute. However once browsers attempt to deploy v2, there is a big
> risk that many of these sites will stop working.
>
> We could specify in v1 that @required on <select> always prevents the
> form from submitting, that would make it easier for browsers to
> implement v2. However that would make it harder for sites to deploy v2
> since it would prevent the site from working in any old browsers that
> only support v1.
>
> Thus I recommend that we add @required now.

That's a good point. Ok. Let's add it now.

The use case here is having a <select> which has a bunch of options, none
of which are selected initially, and require that the user pick one.

For list boxes, this is trivial.

For drop-down boxes (size=1), this request is usually paired with a
request for a placeholder-like inline label indicating to the user that he
must select an option, so what we really want is something like:

   <select name="..." placeholder="Label">
    <option value="1"> Value 1 </option>
    <option value="2"> Value 2 </option>
    <option value="3"> Value 3 </option>
    ...
   </select>

...but then the first <option> gets selected and the label isn't shown,
unless we say that a placeholder means no <option> gets selected
automatically. That unfortunately isn't very usefully backwards-
compatible, so that's out.

People today do:

   <select name="...">
    <option value=""> Label </option>
    <option value="1"> Value 1 </option>
    <option value="2"> Value 2 </option>
    <option value="3"> Value 3 </option>
    ...
   </select>

Today this is suboptimal, because "Label" isn't really an option, but we
can define the first <option> of a <select size=1 required> to be a label
if it has its value="" attribute set to the empty string and isn't
disabled and isn't in an <optgroup>.

This has the benefit of paving a cowpath and being minimally invasive in
terms of required changes to pages.

I have now specified this.


On Tue, 10 Aug 2010, Ashley Sheridan wrote:
>
> If you receive an empty text box then a required element works to
> validate against empty input. As you produce the input for the select
> list, it's pretty stupid to say that it shouldn't have an empty string
> for a value because you put it there.
>
> I can think of lots of places where an empty string is in-fact very
> useful for a select element, such as filters on search results forms,
> but if there's any places that I want a value, then I don't leave empty
> elements lying around. If you need to do that, then maybe use radio
> buttons instead.

The way I have specified it, value="" can still be used:

   <select required>
    <option value="">Choose one:</option> <!-- that's the label -->
    <option value="">None</option>     <!-- this is the first option -->
    <option value="apple">Apple</option>
    <option value="peach">Peach</option>
   </select>


On Tue, 10 Aug 2010, Mike Wilcox wrote:
>
> This seems like the ideal situation to use a placeholder attribute:
>
> <select required="true" placeholder="Select an item...">
>     <option value="Foo"> Foo </option>
>     <option value="Bar"> Bar </option>
>     <option value=""> None </option>
> </select>

I considered that, as noted above, but unfortunately it has a poor
backwards-compatibility story.


On Tue, 10 Aug 2010, Tab Atkins Jr. wrote:
>
> Yes, the value used in this situation is essentially a placeholder value
> - it performs the same function as <input placeholder>. However, an
> <input type=text placeholder=foo required> will fail validation if the
> user doesn't interact with it, while a similar <select> will not at the
> moment (it will just submit the first value).
>
> It could be possible to define the interaction of <select>,
> @placeholder, and @required in such a way that it works intelligently,
> so that the <select> with a placeholder fails validation if the user
> doesn't interact with it, but that may be too much magic.

Indeed.


> I think I'd prefer the simple solution of having it fail @required
> validation in the same way that text inputs do - when their value is the
> empty string.

I hope the middle ground I tried to find is satisfactory as well.


On Tue, 10 Aug 2010, Nils Dagsson Moskopp wrote:
>
> Overloading the string value to me seems to be more magic, especially in
> light of the fact that there are legitimate use cases of selecting an
> empty string — I am currently working on a Wordpress plugin, where a
> <select> is used to select (hehe) the locale for an REST API call.
> Setting the locale to an empty string is not an error, it just returns
> unlocalized results.
>
> Not having @placeholder on <select> may be a bit simpler to implement,
> but having it would be more consistent for authors and users alike.

Does the new text work for you?


On Wed, 11 Aug 2010, Mikko Rantalainen wrote:
>
> I would prefer something like this:
>
> <select pattern="(?!myvalue).*">
>   <option value="myvalue">Select an item...</option>
>   <option ...>...</option>
>   ...
> </select>
>
> That is, the author should explicitly specify that the item with the
> special value will not be accepted.

It seems simpler to just not use a value here.


> Stuff I don't want to see (combined with @required):
>
> - first option is always special

As defined it's only special if it is value="" and required="" is present.
Is that ok?


> - empty string as the value is special

It's only special if it's also first... is that worse or better?


> - option without a value is special
>
> If there needs to be some easier way to specify this but the pattern,
> how about @disallow="xyz"?

I think whatever we do here we should definitely just use boolean
attributes rather something special?


On Tue, 10 Aug 2010, Jesse McCarthy wrote:
>
> I consider it highly desirable to have some way to differentiate between
> SELECT values explicitly selected by the user and values that were
> selected by default and unchanged by the user.

I have a note in the spec to add a feature at some point to track what
controls have been changed and what haven't, but that doesn't seem to have
the need for urgency that Jonas describes required="" as having, so I
still think we should keep delaying that one until browsers have caught up.

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