[whatwg] Improve select required

On Thu, 12 Aug 2010, Mikko Rantalainen wrote:
> 2010-08-11 12:31 EEST: Jonas Sicking:
> > On Wed, Aug 11, 2010 at 2:03 AM, Mikko Rantalainen
> > <mikko.rantalainen at peda.net> wrote:
> >> Stuff I don't want to see (combined with @required):
> >>
> >> - first option is always special
> >> - empty string as the value is special
> >> - option without a value is special
> > 
> > Do you consider it a problem for <input type=text required> to treat
> > empty string special?
> > If yes, do you think @required should be removed completely?
> > If no, why do you consider it a problem for <select>?
> 
> Now that you ask, I don't like <input type=text required> to treat empty
> string special either. I'd rather have the author specify the value that
> will be not accepted (I consider @required in the current spec to mean
> "empty string will not be accepted"). As such, I would rather have
> author specify <input type=text disallow=""> to disallow empty string.

In practice, what people want to say is that the user has to enter 
something in the field. I've rarely if ever seen another specific value be 
disallowed by the empty string allowed.


> A possible use case where this feature could be useful already (and
> cannot be fulfilled with @required):
> 
> 1) An user is trying to register a new user account on some system
>    and uses "foo" as the nick name.
> 2) The registration form is otherwise successful, but the system
>    returns with an error message saying that nick "foo" was already
>    taken. In such case, the actual input field could be specified as:
> 
>       <input type=text value="foo" disallow="foo">
> 
>    That is, the field will be prefilled with "foo" but the field also
>    contains extra information that the value "foo" will not be
>    accepted in any case. The prefilled "foo" may have some value for
>    the use and as a result, it does make more sense to prefil with
>    "foo" instead of presenting an empty field with @required.

Sure, but there it's not just "foo" that's disallowed, it's any registered 
username, and the better UI still would be to use a script to dynamically 
check the values as the user types them (with setCustomValidity()).


> The same behavior can already be implemented with @pattern but I believe 
> that @disallow would be easier to understand to most authors. If 
> @disallow were introduced, the @required should be removed completely 
> because it doesn't provide any functionality not provided by @disallow.

I think disallowed="" would be a lot more confusing for most authors.


On Mon, 13 Sep 2010, Mounir Lamouri wrote:
> 
> I am glad that select required has been accepted and introduced in the 
> specifications. However, I have the feeling we could try to improve that 
> feature.
> 
> Currently, if multiple is set or size>1, having no option selected make
> the element suffering from constraint validation. If multiple is not set
> or size=1, the element suffer from constraint validation if the
> "placeholder label option" is selected. This is not really
> straightforward and the "placeholder label option" thing even less.
> 
> We could keep the rule "if an option is selected then the element
> requirement is fulfilled" even for non-multiple select with size=1
> select. However, we know that authors put options they don't want to be
> selected. It seems that there is two reasons:
> 1. want to show a placeholder
> 2. they don't use <optgroup> so they use an option with no value to show
> a group name or a separator

Reason 1 seems reasonable. Reason 2, not so much, as there's already a 
solution for it: use <optgroup>. So let's ignore reason 2. Are there any 
cases of reason 1 where you might have more than one placeholder, or where 
it could not be the first one? If not, then it seems what we have now is 
simplest to explain.


> I see a few ways that may fix that:
> 1. Select elements will suffer from being missing if there are no
> options selected or all selected options have no value (empty string).
> 2. Introduce a placeholder boolean attribute for <option> and select
> elements will suffer from being missing if there are no options selected
> or selected options all have the placeholder attribute set.
> 3. Introduce a placeholder attribute for <select> which will show the
> text as a placeholder. So, there would be no pre-selected option. Thus,
> the select element would suffer from being missing if no option is selected.
> 
> Solutions 1 and 2 are backward compatible but the last solution isn't
> (ie. the placeholder text wouldn't be shown). However, a workaround can
> be found using javascript: if an option marked as disabled and selected
> is inserted as the first child of a select, it will be shown but not
> selectable (tested with Chromium 7.0.503, Firefox 4 b6pre and Opera
> 10.70). Actually, it looks like this behavior is forbidden by the
> specifications...
> 
> Solution 3, seems to be the nicest and is consistent with the other part 
> of the specifications (placeholder would be used in <input> and 
> <select>).

There's also solution 4: make the first <option> special if it has 
value="" (i.e. the spec's current solution).

I don't think we should rely on JS for back-compat if we don't have to. So 
#3 is IMHO not an option.

I don't really see what value #2 and #3 have over what the spec says now. 
#2 in particular is more complicated (it adds an attribute). #1 could 
work, but I don't really see why you would have an <option> with value="" 
that wasn't the only placeholder <option>.

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

Received on Monday, 15 November 2010 18:16:46 UTC