Re: CfC: Moving webstorage to REC 2nd Edition; deadline May 21

2015-05-14 Thread Kostiainen, Anssi
 On 14 May 2015, at 14:30, Arthur Barstow art.bars...@gmail.com wrote:
 
 1. Publish a new WD of the spec and to seek wide review of the spec, per 
 process 2014. The new WD will be placed in w3.org/TR/webstorage/.

This addresses the concern and clears the confusion around an outdated /TR.

 If you have any comments or concerns about this CfC, please reply by May 21 
 at the latest. Silence will be considered as agreeing with the proposal and 
 explicit responses are preferred. If no non-resolvable blocking issues are 
 raised, this CfC will be considered as passing and we will proceed with this 
 proposal.

+1. Thanks for the swift turnaround.

Thanks,

-Anssi


Re: Directory Upload Proposal

2015-05-14 Thread Jonas Sicking
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: CfC: Moving webstorage to REC 2nd Edition; deadline May 21

2015-05-14 Thread Zhang, Zhiqiang
 From: Kostiainen, Anssi [mailto:anssi.kostiai...@intel.com]
 Sent: Thursday, May 14, 2015 21:16
 To: Arthur Barstow
 Cc: public-webapps
 Subject: Re: CfC: Moving webstorage to REC 2nd Edition; deadline May 21
 
  On 14 May 2015, at 14:30, Arthur Barstow art.bars...@gmail.com wrote:
 
  1. Publish a new WD of the spec and to seek wide review of the spec, per
 process 2014. The new WD will be placed in w3.org/TR/webstorage/.
 
 This addresses the concern and clears the confusion around an outdated /TR.

Yes, the spec looks good to me.

  If you have any comments or concerns about this CfC, please reply by May
 21 at the latest. Silence will be considered as agreeing with the proposal and
 explicit responses are preferred. If no non-resolvable blocking issues are
 raised, this CfC will be considered as passing and we will proceed with this
 proposal.
 
 +1. Thanks for the swift turnaround.

I also regenerated an implementation report at

http://w3c.github.io/test-results/webstorage/all.html

... for your reference.

BTW: I have sent out the above info yesterday, but seems the mailing list 
system didn't get it.

Thanks,
Zhiqiang



CfC: Moving webstorage to REC 2nd Edition; deadline May 21

2015-05-14 Thread Arthur Barstow

Hi All,

Based on Xiaoqian's analysis [1] of Web Storage changes since the REC 
was published in 2013, this is a Call for Consensus to:


1. Publish a new WD of the spec and to seek wide review of the spec, per 
process 2014. The new WD will be placed in w3.org/TR/webstorage/. The 
draft WD is [2] and the review period will be three weeks. The draft 
includes a summary of the changes since the REC was published [3].


2. Update the REC errata doc [4] to include a reference to the new WD 
and its changes since REC section, and the github commit history.


If you have any comments or concerns about this CfC, please reply by May 
21 at the latest. Silence will be considered as agreeing with the 
proposal and explicit responses are preferred. If no non-resolvable 
blocking issues are raised, this CfC will be considered as passing and 
we will proceed with this proposal.


-Thanks, ArtB

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0607.html
[2] https://w3c.github.io/webstorage/
[3] https://w3c.github.io/webstorage/#status-of-this-document
[4] http://dev.w3.org/html5/webstorage/publish/errata-v1.html



Re: Directory Upload Proposal

2015-05-14 Thread Jonas Sicking
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

2015-05-14 Thread Jonas Sicking
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