date:20120924

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

2012-09-24 Thread Kinuko Yasuda

Thanks for the feedback.

On Fri, Sep 14, 2012 at 6:58 AM, Ian Hickson i...@hixie.ch wrote:

 On Tue, 15 Nov 2011, Kinuko Yasuda wrote:
 
  Many sites have 'upload your files' feature, like for your photo images.
  HTML5 allows you to do this via input type=file multiple or
  drag-and-drop feature, but the current solution does not provide clean
  solution for cases with folders, files/folder mixed cases, or folders
  with subfolders cases.
 
  For context, back then we have proposed (and implemented) 'directory'
  attribute for input type=file specifically to upload a directory, but
  the approach does not provide useful information to webapps about which
  file comes from which folder, neither does it allow apps to control how
  and when to enumerate directories (e.g. app cannot show progress meter
  etc even the enumerating part takes long time).
 
 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html

 This isn't really about directories, it's a problem with file I/O in
 general, made worse when there are large numbers of files -- it's just
 that when you have directories you're more likely to have many files.
 Other situations also make this difficult, e.g. if the files are on a
 network drive with high latency, or a removable drive such as a DVD or
 tape drive.


This seems true.  For the record, when this proposal was made there wasn't
clear agreement that file metadata needs to be retrieved when the File
object is created, the file name was the only information that was clearly
necessary to create a File.

Fundamentally the problem is that the objects in drag-and-drop and in
 input type=file synchronously expose all the files, and we just don't
 necessarily have the time to get all the files' sizes before that starts
 to be noticably slow. We could have the UA show progress UI, but while
 that could work for input type=file, it would be quite jarring for drag
 and drop.

 There are various ways we could fix this if we were starting afresh, but
 if we're trying to keep backwards compatibility there's basically no
 solution: the spec already requires this sync API, and pages might depend
 on it.

So we have a problem: do we not fix the problem, do we break all pages
 always, break all pages but only when the user drags in a lot of files (so
 authors might not notice), break all pages whenever there's more than one
 file (so authors will notice but pages still support one file at a time),
 break pages only when the user drags in one or more directories?


My proposal is to add an alternative asynchronous API and encourage app
authors to use the version when they expect it could get large number of
files/directories.  This does not solve the existing problem but could
offer better alternative approach.

There's various ways we could fix the problem, if we're ok with breaking
 things. We could expose all the files in a flat list, incrementally. We
 could expose the directory hiearchy, with asynchronous access. If we do
 incremental access, there's various ways to do that: event-based
 notification that there's more data; an enumerator / callback mechanism; a
 lazy array where reading the number of files, or reading the nth file, is
 asynchronous... We can extend FileList and DataTransferItemList to support
 this, or we can add a new object that they point to, or we can just update
 FileList and make DataTransferItemList support the new object...

 In many cases, exposing the actual hierarchy can reduce the total amount
 of work that's needed, because many use cases don't actually need to crawl
 everything. For example, people gave examples of just wanting Subversion's
 internal .svn directories in a big tree, not the actual data; or indeed in
 other cases vice-versa.

 However, both exposing the hiearchy and flattening it have all kinds of
 risks. It's possible for the user to accidentally expose his entire
 computer's hard drive without realising it.


This seems to be possible regardless of whether we expose files in a
hierarchy or in a flattened list.

On some systems (including at
 least modern Mac OS and Linux OSes, not sure about Windows), it's possible
 to have hard-link loops.


Newer Mac OS X allows hard links on directories, but not in the way that
could create loops.
On most other OSes I believe hard links on directories are still disallowed.

On some systems, it's possible to drag special
 directories like .., and it's not clear what that would mean. When the
 user drags files from multiple parts of the file system (e.g. from a
 Windows virtual folder), it's not clear what parts of the path we should
 expose -- even exposing just the common parts can expose sensitive
 information like the profile path if one file is in the user's profile and
 another is not.


The proposed spec doesn't say anything about that, but Chrome's basic
stance is we should not expose any information that is outside the dropped
files/folders even some of dragged paths have the common parts in

Re: [whatwg] New URL Standard

2012-09-24 Thread Tobie Langel

On Mon, Sep 24, 2012 at 10:58 AM, Anne van Kesteren ann...@annevk.nl wrote:
 The kind of predictability we have for the HTML parser, I want to have for the
 URL parser as well.

Yes, please!!

--tobie

On Sat, Sep 22, 2012 at 9:10 AM, Alexandre Morgaut
alexandre.morg...@4d.com wrote:
Would the URLUtil interface replace the URL decomposition IDL attributes of
the Location interface?
-
http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#url-decomposition-idl-attributes
-
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#the-location-interface

Yes. My plan is to obsolete most URL parts of HTML.

Could the search property have a key/value mapping?
ex:
http://test.com?param1=value1
- var value1 = url.search.param1
search as window.location could still be usable as a string

I have been thinking about introducing a .query attribute that would
return a special interface for this purpose, but what the right API
should be seems somewhat tricky. Adam and Erik came up with a solution
that introduces eight new methods (see
http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html#url ) but I hope
we can find something more elegant. (Unless we are stuck with their
solution for some reason, but I believe that is not the case.)

Shouldn't this document have references on some of the URL related RFCs:

The plan is to obsolete the RFCs. But yes, I will add some references
in the Goals section most likely. Similar to what has been done in the
DOM Standard.

Should this document include a more complete list of schemes with ones that
are more and more used in URLs?

Maybe, kinda depends on what turns out to be the ideal scope for the
URL Standard. For now I only wanted to include those schemes relevant
to the parser (and it may turn out there is a few more of those, e.g.
mailto, javascript, data, and file might need some special casing).

Unfortunately, the URLUtil interface would not be adapted for them:
- the protocol, host, and hostname properties make sense and would work;
- the query part (search property) is used by the mailto:; and sms: URIs;
- for tel: and fax, we see parameters prefixed by ; as the ones used
in some media types, those parameters could be found in the search property

We might not want to adapt it either because of the relative increase
in complexity while not actually addressing many use cases. You want
to modify query/path for http/https and maybe ws/wss a lot, but not so
much for mailto I'd think.

38 matches

Mail list logo