Re: File API: reading a Blob

2014-07-16 Thread Aymeric Vitte


Le 10/07/2014 19:05, Arun Ranganathan a écrit :

We agreed some time ago to not have partial data.


I still think that's a big mistake. Even if the Streams API will solve 
this, this should be corrected in the File API.


Unless I am misusing the API, you can not even increment a Blob, you 
have to create a new one each time, this should be corrected too.


Example:
var myfile=new Blob();

//chunks are coming in
myfile=new Blob([myfile,chunk],...)

//mylink A tag
mylink.href=URL.createObjectURL(myfile)

click on mylink -- does not work

Expected behavior: the file (a video for example) should play as it is 
incremented.


This is inconsistent with the standard files behavior (see [1] for 
example), this example should work without having to use the Media 
Source Extensions API.


Regards

Aymeric

[1] https://github.com/Ayms/torrent-live

--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms




Re: [imports] credentials flag bits need to be updated to current fetch terminology

2014-07-16 Thread Hajime Morrita
That's right. Thanks for the catch!
Fixed:
https://github.com/w3c/webcomponents/commit/90da4809a207916486bc7af83a568f3762e780a0


On Tue, Jul 15, 2014 at 10:00 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 In http://w3c.github.io/webcomponents/spec/imports/#fetching-import the
 spec says:

   Fetch a resource from LOCATION with request's origin set to the
   origin of the master document, the mode to CORS and the omit
   credentials mode to CORS.

 There is no omit credentials mode in the current Fetch draft, and the
 mode that _is_ there, credentials mode, doesn't have CORS as a value.
  Presumably this is asking for same-origin?

 -Boris




-- 
morrita


[Bug 26365] New: [Shadow]: Need an evquivalent definition of 'in a Document' for shadow trees

2014-07-16 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365

Bug ID: 26365
   Summary: [Shadow]: Need an evquivalent definition of 'in a
Document' for shadow trees
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: hay...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14978

The context is:

https://code.google.com/p/chromium/issues/detail?id=393350
https://code.google.com/p/chromium/issues/detail?id=394327

According to the current definition of a 'in a Document' [1], some important
features, such as scripting, should not work in shadow trees as per the spec.

[1]: http://dev.w3.org/html5/spec-preview/infrastructure.html#in-a-document


Because I am afraid that it's not a good idea to change the definition of 'in a
Document', we need a better terminology for alternative of 'in a Document',
such as 'in a Document or in a shadow tree', and should fix the relevant specs
by using that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.