Simple API proposal for writing file in local file system
Hello!
As a Web developer, I recently dig into the proposed FileSystem API [1]
which cover many use cases except one: How a user can actually allows a web
application to really write something in the user local file system (even
if it's slow). On the other hand, the File API: Writer [2] cover that need
but with a very overwelming interface which make very hard to use for
simple open/save operation.
There are well known workaround but we could make the life of web developer
easier by providing a simple convenient and secure interface to do this.
*# Accessing a file.*
Currently, as per the File API [3], the only way to access a file in the
user file system is by using the input type=file element. For some
reason, web developer don't want to expose such input to the user
(basically, because it's impossible to change its look and feel
consistently across browsers). To work around this, they hide it and
perform a fake click on it to prompt the user to pick some files.
We could provide a method that allow to do the same. In terms of security,
it would also make easier to track malicious attempt to acces the file
system as we will be able to monitor all access through that single method.
partial interface Navigator {
Promise openFile();
}
In case of success, the Promise will get a FileList object as the user can
pick more than one file.
*# Writing a file*
Currently, the only way to write a file on the user file system is to turn
a File object into a data URI with the MIME type application/octet-stream
in order to force a download of the file. This allows the user to save the
file wherever he wants on his device.
This is very rough and have two drawbacks:
1. if the user has setup his browser to always put downloaded file in a
given repository, it could require some extra action from the user to move
the file in his file system. This lead to a bad user experience that many
web developers wish to avoid.
2. if the user has previously open the file that need to be put back in
his file system, it's impossible to perform a silent writing. The user is
always prompt to perform the overriding itself. Once again, it's a bad user
experience that web developers wish to avoid.
To solve those two issues, we could provide a save method that will allow
to bypass any download setup and to provide a secure way of making silent
writing.
Note: It is worth noticing that Microsoft did something similare for IE11
with the msSaveBlob [4] and msSaveOrOpenBlob [5] methods
partial interface Navigator {
Promise saveFile(File file, optional boolean silent);
}
Note: it would be possible to add some events to keep track of the writing
operation, but Promise are good enough as we just want to save files in the
local file system rather than making some intensive IO operation. If a web
developer want to do that it would be better for him to relay on the
FileSystem API.
Making secured silent writing require two things:
1. Only file picked by the user and explicitely chose as writable by him
can be silently writen. The LockedFile object in the FileSystem API draft
is close to that but looks unnecessary complicated. I suggest to make
something simple by extending the File interface.
partial interface File {
readonly attribute DOMString? mode; // It can be 'readonly' or 'writable'
readonly attribute boolean? lock; // If true, only that tab can modify
the file
}
In order to sustain this, the 'mode' and 'lock' must be set when calling
the openFile method:
partial interface Navigator {
Promise openFile(optional DOMString mode, optional boolean lock);
}
- The 'mode' indicate if the File is 'readonly' or 'writable'. The
browser must retain the information of the location in the file system for
all writable files object, but this information will never be exposed to
web content.
- The 'lock' indicate if the browser must put a lock on the file,
allowing only the tab which access it first to write back into the file
(It's an internal lock maintain by the browser, it is never put at the file
system level, I'm not sure but I think there are to many side effects to
allow such a hard lock). If another tab has already put a lock on the file,
the Promise will fail with an appropriate error message. The lock is
released when the File object is destroyed (it is garbage collected, the
tab using it is shutdown, etc.). Note: it could be convenient to have a
setLock method to change the lock state.
If a File object is created without using the openFile method, the mode and
lock will be null;
The saving steps should be the following:
1. If a File object is saved using the saveFile method:
1. If the object has its mode set to 'readonly' or null
1. The user is prompt to choose where to save the file
2. If the object has its mode set to 'writable'
1. If the silent parameter is set to true
1. if the file is no longer available in the
Re: Missing Features: Stream Control
Should this not be synchronized with the Streams API? Please see recent evolutions [1] and thread [2] (where WebRTC streams are mentioned) Ccing Webapps and Takeshi/Feras. Regarding your proposal I was about to propose to add about the same thing in Streams: at least a stop method (which would send an EOF) and maybe a resume method, or something like your pause/unpause. For flow control I think I am changing my mind, it looks impossible to do a precise flow control with js, so probably the API itself should handle it. Regards, Aymeric [1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0152.html [2] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0049.html Le 18/10/2013 18:24, Adam Roach a écrit : We've recently had some implementors reach out to ask about how to do certain things with the WebRTC interfaces, and I've been pretty well unable to turn up anything that makes a lot of sense for most of the interesting stream-control interfaces. Some of this is talked about here, with an implication that the author of this wiki page, at least, would be willing to leave some of them unspecified for the first version of WebRTC: http://www.w3.org/2011/04/webrtc/wiki/Transport_Control#Needs_further_discussion.2C_maybe_for_later_versions Unfortunately, I don't think we can leave stream pause/unpause or stream rejection/removal out of the first version of the document. The good news is that I think we have all the interfaces necessary to do these things; we just need to spell out clear semantics for them. As a high-level thumbnail sketch, here's what I think makes sense: 1. To pause a track that you are sending, set enabled=false on a MediaStreamTrack that you have added to a PeerConnection. This information will cause the PeerConnection to stop sending the associated RTP. Maybe this triggers an onnegotiationneeded to set the corresponding m-line to recvonly or inactive and maybe it just stops sending the stream; I'm not sure which makes more sense. * To unpause, set enabled back to true, and the steps are reversed * To pause all the MSTs associated with a MediaStream, use enabled on the MediaStream itself. 2. To pause a track that you are receiving, set enabled=false on the MediaStreamTrack that you received from the PeerConnection via onaddstream. This will cause the MST to stop providing media to whatever sink it has been wired to, and trigger an onnegotiationneeded event. The subsequent CreateOffer sets the corresponding m-line to sendonly or inactive, as appropriate. * As above, this operation can also be performed on a MediaStream to impact all of its tracks. 3. To reject a track that has been offered, call stop() on the corresponding MediaStreamTrack after it has been received via onaddstream, but before calling CreateAnswer. This will cause it to be rejected with a port number of zero. 4. To remove a track from an ongoing session, call stop() on the corresponding MediaStreamTrack object. This will (a) immediately stop transmitting associated RTP, and (b) trigger an onnegotiationneeded event. * If both the sending and receiving MST associated with that m-line have been stop()ed, then the subsequent CreateOffer sets the port on the corresponding m-line to zero. * If only one of the two MSTs associated with that m-line has been stop()ed, then the subsequent CreateOffer sets the corresponding m-line to sendonly, receiveonly, or inactive, as appropriate. Does this make sense to everyone? It seems pretty clean, easy to specify, and reasonable to implement. Best of all, we're not changing any currently defined interfaces, just providing clear semantics for certain operations. /a -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms
Re: Missing Features: Stream Control
On 10/18/13 11:56, Aymeric Vitte wrote: Regarding your proposal I was about to propose to add about the same thing in Streams: at least a stop method (which would send an EOF) and maybe a resume method, or something like your pause/unpause. To be clear, the .enabled flag and .stop() method are already there, and they already pause/unpause the stream and tear it down, respectively. I'm just proposing concrete semantics for how they interact with any PeerConnection that the track is associated with. /a
Re: Simple API proposal for writing file in local file system
Hi Jeremie,
Have you seen this proposal?
http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0379.html
It's not clear to me if your proposal here is trying to solve problems
that the above proposal doesn't already solve...
Cheers,
Ehsan
On 2013-10-18 8:07 AM, Jeremie Patonnier wrote:
Hello!
As a Web developer, I recently dig into the proposed FileSystem API [1]
which cover many use cases except one: How a user can actually allows a web
application to really write something in the user local file system (even
if it's slow). On the other hand, the File API: Writer [2] cover that need
but with a very overwelming interface which make very hard to use for
simple open/save operation.
There are well known workaround but we could make the life of web developer
easier by providing a simple convenient and secure interface to do this.
*# Accessing a file.*
Currently, as per the File API [3], the only way to access a file in the
user file system is by using the input type=file element. For some
reason, web developer don't want to expose such input to the user
(basically, because it's impossible to change its look and feel
consistently across browsers). To work around this, they hide it and
perform a fake click on it to prompt the user to pick some files.
We could provide a method that allow to do the same. In terms of security,
it would also make easier to track malicious attempt to acces the file
system as we will be able to monitor all access through that single method.
partial interface Navigator {
Promise openFile();
}
In case of success, the Promise will get a FileList object as the user can
pick more than one file.
*# Writing a file*
Currently, the only way to write a file on the user file system is to turn
a File object into a data URI with the MIME type application/octet-stream
in order to force a download of the file. This allows the user to save the
file wherever he wants on his device.
This is very rough and have two drawbacks:
1. if the user has setup his browser to always put downloaded file in a
given repository, it could require some extra action from the user to move
the file in his file system. This lead to a bad user experience that many
web developers wish to avoid.
2. if the user has previously open the file that need to be put back in
his file system, it's impossible to perform a silent writing. The user is
always prompt to perform the overriding itself. Once again, it's a bad user
experience that web developers wish to avoid.
To solve those two issues, we could provide a save method that will allow
to bypass any download setup and to provide a secure way of making silent
writing.
Note: It is worth noticing that Microsoft did something similare for IE11
with the msSaveBlob [4] and msSaveOrOpenBlob [5] methods
partial interface Navigator {
Promise saveFile(File file, optional boolean silent);
}
Note: it would be possible to add some events to keep track of the writing
operation, but Promise are good enough as we just want to save files in the
local file system rather than making some intensive IO operation. If a web
developer want to do that it would be better for him to relay on the
FileSystem API.
Making secured silent writing require two things:
1. Only file picked by the user and explicitely chose as writable by him
can be silently writen. The LockedFile object in the FileSystem API draft
is close to that but looks unnecessary complicated. I suggest to make
something simple by extending the File interface.
partial interface File {
readonly attribute DOMString? mode; // It can be 'readonly' or 'writable'
readonly attribute boolean? lock; // If true, only that tab can modify
the file
}
In order to sustain this, the 'mode' and 'lock' must be set when calling
the openFile method:
partial interface Navigator {
Promise openFile(optional DOMString mode, optional boolean lock);
}
- The 'mode' indicate if the File is 'readonly' or 'writable'. The
browser must retain the information of the location in the file system for
all writable files object, but this information will never be exposed to
web content.
- The 'lock' indicate if the browser must put a lock on the file,
allowing only the tab which access it first to write back into the file
(It's an internal lock maintain by the browser, it is never put at the file
system level, I'm not sure but I think there are to many side effects to
allow such a hard lock). If another tab has already put a lock on the file,
the Promise will fail with an appropriate error message. The lock is
released when the File object is destroyed (it is garbage collected, the
tab using it is shutdown, etc.). Note: it could be convenient to have a
setLock method to change the lock state.
If a File object is created without using the openFile method, the mode and
lock will be null;
The saving steps should be the following:
1. If
Re: Missing Features: Stream Control
On 10/18/13 6:57 PM, Aymeric Vitte wrote: Should this not be synchronized with the Streams API? Please see recent evolutions [1] and thread [2] (where WebRTC streams are mentioned) I think we're talking about completely different streams, and what Adam is proposing is applicable for MediaStreamTracks in the context of a WebRTC PeerConnection. Ccing Webapps and Takeshi/Feras. Regarding your proposal I was about to propose to add about the same thing in Streams: at least a stop method (which would send an EOF) and maybe a resume method, or something like your pause/unpause. For flow control I think I am changing my mind, it looks impossible to do a precise flow control with js, so probably the API itself should handle it. Regards, Aymeric [1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0152.html [2] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0049.html Le 18/10/2013 18:24, Adam Roach a écrit : We've recently had some implementors reach out to ask about how to do certain things with the WebRTC interfaces, and I've been pretty well unable to turn up anything that makes a lot of sense for most of the interesting stream-control interfaces. Some of this is talked about here, with an implication that the author of this wiki page, at least, would be willing to leave some of them unspecified for the first version of WebRTC: http://www.w3.org/2011/04/webrtc/wiki/Transport_Control#Needs_further_discussion.2C_maybe_for_later_versions Unfortunately, I don't think we can leave stream pause/unpause or stream rejection/removal out of the first version of the document. The good news is that I think we have all the interfaces necessary to do these things; we just need to spell out clear semantics for them. As a high-level thumbnail sketch, here's what I think makes sense: 1. To pause a track that you are sending, set enabled=false on a MediaStreamTrack that you have added to a PeerConnection. This information will cause the PeerConnection to stop sending the associated RTP. Maybe this triggers an onnegotiationneeded to set the corresponding m-line to recvonly or inactive and maybe it just stops sending the stream; I'm not sure which makes more sense. * To unpause, set enabled back to true, and the steps are reversed * To pause all the MSTs associated with a MediaStream, use enabled on the MediaStream itself. 2. To pause a track that you are receiving, set enabled=false on the MediaStreamTrack that you received from the PeerConnection via onaddstream. This will cause the MST to stop providing media to whatever sink it has been wired to, and trigger an onnegotiationneeded event. The subsequent CreateOffer sets the corresponding m-line to sendonly or inactive, as appropriate. * As above, this operation can also be performed on a MediaStream to impact all of its tracks. 3. To reject a track that has been offered, call stop() on the corresponding MediaStreamTrack after it has been received via onaddstream, but before calling CreateAnswer. This will cause it to be rejected with a port number of zero. 4. To remove a track from an ongoing session, call stop() on the corresponding MediaStreamTrack object. This will (a) immediately stop transmitting associated RTP, and (b) trigger an onnegotiationneeded event. * If both the sending and receiving MST associated with that m-line have been stop()ed, then the subsequent CreateOffer sets the port on the corresponding m-line to zero. * If only one of the two MSTs associated with that m-line has been stop()ed, then the subsequent CreateOffer sets the corresponding m-line to sendonly, receiveonly, or inactive, as appropriate. Does this make sense to everyone? It seems pretty clean, easy to specify, and reasonable to implement. Best of all, we're not changing any currently defined interfaces, just providing clear semantics for certain operations. /a -- Peersm :http://www.peersm.com node-Tor :https://www.github.com/Ayms/node-Tor GitHub :https://www.github.com/Ayms
Re: Missing Features: Stream Control
Le 18/10/2013 19:31, Stefan Håkansson LK a écrit : I think we're talking about completely different streams, and what Adam is proposing is applicable for MediaStreamTracks in the context of a WebRTC PeerConnection. I don't see why, a stream is a stream, this would be strange that a Streams API is defined and WebRTC is using something different, moreover that this does not change the spec, the spec just has to support Streams -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms
Re: Missing Features: Stream Control
Le 18/10/2013 19:13, Adam Roach a écrit : To be clear, the .enabled flag and .stop() method are already there, and they already pause/unpause the stream and tear it down, respectively. I'm just proposing concrete semantics for how they interact with any PeerConnection that the track is associated with. But they are not in the Streams proposal, see my other answer. -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms
Re: Missing Features: Stream Control
On 10/18/13 12:47, Aymeric Vitte wrote: Le 18/10/2013 19:13, Adam Roach a écrit : To be clear, the .enabled flag and .stop() method are already there, and they already pause/unpause the stream and tear it down, respectively. I'm just proposing concrete semantics for how they interact with any PeerConnection that the track is associated with. But they are not in the Streams proposal, see my other answer. To make my point clearer: this isn't the right mailing list to talk about making changes to the API on MediaStream and MediaStreamTrack. If I had been proposing to change those APIs, it would have been on the public-media-capture list, not the public-webrtc list. All I was trying to talk about is how the existing API influences the behavior of RTCPeerConnection, which is why I was talking about it on this list. If you want to propose changes to MediaStream and MediaStreamTrack, please take them to public-media-capture. /a
Re: Simple API proposal for writing file in local file system
Hi!
2013/10/18 Ehsan Akhgari ehsan.akhg...@gmail.com
Hi Jeremie,
Have you seen this proposal? http://lists.w3.org/Archives/**
Public/public-script-coord/**2013JulSep/0379.htmlhttp://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0379.html
It's not clear to me if your proposal here is trying to solve problems
that the above proposal doesn't already solve...
Yes, I saw that proposal but no, I do not suggest to solve the same problem.
I found that proposal for an abstract file system very good when the
application have to work in its own world.
Unfortunately there is a few cases where it is very convenient to allow to
actually truly write on the os file system.
Here a few concrete example:
- When the user want to export his file to an external storage (Hard
drive, USB storage, SD Card, etc.) In that case it where web dev use the
data URI workaround to download the file.
- When the user want to use a resource available in its file system and
want to update that resource with any change he made to have some other
application using it as well (mostly native apps on desktop). For example,
editing an image and put it back on the file system to have another native
application accessing it (let's say for example Adobe Lightroom). So being
able to open a file and perform (silent) saving on the original file allows
to build smoother workflow when using a native app and a web app at the
same time.
As Mozilla teams are currently completely overwhelmed by the Firefox OS
project, they tend to forget those use cases that are very common on
Desktop. On the other hand, I think that FileWriter is way to complex and
there is a middle simpler ground that can solve the most common use cases
such as the two above.
My proposal does not suggest to do something different than what is
currently possible (except the silent saving). Just to ease the life of Web
dev by avoiding them to work around their usual problem:
- Instantiate a full DOM object and listen for its events just to pick a
file sucks
- Being unable to silently save a file granted by the user to be savable
sucks.
I don't try to solve more than this. It's just common issues for web dev
like me and that will make my life easier if it would be possible do this
simply, efficiently and in a secure way.
Best,
Jérémie
On 2013-10-18 8:07 AM, Jeremie Patonnier wrote:
Hello!
As a Web developer, I recently dig into the proposed FileSystem API [1]
which cover many use cases except one: How a user can actually allows a
web
application to really write something in the user local file system (even
if it's slow). On the other hand, the File API: Writer [2] cover that need
but with a very overwelming interface which make very hard to use for
simple open/save operation.
There are well known workaround but we could make the life of web
developer
easier by providing a simple convenient and secure interface to do this.
*# Accessing a file.*
Currently, as per the File API [3], the only way to access a file in the
user file system is by using the input type=file element. For some
reason, web developer don't want to expose such input to the user
(basically, because it's impossible to change its look and feel
consistently across browsers). To work around this, they hide it and
perform a fake click on it to prompt the user to pick some files.
We could provide a method that allow to do the same. In terms of security,
it would also make easier to track malicious attempt to acces the file
system as we will be able to monitor all access through that single
method.
partial interface Navigator {
Promise openFile();
}
In case of success, the Promise will get a FileList object as the user can
pick more than one file.
*# Writing a file*
Currently, the only way to write a file on the user file system is to turn
a File object into a data URI with the MIME type application/octet-stream
in order to force a download of the file. This allows the user to save the
file wherever he wants on his device.
This is very rough and have two drawbacks:
1. if the user has setup his browser to always put downloaded file in
a
given repository, it could require some extra action from the user to
move
the file in his file system. This lead to a bad user experience that
many
web developers wish to avoid.
2. if the user has previously open the file that need to be put back
in
his file system, it's impossible to perform a silent writing. The
user is
always prompt to perform the overriding itself. Once again, it's a
bad user
experience that web developers wish to avoid.
To solve those two issues, we could provide a save method that will allow
to bypass any download setup and to provide a secure way of making silent
writing.
Note: It is worth noticing that Microsoft did something similare for IE11
with the msSaveBlob [4] and msSaveOrOpenBlob [5]
[Bug 23564] New: IDL for open() doesn't match implementation reality
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23564 Bug ID: 23564 Summary: IDL for open() doesn't match implementation reality Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: bzbar...@mit.edu QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org WebIDL redefined what happens when undefined is passed to an optional boolean whatever = true argument, but for open() I believe we want to keep the old behavior of treating undefined as false. See http://lists.w3.org/Archives/Public/public-script-coord/2013OctDec/0041.html for details, including the IDL Gecko is using for open() now. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Simple API proposal for writing file in local file system
On 10/18/2013 11:11 AM, Jeremie Patonnier wrote: 2013/10/18 Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com Have you seen this proposal? http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0379.html It's not clear to me if your proposal here is trying to solve problems that the above proposal doesn't already solve... Yes, I saw that proposal but no, I do not suggest to solve the same problem. I found that proposal for an abstract file system very good when the application have to work in its own world. Unfortunately there is a few cases where it is very convenient to allow to actually truly write on the os file system. Here a few concrete example: * When the user want to export his file to an external storage (Hard drive, USB storage, SD Card, etc.) In that case it where web dev use the data URI workaround to download the file. * When the user want to use a resource available in its file system and want to update that resource with any change he made to have some other application using it as well (mostly native apps on desktop). For example, editing an image and put it back on the file system to have another native application accessing it (let's say for example Adobe Lightroom). So being able to open a file and perform (silent) saving on the original file allows to build smoother workflow when using a native app and a web app at the same time. Chrome has a secured extension for maintaining access to the local file system: http://developer.chrome.com/apps/fileSystem.html They only allow this for packaged applications. This, with the FileSystem API allows for -most- of what you'd like. While it can be a little clumsy to work with, so can IDB; it just takes some wrapping code. As discussed, an easier promises based API is being developed by Mozilla, and while it's questionable as to whether Google or other vendors will follow, wrapping existing callback APIs into promises is not a big deal in the JS-side. Unfortunately, nobody has stepped forward with concrete code for file watchers. The File API itself is a little broken, as File objects were supposed to be immutable, but we have undefined behavior when a File is changed on the local file system. http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0846.html http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0431.html -Charles
Re: [webcomponents] HTML Imports
On Sun, Oct 6, 2013 at 9:38 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
So you have link href=blah.html in meh.html and blah.html is:
div id=test/div
script /* how do I get to #test? */ /script
document.currentScript.ownerDocument.querySelector(#test) :)
This only works for code running directly in the script. The current
setup means that any time an author has something like:
template id=foo.../template
script
function cloneFoo() { /* get foo and return it. */ }
/script
they'll have to use a closure to capture the document that the
template lives in, which is rather surprising to me. Also, storing the
document in a global variable is a footgun, because that global
variable would potentially collide with another import trying to do
the same thing. ES6 modules would help here, but there a way's off.
I think the greatest impact here will be on developers. They have to start
thinking in terms of multiple documents. We should ask Polymer people: they
wrote a ton of code with Imports now and I bet they have opinions.
Out of curiosity, what have the Polymer guys been using imports for?
More than just declaring custom elements? I'm worried that we're
coming up with a very generic feature with odd semantics that only
make sense for one narrow use-case.
--
Blake Kaplan
Re: [webcomponents] HTML Imports
they'll have to use a closure to capture the document that the template
lives in
Yes, this is true. But stamping of templates tends to be something custom
elements are really good at, so this paritcular use case doesn't come up
very often.
Out of curiosity, what have the Polymer guys been using imports for?
1. Bundling resources. Imports can contain or chain to JS, CSS, or
additional HTML imports, so I have access to bundles in silos of
functionality instead of syntax.
2. Obscuring production details. I can import library.html and get an
entire dependency without knowing if it's an optimized build file or a
dependency tree of imports.
3. Relocatability. I can import elements.html and that package can
reference resources relative to itself.
4. Importing data as markup, where typically it's then the responsibility
of the importer to consume the data, not the import itself.
5. We would like to use imports for preloading images, depending on the
resolution of the 'view-in-import' discussion.
[sidebar] we tend to declare self-organizing custom elements for data and
then load them in imports. For example, many of our library elements has an
associated `metadata.html` file that contains `x-meta` elements with
various details. An interested object can make an blank x-meta element to
access the database, and the details are are encapsulated inside the x-meta
implementation.
Scott
On Fri, Oct 18, 2013 at 3:37 PM, Blake Kaplan mrb...@gmail.com wrote:
On Sun, Oct 6, 2013 at 9:38 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
So you have link href=blah.html in meh.html and blah.html is:
div id=test/div
script /* how do I get to #test? */ /script
document.currentScript.ownerDocument.querySelector(#test) :)
This only works for code running directly in the script. The current
setup means that any time an author has something like:
template id=foo.../template
script
function cloneFoo() { /* get foo and return it. */ }
/script
they'll have to use a closure to capture the document that the
template lives in, which is rather surprising to me. Also, storing the
document in a global variable is a footgun, because that global
variable would potentially collide with another import trying to do
the same thing. ES6 modules would help here, but there a way's off.
I think the greatest impact here will be on developers. They have to
start
thinking in terms of multiple documents. We should ask Polymer people:
they
wrote a ton of code with Imports now and I bet they have opinions.
Out of curiosity, what have the Polymer guys been using imports for?
More than just declaring custom elements? I'm worried that we're
coming up with a very generic feature with odd semantics that only
make sense for one narrow use-case.
--
Blake Kaplan
Re: [webcomponents] HTML Imports
I remember Adam raving about HTML Imports being awesome after he tried
them. Adam, can you provide color? :)
:DG
On Fri, Oct 18, 2013 at 4:11 PM, Scott Miles sjmi...@google.com wrote:
they'll have to use a closure to capture the document that the template
lives in
Yes, this is true. But stamping of templates tends to be something custom
elements are really good at, so this paritcular use case doesn't come up
very often.
Out of curiosity, what have the Polymer guys been using imports for?
1. Bundling resources. Imports can contain or chain to JS, CSS, or
additional HTML imports, so I have access to bundles in silos of
functionality instead of syntax.
2. Obscuring production details. I can import library.html and get an
entire dependency without knowing if it's an optimized build file or a
dependency tree of imports.
3. Relocatability. I can import elements.html and that package can
reference resources relative to itself.
4. Importing data as markup, where typically it's then the responsibility
of the importer to consume the data, not the import itself.
5. We would like to use imports for preloading images, depending on the
resolution of the 'view-in-import' discussion.
[sidebar] we tend to declare self-organizing custom elements for data and
then load them in imports. For example, many of our library elements has an
associated `metadata.html` file that contains `x-meta` elements with
various details. An interested object can make an blank x-meta element to
access the database, and the details are are encapsulated inside the x-meta
implementation.
Scott
On Fri, Oct 18, 2013 at 3:37 PM, Blake Kaplan mrb...@gmail.com wrote:
On Sun, Oct 6, 2013 at 9:38 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
So you have link href=blah.html in meh.html and blah.html is:
div id=test/div
script /* how do I get to #test? */ /script
document.currentScript.ownerDocument.querySelector(#test) :)
This only works for code running directly in the script. The current
setup means that any time an author has something like:
template id=foo.../template
script
function cloneFoo() { /* get foo and return it. */ }
/script
they'll have to use a closure to capture the document that the
template lives in, which is rather surprising to me. Also, storing the
document in a global variable is a footgun, because that global
variable would potentially collide with another import trying to do
the same thing. ES6 modules would help here, but there a way's off.
I think the greatest impact here will be on developers. They have to
start
thinking in terms of multiple documents. We should ask Polymer people:
they
wrote a ton of code with Imports now and I bet they have opinions.
Out of curiosity, what have the Polymer guys been using imports for?
More than just declaring custom elements? I'm worried that we're
coming up with a very generic feature with odd semantics that only
make sense for one narrow use-case.
--
Blake Kaplan
Re: Missing Features: Stream Control
What I am saying here is that there should be an unique and unified Streams API supported by all related APIs, each group where it is relevant should feel concerned instead of thinking another one might be. Le 18/10/2013 20:04, Adam Roach a écrit : On 10/18/13 12:47, Aymeric Vitte wrote: Le 18/10/2013 19:13, Adam Roach a écrit : To be clear, the .enabled flag and .stop() method are already there, and they already pause/unpause the stream and tear it down, respectively. I'm just proposing concrete semantics for how they interact with any PeerConnection that the track is associated with. But they are not in the Streams proposal, see my other answer. To make my point clearer: this isn't the right mailing list to talk about making changes to the API on MediaStream and MediaStreamTrack. If I had been proposing to change those APIs, it would have been on the public-media-capture list, not the public-webrtc list. All I was trying to talk about is how the existing API influences the behavior of RTCPeerConnection, which is why I was talking about it on this list. If you want to propose changes to MediaStream and MediaStreamTrack, please take them to public-media-capture. /a -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms
Re: Simple API proposal for writing file in local file system
On Fri, Oct 18, 2013 at 11:11 AM, Jeremie Patonnier jeremie.patonn...@gmail.com wrote: My proposal does not suggest to do something different than what is currently possible (except the silent saving). Just to ease the life of Web dev by avoiding them to work around their usual problem: - Instantiate a full DOM object and listen for its events just to pick a file sucks - Being unable to silently save a file granted by the user to be savable sucks. I agree that the current API for bringing up a filepicker is pretty bad. It's something that has come up many times but the appetite for creating a new API that has the same feature set as an existing API has been about the same as it usually is: very low. The ability to open a file with read/write access is definitely an interesting one and one that would be an excellent addition to the web platform. However the trickiest piece is not the exact API. It's how to design the user experience such that users understand that they are giving more than readonly access to a file. I understand that the FileWriter or FileSaver APIs from Google could be part of a solution that did this, but as far as I can tell neither is enough on their own, at least as defined in [1]. If the Google API or implementation allowed opening files in read/write mode, can you show an example snippet of code that triggers this? [1] http://dev.w3.org/2009/dap/file-system/file-writer.html / Jonas
Re: Shadow DOM and Fallback contents for images
On Oct 17, 2013, at 10:57 PM, Hayato Ito hay...@chromium.org wrote: I am aware that there are issues related to selections regarding Shadow DOM both in the spec and the implementation. But I don't have a clear answer to resolve that and couldn't satisfy users. This is one of the toughest issues, I think. Could you elaborate? Some of us have already started to tackle this issue. We had a similar topic on blinkon conference (http://bit.ly/blinkon). Could you summarize what you've discussed? I can't figure out which slide I need to be looking at or what kinds of discussions took place there. CC-ing yosin@, hoping he has the latest idea. On Fri, Oct 18, 2013 at 2:24 PM, Hajime Morrita morr...@google.com wrote: B looks fine. We don't have to rush into the API addition though. The API is just a shortcut of a tree traversal and easy to polyfill. It won't too late to design this after hearing some concrete usecases. Also, we need to extend this rough idea to take reprojection (content and shadow) into account. I hope projection-proficient people like Dimitri and Hayato help to do that. On Fri, Oct 18, 2013 at 1:15 PM, Jonas Sicking jo...@sicking.cc wrote: On Oct 17, 2013 6:48 PM, Hajime Morrita morr...@google.com wrote: On Fri, Oct 18, 2013 at 3:56 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Oct 17, 2013 at 1:55 AM, Hajime Morrita morr...@google.com wrote: On Thu, Oct 17, 2013 at 5:01 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 16, 2013, at 9:47 PM, Hajime Morrita morr...@google.com wrote: D. H[ello Shado]w World - selection spans outside to inside. Suppose we allowed this selection. Then how does one go about pasting this content elsewhere? Most likely, whatever other content editable area, mail client, or some random app (e.g. MS Word) into which the user is going to paste wouldn’t support shadow DOM and most certainly wouldn’t have the component the original page happened to have. We have to define how Range.cloneContents() or extractContents() works against shadow-selecting range, assuming selection is built on top of DOM Range. This doesn't seem that complicated. As cloned element drops its shadow, these range-generated nodes won't have shadow either. Oh, sounds like you are suggesting that we expand the Range API such that it can have awareness of spanning parts of a shadow DOM tree. While still keeping the existing endpoints in the same root? That like that idea! No, that isn't what I meant. I just want to make it explicit that Range API works well with shadow trees. However it happened to be taken by you in some interesting way, and I'm fine with this ;-) So what does this mean? The subranges property exposes the selections of containing ShadowRoots? That sounds reasonable. Although I don't think Blink supports this in short term because it only has per-document selection and doesn't have per-tree ones, it is rather a lack of features which can be improved eventually than something totally incompatible and hurting the Web. Let me confirm what we're talking about. 1. Each shadow tree has its own selection. Each selection spans nodes in the owning tree only. 2. User initiated selection operation (like dragging) can operate multiple selections in different trees seamlessly as if it is single selection crossing boundaries. 3. Range and/or Selection API could expose sub-selections/sub-ranges of containing trees. Going back to the example, C. H[ello Shadow Worl]d - selection stays outside shadow, but its range contains a node with shadow. This turns something like C2: H[ello (Shadow) Worl]d - There are two selections - [] for outside tree and () for inside tree. And this this one D. H[ello Shado]w World - selection spans outside to inside. turns D2: H[ello] (Shado)w World Is is correct? Yes! I think there are at least three ways we could expose these inner ranges: A) Separate function in the selection API for getting shadow ranges. B) Extension to the Range object for getting sub-shadow ranges. C) Through the existing multi-range support in the selection API. C has the advantage that no range or selection API changes are needed. But has the downside that it makes it messy to associate which ranges are subranges of other ranges. B has the advantage that it works anywhere where Range objects are used. But the downside is that it makes Ranges more complicated. A has the advantage that it keeps Ranges simple. I think I'm leaning towards B personally. I don't think the added complexity to Range objects is a big deal. Anywhere where Ranges are used you'd likely want to deal with shadow trees in one way or another. / Jonas -- morrita -- Hayato
