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 <i...@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. `._.-(,_..'--(,_..'`-.;.'
