[whatwg] Forms-related feedback

On Wed, 21 Nov 2012, Mounir Lamouri wrote:
> On 20/11/12 22:51, Ian Hickson wrote:
> > On Tue, 20 Nov 2012, Mounir Lamouri wrote:
> >> > 
> >> > 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(). [...]
> >
> > Done, though I described it in a different way. (I hope it's 
> > equivalent.)
> 
> I think there are two behaviour that you seem to have described differently:
>
> - in step 12, if you take the example page [1], setting the value to 21 
> and calling stepDown() should change the value to 20 and setting it to 
> 19 and calling stepUp() should change it to 20. This how it is 
> implemented in Opera and Firefox and this how the Chrome's UI behaves. 
> As far as I understand the spec you wrote, those two examples would give 
> respectively 10 and 30.
>
> [1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918
>
> - I believe that when the value is set to below min and n < 0, we should 
> not change the value. Same thing for value below max and n > 0. This is 
> the behaviour all UA currently have with stepUp() and stepDown() 
> (though, the previous spec was requiring that) and this is Chrome's UI 
> behaviour. I think that behaviour makes more sense UX-wise because going 
> down or up and having the value going the opposite way is just weird and 
> unexpected.

Done.

For this:

   <input type='number' min='10' step='10' max='21'>

...if the value is 22 and you step up (with the UI), Chrome sets it to 21. 
(Opera does nothing.)

Per spec, stepUp() now would leave this unchanged (like Opera).

(I tried to test Firefox but I couldn't get my build to show UI for 
type=number. Not sure if I'm on the wrong channel or something?)

Also, note that per the new spec if stepUp() or stepDown() are called with 
an argument that isn't 1, it's ignored if the value isn't on a valid step. 
So in the example above, if value=22 and you call stepDown(5), it only 
goes down to 20, not 10. Is that ok?

Also, if you call it as stepDown(-2), it goes down to 20, it's not left at 
22, because the argument is ignored and the method itself is used to 
determine the direction if we're not on step. Is that ok?

Similarly, if you're at 10, and you call stepUp(1), it goes to 20, but if 
you call stepUp(2), it stays at 10, because 30 is out of range (max 21). 
Is that ok?


> >> > [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="".
> >
> > I'm open to doing that too; what would you preference be?
> 
> Maybe if value isn't valid, we could have it changed to the step base or 
> |min + (max - min)/2| and exit the steps if stepDown() or stepUp() is 
> called. (I think even if stepDown(hugeNumber) is called, we should still 
> just set the value and do nothing else.) I would tend to prefer step 
> base mostly because it would know set it to the default value if there 
> is a default value. However, I think step base is quite a bad solution 
> for some types. Maybe we could use the "default value" if there is such 
> a concept for the type or the "step base" otherwise?

It's probably simple enough for authors to check valueAsNumber is not NaN 
and then have them set it to the value they want as the default, if 
they're calling the stepUp/stepDown methods. I've left this as throwing if 
the value isn't a number.


On Sun, 25 Nov 2012, Scott González wrote:
> 
> 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 that makes sense for the UI, but for the methods I'm less sure, 
given how easy it is to check for this case and do whatever behaviour 
makes the most sense for the control.


On Thu, 22 Nov 2012, Markus Ernst wrote:
> Am 22.11.2012 01:51 schrieb Ian Hickson:
> > On Sun, 14 Aug 2011, Timo Beermann wrote:
> > > 
> > > It should be able to implemet checkboxes, where by only 
> > > activating/deactivating this single checkbox you can 
> > > active/deactivate multiple other checkboxes. That is possible with 
> > > scripting today, but it should be possible without scripting, only 
> > > with HTML/CSS. Because some users deactivate Scripting (for security 
> > > or whatever other reason) and on other computers (school, 
> > > university, work,...) you are not able to change the settings, even 
> > > if you want to. E.g. I use NoScript and only allow scripting on very 
> > > few trusted sites, that really need it.
> > 
> > I haven't added this yet, but it is already logged as a possible 
> > future extension, so it's possible it may be added in the future.
> > 
> > What would be helpful though is examples of sites that do this kind of 
> > thing, so that we can study how necessary it is, and how to implement 
> > it. For instance, are the dependent fields always in a <fieldset>? Are 
> > they always other checkboxes? Is there more complex logic than just 
> > "check box A is checked so those controls are enabled"?
> 
> This seems to be a special case of a larger problem to me. In order to make
> forms behave intelligently without scripting, there are more similar tasks:
> - Check/uncheck check and radio boxes based on the selected value of a select
> element (or even on the values of other input elements)
> - Enable/disable or make readonly any kinds of controls based on the state or
> value of an other element
> - Or even show/hide a set of elements based on the state or value of an other
> element
> 
> Maybe, instead of adding that kind of functionalities to form elements, 
> it might be worth thinking of a different way. E.g., define a set of 
> scripting actions that are considered as very useful for UIs, and have 
> no security issues, and let UAs execute that kind of scripts even if 
> scripting is actually disabled, or let UAs offer a user setting such as 
> "Allow only useful form actions" or whatever.

I'd be open to speccing something like this, but it needs research to 
indicate what these common actions are.


On Fri, 23 Nov 2012, Michael A. Puls II wrote:
> > 
> > What would be helpful though is examples of sites that do this kind of 
> > thing, so that we can study how necessary it is, and how to implement 
> > it. For instance, are the dependent fields always in a <fieldset>? Are 
> > they always other checkboxes? Is there more complex logic than just 
> > "check box A is checked so those controls are enabled"?
> 
> My non-web use-case is with 
> <https://addons.opera.com/en/extensions/details/gmail-compose/?display=en> 
> (options.html in the unzipped package). I *disable* a checkbox when 
> another checkbox is checked. I just use addEventListener('input') and 
> check for e.target.checked to decide what to do.

Thanks. This kind of thing (though mainly for Web apps) is just the kind 
of thing we would need to document to learn how to add this.


> However, it'd be cool if there were @disables and @enables for 
> checkboxes (at least) where you can specify a list of controls (that 
> match @name I guess). Those controls would still fire 'input' and 
> 'change'.
> 
> In my case, since I'm already using JS, it's no biggie, but it'd still 
> be cool to do that part without JS.

(That's what the old 'onforminput' handlers were intended for.)



On Tue, 27 Nov 2012, Mikko Rantalainen wrote:
> Ian Hickson, 2012-11-22 07:15 (Europe/Helsinki):
> > On Wed, 21 Nov 2012, Mounir Lamouri wrote:
> >> Then, maybe a better naming could be "datetime-utc"?
> > 
> > I think that would mislead authors into thinking that the UI that 
> > users will see is one that asks for a UTC time. That kind of UI is the 
> > worst UI for this kind of feature, so that would be misleading.
> 
> I'd suggest "datetime-absolute" because the other variant is "floating" 
> or "relative" (to local politically decided time which may vary 
> depending on future political decisions).

We could rename "datetime" to "datetime-absolute" and leave 
"datetime-local" as named, but I'm not really convinced that's much better 
than what we have now.


> > It's not a question of which is _used_ more, it's a question of which 
> > is _authored_ more. As far as I can tell, the use cases for floating 
> > times are basically cross-time-zone transport facilities, e.g. plane 
> > tickets, while the use cases for absolute times are anything involving 
> > coordination amongst multiple people in multiple time zones, e.g. 
> > meetings (in person or online), game events, product launches, online 
> > live streaming events...
> 
> At least here in Finland, floating times are also used for scheduling 
> repeating events (e.g. meetings or lectures). I'd much prefer always 
> scheduling everything in absolute time (UTC) but usually other people 
> are not happy with that.

That makes sense.


> A good UI for relative/floating datetime would be to request user to 
> define date and time without any hint about the timezone.

I'd say the main UI for "absolute" times would look the same, it would 
just assume the user's geographical location to determine the time zone 
offset. Maybe the UI would allow the user to access more explicit controls 
for time zone area or time zone offset via the context menu, but I 
wouldn't expect that by default.


> However, I'm not sure how this can be presented to the user. In the 
> example above I suggested that time input UI should be accompanied with 
> local time zone ("Europe/Helsinki" in my example). However, that would 
> suggest that this info would be transferred to the server and that the 
> server is expected to follow political time zone changes to that 
> timezone. The user could be assuming that he has defined a specific time 
> in a specific timezone (an absolute time as far has he knows).
> 
> In the reality, the server would like to transfer *the responsibility* 
> for the possible future time zone changes to the user -- the server 
> expects user to come by and modify the absolute time in case the user 
> local timezone has been modified since entering this absolute time. I 
> have absolutely no idea how on earth this could be explained to casual 
> user. And even if it could be explained, I'm pretty sure the end user 
> wouldn't be happy with that responsibility.

Yeah. Indeed.


> The next best choice would be to have datetime-with-timezone but 
> unfortunately
> 
> (1) Official database for all timezones does not exist
> (2) Official timezone names (or labels) do not exist
> (3) Timezones are subject to future political decisions
> 
> The problems (1) and (2) make transferring the timezone information from 
> the end user to the server very problematic and the problem (3) makes 
> any work to fix (1) and (2) a bit pointless. This is because even if UA 
> could successfully inform the server about the correct timezone, the 
> server could be using a week old timezone data that is not up to the 
> latest political events. Or the server might be using latest timezone 
> data but the UA could be using three year old data. In either case, the 
> absolute time in UTC could be different for the server and UA.

Indeed.

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