gmane.org.w3c.appformats

Re: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

Marcos Caceres — 2012-05-25T16:25:31


On Friday, May 25, 2012 at 4:34 PM, SULLIVAN, BRYAN L wrote:


Still sounds to me like "Made for <insert everyone's favorite 90's browser here>, and best viewed at 800x600" … and look how well that turned out. Even if we don't focus on mobile devices, it seems like a silly requirement as I can just adjust my browser window to whatever size I want (there is no reason to believe I won't be able to do that on future mobile devices). I.e., screen size and application display area are not the same thing and this metadata attribute seems to assume so.

RE: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

SULLIVAN, BRYAN L — 2012-05-25T15:34:09

Marcos, 

Re "I thought we had stopped the whole designing for particular screen sizes, etc. a long time ago.", that may be the still-closely-held goal, but the reality is that designing for multiple screen sizes (and pixel densities) is still far from simple. Even with all the tools that have been developed in CSS and Media Queries. 

So if developers want to claim that they have focused their design on specific form factors (and presumably tested it thoroughly on them), this seems like a good thing as it allows them to be more certain that their apps won't be distributed to users of devices on which they won't work well (which will negatively impact the developer's reputation, use of the app, appstore etc), or if distributed to such users, will be clearly identified as not being designed for those devices.

Like many of the things we wanted to do in widget manifest structures in BONDI and WAC, if these get pulled from the plan the only fallback is developer ecosystem-specific app metadata, which in the end evaporates with the developer ecosystems, or never achieves widespread use or interoperability. So the problem is not solved for developers by leaving these things out of standards, where there is a strong use case.

Thanks,
Bryan Sullivan 

-----Original Message-----
From: Marcos Caceres [mailto:w3c< at >marcosc.com] 
Sent: Friday, May 25, 2012 7:43 AM
To: Anant Narayanan
Cc: public-webapps< at >w3.org
Subject: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs




On Sunday, May 13, 2012 at 5:47 PM, Anant Narayanan wrote:


The above cases seems very "anti-web" IMHO. I thought we had stopped the whole designing for particular screen sizes, etc. a long time ago. I feel it would be a shame to codify this in a spec.

[manifest] asynchronous calls, Re: Review of Web Application Manifest Format and Management APIs

Marcos Caceres — 2012-05-25T15:04:28


On Sunday, May 13, 2012 at 5:47 PM, Anant Narayanan wrote:


Ok, this was not really clear in the spec.  


I'm still not sure why these are asynchronous? Is what apps are installed retrieved from a remote server or something? If you are just checking a small list of installed things on the user's device, then I don't see why you would not just have an "installed" attribute? 
Like: 

myApps =  navigator.apps.installed; 

Otherwise, it seems like a lot of work just to get a list of things that are already installed on my system?

[manifest] features Re: Review of Web Application Manifest Format and Management APIs

Marcos Caceres — 2012-05-25T14:54:48


On Sunday, May 13, 2012 at 5:47 PM, Anant Narayanan wrote:


I think this will quickly become unmanageable. It means you need to take the current web as it is today, freeze it, and then start hiding all future functionality that can only be enabled through this list (and the list of things you need to enable grows forever or you end up having to enable unexpected things, which then may cause security issues that the developer was not expecting). Hence, features like this should only be used for things that are sure not to be part of the Web Platform.  

This also goes against the trend of responsive design: it means that I can't make an app that both uses WebGL and falls back to legacy tech because the store will refuse to install it on my non-webGL-phone. So as a developer, I would need to release two versions of the same app.   

In Widgets, we overcame this issue by allowing features to be declared as optional. However, some did try to do what you are proposing (e.g., WAC): they tried to disable Geolocation and only enable it through a feature… this became a huge issue for implementers (you can't disable it in an Android Webview, hence you can't implement these requirements using a Webview on Android or possibly on iOS).   

I would say this only be used for proprietary hooks, as is currently done with Chrome extensions (or with opera extension in the XML equivalent). Features have a role, but not for enabling/disabling bit of the Web Platform.

[manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

Marcos Caceres — 2012-05-25T14:42:55



On Sunday, May 13, 2012 at 5:47 PM, Anant Narayanan wrote:


The above cases seems very "anti-web" IMHO. I thought we had stopped the whole designing for particular screen sizes, etc. a long time ago. I feel it would be a shame to codify this in a spec.

[manifest] Parsing origins, was Re: Review of Web Application Manifest Format and Management APIs

Marcos Caceres — 2012-05-25T14:39:54

Hi Anant,  

On Sunday, May 13, 2012 at 5:47 PM, Anant Narayanan wrote:


By parsing I mean which ones win, which ones get discarded, what happens to invalid ones, are they resolved already, etc. in the following:

installs_allowed_from: [ "   http://foo/ ", "bar://", 22, "https://foo/bar/#*", "http://foo:80/", "wee!!!", "http://baz/hello there!", "http://baz/hello%20there!"]

And so on. So, all the error handling stuff. Or is a single error fatal?

RE: Push API draft uploaded

SULLIVAN, BRYAN L — 2012-05-25T14:00:01

Hi Jose,

Thanks for the comments.

Re "the idea is to decouple permissions from APIs": potentially for the Sysapps WG this will be possible, but currently in DAP and in Webapps if the Web security model isn't enough (e.g. same-origin and CORS), then any special considerations are addressed in the API specs themselves. In this case the ability to invoke the app (wakeup) and receive Push messages when the app is offline in general (as in the Mozilla proposal) goes beyond the ability of same-origin and CORS to ensure user protection. Thus the user is prompted at least once. It's not a perfect solution but at least consistent with what has been the approach, and usable until we get to a more robust permissions framework.

Re wakeup as part of an App Manifest: this does not yet apply to Web apps in general. It does seem useful to consider in the "Web app manifest" (https://people.mozilla.com/~anarayanan/webapps.html) as proposed to be worked in Webapps, but again that does not apply (or does not have to be used) for all Web apps. I suppose one could make the argument that if you expect to be woken up, the app should be installed, but I think caching also works for that (as described in the spec as "Examples of cases in which webapps should be invokable").

Re "distinguish between registering the interest on receiving push messages and receiving push messages themselves": I am following the Mozilla lead on registering the intent to receive messages, and also going beyond it with the actual reception capability, and there are separate interfaces for the two functions. We don't yet have a generic "intent registration" mechanism for use here (e.g. based upon the API feature URL concept previously proposed for Widgets and leveraged in WAC), and we may approach that again in Sysapps (TBD), but for now I think the APIs need to address both functions.

Re "the possibility of having a queue of pending messages": the spec leaves this as a MAY for now: "When a Push message is received, the user agent must deliver the message data via the onmessage handler, if possible. If delivery is not possible, the user agent may discard the message, or may queue it for later delivery."

Thanks,
Bryan Sullivan 

-----Original Message-----
From: JOSE MANUEL CANTERA FONSECA [mailto:jmcf< at >tid.es] 
Sent: Friday, May 25, 2012 4:36 AM
To: SULLIVAN, BRYAN L; public-webapps
Subject: Re: Push API draft uploaded

I have some comments:

I think the idea is to decouple permissions from APIs, making that part of
a Security Model, so I don't understand why we are putting here that
functionality.

Concerning wakeup, etc. I think that should not be part of the API itself
but of the App Manifest

I think we need to distinguish between registering the interest on
receiving push messages and receiving push messages themselves.

The current API does not address the possibility of having a queue of
pending messages.

best

El 24/05/12 09:14, "SULLIVAN, BRYAN L" <bs3131< at >att.com> escribió:




Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Re: Proposal: Document.parse() [AKA: Implied Context Parsing]

Scott González — 2012-05-25T12:40:47


typo: th

Re: Proposal: Document.parse() [AKA: Implied Context Parsing]

Rafael Weinstein — 2012-05-25T12:34:37

Yes. Thank you. Item 5 should be:

5) A new "selecting a context element" algorithm is defined which
takes a start tag as input and outputs an element. The element's
identity is as follows:

-If start tag is tbody, thead, tfoot, caption or colgroup
 return <table>
-if start tag is tr,
 return <tbody>
-if start tag is col
 return <colgroup>
-if start tag is td or td
 return <tr>
-if start tag is head or body
 return <html>
-if start tag is rp or rt
 return <ruby>

-if start tag is a defined HTML localName (case insensitive)
 return <body>

-if start tag is a defined SVG localName (case insensitive)
 return <svg>

-if start tag is a defined MathML localName (case insensitive)
 return <math>

-otherwise, return <body>

Re: Push API draft uploaded

JOSE MANUEL CANTERA FONSECA — 2012-05-25T11:36:26

I have some comments:

I think the idea is to decouple permissions from APIs, making that part of
a Security Model, so I don't understand why we are putting here that
functionality.

Concerning wakeup, etc. I think that should not be part of the API itself
but of the App Manifest

I think we need to distinguish between registering the interest on
receiving push messages and receiving push messages themselves.

The current API does not address the possibility of having a queue of
pending messages.

best

El 24/05/12 09:14, "SULLIVAN, BRYAN L" <bs3131< at >att.com> escribió:




Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Bug 17184] Please don't use section numbers as these tend to change rapidly and make your feedback harder to understand.

2012-05-25T10:32:17

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17184

Ms2ger <Ms2ger< at >gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |Ms2ger< at >gmail.com
         Resolution|                            |INVALID

--- Comment #2 from Ms2ger <Ms2ger< at >gmail.com> 2012-05-25 10:32:16 UTC ---
This is just a copy of the note below the feedback form.

[Bug 17184] New: Please don't use section numbers as these tend to change rapidly and make your feedback harder to understand.

2012-05-25T10:21:02

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17184

           Summary: Please don't use section numbers as these tend to
                    change rapidly and make your feedback harder to
                    understand.
           Product: WebAppsWG
           Version: unspecified
          Platform: Other
               URL: http://www.whatwg.org/specs/web-apps/current-work/#top
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P3
         Component: WebSocket API (editor: Ian Hickson)
        AssignedTo: ian< at >hixie.ch
        ReportedBy: contributor< at >whatwg.org
         QAContact: public-webapps-bugzilla< at >w3.org
                CC: mike< at >w3.org, public-webapps< at >w3.org


Specification: http://dev.w3.org/html5/websockets/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
Please don't use section numbers as these tend to change rapidly and make your
feedback harder to understand.

Posted from: 120.72.91.20
User agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.5 (KHTML, like Gecko)
Chrome/19.0.1084.46 Safari/536.5

Re: Proposal: Document.parse() [AKA: Implied Context Parsing]

Simon Pieters — 2012-05-25T07:32:28

On Fri, 25 May 2012 09:01:43 +0200, Rafael Weinstein <rafaelw< at >google.com>  
wrote:


I think <ruby> is better handled by always making <rp> and <rt> generate  
implied end tags in the fragment case (maybe even when parsing normally,  
too). Making the context element <ruby> still doesn't make <rt> parse  
right, because the spec currently looks for ruby on the *stack* (and the  
context element isn't on the stack).

Also, the ruby base is allowed to include markup, so this would fail:

ruby.appendChild(document.parse('<span>foo</span><rt>bar<rt>baz'));



Except those that conflict with HTML?


(Making the context element svg or math doesn't do anything currently:  
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 )

Proposal: Document.parse() [AKA: Implied Context Parsing]

Rafael Weinstein — 2012-05-25T07:01:43

Ok, so from consensus on earlier threads, here's the full API & semantics.

Now's the time to raise objections to UA's adding support for this feature.

-----

1) The Document interface is extended to include a new method:

DocumentFragment parse (DOMString markup);

which:
-Invokes the fragment parsing algorithm with markup and an empty
context element,
-Unmarks all scripts in the returned fragment node as "already started"
-Returns the fragment node

2) The fragment parsing algorithm's context element is now optional.

It's behavior is similar to the case of a known context element, but
the tokenizer is simply set to the data state

3) Resetting the insertion appropriately now sets the mode to "Implied
Context" if parsing a fragment and no context element is set, and
aborts.

4) A new "Implied Context" insertion mode is defined which

-Ignores doctype, end tag tokens
-Handles comment & character tokens as if "in body"
-Handles the following start tags as if "in body" (which is as if "in
head"): <style>, <script>, <link>, <meta>
-Handles any other start tag by selecting a context element, resetting
the insertion mode appropriately and reprocessing the token.

5) A new "selecting a context element" algorithm is defined which
takes a start tag as input and outputs an element. The element's
identity is as follows:

-If start tag is tbody, thead, tfoot, caption or colgroup
  return <table>
-if start tag is tr,
  return <tbody>
-if start tag is col
  return <colgroup>
-if start tag is td or td
  return <tr>
-if start tag is head or body
  return <html>
-if start tag is rp or rt
  return <ruby>

-if start tag is a defined SVG localName (case insensitive)
  return <svg>

-if start tag is a defined MathML localName (case insensitive)
  return <math>

-otherwise, return <body>

Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out

Rafael Weinstein — 2012-05-25T05:51:16

This seems sensible. I've updated the WebKit patch to do exactly this:

https://bugs.webkit.org/show_bug.cgi?id=84646

It appears that the details of the proposal are now sorted out. I'll
start a new thread describing the full API & semantics.

On Fri, May 18, 2012 at 8:29 PM, Ryosuke Niwa <rniwa< at >webkit.org> wrote:

Re: [File API] File behavior under modification

Kinuko Yasuda — 2012-05-25T03:49:11


Changing the behavior of .lastModificationDate and .size might affect
existing Web applications, but I like this approach.
It makes things clearer, UAs can avoid synchronous IO (yes, we want to
avoid it) and File becomes a purely constant snapshot. It sounds saner to
me (especially now that we have an alternative live file interface, i.e.
FileEntry).

We absolutely should not have an API which forces implementations to do

The wording in the spec is unfortunate since it says that reading should

Re: RfC: LCWD of WebSocket API; deadline June 14

Julian Reschke — 2012-05-24T19:13:51

I note that many keywords that reference parts of other specs are not 
hyperlinked, so it's extremely hard for a reader to understand what they 
are supposed to mean (phrasing it politely).

For instance, in Section 7:

"If the url string is not an absolute URL, then fail this algorithm."

"absolute URL" is not defined anywhere in this document.

"Resolve the url string, with the URL character encoding set to UTF-8. 
[RFC3629]"

"Resolve" is not defined anywhere in this document.

etc.

Best regards, Julian

http://www.w3.org/TR/2012/WD-url-20120524

Julian Reschke — 2012-05-24T18:06:03

Hi there,

here's some early feedback.

"A control character is a character whose value is less than or equal to 
U+0020 (" ")."

This is really surprising; it doesn't match Unicode 
(<http://www.unicode.org/charts/PDF/U0000.pdf>) nor IETF ABNF (RFC 5234).

I think it would be better to exclude U+0020, in particular as the term 
is just only once.

A more general concern is that the spec defines various URI-related 
operations in terms of algorithms, and doesn't mention whether those 
algorithms are supposed to return the same results as those defined in 
RFC 3986 or not.

If they are not, it would be totally awesome if there was an explanation 
about what these difference are. Lacking that, this is really hard to 
review.

Best regards, Julian

RfC: LCWD of WebSocket API; deadline June 14

Arthur Barstow — 2012-05-24T17:20:50

This is a Request for Comments re the 24-May-2012 LCWD version of the 
WebSocket API:

http://www.w3.org/TR/2012/WD-websockets-20120524/

The comment deadline is June 14 and all comments should be sent to the 
public-webapps< at >w3.org list. The Bugzilla component for the API is [Bugz].

I Cc'ed the hybi list as an FYI and comments from that list's 
subscribers are of course welcome. The Bugzilla component for the API is 
[Bugz].

-Thanks, AB

[Bugz] 
https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=WebSocket%20API%20%28editor%3A%20Ian%20Hickson%29&resolution=---

RfC: LCWD of Indexed Database; deadline June 21

Arthur Barstow — 2012-05-24T17:20:20

This is a Request for Comments re the 24-May-2012 LCWD version of 
Indexed Database:

http://www.w3.org/TR/2012/WD-IndexedDB-20120524/

The comment deadline is June 21 and all comments should be sent to the 
public-webapps< at >w3.org list.

-Thanks, AB

Re: Push API draft uploaded

SULLIVAN, BRYAN L — 2012-05-24T15:23:42

Re "a particular type of Push service that it supports" this is intended to be generic so that new services (perhaps identified by unique URI schemes) can be covered under this.

That being said, WebSockets schemes clearly would imply that protocol, but http schemes could be more flexible. One of the goals is to define how the "serviceUrl" is conveyed to the user agent and Webapp. In the process of determining that URL, there could be other useful info that the server returns, eg the applicable bearer bindings or info that will help ensure events can be delivered to the correct Webapp (e.g. SMS source address, message fields/headers). If its possible to define a lightweight and generic/extensible Push service registration protocol, this would be a good place to invoke it. We defined such a protocol for OMA Push, and some of those ideas might be useful here. This is an area for further study.

If the Push server connection is setup to another domain then CORS would apply. But the checkRemotePermission method (at least as I understood it from the Mozilla proposal) would only test if there was a prior permission by the user, and would not need to invoke any network transactions to do so (though for some implementations this might be a feature).

I will try to develop these ideas in the draft (or at least outline the intent to), but I did not want to put too much into it at this time... As far as possible I am leaning to the simple (but clearly not as simple as the Mozilla proposal). Service lifecycle management, of which registration is a facet, can hopefully be layered above the API for the most part.

Thanks,
Bryan Sullivan

On May 24, 2012, at 9:33 AM, "Charles Pritchard" <chuck< at >jumis.com> wrote: