gmane.org.w3c.appformats

Re: DOM3 Events - additional editing help to move the spec forward

Pablo Garaizar Sagarminaga — 2012-05-26T06:30:05

Hello,

on Fri, 25 May 2012 16:49:25 -0700 Jonas Sicking <jonas< at >sicking.cc>
wrote:


Disclaimer: I don't know how and where to do this proposal. I hope
you'll help me to find the proper place to send it.

  During High Resolution Time working draft final call for public
comments I wrote a suggestion about DOM events' timestamps and the use
of monotonically increasing values provided by High Resolution Time
API: 

  I would love to have the chance to get a DOMHighResTimeStamp as a
property of an DOM event, like event.timeStamp. Events'
timestamps are also subject to system clock skew and other problems
mentioned in High Resolution Time working draft, and providing access
to HRT when triggering events will be very helpful to program accurate
interactions.

  I'm not sure if this could be done adding a new property to the
event interface (e.g., HRTimeStamp) or modifying the typedef of the
current timeStamp property (i.e., DOMHighResTimeStamp).

  It would be great to discuss this feature in future versions of t

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

Adam Barth — 2012-05-26T06:11:07

I seem to have missed the context for this thread, but typically
origins are not parsed.  They're compared character-by-character to
see if they're identical.  If you have a URL, you can find its origin
and then serialize it to ASCII or Unicode if you want to compare it
with another origin.

Adam

RE: Push API draft uploaded

SULLIVAN, BRYAN L — 2012-05-26T03:06:52

Thanks for the comments. Some responses added as <bryan>

Thanks,
Bryan Sullivan

-----Original Message-----
From: Mounir Lamouri [mailto:mounir< at >lamouri.fr] 
Sent: Friday, May 25, 2012 3:17 PM
To: public-webapps< at >w3.org
Subject: Re: Push API draft uploaded

On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote:

Hi,

I have a few random comments:

* As far as I understand it, |requestRemotePermission| and
|checkRemotePermission| could be one single method which could be named
something like |getPushServiceUrl|. The only difference between those
two methods is the permission asking part but that should stay as a UA
decision. Given that the method is anyway asynchronous, the UA can do
whatever wanted before sending a result. Showing a permission prompt
could be one of those.

<bryan> I agree that these methods could collapse into one. But as this interface was based upon the Mozilla proposal (https://wiki.mozilla.org/Services/Notifications/Push/API) I would like to get the author's view on the potential to collapse t

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

SULLIVAN, BRYAN L — 2012-05-26T00:49:28

Perhaps this particular issue then (the need to convey information about intended usage of an app, or preferred device characteristics), especially designing for a diverse set of devices and screen characteristics (mobile phones up to building-side billboards), should be something that we encourage developer input on through the community group process. My sense is that it's a bigger problem than it seems, and that by just saying "apps should work on any device" or "apps should not be tailored to specific device characteristics" thus we don't need such metadata in manifests, we are doing developers a disservice. It's much more complicated than that, and I believe developers *do* commonly focus on particular device segments when designing Webapps.

Thanks,
Bryan Sullivan 

-----Original Message-----
From: Scott Wilson [mailto:scott.bradley.wilson< at >gmail.com] 
Sent: Friday, May 25, 2012 12:59 PM
To: Marcos Caceres
Cc: SULLIVAN, BRYAN L; Anant Narayanan; public-webapps WG; public-webappstore< at >w3.org
Subject: Re:

Re: DOM3 Events - additional editing help to move the spec forward

Jonas Sicking — 2012-05-25T23:49:25

On Fri, May 25, 2012 at 1:08 PM, Travis Leithead
<travis.leithead< at >microsoft.com> wrote:

Yay! Awesome! Thanks for slugging through this work. Looking forward to LC soon!

/ Jonas

[Bug 17198] New: Remove mention of IDBVersionChangeRequest

2012-05-25T23:09:09

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

           Summary: Remove mention of IDBVersionChangeRequest
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
        AssignedTo: dave.null< at >w3.org
        ReportedBy: jonas< at >sicking.cc
         QAContact: public-webapps-bugzilla< at >w3.org
                CC: mike< at >w3.org, public-webapps< at >w3.org


The interface no longer exists, and the place where it's mentioned already
talks about the correct interface as well.

Re: Push API draft uploaded

Mounir Lamouri — 2012-05-25T22:17:01

Hi,

I have a few random comments:

* As far as I understand it, |requestRemotePermission| and
|checkRemotePermission| could be one single method which could be named
something like |getPushServiceUrl|. The only difference between those
two methods is the permission asking part but that should stay as a UA
decision. Given that the method is anyway asynchronous, the UA can do
whatever wanted before sending a result. Showing a permission prompt
could be one of those.

* I wonder if it is really useful to have clients requesting a specific
Push service. I totally understand why a user would request to use his
preferred Push service but that is part of the UA. I would tend to think
we should not add that parameter until it's proven to be needed by some
consumer of the API. Adding it would be simple; removing it might not be
an option. Also, allowing a website to chose the Push service might
break the entire idea of decentralization here: you might end up with
most websites requesting to use "push.popularservice

[Bug 17196] (Note: Your IP address and user agent will be publicly recorded for spam prevention purposes.)

2012-05-25T21:55:06

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

Art Barstow <art.barstow< at >nokia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |art.barstow< at >nokia.com
         Resolution|                            |INVALID

[Bug 17196] New: (Note: Your IP address and user agent will be publicly recorded for spam prevention purposes.)

2012-05-25T21:09:25

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

           Summary: (Note: Your IP address and user agent will be publicly
                    recorded for spam prevention purposes.)
           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:
(Note: Your IP address and user agent will be publicly recorded for spam
prevention purposes.) 

Posted from: 46.254.209.162
User agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20100101

RE: DOM3 Events - additional editing help to move the spec forward

Travis Leithead — 2012-05-25T20:08:02

Quick follow-up:
To my knowledge all remaining Tracker issues and other feedback previously sent to Jacob have now been resolved in the Bugzilla component for DOM3 Events save one last issue. I'm currently working through the final issue (accessibility feedback) but didn't want to wait until that was resolved before sending this mail. The spec has been dramatically updated in the past 3 months, and should now be quite nicely aligned with DOM4's Events section.

My plan, as mentioned at the March F2F meeting, is to resolve the last issue, then ask the chairs to start the LC process for this spec, with advancement to CR hopefully following soon thereafter.

This is not yet an official last call, but if you'd like to re-read the spec and provide additional feedback--this is a good time to do it. Also, if for some reason I missed responding to your previously written feedback, please re-send it or file a bug directly.

DOM3 Events (Ed. Draft) http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.htm

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

Scott Wilson — 2012-05-25T19:58:38


I think there is a problem here that we can get very mobile and tablet focussed - some of our widgets are also designed with interactive whiteboards and TVs in mind which may throw off selections based on things like screen size and pixel density. 

I can see users ending up doing the whole "spoof the user-agent string" again here, as when sites started showing "your browser is not supported" when you viewed them with something the developer hadn't considered. 

Perhaps at the store level it would be nice to have some assertions of platforms tested by the developer, but that would be something different really (perhaps something for the web app stores CG to look at).

[Bug 17192] Trying to find the music i downloaded

2012-05-25T18:39:03

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

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

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

[Bug 17192] New: Trying to find the music i downloaded

2012-05-25T18:35:10

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

           Summary: Trying to find the music i downloaded
           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: Web Storage (editor: Ian Hickson)
        AssignedTo: ian< at >hixie.ch
        ReportedBy: contributor< at >whatwg.org
         QAContact: public-webapps-bugzilla< at >w3.org
                CC: ian< at >hixie.ch, mike< at >w3.org, public-webapps< at >w3.org


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

Comment:
Trying to find the music i downloaded

Posted from: 174.141.208.99
User agent: HUAWEI-M735/001.00 Opera/9.70

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 t

[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 Geoloca

[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)

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

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


typo: th