Re: Blob URL Origin

On Thu, May 22, 2014 at 1:29 AM, Anne van Kesteren wrote: > For blob URLs (and prolly filesystem and indexeddb) we put the origin > in the URL and define a way to extract it again so new > URL(blob).origin does the right thing. Yup. > For fetching blob URLs (and prolly filesystem and indexeddb)

RE: [editing] CommandEvent and contentEditable=minimal Explainer

I don’t think we need to specify the default behavior. We can instead just say that all editing behaviors must fire Intention events that are cancellable. Any events that are already defined (like Clipboard) will continue to work, and others should fire CommandEvents as necessary. We will likel

CfC: publish Candidate Recommendation of DOM Parsing and Serialization; deadline June 4

[ Bcc public-webapps; please Reply-to: www-dom] Two bugs were raised against the May 1 LCWD of DOM Parsing and Serialization [LC]. Travis created a tracking document for these Bugs [Track] and considers the two patches ([P1] and [P2]) that address the comments as non-substantive. As such, he p

Re: Blob URL Origin

On May 22, 2014, at 4:29 AM, Anne van Kesteren wrote: > Thanks, I'm convinced. > > So now I'd like to know what policy we want so we can carefully define it. The lastest editor’s draft of the File API specifies what we discussed in this email thread as syntax for Blob URLs: http://dev.w3.org

Re: [editing] CommandEvent and contentEditable=minimal Explainer

But what is the "default" behaviour then? What will we be preventing? There's no accepted specification for current contentEditable=true AFAIK, so I thought that the goal of contentEditable=minimal is to avoid the need to write a specification for contentEditable=true. Otherwise, developers may dem

RE: [editing] CommandEvent and contentEditable=minimal Explainer

Be careful with having events fire before the DOM is updated—at a minimum you’ll want to consider whether you will allow dangerous situations like the legacy MutationEvents could cause (start a change -> pre-change notification -> make another change -> pre-change notification … unexpected thing

RE: [editing] CommandEvent and contentEditable=minimal Explainer

Great idea! If Intention Events (Clipboard, Selection, Command) cover all of the editing operations that a site would want to handle themselves, we don’t need CE Min as a feature, only a concept that can achieved with preventDefault(). From: Julie Parent [mailto:jpar...@gmail.com] Sent: Tuesday

[Bug 24998] What is the origin of a blob: URL?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24998 Arun changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|---

[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 24998, which changed state. Bug 24998 Summary: What is the origin of a blob: URL? https://www.w3.org/Bugs/Public/show_bug.cgi?id=24998 What|Removed |Added -

[Bug 25713] Formalize the Blob URL Syntax

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25713 Arun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[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 25081, which changed state. Bug 25081 Summary: Make read operation really async https://www.w3.org/Bugs/Public/show_bug.cgi?id=25081 What|Removed |Added ---

[Bug 25081] Make read operation really async

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25081 Arun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

PSA: publishing FPWD of D3E Keyboard {key,code} Values specs and WD of UI Events

[ Bcc: public-webapps; please Reply-to: www-dom ] As previously discussed, Gary and Travis have moved the D3E event key and codes from the D3E and UI Events specs to the following new specs: * DOM Level 3 KeyboardEvent key Values

Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

On Wednesday, May 28, 2014, Anne van Kesteren wrote: > On Wed, May 28, 2014 at 12:20 PM, Mounir Lamouri > > > wrote: > > Then, it might make sense to have the manifest same origin as the web > > page because obviously making start_url same origin as the manifest > > would be moot if the manifest

Re: [manifest] Update and call for review

On Wed, May 28, 2014 at 12:43 PM, Ben Francis wrote: > This is the scenario I was describing. Allowing this to happen has both > benefits (easy to build huge app stores!) and risks (easy to build "fake > apps"). That seems very confusing UI-wise. Also, this is the web, we don't need app stores.

Re: [manifest] Update and call for review

On Wed, May 28, 2014 at 9:39 AM, Anne van Kesteren wrote: > I don't understand this. That would you mean you'd have to modify the > content of Gmail to point to this manifest. That sounds bad. > To quote Marcos: The only way one could do what you describe would be for "my own app store" > to ho

Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

On Wed, May 28, 2014 at 12:20 PM, Mounir Lamouri wrote: > Then, it might make sense to have the manifest same origin as the web > page because obviously making start_url same origin as the manifest > would be moot if the manifest doesn't have to be same origin with the > web page ;) I think we ha

Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

On Wed, 28 May 2014, at 8:59, Jonas Sicking wrote: > On Tue, May 27, 2014 at 12:39 PM, Marcos Caceres wrote: > > > > > > On May 27, 2014 at 2:30:32 PM, Jonas Sicking (jo...@sicking.cc) wrote: > >> On Tue, May 27, 2014 at 9:11 AM, Marcos Caceres wrote: > >> > The only way that gmail would allow "my

Re: [manifest] Update and call for review

On Tue, May 27, 2014 at 3:25 PM, Ben Francis wrote: > As per our conversation in IRC, something else I'd like to highlight is the > fact that in the current version of the spec any web site can host an app > manifest for any web app. That means for example that I could create my own > app store fo

Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

On Tue, May 27, 2014 at 9:53 PM, Marcos Caceres wrote: > On May 27, 2014 at 3:31:15 PM, Ben Francis (bfran...@mozilla.com) wrote: >> One risk of allowing cross-origin manifests might be that these >> "tailored app experiences" are perceived by the actual app author >> and/or end users as a "fake a

[Bug 25908] New: Is element editable if it's hidden

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25908 Bug ID: 25908 Summary: Is element editable if it's hidden Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal

Re: [manifest] Update and call for review

On Mon, May 26, 2014 at 8:18 PM, Marcos Caceres wrote: > Quick update: the Editors have closed off all "V1" bugs for [manifest] and > implementations in Blink and Gecko are underway. A thorough review of > [manifest] by interested parties would be greatly appreciated! You can file > bugs in our G

Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

On Tue, May 27, 2014 at 5:11 PM, Marcos Caceres wrote: > > The only way one could do what you describe would be for "my own app > store" to host its own manifests. So: > http://myownappstore.com/gmail/index.html > > Would contain: > href="http://myownappstore.com/gmail/manifest.json";> > > Which

Re: [manifest] Update and call for review

As per our conversation in IRC, something else I'd like to highlight is the fact that in the current version of the spec any web site can host an app manifest for any web app. That means for example that I could create my own app store for web apps and provide a listing for a GMail app which users

Re: contentEditable=minimal

On Tue, May 27, 2014 at 11:01 AM, Robin Berjon wrote: > On 25/05/2014 20:40 , Piotr Koszuliński wrote: > >> Making some things unselectable might also be useful. IE has >> unselectable, there's also -moz-user-select and friends. But this is >> small fries for later I'd reckon. >> >> T