Re: Directory Upload Proposal
On Wed, May 13, 2015 at 11:51 PM, Jonas Sicking wrote: > One important question though is what would directories> do on platforms that don't have a directory UI concept? > Like most mobile platforms? Err.. that should say: What would do on platforms that don't have a directory UI concept? / Jonas
Re: Directory Upload Proposal
On Wed, May 13, 2015 at 11:39 PM, Jonas Sicking wrote: > >> On that note, there is actually a 5th option that we can entertain. We could >> have three different kinds of file inputs: one type for files, another for >> directories, and yet another for handling both files and directories. This >> means that if a developer has a use case for only wanting a user to pick a >> directory (even on Mac OS X), they would have that option. > > Like with options 2 and 3, I would definitely be ok with this option too. One more thought. I think option 5 is essentially option 2 plus also add support for . I.e. if we do option 5 I'd prefer to do it by having work as described in option 2, but then also have . One important question though is what would do on platforms that don't have a directory UI concept? Like most mobile platforms? / Jonas
Re: Directory Upload Proposal
On Wed, May 13, 2015 at 2:19 PM, Ali Alabbas wrote:
> Thank you for the feedback Jonas. After speaking to the OneDrive team at
> Microsoft, they let me know that their use case for this would involve hiding
> the file input and just spoofing a click to invoke the file/folder picker.
> This makes me believe that perhaps there should be less of an emphasis on UI
> and more on providing the functionality that developers need.
I do agree with you that most websites will likely want to hide the
browser-provided UI. And for those websites options 2 and 3 are pretty
much equivalent.
But my theory has been that some websites will want to use the
browser-provided UI. For those websites I think option 2 is
advantageous.
But I don't really have much data to go on, other than that I still do
see quite a few websites using the browser-provided UI for .
> On that note, there is actually a 5th option that we can entertain. We could
> have three different kinds of file inputs: one type for files, another for
> directories, and yet another for handling both files and directories. This
> means that if a developer has a use case for only wanting a user to pick a
> directory (even on Mac OS X), they would have that option.
Like with options 2 and 3, I would definitely be ok with this option too.
It isn't clear to me though that there are actually use-cases for
enabling the user to *just* pick a directory, even on platforms where
the file-or-directory picker is available?
/ Jonas
> Thanks,
> Ali
>
> On Friday, May 8, 2015 at 3:29 PM, Jonas Sicking wrote:
>
>>On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas wrote:
>>> I recommend that we change the "dir" attribute to "directories" and keep
>>> "directory" the same as it is now to avoid clashing with the existing "dir"
>>> attribute on the HTMLInputElement. All in favor?
>>
>>There's no current "directory" attribute, and the current "dir"
>>attribute stands for "direction" and not "directory", so I'm not sure which
>>clash you are worried about?
>>
>>But I'm definitely fine with "directories". I've used that in the examples
>>below.
>>
>>> As for the behavior of setting the "directories" attribute on a file input,
>>> we have the following options:
>>>
>>> 1) Expose two buttons in a file input ("choose files" and "choose
>>> directory") (see Mozilla's proposal [1])
>>> - To activate the "choose directory" behavior of invoking the
>>> directory picker there would need to be a method on the
>>> HTMLInputElement e.g. chooseDirectory()
>>> - To activate the "choose files" behavior of invoking the files
>>> picker, we continue to use click() on the file input
>>>
>>> 2) Expose two buttons in file input for Windows/Linux ("choose files"
>>> and "choose directory") and one button for Mac OS X ("choose files and
>>> directories")
>>> - Allows users of Mac OS X to use its unified File/Directory picker
>>> - Allows users of Windows/Linux to specify if they want to pick files
>>> or a directory
>>> - However, there would still need to be a method to activate the
>>> "choose directory" button's behavior of invoking the directory picker
>>> (e.g. chooseDirectory() on the HTMLInputElement)
>>> - This results in two different experiences depending on the OS
>>>
>>> 3) Expose only one button; Windows/Linux ("choose directory") and Mac
>>> OS X ("choose files and directories")
>>> - Allows users of Mac OS X to use its unified File/Directory picker
>>> - Windows/Linux users are only able to select a directory
>>> - click() is used to activate these default behaviors (no need for an
>>> extra method such as chooseDirectory() on the HTMLInputElement
>>> interface)
>>> - For Windows/Linux, in order to have access to a file picker,
>>> app/site developers would need to create another file input without
>>> setting the "directories" attribute
>>> - Can have something like isFileAndDirectorySupported so that
>>> developers can feature detect and decide if they need to have two
>>> different file inputs for their app/site (on Windows/Linux) or if they
>>> just need one (on Mac OS X) that can allow both files and directories
>>>
>>> 4) Expose only one button ("choose directory")
>>> - User must select a directory regardless of OS or browser (this
>>> normalizes the user experience and the developer design paradigm)
>>> - To make users pick files rather than directories, the developer
>>> simply does not set the "directories" attribute which would show the
>>> default file input
>>> - Developers that want to allow users the option to select directory
>>> or files need to provide two different inputs regardless of OS or
>>> browser
>>
>>Hi Ali,
>>
>>I think the only really strong requirement that I have is that I'd like to
>>enable the platform widget on OSX which allows picking a file or a directory.
>>This might also be useful in the future on other platforms if they grow such
>>a widget.
>>
>>I understand that this will mean extra work on the part of the developer,
>>especially
Re: Directory Upload Proposal
I strongly support this proposal. However - if it is possible to upload
a directly, it should also be possible to download it, including
exporting it from the download / sandbox into the "real" world.
I would also like to ask for an opinion on letting the developers choose
how they actually want to handle the uploaded data. If possible, the
browser should be able to make the uploaded directory available as one
blob (maybe in zip or tar format) or in multiple blobs (individual files).
Michaela
On 05/13/2015 04:19 PM, Ali Alabbas wrote:
> Thank you for the feedback Jonas. After speaking to the OneDrive team at
> Microsoft, they let me know that their use case for this would involve hiding
> the file input and just spoofing a click to invoke the file/folder picker.
> This makes me believe that perhaps there should be less of an emphasis on UI
> and more on providing the functionality that developers need. On that note,
> there is actually a 5th option that we can entertain. We could have three
> different kinds of file inputs: one type for files, another for directories,
> and yet another for handling both files and directories. This means that if a
> developer has a use case for only wanting a user to pick a directory (even on
> Mac OS X), they would have that option. This would also future-proof for
> Windows/Linux if they ever introduce a file and folder picker in the future.
> This kind of solution would be more additive in nature which would mitigate
> any heavy changes that could run the risk of breaking sites.
>
> What do you think about this option?
>
> Thanks,
> Ali
>
> On Friday, May 8, 2015 at 3:29 PM, Jonas Sicking wrote:
>
>> On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas wrote:
>>> I recommend that we change the "dir" attribute to "directories" and keep
>>> "directory" the same as it is now to avoid clashing with the existing "dir"
>>> attribute on the HTMLInputElement. All in favor?
>>
>> There's no current "directory" attribute, and the current "dir"
>> attribute stands for "direction" and not "directory", so I'm not sure which
>> clash you are worried about?
>>
>> But I'm definitely fine with "directories". I've used that in the examples
>> below.
>>
>>> As for the behavior of setting the "directories" attribute on a file input,
>>> we have the following options:
>>>
>>> 1) Expose two buttons in a file input ("choose files" and "choose
>>> directory") (see Mozilla's proposal [1])
>>> - To activate the "choose directory" behavior of invoking the
>>> directory picker there would need to be a method on the
>>> HTMLInputElement e.g. chooseDirectory()
>>> - To activate the "choose files" behavior of invoking the files
>>> picker, we continue to use click() on the file input
>>>
>>> 2) Expose two buttons in file input for Windows/Linux ("choose files"
>>> and "choose directory") and one button for Mac OS X ("choose files and
>>> directories")
>>> - Allows users of Mac OS X to use its unified File/Directory picker
>>> - Allows users of Windows/Linux to specify if they want to pick files
>>> or a directory
>>> - However, there would still need to be a method to activate the
>>> "choose directory" button's behavior of invoking the directory picker
>>> (e.g. chooseDirectory() on the HTMLInputElement)
>>> - This results in two different experiences depending on the OS
>>>
>>> 3) Expose only one button; Windows/Linux ("choose directory") and Mac
>>> OS X ("choose files and directories")
>>> - Allows users of Mac OS X to use its unified File/Directory picker
>>> - Windows/Linux users are only able to select a directory
>>> - click() is used to activate these default behaviors (no need for an
>>> extra method such as chooseDirectory() on the HTMLInputElement
>>> interface)
>>> - For Windows/Linux, in order to have access to a file picker,
>>> app/site developers would need to create another file input without
>>> setting the "directories" attribute
>>> - Can have something like isFileAndDirectorySupported so that
>>> developers can feature detect and decide if they need to have two
>>> different file inputs for their app/site (on Windows/Linux) or if they
>>> just need one (on Mac OS X) that can allow both files and directories
>>>
>>> 4) Expose only one button ("choose directory")
>>> - User must select a directory regardless of OS or browser (this
>>> normalizes the user experience and the developer design paradigm)
>>> - To make users pick files rather than directories, the developer
>>> simply does not set the "directories" attribute which would show the
>>> default file input
>>> - Developers that want to allow users the option to select directory
>>> or files need to provide two different inputs regardless of OS or
>>> browser
>>
>> Hi Ali,
>>
>> I think the only really strong requirement that I have is that I'd like to
>> enable the platform widget on OSX which allows picking a file or a
>> directory. This might also be useful in the future on other
RE: Directory Upload Proposal
Thank you for the feedback Jonas. After speaking to the OneDrive team at
Microsoft, they let me know that their use case for this would involve hiding
the file input and just spoofing a click to invoke the file/folder picker. This
makes me believe that perhaps there should be less of an emphasis on UI and
more on providing the functionality that developers need. On that note, there
is actually a 5th option that we can entertain. We could have three different
kinds of file inputs: one type for files, another for directories, and yet
another for handling both files and directories. This means that if a developer
has a use case for only wanting a user to pick a directory (even on Mac OS X),
they would have that option. This would also future-proof for Windows/Linux if
they ever introduce a file and folder picker in the future. This kind of
solution would be more additive in nature which would mitigate any heavy
changes that could run the risk of breaking sites.
What do you think about this option?
Thanks,
Ali
On Friday, May 8, 2015 at 3:29 PM, Jonas Sicking wrote:
>On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas wrote:
>> I recommend that we change the "dir" attribute to "directories" and keep
>> "directory" the same as it is now to avoid clashing with the existing "dir"
>> attribute on the HTMLInputElement. All in favor?
>
>There's no current "directory" attribute, and the current "dir"
>attribute stands for "direction" and not "directory", so I'm not sure which
>clash you are worried about?
>
>But I'm definitely fine with "directories". I've used that in the examples
>below.
>
>> As for the behavior of setting the "directories" attribute on a file input,
>> we have the following options:
>>
>> 1) Expose two buttons in a file input ("choose files" and "choose
>> directory") (see Mozilla's proposal [1])
>> - To activate the "choose directory" behavior of invoking the
>> directory picker there would need to be a method on the
>> HTMLInputElement e.g. chooseDirectory()
>> - To activate the "choose files" behavior of invoking the files
>> picker, we continue to use click() on the file input
>>
>> 2) Expose two buttons in file input for Windows/Linux ("choose files"
>> and "choose directory") and one button for Mac OS X ("choose files and
>> directories")
>> - Allows users of Mac OS X to use its unified File/Directory picker
>> - Allows users of Windows/Linux to specify if they want to pick files
>> or a directory
>> - However, there would still need to be a method to activate the
>> "choose directory" button's behavior of invoking the directory picker
>> (e.g. chooseDirectory() on the HTMLInputElement)
>> - This results in two different experiences depending on the OS
>>
>> 3) Expose only one button; Windows/Linux ("choose directory") and Mac
>> OS X ("choose files and directories")
>> - Allows users of Mac OS X to use its unified File/Directory picker
>> - Windows/Linux users are only able to select a directory
>> - click() is used to activate these default behaviors (no need for an
>> extra method such as chooseDirectory() on the HTMLInputElement
>> interface)
>> - For Windows/Linux, in order to have access to a file picker,
>> app/site developers would need to create another file input without
>> setting the "directories" attribute
>> - Can have something like isFileAndDirectorySupported so that
>> developers can feature detect and decide if they need to have two
>> different file inputs for their app/site (on Windows/Linux) or if they
>> just need one (on Mac OS X) that can allow both files and directories
>>
>> 4) Expose only one button ("choose directory")
>> - User must select a directory regardless of OS or browser (this
>> normalizes the user experience and the developer design paradigm)
>> - To make users pick files rather than directories, the developer
>> simply does not set the "directories" attribute which would show the
>> default file input
>> - Developers that want to allow users the option to select directory
>> or files need to provide two different inputs regardless of OS or
>> browser
>
>Hi Ali,
>
>I think the only really strong requirement that I have is that I'd like to
>enable the platform widget on OSX which allows picking a file or a directory.
>This might also be useful in the future on other platforms if they grow such a
>widget.
>
>I understand that this will mean extra work on the part of the developer,
>especially in the case when the developer render their own UI. However authors
>generally tend to prefer to optimize a good UI experience over saving a few
>lines of code. This seems especially true in this case given that the author
>has chosen to provide their own UI rather than use the browser-provided one.
>
>So that leaves us with options 2 and 3.
>
>I think both of these are options that I can live with. And for authors that
>render their own UI the difference is only one of syntax.
>And most likely authors will wrap our API in
Re: Directory Upload Proposal
On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas wrote:
> I recommend that we change the "dir" attribute to "directories" and keep
> "directory" the same as it is now to avoid clashing with the existing "dir"
> attribute on the HTMLInputElement. All in favor?
There's no current "directory" attribute, and the current "dir"
attribute stands for "direction" and not "directory", so I'm not sure
which clash you are worried about?
But I'm definitely fine with "directories". I've used that in the
examples below.
> As for the behavior of setting the "directories" attribute on a file input,
> we have the following options:
>
> 1) Expose two buttons in a file input ("choose files" and "choose directory")
> (see Mozilla's proposal [1])
> - To activate the "choose directory" behavior of invoking the directory
> picker there would need to be a method on the HTMLInputElement e.g.
> chooseDirectory()
> - To activate the "choose files" behavior of invoking the files picker, we
> continue to use click() on the file input
>
> 2) Expose two buttons in file input for Windows/Linux ("choose files" and
> "choose directory") and one button for Mac OS X ("choose files and
> directories")
> - Allows users of Mac OS X to use its unified File/Directory picker
> - Allows users of Windows/Linux to specify if they want to pick files or a
> directory
> - However, there would still need to be a method to activate the "choose
> directory" button's behavior of invoking the directory picker (e.g.
> chooseDirectory() on the HTMLInputElement)
> - This results in two different experiences depending on the OS
>
> 3) Expose only one button; Windows/Linux ("choose directory") and Mac OS X
> ("choose files and directories")
> - Allows users of Mac OS X to use its unified File/Directory picker
> - Windows/Linux users are only able to select a directory
> - click() is used to activate these default behaviors (no need for an extra
> method such as chooseDirectory() on the HTMLInputElement interface)
> - For Windows/Linux, in order to have access to a file picker, app/site
> developers would need to create another file input without setting the
> "directories" attribute
> - Can have something like isFileAndDirectorySupported so that developers can
> feature detect and decide if they need to have two different file inputs for
> their app/site (on Windows/Linux) or if they just need one (on Mac OS X) that
> can allow both files and directories
>
> 4) Expose only one button ("choose directory")
> - User must select a directory regardless of OS or browser (this normalizes
> the user experience and the developer design paradigm)
> - To make users pick files rather than directories, the developer simply does
> not set the "directories" attribute which would show the default file input
> - Developers that want to allow users the option to select directory or files
> need to provide two different inputs regardless of OS or browser
Hi Ali,
I think the only really strong requirement that I have is that I'd
like to enable the platform widget on OSX which allows picking a file
or a directory. This might also be useful in the future on other
platforms if they grow such a widget.
I understand that this will mean extra work on the part of the
developer, especially in the case when the developer render their own
UI. However authors generally tend to prefer to optimize a good UI
experience over saving a few lines of code. This seems especially true
in this case given that the author has chosen to provide their own UI
rather than use the browser-provided one.
So that leaves us with options 2 and 3.
I think both of these are options that I can live with. And for
authors that render their own UI the difference is only one of syntax.
And most likely authors will wrap our API in a library since none of
the APIs here are particularly nice.
However I do think that 3 has some disadvantages for authors that *do*
use the browser provided UI.
The main one being that the UI gets kind of awkward when rendering one
and one .
>From a user point of view, it ends up being sort of half-way between a
UI where you select one "thing", and a UI where you can add as many
files/directories as you want. Specifically the user can select no
more than 2 things, but require that one and only one is a directory.
So the double- UI ends up neither being a good UI to allow the
user to select one "thing", nor to allow the user to select an
arbitrary number of "things".
The other downside with 3 when used with the browser-provided UI is
that the website will still have to use javascript to dynamically
generate one or two s. This is needed in order to avoid having
two exactly alike UI widgets on old browsers or browsers which doesn't
have a separate directory picker.
That said, 2 definitely has the disadvantage that it'll force us to
cram two buttons into the small layout size that is used by a . But I think this is solvable. One simple solution is to
initially render tw
RE: Directory Upload Proposal
I recommend that we change the "dir" attribute to "directories" and keep
"directory" the same as it is now to avoid clashing with the existing "dir"
attribute on the HTMLInputElement. All in favor?
As for the behavior of setting the "directories" attribute on a file input, we
have the following options:
1) Expose two buttons in a file input ("choose files" and "choose directory")
(see Mozilla's proposal [1])
- To activate the "choose directory" behavior of invoking the directory picker
there would need to be a method on the HTMLInputElement e.g. chooseDirectory()
- To activate the "choose files" behavior of invoking the files picker, we
continue to use click() on the file input
2) Expose two buttons in file input for Windows/Linux ("choose files" and
"choose directory") and one button for Mac OS X ("choose files and directories")
- Allows users of Mac OS X to use its unified File/Directory picker
- Allows users of Windows/Linux to specify if they want to pick files or a
directory
- However, there would still need to be a method to activate the "choose
directory" button's behavior of invoking the directory picker (e.g.
chooseDirectory() on the HTMLInputElement)
- This results in two different experiences depending on the OS
3) Expose only one button; Windows/Linux ("choose directory") and Mac OS X
("choose files and directories")
- Allows users of Mac OS X to use its unified File/Directory picker
- Windows/Linux users are only able to select a directory
- click() is used to activate these default behaviors (no need for an extra
method such as chooseDirectory() on the HTMLInputElement interface)
- For Windows/Linux, in order to have access to a file picker, app/site
developers would need to create another file input without setting the
"directories" attribute
- Can have something like isFileAndDirectorySupported so that developers can
feature detect and decide if they need to have two different file inputs for
their app/site (on Windows/Linux) or if they just need one (on Mac OS X) that
can allow both files and directories
4) Expose only one button ("choose directory")
- User must select a directory regardless of OS or browser (this normalizes the
user experience and the developer design paradigm)
- To make users pick files rather than directories, the developer simply does
not set the "directories" attribute which would show the default file input
- Developers that want to allow users the option to select directory or files
need to provide two different inputs regardless of OS or browser
I am leaning towards option 3 or 4 since it allows us to avoid needing an extra
method such as chooseDirectory() but also allows the developer to cater the
experience based on the capabilities of the OS via feature detection as is the
case with option 3. It also allows us to keep the current look and feel of the
file inputs meaning we don't break current sites nor do we create an experience
that puts backwards compatibility at risk by outright changing the behavior of
the file input.
Thanks,
Ali
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=846931
Re: Directory Upload Proposal
On Mon, Apr 27, 2015 at 9:45 PM, Jonas Sicking wrote: > On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas wrote: >> Hello WebApps Group, > > Hi Ali, > > Yay! This is great to see a formal proposal for! Definitely something > that mozilla is very interested in working on. > >> If there is sufficient interest, I would like to work on this within the >> scope of the WebApps working group. > > I personally will stay out of WG politics. But I think the proposal > will receive more of the needed attention and review in this WG than > in the HTML WG. But I'm not sure if W3C policies dictate that this is > done in the HTML WG. > >> [4] Proposal: >> http://internetexplorer.github.io/directory-upload/proposal.html > > So, some specific feedback on the proposal. > > First off, I don't think you can use the name "dir" for the new > attribute since that's already used for setting rtl/ltr direction. > Simply renaming the attribute to something else should fix this. > > Second, rather than adding a .directory attribute, I think that we > should simply add any selected directories to the .files list. My > experience is that having a direct mapping between what the user does, > and what we expose to the webpage, generally results in less developer > confusion and/or annoyance. > > My understanding is that the current proposal is mainly so that if we > in the future add something like Directory.enumerateDeep(), that that > would automatically enable deep enumeration through all user options. > However that could always be solved by adding a > HTMLInputElement.enumerateFilesDeep() function. Oh, there's another thing missing that I missed. We also need some function, similar to .click(), which allows a webpage to programmatically bring up a directory picker. This is needed on platforms like Windows and Linux which use separate platform widgets for picking a directory and picking a file. Many websites hide the default browser provided UI and then call .click() when the user clicks the website UI. A tricky question is what to do on platforms that don't have a separate directory picker (like OSX) or which doesn't have a concept of directories (most mobile platforms). We could either make those UAs on those platforms not have the separate .clickDirectoryPicker() function (or whatever we'll call it), or make them have it but just do the same as .click(). / Jonas
Re: Directory Upload Proposal
On Tue, Apr 28, 2015 at 4:28 PM, Travis Leithead wrote: >>> Aaron opened an issue for this on GitHub [1] and I agree that it is a >>> problem and we should definitely rename it to something else! One option >>> might be to change dir to directory, but we would need a different name for >>> directory (the attribute that gets back the virtual root holding the >>> selected files and folders). > > I wonder, is it necessary to have a separate "dir"/"directory" attribute from > "multiple"? Adding a new DOM attribute will allow for feature detecting this > change. UA's can handle the presentation of a separate directory picker if > necessary--why force this distinction on the web developer? We need the "dir"/"directory" attribute in order for pages to indicate that it can handle Directory objects. No matter where/how we expose those Directory objects. / Jonas
Re: Directory Upload Proposal
On Tue, Apr 28, 2015 at 4:26 PM, Travis Leithead wrote: >>> Second, rather than adding a .directory attribute, I think that we should >>> simply add any selected directories to the .files list. My experience is >>> that having a direct mapping between what the user does, and what we expose >>> to the webpage, generally results in less developer confusion and/or >>> annoyance. > > I like this consolidation, but Ali concern (and one I share) is that legacy > code using .files will not expect to encounter new Directory objects in the > list and will likely break unless the Directory object maintains a > backwards-compatible File-like appearance. Legacy pages won't be setting the "directory" attribute. In fact, this is the whole purpose of the "directory" attribute. To enable pages to signal "I can handle the user picking directories". > I have a concern about revealing the user's directory names to the server, > and suggested anonymizing the names, but it seems that having directory path > names flow through to the server intact is an important scenario for > file-syncing, which anonymizing might break. I agree that this is a concern, though one separate from what API we use. I do think it's fine to expose the directory name of the directory that the user pick. It doesn't seem very different from the fact that we expose the filename of the files that the user pick. / Jonas
RE: Directory Upload Proposal
>> Aaron opened an issue for this on GitHub [1] and I agree that it is a >> problem and we should definitely rename it to something else! One option >> might be to change dir to directory, but we would need a different name for >> directory (the attribute that gets back the virtual root holding the >> selected files and folders). I wonder, is it necessary to have a separate "dir"/"directory" attribute from "multiple"? Adding a new DOM attribute will allow for feature detecting this change. UA's can handle the presentation of a separate directory picker if necessary--why force this distinction on the web developer? -Original Message- From: Ali Alabbas [mailto:a...@microsoft.com] Sent: Tuesday, April 28, 2015 4:21 PM To: Tab Atkins Jr.; Ryan Seddon Cc: Web Applications Working Group WG Subject: RE: Directory Upload Proposal On Tue, Apr 28, 2015 at 4:15 PM, Tab Atkins Jr. wrote: >On Tue, Apr 28, 2015 at 3:53 PM, Ryan Seddon wrote: >>> To enable developers to build future interoperable solutions, we've >>> drafted a proposal [4], with the helpful feedback of Mozilla and >>> Google, that focuses strictly on providing the mechanisms necessary >>> to enable directory uploads. >> >> The use of the dir attribute seems odd since I can already apply dir="rtl" >> to an input to change the text direction. > >Good catch; that's a fatal naming clash, and needs to be corrected. >The obvious one is to just expand out the name to "directory". > >~TJ Aaron opened an issue for this on GitHub [1] and I agree that it is a problem and we should definitely rename it to something else! One option might be to change dir to directory, but we would need a different name for directory (the attribute that gets back the virtual root holding the selected files and folders). [1] https://github.com/InternetExplorer/directory-upload/issues/1
RE: Directory Upload Proposal
>> Second, rather than adding a .directory attribute, I think that we should >> simply add any selected directories to the .files list. My experience is >> that having a direct mapping between what the user does, and what we expose >> to the webpage, generally results in less developer confusion and/or >> annoyance. I like this consolidation, but Ali concern (and one I share) is that legacy code using .files will not expect to encounter new Directory objects in the list and will likely break unless the Directory object maintains a backwards-compatible File-like appearance. In the proposed model, the "directory" would be a virtual wrapper around any existing selected files, and could wholly replaces .files, while providing a nice extension point for additional behavior later. I have a concern about revealing the user's directory names to the server, and suggested anonymizing the names, but it seems that having directory path names flow through to the server intact is an important scenario for file-syncing, which anonymizing might break. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Monday, April 27, 2015 9:45 PM To: Ali Alabbas Cc: Web Applications Working Group WG Subject: Re: Directory Upload Proposal On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas wrote: > Hello WebApps Group, Hi Ali, Yay! This is great to see a formal proposal for! Definitely something that mozilla is very interested in working on. > If there is sufficient interest, I would like to work on this within the > scope of the WebApps working group. I personally will stay out of WG politics. But I think the proposal will receive more of the needed attention and review in this WG than in the HTML WG. But I'm not sure if W3C policies dictate that this is done in the HTML WG. > [4] Proposal: > http://internetexplorer.github.io/directory-upload/proposal.html So, some specific feedback on the proposal. First off, I don't think you can use the name "dir" for the new attribute since that's already used for setting rtl/ltr direction. Simply renaming the attribute to something else should fix this. My understanding is that the current proposal is mainly so that if we in the future add something like Directory.enumerateDeep(), that that would automatically enable deep enumeration through all user options. However that could always be solved by adding a HTMLInputElement.enumerateFilesDeep() function. / Jonas
RE: Directory Upload Proposal
On Tue, Apr 28, 2015 at 4:15 PM, Tab Atkins Jr. wrote: >On Tue, Apr 28, 2015 at 3:53 PM, Ryan Seddon wrote: >>> To enable developers to build future interoperable solutions, we've >>> drafted a proposal [4], with the helpful feedback of Mozilla and >>> Google, that focuses strictly on providing the mechanisms necessary >>> to enable directory uploads. >> >> The use of the dir attribute seems odd since I can already apply dir="rtl" >> to an input to change the text direction. > >Good catch; that's a fatal naming clash, and needs to be corrected. >The obvious one is to just expand out the name to "directory". > >~TJ Aaron opened an issue for this on GitHub [1] and I agree that it is a problem and we should definitely rename it to something else! One option might be to change dir to directory, but we would need a different name for directory (the attribute that gets back the virtual root holding the selected files and folders). [1] https://github.com/InternetExplorer/directory-upload/issues/1
Re: Directory Upload Proposal
On Tue, Apr 28, 2015 at 3:53 PM, Ryan Seddon wrote: >> To enable developers to build future interoperable solutions, we've >> drafted a proposal [4], with the helpful feedback of Mozilla and Google, >> that focuses strictly on providing the mechanisms necessary to enable >> directory uploads. > > The use of the dir attribute seems odd since I can already apply dir="rtl" > to an input to change the text direction. Good catch; that's a fatal naming clash, and needs to be corrected. The obvious one is to just expand out the name to "directory". ~TJ
Re: Directory Upload Proposal
> To enable developers to build future interoperable solutions, we've > drafted a proposal [4], with the helpful feedback of Mozilla and Google, > that focuses strictly on providing the mechanisms necessary to enable > directory uploads. > The use of the dir attribute seems odd since I can already apply dir="rtl" to an input to change the text direction.
Re: Directory Upload Proposal
On Fri, Apr 24, 2015 at 2:28 AM, Ali Alabbas wrote: > > > If there is sufficient interest, I would like to work on this within the > scope of the WebApps working group. > > And I'll help with the FileSystem API bit, ensuring that "full" spec.[3] has bits about the Directory Upload proposal (outside of the sandbox). There's an HTML WG bit, too, as Jonas and Anne v K point out. I'm not sure what the best way to tackle that is, but I think a bug on HTML plus nudging over IRC over attribute names will go a fair distance. -- A*
Re: Directory Upload Proposal
On Thu, Apr 23, 2015 at 5:45 PM, Anne van Kesteren wrote: > On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas wrote: >> If there is sufficient interest, I would like to work on this within the >> scope of the WebApps working group. > > It seems somewhat better to just file a bug against the HTML Standard > since this also affects the processing model of e.g. .files. > Which I think was the original proposal for how to address this... > Just expose all the files in .files and expose the relative > paths, but I guess that might be a bit too synchronous... Yeah. Recursively enumerating the selected directory (/directories) can be a potentially very lengthy process. So something which the page might want to display progress UI while it's happening. We looked at various ways of doing this in [1] but ultimately all of them felt clunky and not as flexible as allowing the page to enumerate the directory tree itself. This way pages could even save time on enumeration by displaying UI which allows the user to select which sub-directories to traverse. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=846931 / Jonas
Re: Directory Upload Proposal
On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas wrote: > Hello WebApps Group, Hi Ali, Yay! This is great to see a formal proposal for! Definitely something that mozilla is very interested in working on. > If there is sufficient interest, I would like to work on this within the > scope of the WebApps working group. I personally will stay out of WG politics. But I think the proposal will receive more of the needed attention and review in this WG than in the HTML WG. But I'm not sure if W3C policies dictate that this is done in the HTML WG. > [4] Proposal: http://internetexplorer.github.io/directory-upload/proposal.html So, some specific feedback on the proposal. First off, I don't think you can use the name "dir" for the new attribute since that's already used for setting rtl/ltr direction. Simply renaming the attribute to something else should fix this. Second, rather than adding a .directory attribute, I think that we should simply add any selected directories to the .files list. My experience is that having a direct mapping between what the user does, and what we expose to the webpage, generally results in less developer confusion and/or annoyance. My understanding is that the current proposal is mainly so that if we in the future add something like Directory.enumerateDeep(), that that would automatically enable deep enumeration through all user options. However that could always be solved by adding a HTMLInputElement.enumerateFilesDeep() function. / Jonas
Re: Directory Upload Proposal
On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas wrote: > If there is sufficient interest, I would like to work on this within the > scope of the WebApps working group. It seems somewhat better to just file a bug against the HTML Standard since this also affects the processing model of e.g. .files. Which I think was the original proposal for how to address this... Just expose all the files in .files and expose the relative paths, but I guess that might be a bit too synchronous... (Also, you want to use sequence<> not [] for listContents().) -- https://annevankesteren.nl/
