[whatwg] Constraint validation feedback (various threads)

[Ian Hickson]

On Wed, 11 Aug 2010, Jesse McCarthy wrote:
> Ian wrote:
> > 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.

I did eventually add required="", so this is not moot, hopefully.


On Thu, 12 Aug 2010, Aryeh Gregor wrote:
> On Wed, Aug 11, 2010 at 6:03 PM, Ian Hickson <ian at hixie.ch> wrote:
> > 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.
> 
> """
> value
> On getting, it must return the current value of the element. On
> setting, it must set the element's value to the new value, set the
> element's dirty value flag to true, and then invoke the value
> sanitization algorithm, if the element's type attribute's current
> state defines one.
> """
> http://www.whatwg.org/specs/web-apps/current-work/#common-input-element-apis
> 
> That seems to say that setting via .value will set the dirty flag 
> (although setting via .setAttribute() will not).  Am I mistaken?

Hm, yes, you are correct.

I've lost track of the context for this; does the above imply that there 
is a change we need to make?


On Fri, 24 Sep 2010, Mounir Lamouri wrote:
> 
> I don't think having invalid <output> will be confusing for the user 
> given that the authors will have to set a message describing the issue. 
> The authors would have no reason to make this message unclear.

Your optimism about Web authors is higher than mine. :-)


> In addition, <output> is already semantically linked to some elements so 
> marking it invalid should be a hint that they need to be modified.
> 
> For the UI point of view, you can easily found use cases when showing 
> the output is much more convenient that highlighting all elements making 
> the output invalid. For example, in a web application to select courses 
> in a university. If there is an output showing the sum of credits which 
> has to be between 12 and 18, it sounds to be nicer to have the output 
> marked as invalid with a message explaining that the sum of credits has 
> to be between 12 and 18 than having all courses marked as invalid which 
> can be wrongly interpreted.
>
> Though, I don't think the UI is a valid point here. Shouldn't we let the 
> authors choose what UI they want to implement and just give them the API 
> to do it?

Well the setCustomValidity() API is just to set the UI; if they want to do 
their own UI then they can just do that without using the method at all.

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