Re: [whatwg] Make stepUp() and stepDown() more developer-friendly
On Tue, Nov 20, 2012 at 5:55 PM, Ian Hickson wrote: > > I can list out the steps we take for all conditions, but I'd like to > > hear everyone's thoughts on the various cases where you're suggesting > > that the methods do nothing. > > Mostly I agree with Mounir here, but I'm curious about what you think > should happen for the case where there's no value, and the case where the > control isn't a numeric/date/time type. I could see an argument for > stepping from the default in the former case (Mounir, what do you think > about doing that?) but for the latter case I don't really see any point > doing anything but throw an exception, as Mounir suggested. For any non-parsable value (including no value), we start at 0, take the step, then confine to a valid step within min/max. I think it makes sense to throw if the control doesn't support stepping.
Re: [whatwg] Make stepUp() and stepDown() more developer-friendly
On 20/11/12 22:55, Ian Hickson wrote: > On Tue, 20 Nov 2012, Scott González wrote: >> >> Can you explain why these methods should be no-ops if the value is above >> the max or below the min? In jQuery UI, we decided that using these >> methods should always result in a valid value. > > I actually missed that in Mounir's suggestion, and the spec now rounds to > the nearest allowed value in that case, rather than doing nothing. > > Mounir: is that ok? As said in my reply to "Forms-related feedback" thread, I think it is weird to have stepDown() going up or stepUp() going down. Users should understand that they can't go down if the down arrow isn't doing nothing. FWIW, this is the behaviour Opera and Chrome UI's have. This is also the behaviour stepUp() and stepDown() have in Gecko and Presto. >> I can list out the steps we take for all conditions, but I'd like to >> hear everyone's thoughts on the various cases where you're suggesting >> that the methods do nothing. > > Mostly I agree with Mounir here, but I'm curious about what you think > should happen for the case where there's no value, and the case where the > control isn't a numeric/date/time type. I could see an argument for > stepping from the default in the former case (Mounir, what do you think > about doing that?) but for the latter case I don't really see any point > doing anything but throw an exception, as Mounir suggested. I also replied about the no value case in "Forms-related feedback" thread. I believe it might be better to set the value to something. I'm not sure which value should be used for that. Cheers, -- Mounir
Re: [whatwg] Make stepUp() and stepDown() more developer-friendly
On Tue, 20 Nov 2012, Scott González wrote: > > Can you explain why these methods should be no-ops if the value is above > the max or below the min? In jQuery UI, we decided that using these > methods should always result in a valid value. I actually missed that in Mounir's suggestion, and the spec now rounds to the nearest allowed value in that case, rather than doing nothing. Mounir: is that ok? > I can list out the steps we take for all conditions, but I'd like to > hear everyone's thoughts on the various cases where you're suggesting > that the methods do nothing. Mostly I agree with Mounir here, but I'm curious about what you think should happen for the case where there's no value, and the case where the control isn't a numeric/date/time type. I could see an argument for stepping from the default in the former case (Mounir, what do you think about doing that?) but for the latter case I don't really see any point doing anything but throw an exception, as Mounir suggested. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Make stepUp() and stepDown() more developer-friendly
Can you explain why these methods should be no-ops if the value is above the max or below the min? In jQuery UI, we decided that using these methods should always result in a valid value. I can list out the steps we take for all conditions, but I'd like to hear everyone's thoughts on the various cases where you're suggesting that the methods do nothing. On Tue, Nov 20, 2012 at 6:49 AM, Mounir Lamouri wrote: > Hi, > > Currently stepUp(n) and stepDown(n) are very basic methods. They more or > less do value += n * allowedValueStep; with n = -n; if stepDown() was > called. In addition of being pretty dumb, there are a lot of reasons why > they can throw. > > At Mozilla, we think that the main use case for stepUp() and stepDown() > is to create a UI with spin buttons: clicking on the up arrow would call > stepUp() and clicking on the down arrow would call stepDown(). Such a > use case needs methods that do better than just adding n * > allowedValueStep. > In addition, we think that throwing is very often a bad idea and that > should happen when the developer clearly did something wrong. > > So, we would like to change the stepUp()/stepDown() algorithm to match > the following behaviour: > - we only throw if the input type doesn't allow those methods or if > there is no allowed value step; > - if the value isn't a number (aka empty string), we should just exit > the steps; > - if the value is below the minimal allowed value and n is negative, we > should exit the steps; > - if the value is above the maximal allowed value and n is positive, we > should exit the steps; > - if the element is suffering from a step mismatch, and n is negative, > the value should be changed to the next valid value. Otherwise, it > should be changed to the previous allowed value; > - newValue = value + n * allodValueStep; > - if the newValue is below the minimal allowed value, the newValue > should be equal the minimal allowed value; > - if the newValue is higher than the minimal allowed value, the newValue > should be equal the minimal allowed value. > > Such a behaviour creates a real added value in stepUp() and stepDown() > that make those methods useful compared to simply do value += n * > allowedValueStep; and prevent throwing when there is no need to. > > It is interesting to see that spin buttons in Chrome > have that behaviour [1] but stepUp() and stepDown() do not. > > Opera has the same kind of UI behaviour than Chrome and > stepUp()/stepDown() tries to be more clever than what the specifications > say (it is clamping to the nearest allowed value). However, it is still > throwing too much. > > You can try the implementation of stepUp() and stepDown() in Firefox > desktop by enablinig the pref "dom.experimental_forms" or by using > Firefox Android (no need to toggle any pref). > > You can use this page to test: > http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918 > > [1] The only difference between Chrome's spin buttons behaviour and our > proposal is that when value is the empty string, it is setting value to > 0 and continue to the next steps (unless the 0 is below the minimal > allowed value and n < 0, in that case value=min). It might be > interesting to specify something better than "do nothing" if value="". > > Cheers, > -- > Mounir >
