[whatwg] Forms-related feedback

On Wed, 2 Oct 2013, Jonas Sicking wrote:
> Hixie wrote:
> >
> > That's not the only alternative. For example, a third alternative is 
> > that the user's selection (e.g. a directory) is returned quickly, not 
> > pre-expanded, and then any uploading happens in the background with 
> > the author script doing the walk and uploading the files.
> 
> It's unclear to me what you are proposing here. Can you elaborate?

On Wed, 2 Oct 2013, Glenn Maynard wrote:
> 
> The same thing I did, I think: an API to navigate the directory tree as 
> needed, and to never greedily recursing the directory tree.

On Wed, 2 Oct 2013, Jonas Sicking wrote:
> 
> Unfortunately that's forbidden by current specs.

Right, my point is that this would be a new API.

I've filed this bug to track this feature request; if there are multiple 
implementors interested in this, I can add it:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=23988


On Wed, 2 Oct 2013, Jonas Sicking wrote:
> 
> The first application that I could think of that is designed for opening 
> or importing large number of files is iTunes. And indeed on windows 
> where there is no native "open file or directory" widget, they use 
> separate menu items for "import file" and "import folder".

Wow, fascinating.

I guess on Windows then <input type=file multiple> should indeed expose 
two buttons.


> On OSX iTunes relies on the combined file-or-folder picker that's not 
> available on windows.

Right, that picker is what I would have expected on all platforms.


On Wed, 2 Oct 2013, David Dailey wrote:
>
> [...] ability to allow JavaScript, with user-consent, to insert an image 
> file as the src of an <img> into a web page [...]
> 
> It all used to be easy and worked in the two relevant browsers at the 
> time: Netscape and IE. Then someone decided it was a security risk and 
> that it preserved the privacy of the end user more to force him or her 
> to upload the image to the server, create a round-trip from server to 
> client and thence to be able to view a local image in a local web page. 
> The old functionality continued to work in Netscape until its demise, 
> and in IE until maybe version 6. The other browsers viewed the security 
> risk as too high and ultimately IE seems to have agreed, hence breaking 
> previous functionality. [...]
> 
> Anyhow, as I recall, at the time, Hixie commented and someone else 
> chimed in with details (that seemed rather convoluted at the time) 
> saying that it was something people were working on. Has this effort led 
> to fruition?

Yes, you can now read the image data without it being first uploaded to 
the server, via the HTMLInputElement.files API. You can take such a File 
and then display it in an <img> via the Blob API and createObjectURL.


On Wed, 2 Oct 2013, Glenn Maynard wrote:
> 
> Assuming for now that we need separate modes for files and directories, 
> I'd suggest <input type=directory>, which causes a directory picker to 
> be shown, doesn't populate .files at all, and adds an API entry point to 
> retrieve a filesystem.  If somebody suggests an implementable way to 
> expose UI that doesn't need to separate files and directories then we 
> may want something else, but that doesn't seem likely to me.

I think we want to support the Mac-style file+directory mode.


On Thu, 3 Oct 2013, Jonas Sicking wrote:
> 
> I'd rather extend <input type=file multiple> such that platforms that 
> have directories can expose those, and ones that don't just expose 
> files.

Right.


> And on platforms that have combined file-or-directory pickers can render 
> a single button, and platforms that use separate Widgets can render two 
> buttons.

Right.


On Thu, 3 Oct 2013, Jan Tosovsky wrote:
> 
> The missing access to the file system is a blocker now for replacing 
> many client apps to their web counterparts. The basic question is 
> whether web technologies should implement this functionality or not. I 
> think it is a must, though limited to a trusted zone and OSes with file 
> systems.
>
> By that trusted zone I mean a local network (local servers can access 
> the client file system via user action) or Internet location authorized 
> by a specific means (e.g. certificate like Java Applets).

There have been several proposals for doing this kind of thing. I think 
the main mailing list where they've been discussed most recently is 
public-webapps@w3.org. (In practice, there seems to be a lot of different 
things people want that all fall into the same general area, so not much 
progress has been made as far as I can tell. It's also hard to design a 
highly usable system that's also secure. You don't want a "permissions" 
dialog, since that's not very usable or safe, but it's hard to see how 
else you would grant a page access to a remote file system. The <input 
type=file> security model, which works great for reading single files, is 
not necessarily easy to extrapolate to read+write rights to filesystems.)

Anyway, I would recommend taking this up with the people already working 
on this in public-webapps.


On Tue, 15 Oct 2013, Cameron Jones wrote:
> On Mon, Oct 14, 2013 at 9:04 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Thu, 21 Feb 2013, Cameron Jones wrote:
> > >
> > > http://cameronjones.github.com/form-http-extensions/index.html
> >
> > On Fri, 22 Feb 2013, Cameron Jones wrote:
> > >
> > > The motivations are the same which support declarative over 
> > > imperative programming, access to the HTTP protocol methods and 
> > > headers (ETags, versioning), greater flexibility over payload 
> > > binding and the ability to avoid using cookies for session 
> > > continuation.
> >
> > Can you elaborate? What are the end-user use cases that this proposal 
> > would enable, that are not possible today?
> 
> The direct enabler for the end-user is the ability to interact with web 
> sites under the guarantees of HTTP method semantics without the need for 
> them to be using a Javascript-enabled browser.

That's not really a use case, that's more a description of what it does.

What I mean is, can you illustrate an actual end-user scenario, without 
reference to the underlying technologies, that isn't possible today?

For example, a use case for <input type=file> would be "A user wants to 
chnge their profile picture and has a file on their desktop that they 
would like to use for this". Without <input type=file>, this isn't really 
possible on the Web. So, the question is: what isn't possible without the 
feature proposed above?


> The HTTP idempotent methods (PUT, DELETE) guarantee that that multiple 
> identical requests should have the same effect as a single request.

They don't guarantee it, in the same way that a speed limit sign doesn't 
guarantee that cars don't exceed the speed limit, or that the HTML 
comformance criteria guarantee that a <p> won't contain a <div>.


> This alleviates the end-user from potentially executing multiple 
> requests either from hitting 'refresh' or the 'back button' when such 
> requests would have unintended consequences.

Isn't this essentially a solved problem today? I mean, the same way that a 
PUT implementation can check to make sure it doesn't happen twice, a POST 
implementation can as well.


> The ability to set request headers (also without JS) provides a 
> universal method for employing session continuation and request 
> verification through the application of 'capability-based security' 
> tokens as HTTP headers. This can be applied for GET requests without 
> polluting URL queries.

Why is the lack of JS important here? I don't follow. Also, aren't session 
continuation and request verification solved problems by now?

I don't understand exactly how you expect to use this with capability 
tokens. Can you elaborate on this? How would the user interface work?


> The use of HTML declarations, as opposed to Javascript imperative 
> statements, provides the structure of a website for static generation 
> and analysis.

I don't understand what exactly it is you want to statically generate or 
analyse here. Can you elaborate? A concrete example of a real site cast 
into this new paradigm would help illustrate what you mean.


> Web crawlers, screen readers and other HTML tools will have the ability 
> to read, validate or otherwise process the site which would otherwise be 
> effectively impossible if required to define the structure in imperative 
> form.

Can you give examples of sites that Web crawlers, screen readers and other 
HTML tools cannot handle today but that they could handle if this proposal 
was adopted, and how that would look?


> The extension specification also includes the ability to declare HTTP 
> authentication forms, and the ability to 'logout' and clear the 
> authentication cache. In lieu of a Javascript interface, this provides 
> the only ability of this functionality.

Logout seems somewhat well supported today with cookie-based 
authentication, even without script.


On Fri, 18 Oct 2013, TAMURA, Kent wrote:
> On Tue, Sep 24, 2013 at 5:35 AM, Ian Hickson <ian@hixie.ch> wrote:
> > On Wed, 21 Aug 2013, TAMURA, Kent wrote:
> > > On Sat, Jul 13, 2013 at 6:39 AM, Ian Hickson <ian@hixie.ch> wrote:
> > > > On Wed, 9 Jan 2013, TAMURA, Kent wrote:
> > > > > On Wed, Nov 21, 2012 at 7:51 AM, Ian Hickson <ian@hixie.ch> wrote:
> > > > > > On Fri, 7 Sep 2012, TAMURA, Kent wrote:
> > > > > > >
> > > > > > > * For date, datetime, datetime-local, month, time, week, the 
> > > > > > > attribute returns a string in a field. If a field is 
> > > > > > > text-editable, it should return user-editing string like 
> > > > > > > email and number.  If a field has a fixed localized 
> > > > > > > date/time string chosen by a date/time picker, the attribute 
> > > > > > > should return the localized string. [...]
> > > > > > >
> > > > > > > - We can enable text field selection APIs for email, number, 
> > > > > > > and other types
> > > > > >
> > > > > > How would this work when the control isn't a text control? I 
> > > > > > don't understand. For example, consider a date control that is 
> > > > > > actually three separate text fields (year month day); how do 
> > > > > > you envisage the selection API working and how would rawValue 
> > > > > > help with this?
> > > > >
> > > > > I think it's ok that rawValue doesn't work with form controls 
> > > > > without any text. One of use cases of rawValue would be to 
> > > > > handle user input errors.  I think non-text form controls should 
> > > > > be clever enough to avoid bad user input. For example, users 
> > > > > can't set bad values to input[type=range].
> > > > 
> > > > I still don't understand how this would work. You suggest that it 
> > > > should work for type=date, but how? What happens when it's mutated 
> > > > by script, for instance? I really don't understand the purpose 
> > > > here or how it would work to achieve that purpose.
> > > 
> > > As for type=date, rawValue should return what a user see.
> > 
> > What if the user sees a calendar with a date circled? Or the string 
> > "your birthday"? (Exposing that would be a privacy violation.) Or what 
> > if the user doesn't see anything (because it's not a visual UA), but 
> > every time the user focuses it, the user agent plays a tune from one 
> > of Vivaldi's four seasons, followed by a trill to indicate how far 
> > into the season the date is?
> 
> I have no good idea for them.  However I don't think UA provides some of 
> such UIs.

They should, though. At least the calendar UI for type=date. I think we 
should avoid doing anything that prevents user agents from making better 
UIs than we have now.


> The specification allows to implement any UI for form controls, but web 
> authors won't accept UIs which are drastically different from existing 
> implementations. For example, existing implementations of 
> input[type=date] have about 1-line height by default. If a UA provided 
> an inline-calendar-style implementation and it requires 300px height, 
> web authors would have a hard time to design their pages.

Right, it would be like a <select>, which expands when tapped.


> > > Value set by script or not doesn't matter.
> > 
> > I mean, how would the user agent parse the script's new value.
> 
> It's implementation-specific even now, and unrelated to this proposal.

How is it implementation-specific now?

Today, there is a well-defined interface from scripts to the 
user-displayed value, regardless of how the user agent displays the value.

I think making parts of the API UA-specific would be really bad for 
interoperability.


> > > As for type=number, I heard a web author wanted to get invalid value 
> > > typed by a user in order to show friendly error message without HTML 
> > > interactive form validation.
> > 
> > The point of type=number is that the browser can do this, no need to 
> > reimplement it. (If an author does want to reimplement it, Web 
> > Components are presumably the long-term solution: reimplement the 
> > widget.)
> 
> I don't think Web Components becomes widely available in 10 years.

I sure hope it becomes widely available long before 2023.

But we certainly shouldn't spend effort on work arounds for the lack of 
Web Components rather than just work on Web Components. There's an 
opportunity cost here. The more we work on work-arounds, the longer it'll 
be til we have a real solution, and we desperately need a real solution 
for a lot more than just replacing built-in form validation UI.


> Web authors want to replace UA-builtin form validation UI now. Do you 
> think web authors should not use new input types if they don't like 
> builtin form validation UI?

I don't understand what behaviour you would want that you can't get today 
with the existing form validation API, that wouldn't be so drastic that 
you in fact would need a whole new widget.


> > > https://code.google.com/p/chromium/issues/detail?id=263910#c3 This 
> > > is an actual case.  I talked with him, and he said <datalist> didn't 
> > > work in his case because he wanted to show images on choices.
> > 
> > [...] If people want to reimplement widgets, then we should make sure 
> > Web Components can support their particular widget desires. I don't 
> > think it makes sense for us to make the default widgets be able to 
> > support every weird thing people want to do.
> 
> I understand such stance. However it's hard to know whether a request is 
> weird or not.

That's a pretty weird request. I don't think it's hard to know.


> > On Wed, 21 Aug 2013, Anne van Kesteren wrote:
> > > If we start doing this (and other things you proposed) we'll 
> > > constrain future implementation strategies for this control. And 
> > > other implementations might be forced to follow particular 
> > > conventions in order to not break sites. That doesn't seem exactly 
> > > ideal.
> > 
> > Exactly.
> 
> It's too optimistic. We are already constrained.

Nowhere near as much as this would constrain us.


Brian Blakely wrote:
>
> "iPhone OS" introduced the switch control 
> (http://i.imgur.com/TA79fo2.png) in 2007.  Since then, there have been 
> many attempts to recreate this on the Web Platform by hacking existing 
> control types and using a lot of meaningless markup, to varying degrees 
> of success.

This is just a checkbox with different styling.

We should definitely support it, though.


On Tue, 19 Nov 2013, Mikko Rantalainen wrote:
> 
> I agree that the look and feel is different from checkbox but all the 
> differences seem to be purely presentational. If you disagree, you need 
> to elaborate a bit more.
> 
> I'd suggest pursuing something along the lines
> 
> input[type="checkbox"].switch { appearance: lightswitch; }
> 
> instead.

Yes, this seems like the right approach.


> However, if you're requesting for more featured switch seen in e.g. 
> newer Android applications where the switch has embedded text labels to 
> declare the switch positions, there might be need for a new markup.
> 
> An example of such UI in ASCII graphics:
> 
> +----+---------------+
> | °C |========== °F =| Temperature unit
> +----+---------------+

That's basically a two-item <select>, no?

   select:matches(# > option:first-child + option:last-child) {
     appearance: lightswitch;
   }


> The closest thing is allowing to allow rendering a <select> element with 
> just options with a "lightswitch" appearance.

Yup.


On Tue, 19 Nov 2013, Jonas Sicking wrote:
>
> Realistically speaking, I don't think this will help much at all. Few 
> websites like using the default styling for form controls anyway and so 
> people would be just as unhappy with the default switch rendering as 
> they are with the default checkbox rendering.

Possibly.


> The real fix is to allow styling formcontrols. It's one of the most 
> requested features from web developers, yet no one has taken the time to 
> research what it would take to do it.

Isn't that what Web Components is for?


On Tue, 19 Nov 2013, Domenic Denicola wrote:
> 
> Interestingly, Microsoft's Windows Store apps guidelines disagree. I 
> find their reasoning somewhat compelling, although novel:
> 
> http://msdn.microsoft.com/en-us/library/windows/apps/hh465475.aspx
> 
> "Use a toggle switch for binary settings when changes become effective 
> immediately after the user changes them."
> 
> "Use a checkbox when the user has to perform extra steps for changes to 
> be effective."
> 
> These aren't exactly semantic differences, but I think they reveal 
> different underlying semantics. Roughly, we have two controls which each 
> have two states. But the meanings of those two states are completely 
> different for switches vs. checkboxes; perhaps it could be boiled down 
> to "on vs. off for this thing" and "yes vs. no for this option."

On the Web there are checkboxes whose effects are immediate and there are 
checkboxes whose effects only engage when the form is committed; similarly 
for <select> and all the other controls. So on the Web I think this 
distinction is a lost cause.


On Tue, 19 Nov 2013, Michael Zajac wrote:
>
> There is certainly a semantic difference between switches and 
> checkboxes. As much of a difference as between buttons and links.

The difference between a button and a link is that a link has an address 
that you can copy and open in a diffferent browser, while a button 
triggers an action. This seems much more different than checkboxes vs 
switches vs <select>s.


> A checkbox is part of a checklist, something you use to indicate or 
> track the states of things. You put a series of checkmarks on a form, 
> then bring it to the reception desk.
> 
> A switch, like a button, is a mechanical control that actuates 
> something. You flick a switch to turn the light on.

There's plenty of check boxes on the Web that turn lights on. I don't 
think this distinction is true on the Web.


On Tue, 19 Nov 2013, Jukka K. Korpela wrote:
> 
> From the usability and accessibility point of view, this seems to 
> address an important issue. Authors sometimes use checkboxes (or radio 
> buttons) so that changing their state has an immediate effect, even 
> submitting a form. This may violate normal user expectations and can be 
> confusing. Normally, we enter some data, using various controls, and 
> then click on a button (or do something equivalent) to request for an 
> action. Checking a checkbox should not be a commitment, any more than 
> typing text in a feedback form or selecting an item from a dropdown list 
> in an order form should be a commitment.

The same applies to a switch. Toggling a switch shouldn't be irreversible 
either.

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