Re: WebApp installation via the browser
Another question about the subject https://developers.google.com/chrome/apps/docs/developers_guide This says that they can also run in the background, which is huge. I'm not sure if they support content scripts like extensions and packaged apps do. I would love to find out if the spec says anything about that. Thanks in advance, Marc On Fri, May 30, 2014 at 7:42 PM, Jeffrey Walton wrote: > On Fri, May 30, 2014 at 9:04 PM, Brendan Eich wrote: > > Jeffrey Walton wrote: > >> > >> Are there any platforms providing the feature? Has the feature gained > >> any traction among the platform vendors? > > > > Firefox OS wants this. > Thanks Brendan. > > As a second related question, is an Installable WebApp considered a > side-loaded app? > >
Re: WebApp installation via the browser
Jeffrey Walton wrote: On Fri, May 30, 2014 at 9:04 PM, Brendan Eich wrote: Jeffrey Walton wrote: Are there any platforms providing the feature? Has the feature gained any traction among the platform vendors? Firefox OS wants this. Thanks Brendan. As a second related question, is an Installable WebApp considered a side-loaded app? Sicking can answer with more authority, but side-loaded or downloaded, so long as the user installs it, no difference. /be
Re: WebApp installation via the browser
On Fri, May 30, 2014 at 9:04 PM, Brendan Eich wrote: > Jeffrey Walton wrote: >> >> Are there any platforms providing the feature? Has the feature gained >> any traction among the platform vendors? > > Firefox OS wants this. Thanks Brendan. As a second related question, is an Installable WebApp considered a side-loaded app?
Re: WebApp installation via the browser
Jeffrey Walton wrote: Are there any platforms providing the feature? Has the feature gained any traction among the platform vendors? Firefox OS wants this. /be
WebApp installation via the browser
I have a question about Use Cases for Installable WebApps located at https://w3c-webmob.github.io/installable-webapps/. Under section "Add to Homescreen", the document states: ... giving developers the choice to tightly integrate their web applications into the OS directly from the Web browser is still somewhat new... ... [Installable WebApps] are different in that the applications are "installed" directly from the browser itself rather than from an app store... It sounds like to me the idea is to allow any site on the internet to become a app store. My observations are the various app stores provide vendor lock-in and ensure a revenue stream. Its architected into the platform. Companies like Apple, Microsoft and RIM likely *won't* give up lock-in or the revenue stream (at least not without a fight). Are there any platforms providing the feature? Has the feature gained any traction among the platform vendors? Thanks in advance.
[Bug 25914] No definition of parsing blob's scheme data
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914 Arun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Arun --- (In reply to Anne from comment #3) > If we use scheme data as identifier, fine. > > Yes, I'd like a way to extract an origin out of the scheme data. OK, I think http://dev.w3.org/2006/webapi/FileAPI/#extractionOfOriginFromBlobURL will work. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25915] Cross-origin requests
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25915 Arun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Arun --- (In reply to Anne from comment #0) > I'm not sure why > http://dev.w3.org/2006/webapi/FileAPI/#cross-origin-requests-on-blobs is > included in this specification. That should follow from URL / Fetch, no? > > Duplicate requirements are bad. You're right. I've fixed this now so that Fetch is normative. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25924] [Imports]: The spec. is not very specific about the edge cases of the load
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25924 Gabor Krizsanits changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Gabor Krizsanits --- After talking to Anne, I think I got all my questions answered... so I'm closing this for now. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [Bug 25376] - Web Components won't integrate without much testing
On Fri, May 23, 2014 at 8:10 AM, Brian Kardell wrote: > > > > Web Components install complex concepts (e.g. ) by > introducing unique, complex, opaque behaviours, abandoning the pure nature > of presentation. > > Decorators were dropped last i checked, but many of the new features > create a lightweight alternative to iframes and, again, give us, new powers > to create. > Does anyone have a reference for this?
[Bug 25924] New: [Imports]: The spec. is not very specific about the edge cases of the load
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25924 Bug ID: 25924 Summary: [Imports]: The spec. is not very specific about the edge cases of the load Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: gkrizsan...@mozilla.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org It can be that I'm overlooking something, but I don't see answers for these questions in the spec: - what about data urls? are they allowed? and blobs? - what about HTTP error pages? (is redirection allowed?) - what about response other than text/html? - should we be able to stop external resource loading for only one import (and it's subtree) or only for the whole master document? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25908] Is element editable if it's hidden
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25908 Aryeh Gregor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Aryeh Gregor --- (In reply to Anne from comment #4) > Yes, HTML defers to HTML editing APIs for the definition of > isContentEditable and there it is quite clear: > https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#editable Don't put much stock in this definition, I made it up on a whim and didn't consider this issue. That said, making it depend on CSS properties doesn't seem desirable to me offhand. The reason given on the Chromium bug is > Since users can't edit elements not rendered, Blink considers > such elements aren't editable. This is reason why > isContentEditable returns false for elements which have > contenteditable="true" attribute but hidden. I don't find this convincing. You can't access the inside of the element because you can't put the cursor there, but I wouldn't say that means it's not editable, just that you don't have any way to tell the UA to do anything to it. It's perfectly editable if, say, script places the cursor there -- which is very relevant, since we're talking about a script-accessible property here. Per spec, the editor doesn't treat hidden elements the same as non-editable elements at all. (In reply to Anne from comment #1) > This should be true. We don't want isContentEditable to have to do > synchronous style resolution. Ryosuke once told me that contenteditability is implemented by a CSS property in WebKit anyway, so they have to. (In Gecko, it's implemented by a flag bit that's set and unset recursively as needed with special code. This has caused bugs that the WebKit approach would probably have avoided.) But I agree that this is another reason not to have it this way in the spec. So in the absence of anyone actively editing the editing spec, I'll call this RESOLVED. -- You are receiving this mail because: You are on the CC list for the bug.