RE: Shadow DOM: state of the distribution API

2015-05-13 Thread Travis Leithead
I wonder if there is some sort of imperative-declarative model that we could 
adopt here? I mean, allow script to specify the distribution logic, but do it 
with a static model. After all, what is being asked for is a relatively simple 
mapping from candidate node to content distribution point.

I’m just thinking out loud here, but what about something like:

assignDistributionMap( {
   source: {
 /* examples… */
 tagName: “foo”,
 className: “bar”
 childIndex: 2,
 selector: “”,
 textContains: “some text”,
   },
   target:
} );

And then providing a mechanism to notify the app when the set of distribution 
targets changes (which should be a relatively rare occurrence)?

Thinking creatively, this could be modified to be an ordered list of “fill” 
candidate rules, where the first filled rule takes the selection…?

This could also be used to provide flags indicating whether children, or 
subtrees should be considered for distribution candidates, etc.


RE: Directory Upload Proposal

2015-05-13 Thread Ali Alabbas
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

2015-05-13 Thread Michaela Merz

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: Shadow DOM: state of the distribution API

2015-05-13 Thread Dimitri Glazkov
I did a quick experiment around distribution timing:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Distribution-Timing-Experiment.md.
Hope you find it helpful.

:DG