[whatwg] Constraint validation feedback (various threads)
ian at hixie.ch
Mon Nov 15 18:05:55 PST 2010
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.
> 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.
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg