Re: Publishing a new WD of Clipboard API and events spec
Arthur Barstow wrote: Given the last WD of Clipboard API was published about one year ago (April 2013) and the spec has had some substantive changes ([1]), I think it would be useful to publish a new WD to replace the current Technical Report and to clearly indicate the spec is active. Is that something you can do within the next week or two? I think so, yes - though I may not have Anolis set up on any computer I'm carrying right now, so only if somebody else can run Anolis for me.. (I'm back home in one month or so, so I could presumably get the draft pubready all by myself then. I guess I could also add the cross-references manually for such a small spec..). Also, given this spec started in 2006, I'm wondering if it would be practical or useful to put those features that have two or more interoperable features in one spec and moving other less interoperable features into a separate spec (like has been done with Selectors API and XHR). WDYT? I'll look at this a bit, but I don't think the differences between a v.1 and v.2 would make much sense from an editing point of view. I'd be more inclined to call the spec feature complete at some point even though it may have to wait a few years for implementations to catch up before being officially blessed.. -Hallvord
Re: [admin] Should WebApps' HTML Templates spec be published as a WG Note?
On 2/26/14 9:43 AM, ext Arthur Barstow wrote: Hi Robin, Dimitri, All, Since HTML Templates is now part of HTML5, to help avoid confusion, I think WebApps' last TR of the spec ([html-templates]) should be replaced with a WG Note that clearly indicates WebApps' work on the standalone spec has stopped and the feature is now part of HTML5. (The Note could also be void of any technical substance as DAP recently did f.ex. [contacts-api]). Dimitri, Rafael, Tony - there is also a question about the contents of the HTML Templates [ED]. What are you planning to do with it (delete it; remove the guts and link to HTML(5); something else)? -Art [ED] http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html WDYT? Any objections? (If we agree to publish a WG Note, I'll create it). -Thanks, AB [html-templates] http://www.w3.org/TR/html-templates/ [contacts-api] http://www.w3.org/TR/contacts-api/
Re: [admin] Should WebApps' HTML Templates spec be published as a WG Note?
What do you recommend? It seems a little heavy-handed to kill it or gut it. What about putting a big-red warning at the top that it has been merged to HTML and no longer has normative weight. On Thu, Feb 27, 2014 at 7:27 AM, Arthur Barstow art.bars...@nokia.comwrote: On 2/26/14 9:43 AM, ext Arthur Barstow wrote: Hi Robin, Dimitri, All, Since HTML Templates is now part of HTML5, to help avoid confusion, I think WebApps' last TR of the spec ([html-templates]) should be replaced with a WG Note that clearly indicates WebApps' work on the standalone spec has stopped and the feature is now part of HTML5. (The Note could also be void of any technical substance as DAP recently did f.ex. [contacts-api]). Dimitri, Rafael, Tony - there is also a question about the contents of the HTML Templates [ED]. What are you planning to do with it (delete it; remove the guts and link to HTML(5); something else)? -Art [ED] http://dvcs.w3.org/hg/webcomponents/raw-file/tip/ spec/templates/index.html WDYT? Any objections? (If we agree to publish a WG Note, I'll create it). -Thanks, AB [html-templates] http://www.w3.org/TR/html-templates/ [contacts-api] http://www.w3.org/TR/contacts-api/
Re: [admin] Should WebApps' HTML Templates spec be published as a WG Note?
On 2/27/14 11:41 AM, ext Rafael Weinstein wrote: What do you recommend? It seems a little heavy-handed to kill it or gut it. What about putting a big-red warning at the top that it has been merged to HTML and no longer has normative weight. I don't have a strong preference now and would like to hear from others. The above do have different +/-. I think the principle of least surprise (`follow your nose`) indicates navigating to the ED would redirect to the HTML spec. It seems like the worst case scenario is for the contents of the ED to be inconsistent with HTML. -Art On Thu, Feb 27, 2014 at 7:27 AM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: On 2/26/14 9:43 AM, ext Arthur Barstow wrote: Hi Robin, Dimitri, All, Since HTML Templates is now part of HTML5, to help avoid confusion, I think WebApps' last TR of the spec ([html-templates]) should be replaced with a WG Note that clearly indicates WebApps' work on the standalone spec has stopped and the feature is now part of HTML5. (The Note could also be void of any technical substance as DAP recently did f.ex. [contacts-api]). Dimitri, Rafael, Tony - there is also a question about the contents of the HTML Templates [ED]. What are you planning to do with it (delete it; remove the guts and link to HTML(5); something else)? -Art [ED] http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html WDYT? Any objections? (If we agree to publish a WG Note, I'll create it). -Thanks, AB [html-templates] http://www.w3.org/TR/html-templates/ [contacts-api] http://www.w3.org/TR/contacts-api/
Re: Indexed DB: Opening connections, versions, and priority
On Feb 26, 2014, at 10:35 AM, Joshua Bell jsb...@google.com wrote: While looking at a Chrome bug [1], I reviewed the Indexed DB draft, section 3.3.1 [2] Opening a database: These steps are not run for any other connections with the same origin and name but with a higher version And the note: This means that if two databases with the same name and origin, but with different versions, are being opened at the same time, the one with the highest version will attempt to be opened first. If it is able to successfully open, then the one with the lower version will receive an error. I interpret that as (and perhaps the spec should be updated to read): This means that if two open requests are made to the database with the same name and origin at the same time, the open request with the highest version will be processed first. If it is able to successfully open, then the request with the lower version will receive an error. So far as I can tell with a test [3], none of Chrome (33), Firefox (27), or IE (10) implement this per spec. Instead of processing the request with the highest version first, they process the first request that was received. Is my interpretation of the spec correct? Is my test [3] correct? If yes and yes, should we update the spec to match reality? I think the ambiguous language in the spec, and also in your substitute proposal, is at the same time. I would think if one request is received first, then they are not, in fact, at the same time. Indeed, it would be pretty hard for two requests to be exactly simultaneous. If at the same time is actually supposed to mean something about receiving a new open request while an older one is still in flight in some sense, then the spec should say that, and specify exactly what it means. I would think the only observable time is actually delivering the callback. That would imply a rule that if you receive a request with a higher version number before the completion callback for a currently pending open request has been delivered, you need to cancel the attempt and try with the higher version (possibly retrying with the lower version again later). Regards, Maciej
Re: Indexed DB: Opening connections, versions, and priority
On Thu, Feb 27, 2014 at 10:51 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 26, 2014, at 10:35 AM, Joshua Bell jsb...@google.com wrote: While looking at a Chrome bug [1], I reviewed the Indexed DB draft, section 3.3.1 [2] Opening a database: These steps are not run for any other connections with the same origin and name but with a higher version And the note: This means that if two databases with the same name and origin, but with different versions, are being opened at the same time, the one with the highest version will attempt to be opened first. If it is able to successfully open, then the one with the lower version will receive an error. I interpret that as (and perhaps the spec should be updated to read): This means that if two open requests are made to the database with the same name and origin at the same time, the open request with the highest version will be processed first. If it is able to successfully open, then the request with the lower version will receive an error. So far as I can tell with a test [3], none of Chrome (33), Firefox (27), or IE (10) implement this per spec. Instead of processing the request with the highest version first, they process the first request that was received. Is my interpretation of the spec correct? Is my test [3] correct? If yes and yes, should we update the spec to match reality? I think the ambiguous language in the spec, and also in your substitute proposal, is at the same time. I would think if one request is received first, then they are not, in fact, at the same time. Indeed, it would be pretty hard for two requests to be exactly simultaneous. Agreed. If at the same time is actually supposed to mean something about receiving a new open request while an older one is still in flight in some sense, then the spec should say that, and specify exactly what it means. I would think the only observable time is actually delivering the callback. The spec appears to implicitly describe a queue (or set?) of pending connection requests, and then how to process them. There's a thread which touches on this at http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0725.html - which also points out that at the same time is unclear. The jsfiddle shows how this can happen, when a connection is currently open and several subsequent requests are blocked by either being a different version and/or there being a pending delete. Once several requests are blocked, and become unblocked, one could argue that these are now available to be processed at the same time. But as I said, I agree that the spec's informative NOTE is ambiguous and unhelpful, despite trying to clarify a normative algorithm. But ignoring the note and looking at the normative algorithm: am I correct that this does not appear to match the behavior any of the current implementations? That would imply a rule that if you receive a request with a higher version number before the completion callback for a currently pending open request has been delivered, you need to cancel the attempt and try with the higher version (possibly retrying with the lower version again later). Once a connection request has made it past step 3, neither the spec nor any implementations appear to abort the steps if another request comes in, but I'm not sure that's observably different than processing pending requests in arrival order vs. version order.
[Bug 24844] New: Spec is missing body and head elements
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24844 Bug ID: 24844 Summary: Spec is missing body and head elements Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Web Storage (editor: Ian Hickson) Assignee: i...@hixie.ch Reporter: tobie.lan...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org The spec hosted on /TR doesn't have a head or body element. This makes parsing it (e.g. for testing purposes) a lot more complicated than other specs. -- You are receiving this mail because: You are on the CC list for the bug.
RE: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
Of course it would be nice to support a script that wants to generate random
HTML with embedded files to place on the clipboard (although I think most of
those use cases can already be met by using URLs and assuming that any
software reading HTML from the clipboard can understand URLs..). However, one
can imagine a use case for example with a CANVAS app where the script wants
to copy the state of the CANVAS as an image inside HTML it places on the
clipboard - having the script create src=cid:n type markup, append files,
and make the UA translate that to the platform's native clipboard
implementation's way of referencing one part on the clipboard from another
part..
I was thinking about images that aren't available cross-domain, like Facebook
pictures. If you copy them, Facebook could use CID to place them on the
clipboard since a Facebook URL wouldn’t be accessible to an email client that
receives the pasted content.
document.addEventListener('copy', function(e){
// So, you want to copy the current status of your game? No problem.
// Let's say this game generates a number of PNG graphics from CANVAS
tags
// and keeps them in memory in ArrayBuffers or something
var html = 'divbplayer/b\'s medals: img src=cid:1img
src=cid:2/div';
e.clipboardData.items.add(html, 'text/html');
e.clipboardData.items.add(new File(medals[0], 'medal.png',
{type:'image/png'}));
e.clipboardData.items.add(new File(medals[1], 'medal.png',
{type:'image/png'}));
e.preventDefault();
}, false);
This seems like we're depending on add() working in a precise order, which
seems vulnerable to code changes or other issues. Maybe add() should return the
location in the list where the item was added, and then it can be used with CID
more safely? I know this is part of HTML5 not ClipboardAPI though. Thoughts?
Second, can you provide the javascript for how a site would put them into the
pasted markup during paste?
The way I thought this would work, would be that the site starts XHR uploads
from the paste processing, and shows some intermediate 'loading' animation or
something before it gets the final URLs back from the server. A bit like this
(although some things could be more elegant, like the insertion of the data
which needs to take cursors and selections into account):
http://jsfiddle.net/2Qqrp/
Thinking about it, it may be considered somewhat wasteful (or exceedingly
slow - if for example the embedded data is a video) to do it this way - but
it quickly gets complex and/or confusing if we have a some show this local
file until it's uploaded, then reference the online file instead magic..?
This generally makes sense. If sites prefer to use local dataURI or blob, they
can use the blob URL, and then upload the file later (like in an email
scenario). This means they don't have to wait for them to be on the server
before displaying them. If they want to upload them first and use the server's
new URL for them, they would need to do what you're saying.
-Ben
[Bug 24339] File API should specify Blob.close() with a state in the model and influence on read methods
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24339 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Arun a...@mozilla.com --- Done. http://dev.w3.org/2006/webapi/FileAPI/#close-method -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24469] Definition of valid blob is unclear and probably wrong
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24469 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Arun a...@mozilla.com --- Fixed; this concept doesn't exist anymore, but closed blobs have been defined more clearly. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23946] Lift the ban on query parts in “blob:” URIs
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23946 Arun a...@mozilla.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Arun a...@mozilla.com --- I think this is fixed. There isn't an active ban now. 1. The query isn't defined (http://dev.w3.org/2006/webapi/FileAPI/#DefinitionOfScheme) but isn't banned. 2. What is emitted by the methods URL.createFor and URL.createObjectURL (http://dev.w3.org/2006/webapi/FileAPI/#createRevokeMethodsParams) and what is consumed by parse and fetch (http://dev.w3.org/2006/webapi/FileAPI/#lifeTime and http://dev.w3.org/2006/webapi/FileAPI/#requestResponseModel) have been more tightly defined. See url.spec.whatwg.org and fetch.spec.whatwg.org for future updates on parsing and fetching blob URLs. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24102] Specify the targets for events
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24102 Arun a...@mozilla.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Arun a...@mozilla.com --- I think this is fixed. Relevant fixes include: 1. http://dev.w3.org/2006/webapi/FileAPI/#fire-a-progress-event 2. All the asynch read methods: http://dev.w3.org/2006/webapi/FileAPI/#readAsDataURL http://dev.w3.org/2006/webapi/FileAPI/#readAsDataText http://dev.w3.org/2006/webapi/FileAPI/#readAsArrayBuffer -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23853] Please clarify the interpretation of the WebIDL undefined Date in the File constructor
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23853 Arun a...@mozilla.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #35 from Arun a...@mozilla.com --- I think we can safely close this bug, having left it open for further info. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24470] Link to #networkError in fetching section is broken
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24470 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Arun a...@mozilla.com --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24072] Clarify handling of neutered objects
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24072 Bug 24072 depends on bug 24339, which changed state. Bug 24339 Summary: File API should specify Blob.close() with a state in the model and influence on read methods https://www.w3.org/Bugs/Public/show_bug.cgi?id=24339 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23147] Describe File API Model
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23147 Arun a...@mozilla.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Arun a...@mozilla.com --- I think this is fixed. Relevant changes are: 1. http://dev.w3.org/2006/webapi/FileAPI/#blob 2. http://dev.w3.org/2006/webapi/FileAPI/#reading-data-section If this doesn't sufficiently unblock dependency bugs, please reopen. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24453] Expose interfaces to workers
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24453 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Arun a...@mozilla.com --- Fixed. The only interface which isn't annotated is the partial URL interface, but I think appropriate annotations (and decisions on whether it should be exposed on Workers) should happen as part of the URL spec. Relevant changes are: 1. http://dev.w3.org/2006/webapi/FileAPI/#blob 2. http://dev.w3.org/2006/webapi/FileAPI/#file 3. http://dev.w3.org/2006/webapi/FileAPI/#filelist-section (which isn't long for this world, and is likely to get replaced by an Array soon). 4. http://dev.w3.org/2006/webapi/FileAPI/#APIASynch 5. http://dev.w3.org/2006/webapi/FileAPI/#readingOnThreads -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24338] Spec should have Fetch for Blob URLs
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338 Bug 24338 depends on bug 23147, which changed state. Bug 23147 Summary: Describe File API Model https://www.w3.org/Bugs/Public/show_bug.cgi?id=23147 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24848] New: [imports]: ES6 module loader should be aware modules in HTML Imports
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24848 Bug ID: 24848 Summary: [imports]: ES6 module loader should be aware modules in HTML Imports Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: morr...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 23278 As ES6 modules going to have a way to define a module using script or module tag, such JS modules in an import should be able to imported from another module in linking document. import_a.html module name=a/module import_b.html link rel=import href=import_a.html module import _ from a; // This should work. /module To make this possible, ES6 loader should aware of HTML Imports and HTML Imports should publish readiness to its possible clients somehow. One idea is to let these two standards share some commonplace where the dependency management coordination happens. Such a place could be HTML, fetch, or somewhere else. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24823] [ServiceWorker]: MAY NOT is not defined in RFC 2119
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24823 Jungkee Song jungk...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jungk...@gmail.com Resolution|--- |FIXED --- Comment #1 from Jungkee Song jungk...@gmail.com --- The entire section containing the part has been deleted. Note that the document is currently being drafted and there might be quite a lot of changes as such. As we decided to use Github issues instead of here, please file any further issues in https://github.com/slightlyoff/ServiceWorker/issues. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
Re: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
Of course it would be nice to support a script that wants to generate random
HTML with embedded files
X
use case for example with a CANVAS app where the script wants to copy the
state of the CANVAS
I was thinking about images that aren't available cross-domain
Indeed, that's another use case which is pretty important.
document.addEventListener('copy', function(e){
// So, you want to copy the current status of your game? No problem.
// Let's say this game generates a number of PNG graphics from CANVAS
tags
// and keeps them in memory in ArrayBuffers or something
var html = 'divbplayer/b\'s medals: img src=cid:1img
src=cid:2/div';
e.clipboardData.items.add(html, 'text/html');
e.clipboardData.items.add(new File(medals[0], 'medal.png',
{type:'image/png'}));
e.clipboardData.items.add(new File(medals[1], 'medal.png',
{type:'image/png'}));
e.preventDefault();
}, false);
This seems like we're depending on add() working in a precise order, which
seems vulnerable
to code changes or other issues. Maybe add() should return the location in
the list where
the item was added, and then it can be used with CID more safely?
That is a good observation and a very good suggestion! We should suggest a
change to the HTML spec.
Second, can you provide the javascript for how a site would put them into
the pasted markup during paste?
The way I thought this would work, would be that the site starts XHR uploads
from the paste processing,
and shows some intermediate 'loading' animation or something before it gets
the final URLs back from the server.
This generally makes sense. If sites prefer to use local dataURI or blob,
they can use the blob URL, and then
upload the file later (like in an email scenario). This means they don't have
to wait for them to be on the
server before displaying them. If they want to upload them first and use the
server's new URL for them,
they would need to do what you're saying.
Sounds good, but this requires standardising something similar to
msConvertURL(), right?
-Hallvord
Re: Indexed DB: Opening connections, versions, and priority
On Wed, Feb 26, 2014 at 10:35 AM, Joshua Bell jsb...@google.com wrote: While looking at a Chrome bug [1], I reviewed the Indexed DB draft, section 3.3.1 [2] Opening a database: These steps are not run for any other connections with the same origin and name but with a higher version And the note: This means that if two databases with the same name and origin, but with different versions, are being opened at the same time, the one with the highest version will attempt to be opened first. If it is able to successfully open, then the one with the lower version will receive an error. I interpret that as (and perhaps the spec should be updated to read): This means that if two open requests are made to the database with the same name and origin at the same time, the open request with the highest version will be processed first. If it is able to successfully open, then the request with the lower version will receive an error. So far as I can tell with a test [3], none of Chrome (33), Firefox (27), or IE (10) implement this per spec. Instead of processing the request with the highest version first, they process the first request that was received. Is my interpretation of the spec correct? Yes Is my test [3] correct? Well... If yes and yes, should we update the spec to match reality? Short answer: Yes, I think we can remove the current text from the spec Long answer: It depends on how one defines same time. Your testcase doesn't open make the open calls at the same time but rather one after another. Though it's a clever trick to stall them all using a delete operation. But ultimately I think the definition of same time is ambiguous enough that the current spec language doesn't add any value. So your proposed change seem like an improvement. / Jonas [1] https://code.google.com/p/chromium/issues/detail?id=225850 [2] https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#opening [3] http://jsfiddle.net/Nbg2K/2/
