[whatwg] Forms feedback

[Tab Atkins Jr.]

On Tue, Apr 6, 2010 at 2:00 AM, Ian Hickson <ian at hixie.ch> wrote:
> Well you currently can do this by using the onbeforeprint and onafterprint
> hooks, though that's not exactly pretty. Hopefully it will also be
> possible with media-specific CSS, though that depends on how <details>
> ends up working in CSS. If this proves to not be enough, we'll have to add
> something to support it; however, I'd like to wait until this is more
> widely deployed (so we get more experience) before changing this.

I believe the CSS for <details> can be nothing more than:

details:not(open) > :not(summary) {
  display: none;
}

(Plus general default styling of <details> and <summary>, of course.)


> On Mon, 22 Mar 2010, bgy wrote:
>> On webkit based browser, we can see a little cross used to reset the
>> field, it's useful, but in some ajax based application, it could be
>> useful to be able to handle this event, to dispatch the event to any
>> controller and reset results.
>>
>> Use case:
>>
>> Highlight a given text in webpage.
>>
>> Input search is likely to be used since the highlight functionnality
>> will search through the webpage and highlight all matched patterns. In a
>> server side solution, the problem is likely to be inexistant, but if we
>> use a plain javascript option, it'll be usefull to handle the reset
>> event to remove the highlighting from the page in browser impletementing
>> this functionnality.
>>
>> What are your thoughts about this ?
>
> I don't really understand the proposal or the use case. Can you elaborate?

The proposal is to mandate that <input type=search> expose some sort
of "clear" widget in itself, which fires an appropriate event when the
user activates it.

His use-case was doing an in-page text search+highlight in javascript,
and wanting to know when he can just yank all the highlighting.


> On Thu, 1 Apr 2010, John Gregg wrote:
>>
>> For context, Ian Fette started a thread about uploading directories of
>> files in December:
>> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024455.html
>>
>> At that time, it was thought that directory upload could be implemented
>> by a UA in response to a <input type="file" multiple> tag using
>> different UI only, and modifying the FileAPI spec to allow path
>> information in the form
>>
>> input.files[0].name="1.jpg"
>> input.files[0].path="a"
>> input.files[1].name="2.jpg"
>> input.files[1].path="a/b"
>> input.files[2].name="3.jpg"
>> input.files[2].path="a/c"
>>
>> I've started developing a prototype of this in WebKit/Chromium.  Based
>> on what I've encountered so far, I would like to propose adding
>> directory upload functionality using an explicit new 'directory'
>> attribute on the file input element.
>>
>> The existing behavior of <input type="file" multiple> would not change,
>> but when processing <input type="file" directory>, the UA would display
>> a directory selection UI and store the path information, and *not* allow
>> individual files to be selected.  It would allow multiple files to have
>> the same leaf name (.name attribute), as long as the paths were
>> different.  The path attributes would include the name of the chosen
>> directory
>>
>> This would be preferable for several reasons:
>>
>>  - Most built-in file system UI on major platforms (Windows/Mac/Linux)
>> have distinct dialogs for choosing files and choosing directories.
>> Allowing the UA to use these directly makes sense rather than creating
>> hybrids.
>>
>>  - Avoiding "leaf name" conflicts in a directory tree is not feasible in
>> many applications -- asking a user to ensure unique photo names in a
>> large set of albums before uploading would fail to meet that use case.
>> Therefore HTML documents should know in advance whether the path
>> information will be relevant in the eventual storage of the files.
>> Sites currently using <input type="file" multiple> would have
>> compatibility problems with an implementation which allowed conflicting
>> file names along different paths.
>>
>> What are your thoughts about adding the 'directory' attribute?
>
> What is the advantage over an <input type=file multiple> control? It seems
> like it would be more backwards compatible to just make this a UI switch
> -- let the user chose whether he's uploading a file, many files, or a
> directory of files. That's also more backwards-compatible.

The advantages are precisely what was listed in the email - a proper
directory uploader with path information for the files (either baked
into the filename or available separately) allows you to:

1. Easily accept multiple files with the same name, as long as they're
in different directories (this restriction is already enforced in all
major OSes)

2. Maintain the directory structure the user uploaded, for example a
pictures directory with folders for "vacation" and "wedding" photos
separate.

3. Expose the most appropriate UI to the user - in most file selection
dialogs you are *unable* to select a folder itself.  In the few that
allow it, it is often difficult to discover the functionality.  OSes
do provide a proper directory picker, though, which is much more clear
about what it does.

~TJ