[Bug 25924] [Imports]: The spec. is not very specific about the edge cases of the load

2014-05-31 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25924

Anne ann...@annevk.nl changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #4 from Anne ann...@annevk.nl ---
We should probably actually clarify data URLs. I suspect they should not be
allowed here as they would be able to execute scripts. I need to add the flag
proposed by Jonas in
http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0696.html and
HTML imports should probably not set it.

Is the text/html requirement stated?


Brendan, as for the rest:

* blob URLs can work if they're same-origin
* redirect should be followed
http://fetch.spec.whatwg.org/#atomic-http-redirect-handling
* HTTP response status should probably be ignored (we never pay attention to
it)
* only text/html should be allowed (is that stated in the specification now?)
* stopping of external resource loading is up to the UA mostly (unless there's
explicit API which there's not)

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



[Bug 25915] Cross-origin requests

2014-05-31 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25915

Anne ann...@annevk.nl changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #2 from Anne ann...@annevk.nl ---
Now you use must in a non-normative section.

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



[Bug 25914] No definition of parsing blob's scheme data

2014-05-31 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914

Anne ann...@annevk.nl changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from Anne ann...@annevk.nl ---
This algorithm should operate on a parsed URL, not a fresh URL. You want to
hand this algorithm a scheme data component.

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



Re: WebApps and permission list?

2014-05-31 Thread Dave Raggett


On 31/05/14 08:12, Jeffrey Walton wrote:

I have a question about WebApps manifests and permissions. The page is
part of Manifest for Web Applications located at
http://www.w3.org/2012/sysapps/manifest/.


The editor's draft for Manifest  is at: http://w3c.github.io/manifest/

The work item started in SysApps but was transferred to WebApps.

--
  Dave Raggett d...@w3.org http://www.w3.org/People/Raggett




Re: WebApp installation via the browser

2014-05-31 Thread Mounir Lamouri
On Sat, 31 May 2014, at 10:40, Jeffrey Walton wrote:
 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?

Isn't Add to homescreen feature something you can find in a more or
less advanced fashion on Safari iOS, Firefox Android, Firefox OS and
Chrome Android? I believe IE had something similar some time ago on
desktop but I don't know what's the current status of that. Chrome Apps
is also doing some experiments on desktop [1].

[1] https://plus.google.com/+FrancoisBeaufort/posts/74WCmneFJ8j

-- Mounir



Re: WebApp installation via the browser

2014-05-31 Thread James Greene
You're probably think of IE's Pinned Sites concept on Windows 8:

http://msdn.microsoft.com/en-us/library/gg491731.aspx

Sincerely,
James Greene
Sent from my [smart?]phone
On May 31, 2014 10:35 AM, Mounir Lamouri mou...@lamouri.fr wrote:

 On Sat, 31 May 2014, at 10:40, Jeffrey Walton wrote:
  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?

 Isn't Add to homescreen feature something you can find in a more or
 less advanced fashion on Safari iOS, Firefox Android, Firefox OS and
 Chrome Android? I believe IE had something similar some time ago on
 desktop but I don't know what's the current status of that. Chrome Apps
 is also doing some experiments on desktop [1].

 [1] https://plus.google.com/+FrancoisBeaufort/posts/74WCmneFJ8j

 -- Mounir




Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-31 Thread Ryosuke Niwa
I agree it's better to let authors define what behavior they want from UA 
instead of defining the set of behaviors ourselves.

Furthermore, I'd argue that we should separately have a mode where scripts 
would get intention events but UA wouldn't enact any builtin editing commands 
as default actions.  This is  useful for non-text editing applications such as 
drawing and presentation apps.

- R. Niwa

 On May 28, 2014, at 1:39 PM, Ben Peters ben.pet...@microsoft.com wrote:
 
 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, May 27, 2014 4:40 PM
 To: Ben Peters
 Cc: public-webapps@w3.org
 Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer
  
 The discussion of which minimal default handling to include with 
 contenteditable=minimal makes me wonder if contentEditable=minimal is 
 necessary at all.  It quickly becomes a can of worms of *which* default 
 handling should be included, and it seems likely to not satisfy every use 
 case no matter which decisions are made.  However, minimal is proposed as a 
 building block because currently, disabling all default functionality of 
 contentEditable=true is difficult/impossible.  But with CommandEvents, 
 shouldn't contentEditable=minimal be equivalent to:
  
 // Let editRegion be div contentEditable id='editRegion'
  
 var editRegion = document.getElementById(editRegion);
 editRegion.addEventListener(command, handleCommand);
 function handleCommand(evt){
   evt.preventDefault();
 }
  
 No default actions would be taken, but selection events would still fire and 
 be handled.  There would be no ambiguity.  If implementing 
 contentEditable=minimal on top of CommandEvents could just be a few lines 
 of code, why complicate things by spec'ing another property?
  
 Then, if someone wants a region that just does basic text input, then they 
 simply allow it:
 function handleCommand(evt){
  switch (evt.commandType){
case 'insertText':
  // Let the browser do text insertion
  break;
default:
  // Prevent all other magic
  evt.preventDefault();
 }
  
 This hedges on the fact that CommandEvents would capture ALL the cases that 
 contentEditable currently handles, and that the event would fire BEFORE the 
 dom is modified, and that calling preventDefault would cancel the event, but 
 isn't that a goal of this design anyway?
  
 Julie
  
 -- Forwarded message --
 From: Ben Peters ben.pet...@microsoft.com
 Date: Thu, May 22, 2014 at 4:56 PM
 Subject: [editing] CommandEvent and contentEditable=minimal Explainer
 To: public-webapps@w3.org public-webapps@w3.org
 
 
 I have completed a first-draft explainer document [1], taking the generous 
 feedback of many of you into account. There are 6 open issues on the document 
 currently, and I'm sure there are others that I have missed. It would be 
 great to know if this is heading in in the right direction.
 
 My vision is to use this a non-normative Explainer, and create 2 normative 
 specs to go with it. The specs for contentEditable=minimal and CommandEvent 
 should have first-drafts next week.
 
 Thanks!
 Ben
 
 [1] http://benjamp.github.io/commands-explainer.htm
 
  


Re: [selection] Selection.setBaseAndExtent

2014-05-31 Thread Ryosuke Niwa
Thanks!

- R. Niwa

 On May 20, 2014, at 11:36 AM, Ben Peters ben.pet...@microsoft.com wrote:
 
 I have filed a bug to track this issue [1].
  
 Ben
  
 [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25831
  
  
 From: Ben Peters [mailto:ben.pet...@microsoft.com] 
 Sent: Monday, May 5, 2014 11:28 PM
 To: Ryosuke Niwa; public-webapps@w3.org
 Subject: [selection] Selection.setBaseAndExtent
  
 I noticed that some websites use selection.setBaseAndExtent [1]. According to 
 what limited documentation I could find, it works similar to 
 selection.extend. Is there any intention to standardize this, or is it made 
 obsolete by selection.extend?
  
 Ben
  
 [1] 
 http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse