Re: Directory Upload Proposal
On Wed, May 13, 2015 at 11:51 PM, Jonas Sicking jo...@sicking.cc wrote: One important question though is what would input type=file directories do on platforms that don't have a directory UI concept? Like most mobile platforms? Err.. that should say: What would input type=directory 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 jo...@sicking.cc 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 input type=directory. I.e. if we do option 5 I'd prefer to do it by having input type=file directories work as described in option 2, but then also have input type=directory. One important question though is what would input type=file directories 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 a...@microsoft.com 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 input type=file. 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 jo...@sicking.cc wrote: On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas a...@microsoft.com 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
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 jo...@sicking.cc wrote: On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas a...@microsoft.com 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*
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 jo...@sicking.cc wrote: On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas a...@microsoft.com 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
Re: Directory Upload Proposal
On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas a...@microsoft.com 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 input type=file (multiple) and one input type=file directories. 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-input 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 inputs. 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 input type=file. But I think this is solvable. One simple solution is to initially render two
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 Tue, Apr 28, 2015 at 4:28 PM, Travis Leithead travis.leith...@microsoft.com 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:15 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 28, 2015 at 3:53 PM, Ryan Seddon seddon.r...@gmail.com 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
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
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 a...@microsoft.com 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 Mon, Apr 27, 2015 at 9:45 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas a...@microsoft.com 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 input type=file 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 3:53 PM, Ryan Seddon seddon.r...@gmail.com 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
On Tue, Apr 28, 2015 at 4:26 PM, Travis Leithead travis.leith...@microsoft.com 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. jackalm...@gmail.com wrote: On Tue, Apr 28, 2015 at 3:53 PM, Ryan Seddon seddon.r...@gmail.com 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 Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas a...@microsoft.com 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 5:45 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas a...@microsoft.com 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. input.files. Which I think was the original proposal for how to address this... Just expose all the files in input.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 Fri, Apr 24, 2015 at 2:28 AM, Ali Alabbas a...@microsoft.com 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 12:28 PM, Ali Alabbas a...@microsoft.com 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. input.files. Which I think was the original proposal for how to address this... Just expose all the files in input.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/
