from:"marcos"


On May 27, 2014 at 9:25:26 AM, Ben Francis (bfran...@mozilla.com) 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.

I'm really sorry, seems I wasn't very coherent on IRC - it's not possible for 
site A to use site B's manifest unless site B explicitly shares it (using 
CORS). 

Unlike with stylesheets or other link'ed resources, the fetch mode for 
manifests is always CORS - meaning that the following would not work:

titlefakegmail.com/title
link rel=manifest href=http://mail.google.com/manifest.json;

Even if the above manifest.json existed, the above would result in a network 
error when the user agent tries to fetch manifest.json from google.com. The 
error is because the request is not same origin, and because google doesn't 
include the CORS header allowing the cross-origin request. 

The only way that gmail would allow my own app store to use its manifest 
would be for Google to include the HTTP header:

Access-Control-Allow-Origin: http://myownappstore.com;

Or from *. 

You can see this in the spec in the obtaining a manifest algorithm [1].

Sorry again about the confusion. Hope that is more clear now!

 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 can add to their homescreen, without  
 any involvement from Google.

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: 
link rel=manifest
href=http://myownappstore.com/gmail/manifest.json;

Which would have:

{
   name: Gmail
   start_url: http://gmail.com;
}

This would allow custom stores that provide tailored app experiences for 
sites that lack manifests. 

Where this could become a problem in the future is if manifests start granting 
elevated privileges (e.g., access to specific APIs or unlimited storage). 
However, the security model could then be refined so that, for instance, only 
same origin manifests that are served over HTTPS get special powers. In such a 
case, non-same-origin manifests could be tainted and only the basic metadata 
from the manifest would be used by the user agent.  

 It would be good to hear some opinions on whether it is a good thing  
 or a bad thing that manifests don't have to be served from the same  
 origin as the web app itself.

It would indeed be great to get some more opinions about this. 

[1] http://w3c.github.io/manifest/#obtaining-a-manifest

-- 
Marcos Caceres

[manifest] URL Scope and priorities, was Re: [manifest] Update and call for review



On May 27, 2014 at 9:19:45 AM, Ben Francis (bfran...@mozilla.com) wrote:
  I think a particular problem with having no defined scope for  
 apps is when you want to hyperlink from one web app to another.  
 A hyperlink with no specified target window will always open  
 in the browsing context of the current app, regardless of whether  
 the URL belongs to another app or web site. That means that the  
 level of browser chrome you get when following a hyperlink (as  
 well as the orientation of the page and the title and icon shown  
 in the task switcher etc.) depends on where you navigated from  
 rather than where you navigated to.
  
 I would like to see some way to define the scope to which an app manifest  
 applies, so that the user agent knows which URLs belong to which  
 apps and therefore what display properties to use for a given  
 URL.

I strongly agree that we need to prioritize: 
https://github.com/w3c/manifest/issues/114

The CSP stuff is also pretty important. Would like to see that also prioritized 
above other things.

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



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 own app store to use its manifest 
  would be for  
 Google to include the HTTP header:
 
  Access-Control-Allow-Origin: http://myownappstore.com;
  
 This is a bit of an abuse of CORS.

hmmm... I thought this was *exactly* the point of having the *-Allow-Origin 
header (restrict sharing to the domains the server chooses in browsers). 

 Adding an
 Access-Control-Allow-Origin: * header currently has the semantic
 meaning of any website can read the contents of this file. I.e. it
 only means that the bits in the file are accessible from other
 websites.

Yep. The point was that combined with the `start_url` member, you can make 
install pages away from the origin where the application resides.  

 That means that for a webserver on the public internet it is currently
 always safe to add the Access-Control-Allow-Origin: * header to any
 file since all files can be read anyway by simply using a different
 HTTP client than a browser, such as wget.

Sure. But that's not the point here. The use of CORS here is to control who can 
do what within the context of the browser (as the policy enforcement point). Of 
course, anyone can just go and download  anything with wget or whatever - but 
that's not going to give that person a web app with the manifest applied.   

 It does not currently mean, and I don't think it should mean, I am ok
 with acting as a manifest for any website.

This is a different interpretation of the semantics of sharing a manifest - and 
certainly not the primary use case (though 
http://generic-manifest.com/manifest.json; could be useful for testing and 
other interesting things). The idea was to say which stores can create a 
product page with the manifest.  

 I think restricting manifests to same-origin is the way to go. I would
 not be surprised if manifests will eventually end up with similar
 security properties as hosting HTML files currently does.

Given the current stuff the manifest defines, I don't have a strong opinion - 
but it certainly does seem like a few less potential headaches down the line. 

I'm happy to make this change and restrict to same origin.

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



On May 27, 2014 at 3:31:15 PM, Ben Francis (bfran...@mozilla.com) wrote:
  To be clear, this is the case I was talking about. The benefit  
 is that it makes it much easier to build a large app store of tailored  
 app experiences for sites that lack manifests without the involvement  
 of app authors themselves. For example,everything.me(http://everything.me)  
 may have a larger catalogue of web apps than the Firefox Marketplace  
 because the latter requires same-origin manifests and for app  
 authors to submit their own apps, whereas the former doesn't  
 require any involvement from app authors themselves.
  
 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 app masquerading as the real thing.  
 In the longer term when additional features are added to the manifest  
 there could be additional risks.
  
 That is why I'm interested in feedback on whether this is a desirable  
 feature or not.

That's a very good summary of both the use case and the problems. I'm also 
interested in hearing feedback. As Ben makes clear, same-origin basically 
kills installations from custom stores. 

It means one or two additional clicks for users to install an app - but we 
assure that apps are always being installed from the source. 
 

-- 
Marcos Caceres

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

On Tuesday, May 27, 2014, Jonas Sicking jo...@sicking.cc wrote:

 On Tue, May 27, 2014 at 12:39 PM, Marcos Caceres 
 w...@marcosc.comjavascript:;
 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 own app store to use its
 manifest would be for
  Google to include the HTTP header:
  
   Access-Control-Allow-Origin: http://myownappstore.com;
 
  This is a bit of an abuse of CORS.
 
  hmmm... I thought this was *exactly* the point of having the
 *-Allow-Origin header (restrict sharing to the domains the server chooses
 in browsers).
 
  Adding an
  Access-Control-Allow-Origin: * header currently has the semantic
  meaning of any website can read the contents of this file. I.e. it
  only means that the bits in the file are accessible from other
  websites.
 
  Yep. The point was that combined with the `start_url` member, you can
 make install pages away from the origin where the application resides.
 
  That means that for a webserver on the public internet it is currently
  always safe to add the Access-Control-Allow-Origin: * header to any
  file since all files can be read anyway by simply using a different
  HTTP client than a browser, such as wget.
 
  Sure. But that's not the point here. The use of CORS here is to control
 who can do what within the context of the browser (as the policy
 enforcement point). Of course, anyone can just go and download  anything
 with wget or whatever - but that's not going to give that person a web app
 with the manifest applied.

 So let's start by asking this: What are you trying to protect against
 by using CORS at all? Rather than using the policy that img uses.

 If the *only* thing you are trying to protect is the actual bytes in
 the manifest itself, then CORS is indeed the right solution.


Yes. This was the only intent.



 But if we're trying to protect more things, then CORS strikes me as
 the wrong solution. And I do think that we will want to protect
 against other things in the future. In FirefoxOS the origin of an
 app is the origin of the app's manifest. This app-origin is then used
 in a bunch of situations.

 For example, we allow pages from the app's to store unlimited amount
 of data through various storage APIs (localStorage excluded for
 reasons I won't get into here). So if you hosted the manifest on a
 CDN, then would mean that only pages whose origin is that of the CDN
 would get access to unlimited storage. That is very unlikely what
 developers want.


Agree - the FX OS model is certainly not the intent or how we, the Eds,
envisioned it working. The manifest relates to the explicit  or implicit
start URL (and soon the URL scope), but not to the manifest's origin.



 In this case hosting the manifest on the CDN would be a footgun, but
 not a security problem.




 I can't off the top of my head think of any actual security problems
 with putting the manifest on a CDN, but I would be surprised if that
 wouldn't happen as we expand the manifest feature set.

 And the footgun is bad enough.

 So I would recommend sticking with having the manifest be same-origin
 with the HTML page.



 Thanks for the additional data point about how FxOS does things.

[manifest] Update and call for review

2014-05-26 Thread Marcos Caceres

Hi,
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 GitHub [bug tracker].

We now have the option to cherry-pick V2 features to either spin off into 
separate specs or to add to the current document. You can view the V2 features 
at [V2]. See also the [CSP-member], which is already in its own spec.

Devs and implementers, please let us know which V2 features should be 
prioritized. 

I've also sent the spec (and [CSP-member]) for a security review to:

* public-webappsec
* public-web-security

Thanks!  

[manifest] http://w3c.github.io/manifest/
[bug tracker]https://github.com/w3c/manifest/issues
[V2] https://github.com/w3c/manifest/issues?labels=V2page=1state=open
[CSP-member] https://github.com/w3c/manifest-csp/

--  
Marcos Caceres

Re: An error in document http://www.w3.org/TR/widgets/

2014-04-18 Thread Marcos Caceres


On April 18, 2014 at 11:05:04 AM, Arthur Barstow (art.bars...@nokia.com) wrote:
 On 4/18/14 10:53 AM, ext Xiaoqian Cindy Wu wrote:
 
 Yes, this is getting much better; thanks Cindy!
  
 There is still a bug with the errata doc's differences document link
 (i.e. it still returns an error):
  
 [[
  
  
  href=http://www.w3.org/2007/10/htmldiff?doc1=http%3A//www.w3.org/TR/widgets/doc2=http%3A//dev.w3.org/2006/waf/widgets/;differences

 document
 ]]
  
 Marcos - this should be updated or perhaps just removed.

yeah, removing it is fine I think.

Re: An error in document http://www.w3.org/TR/widgets/

2014-04-17 Thread Marcos Caceres



On April 17, 2014 at 5:46:17 AM, Wang, Peter H (peter.h.w...@intel.com) wrote:
 Hi all,
  
 I’ve found a small error in document http://www.w3.org/TR/widgets/. In 
 “7.12.4 Example  
 of Usage”:
 古老瓷地图
 Ancient Chinese Maps
 should be
 古老中国地图
 Ancient Chinese Maps
  
 Thank you very much.

Thanks! Fixed:
https://github.com/w3c/packaged-webapps/commit/ae4a1d349e0550dbaad0dbac1bd05c62e942086f

It's in the living standard version:
http://w3c.github.io/packaged-webapps/packaging/

Re: An error in document http://www.w3.org/TR/widgets/

2014-04-17 Thread Marcos Caceres



On April 17, 2014 at 12:21:06 PM, Arthur Barstow (art.bars...@nokia.com) wrote:
 On 4/17/14 12:09 PM, ext Marcos Caceres wrote:
 
  On April 17, 2014 at 5:46:17 AM, Wang, Peter H (peter.h.w...@intel.com) 
  wrote:
  Hi all,
 
  I’ve found a small error in document http://www.w3.org/TR/widgets/. In 
  “7.12.4  
 Example
  of Usage”:
  古老瓷地图
  Ancient Chinese Maps
  should be
  古老中国地图
  Ancient Chinese Maps
 
  Thank you very much.
  Thanks! Fixed:
  https://github.com/w3c/packaged-webapps/commit/ae4a1d349e0550dbaad0dbac1bd05c62e942086f

  
 Thanks to Peter for reporting this and to Marcos for updating the spec.
  
  It's in the living standard version:
  http://w3c.github.io/packaged-webapps/packaging/
  
 Marcos - it seems like this correction should be added to the errata doc
 .

I don't have CVS access anymore (hell, I don't even thing I have cvs installed 
on my computer!:)). The least painful thing would be to point the errata form 
the REC to the document on GH:

http://w3c.github.io/packaged-webapps/packaging/errata.html

I've already updated that document to reflect the recent chance. 

 I also noticed: the REC
 has a link to an ED
 that now 404s and the
 errata doc has a link to a differences document that now returns an error.
  
 Cindy, Yves - would one of you please update the TR with a new link to
 the ED (that Marcos provides, perhaps the URL he gives above)?


Please point to this:
http://w3c.github.io/packaged-webapps/packaging/errata.html

Re: Screen Orientation Status

2014-04-03 Thread Marcos Caceres


On April 3, 2014 at 4:38:41 PM, Mounir Lamouri (mou...@lamouri.fr) wrote:
 
 Test suite:
 None yet. No test suite coordinator at the moment.

I can create the test suite. 
-- 
Marcos Caceres

Re: [April2014Meeting] Building an Issue and Bug focused agenda

2014-04-02 Thread Marcos Caceres



On April 2, 2014 at 6:51:06 AM, Arthur Barstow (art.bars...@nokia.com) wrote:
  * Manifest; led by Marcos; high priority issues, bugs, etc.  

High-priority v1:
* orientation hinting
* Implementer interest 
* should we freeze v1, go to LC? 

V2 feature set:
* url scope
* service workers
* what else? 

Repo:
https://github.com/w3c/manifest/

Issues:
https://github.com/w3c/manifest/issues

-- 
Marcos Caceres

Re: Should events be preferably sent to the Window or the nearest object?

2014-03-20 Thread Marcos Caceres



On March 20, 2014 at 12:58:44 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote:
  Agreed. The exact target isn't very important here, and so being  
 consistent with legacy event firing for the same system is probably  
 a good idea.

Agree. Let's go with consistency, even though it feels a bit weird.

Re: [screen-orientation] Remove the ability to lock to multiple orientations?

2014-03-14 Thread Marcos Caceres


On March 14, 2014 at 9:58:59 AM, Mounir Lamouri (mou...@lamouri.fr) wrote:
 On Fri, 14 Mar 2014, at 16:09, Jonas Sicking wrote:
  However it does mean that we need to also have a way to define that
  orientation should be completely unlocked. This is needed since the
  manifest spec allows overriding the default unlocked orientation. I.e.
  it should be possible to use the manifest to say that an app should be
  in portrait mode, but then allow a page to temporarily override that
  to allow any orientation.
  
 Good point. I meant to mention that in the email but obviously forgot. I
 was wondering between ‘any’, ‘all' or 'sensor' (or 'sensor-all'? :)).

`any` should be fine.

Re: Browser search API

2014-03-13 Thread Marcos Caceres



On March 12, 2014 at 7:16:53 PM, Mitar (mmi...@gmail.com) wrote:
 Hi!
  
 There was no reply. :-(

It usually takes a bit of time for Hixie to get around to all the emails (the 
volume of email on the WHATWG list + other priorities slow things down - but 
I’ve never seen him not respond to a proposal). Give him a few more weeks. If 
you don’t hear back by the end of the month you can try to ping him directly. 



 Mitar
  
 On Mon, Feb 24, 2014 at 8:37 AM, Marcos Caceres wrote:
 
 
 
  On Sunday, February 23, 2014 at 8:53 AM, Mitar wrote:
 
  Hi!
 
  After a bit of delay, I posted a followup to the WHATWG mailing list:
 
  http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-February/042100.html

 
  Looks great, Mitar. I'm sure Hixie and folks at the WHATWG will respond 
  soon.
 
  --
  Marcos Caceres
 
 
 
  
  
  
 --
 http://mitar.tnode.com/
 https://twitter.com/mitar_m

Re: [push-api] Dependency on System Messages

2014-03-13 Thread Marcos Caceres



On March 13, 2014 at 2:33:08 PM, Arthur Barstow (art.bars...@nokia.com) wrote:
 On 3/13/14 1:52 PM, ext Mounir Lamouri wrote:
  System Messages are definitely abandoned, I do not think any
  specification should use them. Even in SysApps, we started working on
  something called Event Pages (similar to what Chrome Apps does) before
  Service Worker took off.
  
 Given this, seems like the runtime ED and TR should be updated accordingly.

I’ll trash the ED’s content. But the SysApps WG needs to make this into a Note.

Re: Browser search API

2014-02-24 Thread Marcos Caceres




On Sunday, February 23, 2014 at 8:53 AM, Mitar wrote:

 Hi!
 
 After a bit of delay, I posted a followup to the WHATWG mailing list:
 
 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-February/042100.html

Looks great, Mitar. I'm sure Hixie and folks at the WHATWG will respond soon.  

-- 
Marcos Caceres

[Manifest] Study on installable web apps

2014-02-21 Thread Marcos Caceres

 to always go back seems critical to make this class of web 
application usable by the general public.  

* Do not expect, or encourage, developers to create single page applications. 
Some will, but they will likely do it wrong. Most everyone won't: it's too 
hard, unnecessary, and evidently error prone.

* Don't expect applications will have good metadata or icons. 

* Automatically generated metadata and template engines will likely be an 
issue. A lot of sites don't seem to test (or might not even know) that their 
websites supports running as standalone. 

* To avoid the issue of UA-specific pop-up banners, a standard way to install 
an application is needed: either through and API and/or some declarative means.

* It needs to be possible to be able to jump between web apps and native apps 
without requiring the developers to constantly save state. That is, leaving a 
standalone web application should work the same as jumping from one browser tab 
to another in a desktop browser. 

HTH,
Marcos 

[1] 
https://github.com/w3c-webmob/installable-webapps/blob/gh-pages/ios_standalone/README.md
  

-- 
Marcos Caceres

Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)

2014-02-17 Thread Marcos Caceres




On Monday, February 17, 2014 at 12:38 PM, Arthur Barstow wrote:

 
 BTW, I noticed there is no Bugzilla component for Service
 Workers so I will ask Mike Smith to create one).

I think they bug tracker on GH is being used instead. It's already very active 
and it would be a shame to have to move to Bugzilla.

Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review

2014-02-16 Thread Marcos Caceres

On Sunday, February 16, 2014, Alex Russell slightly...@google.com wrote:

 On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres 
 w...@marcosc.comjavascript:_e(%7B%7D,'cvml','w...@marcosc.com');
  wrote:

 tl;dr: I strongly agree (and data below shows) that installable web apps
 without offline capabilities are essentially useless.

 Things currently specified in the manifest are supposed to help make
 these apps less useless (as I said in the original email, they by no means
 give us the dream of installable web apps, just one little step closer) -
 even if we had SW tomorrow, we would still need orientation, display mode,
 start URL, etc.

 So yes, SW and manifest will converge... questions for us to decide on is
 when? And if appcache can see us through this transitional period to having
 SW support in browsers? I believe we can initially standardize a limited
 set of functionality, while we continue to wait for SW to come into
 fruition which could take another year or two.


 SW will becoming to chrome ASAP. We're actively implementing. Jonas or
 Nikhil can probably provide more Mozilla context.


I'm also interested in the WebKit and Microsoft context. I just don't know
who to ask there. Have their been any public signals of their level of
interest in SW?


My personal view is that isn't not a good user experience to offer the
 affordance if the resulting system can't be trusted. That is to say, if we
 plow on with V1 without a (required) offline story, I'm not sure what we've
 really won. Happy for this to go to LC, but wouldn't recommend that Chrome
 For Android implement.


I think this is good feedback. I'm happy to add (or for you to add;)) SW
support to the manifest format. At least from Moz perspective it's fine as
we are doing SW already.

Anyone object to adding SW support to V1 of the manifest spec? Anything
else that should be prioritized for V1?





 On Saturday, February 15, 2014 at 1:37 AM, Alex Russell wrote:

  I further think that the marginal utility in bookmarking something to
 the homescreen (sorry, yes, I'm focusing on mobile first) is low if it
 doesn't have a Service Worker / Appcache associated.

 Although I've not published this research yet, this is strongly backed by
 evidence. Nearly all applications in the top 78,000 websites that opt. into
 being standalone applications via apple-mobile-web-app-capable do not, in
 fact, work as standalone applications. If anyone is interested to try this
 for themselves, here is the raw dataset listing all the sites [1] - you
 will need an iPhone to test them. The data set is from Oct. 2013, but
 should still be relevant. Just pick some at random and add to homescreen;
 it makes for depressing viewing.

 There are a few exceptions (listed below) - but those are the exceptions,
 not the rule.
  It's strictly second-class-citizen territory to have web bookmarks
 that routinely don't do anything meaningful when offline.

 Yes, but there are a number of factors that contribute to this: not just
 offline (e.g., flexbox support is still fairly limited, dev tools still
 suck, cross-browser is a nightmare, even how navigation works differs
 across UAs!, limited orientation-locking support, etc.).

 However, to your point the data we have shows that about 50 sites in the
 top 78K declare an appcache [2], while there are 1163 sites that declare
 apple-mobile-web-app-capable. So yeah, appcache, as we all know, is a bit
 of a failure. Some of the sites that declare it actually have it commented
 out... like they tried it and just gave up.

 Interestingly, only 10 sites in the dataset are both capable of running
 standalone AND declare offline:

 1. forecast.io
 2. timer-tab.com
 3. capitalone.com
 4. rachaelrayshow.com
 5. delicious.com
 6. forbesmiddleeast.com
 7. shopfato.com.br
 8. ptable.com
 9 authenticjobs.com

 10. swedenabroad.com

 So, yeah... 10 / 1163 = 0.0085... or, :_(.

 Anyway... do you think it's ok for us to just standardize the limited
 things in the manifest? We could have those at LC like in 2 weeks and then
 spin up V2 to have convergence with SW. Better still, the SW spec can just
 specify how it wants to work with manifests.

 [1] https://gist.github.com/marcoscaceres/7419589
 [2] https://gist.github.com/marcoscaceres/9018819
 --
 Marcos Caceres

Re: [manifest] orientation member

2014-02-12 Thread Marcos Caceres




On Monday, January 27, 2014 at 9:47 PM, Jonas Sicking wrote:

 On Mon, Jan 13, 2014 at 1:44 AM, Marcos Caceres w...@marcosc.com 
 (mailto:w...@marcosc.com) wrote:
 
 Ok, makes sense.
 
 So my counter questions are:
 
 1. Could we get away without using generic media queries and instead
 only allow switching on screen size height and/or width?


Probably - need to check if there is anything else on which this decision would 
be made. This is something we will need to look into.  
 
 2. Could we get away with just using static orientations in v1? I.e.
 punt using different orientations for mobile/tablet until v2 of the
 manifest?
 

Personally, I think so. That's currently what is in the spec [1]. 


[1] http://w3c.github.io/manifest/#default_orientation-member

[manifest] V1 ready for wider review

2014-02-12 Thread Marcos Caceres

The editors of the [manifest] spec have now closed all substantive issues for  
v1. 

The spec defines the following:

* A link relationship for manifests (so they can be used with link 
rel=manifest).

* A standard file name for a manifest resource (/.well-known/manifest.json). 
Works the same as /favicon.ico for when link rel=manifest is missing.

* The ability to point to a start-url. 

* Basic screen orientation hinting for when launching a web app.

* Launch the app in different display modes: fullscreen, minimal-ui, open in 
browser, etc.

* A way of for scripts to check if the application was launched from a bookmark 
(i.e., similar to Safari's navigator.standalone).

* requestBookmark(), which is a way for a top-level document to request it be 
bookmarked by the user. To not piss-off users, requires explicit user action to 
actually work. Expect buttoninstall my app/button everywhere on the Web now 
:)   

If you are wondering where some missing feature is, it's probably slated for 
[v2]. The reason v1 is so small is that it's all we could get agreement on 
amongst implementers (it's a small set, but it's a good set to kick things off 
and get us moving... and it's a small spec, so easy to quickly read over).  

We would appreciate your feedback on this set of features - please file [bugs] 
on GitHub. We know it doesn't fully realize *the dream* of installable web apps 
- but it gets us a few steps closer. 

If we don't get any significant objections, we will request to transition to LC 
in a week or so. 
 
[manifest] http://w3c.github.io/manifest/
[v2] see goals for v2, https://github.com/w3c/manifest#goals-for-v2-and-beyond
[bugs] https://github.com/w3c/manifest/issues

-- 
Marcos Caceres

[manifest] name and icons, was Re: [manifest] V1 ready for wider review

2014-02-12 Thread Marcos Caceres




On Thursday, February 13, 2014 at 1:21 AM, Jonas Sicking wrote:

 
 I still think that leaving out name and icons from a manifest about
 bookmarks is a big mistake. I just made my case here
 
 http://lists.w3.org/Archives/Public/www-tag/2014Feb/0039.html
I'll reply separately.  
 Basically I think we need to make the manifest more self sufficient. I
 think that we're getting Ruby's postulate the wrong way around by
 making the file that describes the bookmark not contain all the data
 about the bookmark. Instead the two most important pieces about the
 bookmark, name and icons, will live in a completely separate HTML
 file, often with no way to find yourself from the manifest to that
 separate HTML file.
 

I still think that icons and name are outside the scope of V1 - but I've added 
them to V2. The whole manifest and icon updating mechanism you describe in your 
email to the TAG adds a bunch of complexity (yes, we need to deal with it 
eventually as it's an extremely valid use case - but we can defer it to HTML at 
this moment and for a few months... even if UAs don't do updating of icons and 
name from HTML). I still hold that we should get the most critical and least 
controversial functionality (display mode, default-orientation, and start-url) 
standardized before we do the other stuff. It also gives a chance for UA's to 
catch up and implement HTML's application-name and link rel=icon properly.  

UAs are going to need to support those HTML features to work with apps that 
don't make use of manifests. And apps the use manifests will work just fine 
till we add proper support for name and icons into the manifest - all web apps 
will need to include application-name and link rel=icon (as well as a bunch 
of proprietary stuff!) to target todays and yesterdays UAs regardless. So, 
IMHO, there is not much to be won by putting name and icons into V1 for 
implementers or for developers at this moment.

I would go as far as to say that it's initially harmful to have name and icon 
in V1 because it discourages UAs from fixing their support for application-name 
and link rel=icon. Having the fallback behavior explicitly tested in V1 of 
the manifest may help improve support for those features of HTML. 

So, I'm not saying let's never do name and icon - I'm saying let just do the 
easy stuff we have some agreement on first.

CFCs for ordinary drafts, was CFC for Re: W3C XHR, was Re: [admin] Draft of updated charter available for review

2014-01-27 Thread Marcos Caceres

Hi Art, 
I'm wondering if we can change the group's work mode to not requiring CFCs for 
ordinary working drafts? Unless I'm not getting something, they seem to add an 
unnecessary delay to getting stuff published. 

Kind regards,
Marcos 

-- 
Marcos Caceres


On Monday, January 27, 2014 at 3:37 PM, Jungkee Song wrote:

 On Fri, Jan 24, 2014 at 8:22 PM, Arthur Barstow art.bars...@nokia.com 
 (mailto:art.bars...@nokia.com) wrote:
  On 1/23/14 8:48 PM, ext Jungkee Song wrote:
   I understand your concern. Indeed, we editors should have made it clearer 
   providing updates on the status and more importantly a new TR.
   
   The goal of the snapshot version of the spec is clear. It aims to 
   standardize all widely implemented parts of the spec that are compatibly 
   supported across major implementations in a *timely* manner. Hence the 
   number one to-do is to enhance the pass ratio of the test suite [1] by 
   interacting with the implementors.
   
   We'd planned to publish LC with the Level 1 spec [2] in a near-term after 
   the last TPAC but the changing publication policy recommends for us to 
   take more conservative approach in publishing LC.
   
   That said, it seems necessary for us to publish a WD with [2] for now 
   before we'll get ready with the test results good enough for publishing 
   LC.
   
   Any comments would be appreciated.
  
  Thanks for the update Jungkee!
  
  I think your plan (to publish a WD now that will replace the 2012 WD and to 
  continue to work toward a LC that is broadly and compatibly implemented) is 
  good. Please let me know when you want me to start a CfC for the WD.
 
 We editors agreed with requesting a CfC to publish [2] as a WD. I'll request 
 it as soon as I'm ready with a WD-ready version.
 
 
 Thanks, 
 Jungkee 
 
 
  -Thanks, Art
  
  
   [1] http://jungkees.github.io/XMLHttpRequest-test/
   [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html
  
 
 
 
 
 -- 
 Jungkee Song

Re: W3C XHR, was Re: [admin] Draft of updated charter available for review

2014-01-24 Thread Marcos Caceres




On Friday, January 24, 2014 at 1:48 AM, Jungkee Song wrote:

   
  To be clear: I’m concerned that the last time the spec on TR was updated 
  was in 2012. That seems like a big failure to me, specially as when you 
  google for the spec, the on the TR comes up first. This means that most 
  people are looking at a grossly outdated spec if they click on the first 
  link.
 I understand your concern. Indeed, we editors should have made it clearer 
 providing updates on the status and more importantly a new TR.
 The goal of the snapshot version of the spec is clear. It aims to standardize 
 all widely implemented parts of the spec that are compatibly supported across 
 major implementations in a *timely* manner. Hence the number one to-do is to 
 enhance the pass ratio of the test suite [1] by interacting with the 
 implementors.
 We'd planned to publish LC with the Level 1 spec [2] in a near-term after the 
 last TPAC but the changing publication policy recommends for us to take more 
 conservative approach in publishing LC.
 That said, it seems necessary for us to publish a WD with [2] for now before 
 we'll get ready with the test results good enough for publishing LC.
 Any comments would be appreciated.
  


Thanks Jungkee for the update - looking forward to seeing an updated WD on TR 
soon. It's good to see the progress in the test suite and that you guys have 
been following up there with the various browser vendors.

W3C XHR, was Re: [admin] Draft of updated charter available for review

2014-01-23 Thread Marcos Caceres

On Thursday, January 23, 2014 at 9:29 PM, Arthur Barstow wrote:
 I don't recall any discussions about stopping the current work, although
 I think it would be useful if the group's XHR Editors would provide a
 short status and plan.


It would indeed be good. However, it would also be good to have a broader 
discussion about what we do about the specs that have move to the WHATWG 
(unless we already did that and I missed it). This whole snapshot thing doesn’t 
feel like it’s working IMO.

Re: W3C XHR, was Re: [admin] Draft of updated charter available for review

2014-01-23 Thread Marcos Caceres



On Thursday, January 23, 2014 at 10:36 PM, Marcos Caceres wrote:

 On Thursday, January 23, 2014 at 9:29 PM, Arthur Barstow wrote:
  I don't recall any discussions about stopping the current work, although
  I think it would be useful if the group's XHR Editors would provide a
  short status and plan.
  
  
  
  
 It would indeed be good. However, it would also be good to have a broader 
 discussion about what we do about the specs that have move to the WHATWG 
 (unless we already did that and I missed it). This whole snapshot thing 
 doesn’t feel like it’s working IMO.  

To be clear: I’m concerned that the last time the spec on TR was updated was in 
2012. That seems like a big failure to me, specially as when you google for the 
spec, the on the TR comes up first. This means that most people are looking at 
a grossly outdated spec if they click on the first link.

Re: [admin] Draft of updated charter available for review

2014-01-21 Thread Marcos Caceres


Quick notes, questions 

Is File API: Directories and System dead? Looks kinda dead (last updated 07 
March 2012). 

Streams should not be part of File - it's a generic API for any data. 

UI Events is linked to the wrong place. 

Drop the currently not supported by web standards. from Gamepad 
description... as it's a bit of an oxymoron to have a standard for a standard 
that's not supported as a standard... standard :) 

Ooohhh! WebApps staking a claim over Service Workers! Nice :) 

URL API should point to http://url.spec.whatwg.org/

Can we please put an end to this whole snapshot nonsense:
https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html

Maybe drop: public-web-inte...@w3.org (archive) for discussion of the Web 
Intents specification

-- 
Marcos Caceres


On Tuesday, January 21, 2014 at 8:36 PM, Arthur Barstow wrote:

 Hi All,
 
 Although WebApps' current charter [Charter] does not expire until the 
 end of May, since it can take a while to agree on a new charter 
 (especially if new deliverables are proposed), I created a Draft [Draft] 
 today. A diff of the current charter vs. the draft is available at [Diff].
 
 My intent was to reflect the current state of WebApps' work and I don't 
 think there are any major surprises.
 
 Comments (as well as PRs) are welcome, especially if anyone has any 
 deliverables to propose.
 
 -Thanks, ArtB
 
 [Charter] http://www.w3.org/2012/webapps/charter/Overview.html
 [Draft] http://afbarstow.github.io/WebApps/charter.html
 [Diff] 
 http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2012%2Fwebapps%2Fcharter%2FOverview.htmldoc2=http%3A%2F%2Fafbarstow.github.io%2FWebApps%2Fcharter.html

Re: [manifest] orientation member

2014-01-13 Thread Marcos Caceres



On Wednesday, December 4, 2013 at 5:26 AM, Jonas Sicking wrote:

 3On Tue, Dec 3, 2013 at 4:20 AM, Mounir Lamouri mou...@lamouri.fr 
 (mailto:mou...@lamouri.fr) wrote:
  On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote:
   My impression has been that the vast majority of apps only need a
   single orientation that is independent of media-query results. If
   that's the case, then I think the above is too complicated. I.e. if
   that is the common case, then we should support:

   orientation: [landscape],

   or maybe even

   orientation: landscape,
   
  I definitely agree with that. Though, we should allow both syntaxes
  (array and string).
  If we want a more complex system later, we could move to that. For the
  moment, I think we should keep it simple. Also, when comparing how
  applications handle landscape/portrait, it is worth considering how
  common/easy it is to write responsive UI on the platform. iOS has a very
  limited number of device sizes so I am not really surprised that iOS
  applications try to optimize for some sizes (thus arbitrary ignore some
  others). Is that common on Android? Would that be common using Web
  applications?
  
  
  
 I too am curious what the use cases are for switching orientation
 based on screen size is. If your app runs fine in both orientations,
 then why lock the orientation at all?

Yes, of course when one presents it like that (if it works on both, why lock 
it?) it seems to makes sense: but it’s overly simplistic: It’s only in the 
opposite case (on smaller devices/phones, single locked orientation makes more 
sense)… i.e., this is a “mobile first” design issue - where even though it 
“works” in landscape, the experience is so sub-optimal for some application 
types that it’s not worth optimizing/designing for. However, the Web case may 
be unique, in that installed applications are bookmarked from browsers, which 
generally support portrait and landscape on phones and anything bigger.   

You can see that the landscape experience is sub-optimal if you just play 
around with apps on your mobile phone that are not games. With the exceptions 
of a few apps (e.g., calculator on iPhone, which turns into a scientific 
calculator when rotated; and the Stocks app - which shows a graph view when 
rotated to landscape), I’m confident that you will see that even the ones that 
support rotation are not particularly useful in landscape mode (i.e., are more 
natural to use in portrait - particularly web applications). Games are always 
the exception, as they really do require landscape to support for continuos 
interaction (i.e., because the user’s fingers are on the screen so would block 
too much of the viewport). Also, on phones, starting applications is generally 
done in portrait mode (at least on iPhone, Android, and FxOS) - so most apps 
are expecting to be launched and primarily used in portrait.  

But that’s not the case on tablets (particularly for applications that are both 
created for both phones and tablets) - where it’s natural to hold the device in 
any orientation. This leads to the problem:  

1. an application may work best as portrait on a phone, but has to work on any 
orientation on tablet. Forcing a single orientation would only be useful for 
games - all other application types would need to support any (forcing 
developers to have to design for landscape on small devices when they don’t 
have to in their native counterparts - or worst, they have to display a “rotate 
your phone portrait” message to users, as some apps already do - e.g., 
forecast.io displays advertising for a future product when rotated to 
landscape).
  
2. Forcing an application on a table into portrait leads to a bad user 
experience (because a percentage of users will be unnecessarily forced to 
rotate their device to portrait). So I don’t imagine anyone will use this, 
unless they are using UA/device sniffing, which would show that the solution is 
broken.  

 I thought that the main use case was for something like a video player
 or a game that wanted to always be in landscape mode was the main use
 case?
  

No - specially the video use case is not really valid because videos will 
usually just enter full screen mode and allow any orientation once they start 
playing (think of them as an application within an application). Again, the 
300+ odd apps we looked at paints a different picture: small device, then 
single orientation (generally portrait primary) - unless it’s a game. Tablet 
device, free to rotate to any orientation - tablet applications that lock to an 
orientation are annoying in that they are unnatural to use (unless it’s a game, 
of course).

We could assume that any orientation be supported on any device, but this means 
we (browsers) are putting developers in a bad situation again of not having the 
freedom to control how their applications are displayed on different device 
types. This can lead to a degraded user experience,

Re: [manifest] orientation member

2014-01-13 Thread Marcos Caceres



On Tuesday, December 3, 2013 at 10:20 PM, Mounir Lamouri wrote:

 On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote:
  My impression has been that the vast majority of apps only need a
  single orientation that is independent of media-query results. If
  that's the case, then I think the above is too complicated. I.e. if
  that is the common case, then we should support:
   
  orientation: [landscape],
   
  or maybe even
   
  orientation: landscape,
  
 I definitely agree with that. Though, we should allow both syntaxes
 (array and string).

 I don’t like the idea of supporting two types, but can live with it. My 
preference is just having an array, and having unknown values ignored - at 
least that gives us some kind of extensibility mechanism.   
 If we want a more complex system later, we could move to that.

As above - so long as whatever we come up with is somewhat future proof.   
 For the
 moment, I think we should keep it simple. Also, when comparing how
 applications handle landscape/portrait, it is worth considering how
 common/easy it is to write responsive UI on the platform.

It’s only technically easy. Design and UX wise it’s actually really hard in 
practice - and doing it cross platform/cross device is even harder because 
support for layout application technology remains in its infancy (i.e., Flexbox 
support is really lacking on mobile, and who knows how long that situation will 
continue for).  
  
In addition, the data we are seeing from applications that declare 
apple-mobile-webapp-capable show that developers are not doing this. Or, 
worst case, when apps are being rotated, they have to display a “rotate your 
phone the other way” message.   
 iOS has a very
 limited number of device sizes so I am not really surprised that iOS
 applications try to optimize for some sizes (thus arbitrary ignore some
 others). Is that common on Android?

Yes, it appears to be common on Android too.   
 Would that be common using Web
 applications?

Web apps don’t really have a choice. But you can try out your favorite apps on 
a phone in landscape move and see how usable they are: they may be usable (and 
some actually do provide a little adaptability - like BBC news), but it’s 
probably just coincidental that they work that was and not the way you would 
normally use them (unless its’ a game, of course).  

In any case, as you suggest, let’s build this up incrementally - but let’s make 
sure that we have a migratory path to give developers a choice to better 
control orientation.

Re: [manifest] orientation member

2014-01-13 Thread Marcos Caceres



On Wednesday, December 4, 2013 at 3:22 AM, Scott Wilson wrote:

 Hmm. Does this take us back to viewmodes [1]? For example you also have the 
 ability on Windows Phone to have the live tiles view, with primary and 
 secondary tiles, and both square and wide tiles...
  


I thought it did, but I don’t think it does… not yet anyway - but we are seeing 
a lot of overlap in the discussion (“windowed”, “fullscreen” for now).   

 Also it may be necessary to consider where apps are intended not to take over 
 the device, but as additional content within another platform, e.g.: 
 OpenSocial has 'canvas', 'profile' views, etc. However I think OpenSocial is 
 heading towards the option of just using adaptive CSS, along with contextual 
 metadata from the container platform via AJAX.
That might work better, specially if we ever get @viewport support in browsers. 
 
  
 [1] http://www.w3.org/TR/view-mode/

Re: Regarding: Making the W3C Web SQL Database Specification Active

2014-01-01 Thread Marcos Caceres



On Tuesday, December 31, 2013 at 3:29 AM, Shane Harrelson wrote:

 Not to beat a dead horse, but would https://code.google.com/p/csharp-sqlite/ 
 count as an independent implementation of the SQLite SQL syntax?
 


Using an unmaintained project as a ways of advancing as specification would 
kinda defeat the point of standardization of browser technology. To benefit the 
web, the only independent implementations that would actually matter would need 
to be browser-based. 

So no, it would not count (not unless we want to really dilute how a 
specification becomes a W3C standard).  

-- 
Marcos Caceres

Re: New manifest spec - ready for FPWD?

2013-12-18 Thread Marcos Caceres




On Tuesday, December 3, 2013 at 3:01 PM, Jonas Sicking wrote:

 On Tue, Nov 26, 2013 at 1:02 PM, Marcos Caceres w...@marcosc.com 
 (mailto:w...@marcosc.com) wrote:
  The Editors would appreciate if people take a look and see if you agree 
  with the feature set.
 
 What I think we should have is something like:
 
 chrome: {
 back: true
 }
 
 If the UA doesn't support any of the properties in the chrome
 section, then the UA should be required to not launch the app in
 standalone mode.

Captured here: https://github.com/w3c/manifest/issues/117 
snip 
 I also think the dont-share-cookies-and-stuff thing needs more work
 before it's ready for inclusion. So might be better to drop that for
 FPWD. But I'm fine with keeping it in for now too and dropping it if
 we can't solidify it.
 


This is has been removed from the spec.

Re: New manifest spec - ready for FPWD?

2013-12-16 Thread Marcos Caceres




On Monday, December 9, 2013 at 10:51 PM, Mounir Lamouri wrote:

 On Wed, Dec 4, 2013, at 10:03, Marcos Caceres wrote:
  From the research we’ve done, none of the proprietary solutions currently
  do this. I’ve added this as a feature request [1] so we can see how much
  interest there is.  
  
  
  
 I think it is exaggerated to say that pages rely on the user seeing the
 page title.  

I tend to agree (particularly for apps that have been added to the home 
screen). Apps that want to display their own name (e.g., Google’s Authenticator 
app on iOS does this) can do that with HTML.   

Having said that, there are other contexts where showing the title makes sense 
(in a task switcher - or when organizing tabs). But that’s generally handled by 
the OS.   
 It is very uncommon to be able to read more than a couple of
 words and depending on your browser/system you might not even see the
 page title at all (the case for me because I rarely have less than a
 dozen tabs open). I think the back button and reload buttons might be
 critical to be able to run some apps while the page title is simply a
 nice to have.
  

Yeah, I think I’m reaching the same conclusion. I’ll keep looking for other 
examples and document them here:
https://github.com/w3c/manifest/issues/89

Re: [manifest] HTTP-based solution for loading manifests

2013-12-11 Thread Marcos Caceres

On Wednesday, December 11, 2013, Julian Reschke wrote:

 On 2013-12-11 13:13, Mounir Lamouri wrote:

 On Wed, Dec 11, 2013, at 14:48, Marcos Caceres wrote:

 Would any potential implementer consider supporting a HTTP based solution
 to loading manifests?


 It seems quite premature to discuss a HTTP based solution to advertise a
 manifest. Even if it happens to be something developers ask for, we will
 anyway need to provide a link solution. It seems that the best course
 of actions we could take here is to implement the manifest feature using
 link and gather developer feedback to evaluate that alternative.


 If you define a way using link, the alternative approach using the Link:
 header field essentially comes for free.


Mark seems to imply otherwise: for example, Mark says that [Link:] was never
specified to be used with the stylesheet relation.

https://github.com/w3c/manifest/issues/98#issuecomment-30293586

If that's the case, then neither would manifest? I also thought Link: was
more or less generic. I should read the spec in detail.



  ...


 Best regards, Julian

[manifest] HTTP-based solution for loading manifests

2013-12-10 Thread Marcos Caceres

Would any potential implementer consider supporting a HTTP based solution to 
loading manifests? 

The rationale being:

For manifests it is much more commonly going to be the case that there's 
existing content that people want to add a manifest to. Doing that by editing 
each and every HTML file or HTML-outputting server side script seems likely to 
in many cases be much harder than adding a config setting [on the server] that 
adds a link header.

It would mean using something like the HTTP `Link:` header defined in [RCF5988] 
or a new HTTP header like `Manifest:`. 

So, something like the following in the case of [1]: 

Link: /manifest.json; rel=manifest

Or the following in the case of a new header: 

Manifest: /manifest 

Please see the following for discussion:
https://github.com/w3c/manifest/issues/98 

[RFC5988] http://tools.ietf.org/html/rfc5988

-- 
Marcos Caceres

Re: New manifest spec - ready for FPWD?

2013-12-10 Thread Marcos Caceres

Hi Rob,  


On Wednesday, November 27, 2013 at 9:28 AM, Rob Manson wrote:

 That's a great overview!
  
 There's 2 points I think haven't fully been addressed.
  
 1. Section 8. Navigation
 Much of this work (and HTML5 in general) is about bringing the Web  
 Platform up to being equal with native apps. But one thing that the  
 Web does that native apps can't do is deep linking (ignoring the  
 fustercluck of intents). I think it would provide a significant  
 advantage if it was also possible to deep link into installed web apps.  
 I understand this is very complex and I'm not proposing any solution  
 right now. But if we don't include this then we are in effect cutting  
 web applications down to the level of native apps instead of leaping  
 ahead of them.
  
 Use Case: Social sharing
 User A and User B both have the same web app installed on the devices  
 they are using. User A finds a resource they like inside the app and  
 decide to share this from within the app through one of their social  
 networks. User B sees this link in their social feed and taps on it.  
 Since User B also has this web app installed it would be nice to be  
 able to open that resource directly within the installed app. Otherwise  
 User X's browser would just open it like a normal web resource. This  
 can also be relevant for the same user using the same web app across  
 multiple devices.
 NOTE: This is one of the key drivers we have found for building business  
 cases of Web instead of Native.

Filed bug to investigate:
https://github.com/w3c-webmob/installable-webapps/issues/30
   
  
  
 2. Section 6. Start page
 This is lightly touched on and slightly related to the point above, but  
 the common experience especially on iOS is that even when you background  
 an installed app and then foreground it again it reloads the entire  
 state. This effectively breaks the UX and makes this mode almost  
 unusable. It's definitely possible to use localStorage, etc. to work  
 around this but the UX is horrible. Allowing installed apps to persist  
 their resources and loaded state across background/foreground (and  
 ideally even launches) would be a massive step forward. Perhaps naming  
 this a First use page would help clarify this focus?
  

Agree. This is really evident in iOS at least. Will also investigate if it’s 
something devs should be dealing with or an OS level thing. At least on iOS, it 
seems like it’s an OS level thing, as native apps don’t have this problem - you 
can switch back and force between them (unless they take up massive amounts of 
RAM, like games… in which case iOS seems to shut down apps as you swap from one 
to another).  

Firefox OS seems to fake it by taking a screenshot when the app boots up, which 
is then used in the task switcher.  

Tracking this here:
https://github.com/w3c-webmob/installable-webapps/issues/31

Re: New manifest spec - ready for FPWD?

2013-12-10 Thread Marcos Caceres



On Wednesday, November 27, 2013 at 10:37 PM, Mounir Lamouri wrote:

 On Wed, Nov 27, 2013, at 8:02, Marcos Caceres wrote:
  Over the last few weeks, a few of us folks in the Web Mob IG have been
  investigating the use cases and requirements for bookmarking web apps to
  home screen. The output of that research is this living document:
  http://w3c-webmob.github.io/installable-webapps/
   
  That (ongoing) research is helping to inform the manifest spec. A bunch
  of us have been working together on IRC, twitter, etc. on a new version
  of the manifest spec:
  http://w3c.github.io/manifest/
   
  The Editors would appreciate if people take a look and see if you agree
  with the feature set.  
  
  
  
 The feature set sounds pretty good. I would gladly discuss more why some
 properties are defined and how some others are but the general gist
 sounds fine. Maybe some properties should be removed to make things go
 faster. For example, what's the current support to implement 'mode' and
 'dont-share-cookies-and-stuff'?


Probably not much… but it’s a thing I want to have in the FPWD for IPR reasons. 
Will remove it from the living doc till we sort out what it means and how it 
works.  

Filed bug for removal:  
https://github.com/w3c/manifest/issues/105

Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?

2013-12-04 Thread Marcos Caceres

More comments inline, but I’ve started running a developer survey here about 
the proposed solutions:
https://gist.github.com/marcoscaceres/7783977

See also:  
https://twitter.com/marcosc/status/408150324629630976

Some really great feedback from the dev community on twitter! Please take a 
look.  


On Wednesday, December 4, 2013 at 8:10 PM, Charles McCathie Nevile wrote:

  Having said that, there are issues also with navigating installed web  
  apps. The phonegap guys have a wealth of experience to share here,  
  though they are proponents of single page apps to overcome limitations  
  in the Web platform (e.g., avoiding the flash of white when loading  
  another web page when navigating). Anyway, we can deal with those issues  
  later - but just want to be clear about what we’ve seen in the dataset  
  we’ve been looking at in WebMob and what the forthcoming issues are  
  going to be if this goes mainstream.
  
  
  
 Looking forward to you publishing that data. Is there a simple pointer for  
 those of us who haven't been following webmob closely so we can start from  
 somewhere better than all of webmob?

The report is here:  
http://w3c-webmob.github.io/installable-webapps/

The data is from webdevdata.org (a W3C community group a few of us set up to 
gather this kind of data - you should join!:))

  I really don’t like this - specially messy with the single quote/double  
  quote thing which is one screws it up is a huge pain in the as to debug.  
  Structured content really feels like it should be in an element.
  
  
 Yes, but I wonder how big a real problem that is. I happen to use a  
 bare-bones version of vi that doesn't balance parentheses, quotes, etc,  
 but I believe that shows I am a very strange person. As far as I know,  
 debugging this kind of error semi-automatically is actually pretty  
 trivial, and common.


It might not be a huge problem because I’m trying my hardest to keep the 
structure flat. It becomes a nightmare pretty quickly once things start 
nesting. The lack of commenting and not being forgiving about trailing commas 
doesn’t help, etc. It also feels crapy that one has to special case this one 
attribute to use single quotes.  
  
   
  I’ll bounce it to HTMLs people and see what they say.
  
 From an authoring perspective I don't think the verbosity is a big issue,  
 and the two options *seem* about equivalent in cognitive load - switching  
 elements is odd but people are clearly used to doing it for style, and  
 setting a type attribute in a script element compared to using link/meta  
 is the same thing.


True. That’s a good point.  
  
 Which makes the big question about taste in syntax (unless there is some  
 real implementation or web-compat issue). So I expect it to be the hardest  
 one of all to solve :)
  

I’m being told in IRC that there might be CSP implications with either of the 
solutions that I need to investigate.

Re: Request for feedback: Streams API

2013-12-04 Thread Marcos Caceres





On Thursday, December 5, 2013 at 3:57 AM, Arthur Barstow wrote:

 Thanks for the update Feras.
  
 Re getting `wide review` of the latest [ED], which groups, lists and  
 individuals should be asked to review the spec?
  
 In IRC just now, jgraham mentioned TC39, WHATWG and Domenic. Would  
 someone please ask these two groups to review the latest ED?
  
 Aymeric - would you please ask the WebRTC list(s) to review the latest  
 ED or provide the list name(s) and I'll ask them.


It’s still a big concern that there are two competing proposals. We can just 
“let the market sort it out”, but I think it would be best if there was a 
single spec with all the folks interested in this area working together.  

How can we work towards that?

inline declarative manifest, was Re: New manifest spec - ready for FPWD?



On Wednesday, December 4, 2013 at 4:27 AM, Jonas Sicking wrote:

   I also think that we need a way to put the manifest in-line in the
   main document. In part, technologies tend to be a lot easier to
   understand if you can create a single-file demo. In part, for small
   simple apps, having to separate the manifest into a separate file
   could be annoying and might drive people to stick to the existing
   meta-tags.
   
   
   
  Would it suffice to use the API? It’s much simpler than trying to write out 
  JSON by hand and wouldn’t require us to create any new special script type, 
  etc.
   
  script
  if(“requestBookmark” in navigator){
   
  var appDetails = {name: “Awesome app!”, mode: “standalone”};
  navigator.requestBookmark(appDetails).then(happy,sad);
  }
  /script
  
  
 I don't think so. That wouldn't let search engines find it. It also
 wouldn't let us hook it up to the bookmark menu unless the page always
 calls requestBookmark very early in the page load sequence at all
 times.


Right, but the search engine use case is what link rel=“manifest” 
href=“foo.json is for.  

Loading of manifest data is then prioritized by the UA till it’s needed (i.e., 
till the user actually takes some action to “bookmark to homescreen”) - then 
the right icons, etc. would be d/l presumedly.  

So, the way I’ve been viewing this is that API provides a way to customize the 
externalized JSON metadata by overriding values - so it tries to cleanly 
abstract the idea of application metadata from the JSON itself by using as much 
information from the document and the JSON as is available.
 I'd rather stick the manifest as metadata in the markup and make
 requestBookmark take no arguments.


This would already be supported, in that once the content of the link element 
is loaded:   

script
var installButton = $(“#installbutton”);  

//wait for it to load
$(“link[rel=manifest]”).on(“load”,  (e) = installButton.enable());

//use the metadata available to the document  
installButton.on(“click”, (e) = navigator.requestBookmark());  
/script

If the load fails for whatever reason, then the developer could provide 
fallback either in the form of meta tags and/or by passing the custom manifest 
object.  

If you and others still don’t think the above meets the use cases, then I’d be 
ok to introduce something like:

script type=“manifest”
{
  … metadata …  
}
/script  

But need to talk to HTML folks about what the right thing to do here is (with 
regards to legacy UAs, not breaking parsing, etc.).  

--  
Marcos Caceres

Re: New manifest spec - ready for FPWD?



On Wednesday, December 4, 2013 at 7:43 AM, Charles McCathie Nevile wrote:

 On Tue, 03 Dec 2013 19:27:15 +0100, Jonas Sicking jo...@sicking.cc 
 (mailto:jo...@sicking.cc) wrote:
  
  On Mon, Dec 2, 2013 at 9:40 PM, Marcos Caceres w...@marcosc.com 
  (mailto:w...@marcosc.com) wrote:
What I think we should have is something like:
 
chrome: {
back: true
}



   Yep, this is currently captured here:
   https://github.com/w3c/manifest/issues/76

   Those of us working on this still need to investigate FxOS a bit more  
   to see what people are using in practice and why (e.g., how much  
   granularity do we really need? to the button level “forward”/“back, or  
   can we just say “navigation-bar”, etc.). Captured here:
   https://github.com/w3c-webmob/installable-webapps/issues/17
   
   
   
  Simply wanting *just* the back/forward buttons has been common. I
  could imagine apps relying on the reload button as well.
  
  
  
 Yes. Especially for things that come off the web (as opposed to packaged  
 apps).
  
  I have not heard of, but I could imagine, apps wanting to rely in the
  title of the page being displayed.
  
  
 Quite possibly
 [use case snipped]


From the research we’ve done, none of the proprietary solutions currently do 
this. I’ve added this as a feature request [1] so we can see how much interest 
there is.  

BTW, the closest I’ve seen to this was in Chrome Beta for Android. Before 
installable apps were removed, it showed the URL automatically if the 
applications changed origin during navigation.  
It’s was a nice security feature. You can see picture of it here:  

https://developers.google.com/chrome/mobile/images/home_navigate.png
  
  The url bar is a very common separate UI piece on most platforms.
  However it's unclear how a URL bar would work in a standalone UI.
  Would the user be able to type any URL while still remaining in within
  the standalone UI? Seems surprising if we imagine that the standalone
  UI uses the icon of the app. Though we could always open any typed URL
  in the default browser. Anyway, staying away from url-bar seems safer
  for now.
  
  
 Yes. In-apge Search is something that might also be useful within an app -  
 especially if you can find out it is happening and respond to it  
 intelligently if the app hides things by default.


I will spin up a separate thread for this.   
  

[1] https://github.com/w3c/manifest/issues/89

in-page search, was Re: New manifest spec - ready for FPWD?




On Wednesday, December 4, 2013 at 7:43 AM, Charles McCathie Nevile wrote:

 Yes. In-apge Search is something that might also be useful within an app -
 especially if you can find out it is happening and respond to it
 intelligently if the app hides things by default.


The ability to do this is useful, but I wonder if it’s kinda context specific. 
Just some very lose thoughts off the top off my head:

* no (mobile) native application platform let’s you do this, AFAIK (just a fact 
- not a judgment or a good/bad thing).
* hardly any mobile browser currently supports this (which sucks, IMO).  
* searching in page is not something that is usually shown by default: you have 
to press ctrl-f on most browsers to bring up in-page search.  
* apps might only want specific runs of text (a group of elements) to be 
searchable… maybe this is a HTML feature section searchable?  

So I guess the option, if we were to support this, would be something like 
“searchable”. Then the UA can work out the best way to present show the search 
box (e.g., long press - “Search on this screen”).
  
--  
Marcos Caceres

Re: in-page search, was Re: New manifest spec - ready for FPWD?



On Wednesday, December 4, 2013 at 9:17 AM, Marcos Caceres wrote:

  
  
  
 On Wednesday, December 4, 2013 at 7:43 AM, Charles McCathie Nevile wrote:
  
  Yes. In-apge Search is something that might also be useful within an app -
  especially if you can find out it is happening and respond to it
  intelligently if the app hides things by default.
  
  
  
  
 The ability to do this is useful, but I wonder if it’s kinda context 
 specific. Just some very lose thoughts off the top off my head:
  
 * no (mobile) native application platform let’s you do this, AFAIK (just a 
 fact - not a judgment or a good/bad thing).
 * hardly any mobile browser currently supports this (which sucks, IMO).  
 * searching in page is not something that is usually shown by default: you 
 have to press ctrl-f on most browsers to bring up in-page search.  
 * apps might only want specific runs of text (a group of elements) to be 
 searchable… maybe this is a HTML feature section searchable?  
  
 So I guess the option, if we were to support this, would be something like 
 “searchable”. Then the UA can work out the best way to present show the 
 search box (e.g., long press - “Search on this screen”).
  


Tracked by: https://github.com/w3c/manifest/issues/90

Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?

tl;dr - a few counter points for consideration, but I’m generally ok with 
adding both the declarative inline alternative and with dropping the arguments 
on the API in V1. For the declarative solution, we would drop using link in 
favor of script entirely.  

On Wednesday, December 4, 2013 at 9:40 AM, Jonas Sicking wrote:
 We currently have both script.../script and script src=..., as
 well as both style.../style and style src. A big reason we have
 both is for author convenience.


I thought this was because script and style are “this page’s script and 
style” (i.e., the scope is very specific).  

This is different to the manifest, which is “this loosely grouped set of 
navigable resources forms a web-app”.  

Also, appcache is a really good counter example of something that doesn’t do 
this… oh.. wait :)  
  
 If you have a script or CSS resource that is shared between lots of
 pages then it's convenient to allow the script/CSS to live in an
 external file such that you can just change it once to have the change
 applied to everyone that links to it.
  
 But if you have a script/CSS which is very specific to a single page,
 then it's very annoying to have to create a separate file that lives
 side-by-side with your HTML file and whenever you make a change to
 your HTML which requires a change in the script/CSS also open and
 change the external file. It also means that if you move/backup/email
 your HTML, you have to remember to include the script/CSS file. Hence
 we allow script/CSS to live inline inside the HTML.

Sure, I can sympathize with that, but the trend and best practice is still not 
to include things inline (e.g., as per CSP).

I’m not saying we shouldn’t allow it - just sayin’ its kinda crappy because it 
encourages bad development practices (leading to single page apps, etc.).   

 There are performance benefits to allowing both as well. With an
 external script/CSS the script/CSS can be cached and not have to be
 downloaded with every HTML file that uses them. But if only a single
 HTML file uses the script/CSS then the extra network roundtrip
 involved with fetching another resource can be saved by including the
 script/CSS inline.

Right, but HTTP2 is supposed to erode those differences. Also, in many cases 
it’s not really necessary to download the manifest at all (because the user may 
not be on the page long enough to make a decision about bookmarking), so it’s 
wasted bytes to include them.  
 It seems to me that the same arguments applies to metadata such as
 what's included in the manifest.

Yes.   
 If you have a big app consisting of multiple HTML files then having
 them all link to an external manifest makes a lot of sense. That way
 you only need to change a single location when you want to change
 something and the risk of the different pages of your app getting
 out-of-sync is reduced.
  
 However if your app is very simple and just consists of a single
 HTML page, then forcing that HTML to link to an external resource is
 just annoying for the developer. By allowing the manifest to live
 inside the HTML it makes maintaining the manifest easier and the
 developer is less likely to forget to do so. This also simplifies
 creating tutorials and filing bugs since you can create single-file
 examples.
  
 Does this explain the use case better?
Absolutely. I personally think there are better ways of dealing with these 
things, but I’m certainly not adverse to including this.  
 I don't have a strong opinion on if we should use script
 type=manifest{ ... }/script,  

This one is the most sane, IMO. There is precedence for this on the Web.  
 meta name=manifest content={ ... },
 link rel=manifest content={ ... },


I think developers will object to the above. If src-n was an abomination to 
some, then I can’t imagine the above being well received.
 
 manifest{ ... }/manifest


This wouldn’t work… not in the head, at least as it would auto close head so it 
gets rendered in legacy browsers. See livedomviewer here:
http://tinyurl.com/knbhe3s

  
 or
 something else. Like you said, I think it's a conversation we need to
 have with the HTML people.


I’ll investigate a bit more. I’ve added a bug here:
https://github.com/w3c/manifest/issues/91

I’ll just note that having link rel=manifest and script type manifest would 
kinda suck… if we can just have:

* script type=“application/manifest+json” src=“manifest.json”/script
* script type=“application/manifest+json”{}/script that would be great.  

That would be great. Reading the HTML spec, I think we can.  

 As for the API, I generally don't like the idea of having a script API
 which allows passing a full manifest constructed in JS to the UA as
 part of the API. That solution discourages finding manifests using
 search engines which effectively hides critical metadata. While I
 don't want to *force* developers to expose metadata to search engines,
 I want to try to avoid that happening accidentally since this metadata
 seems

Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?




On Wednesday, December 4, 2013 at 4:16 PM, Jonas Sicking wrote:

  I’m not saying we shouldn’t allow it - just sayin’ its kinda crappy because 
  it encourages bad development practices (leading to single page apps, etc.).
  
 For simple apps I don't see anything wrong with single-page.
 I'd rather spend time on making multi-page experiences good so that authors 
 don't avoid it, than try to force it.
 I.e. the thing that I think is bad practices is when developers that have 
 multi-page UIs use excessively complicated solutions to create a single-page 
 implementation. We should improve the web so that they don't have to.
 I don't think single-page apps is something that is inherently bad.


Sorry, I should have clarified this a bit more. This isn’t about single page vs 
multipage apps (of course there will be apps that are single page!) - it’s 
about the expectation by browser vendors that apps would be developed as single 
page and what we are seeing in the data about single page apps: When looking at 
apps that declare “*-mobile-web-app-capable”, which are supposed to be single 
page apps by design, we found that very few apps are actually built as single 
page.  

I haven’t yet published this data in the use cases document, but it’s pretty 
clear that developers are adding “*-mobile-web-app-capable” and:  

1. not actually testing what that does (one finds “*-mobile-web-app-capable” 
with no meta viewport, which means they are serving a “desktop site” and 
pretending it’s installable… some of the sites also lack icons, etc.).  
2. not actually caring that only the bookmarked page will open full screen and 
any clicked link will throw the user back into the Web browser.  
3. finding it too hard to build their app as a single page app, but allowing 
for install-ability regardless (e.g., ESPN, Vanity).  

Having said that, there are issues also with navigating installed web apps. The 
phonegap guys have a wealth of experience to share here, though they are 
proponents of single page apps to overcome limitations in the Web platform 
(e.g., avoiding the flash of white when loading another web page when 
navigating). Anyway, we can deal with those issues later - but just want to be 
clear about what we’ve seen in the dataset we’ve been looking at in WebMob and 
what the forthcoming issues are going to be if this goes mainstream.  
  
   meta name=manifest content={ ... },
   link rel=manifest content={ ... },
   
   
   
  I think developers will object to the above. If src-n was an abomination to 
  some, then I can’t imagine the above being well received.  
 I think the src-n dislike came from the fact that it tried to use something 
 that has always been a dictionary with a limited and defined set of keys and 
 tried to use it as an array with an unbounded key set.

Yes, from an implementation perspective yes. But in the RICG, from web 
developer perspective, it was more about the strange use of the attribute.   
 That's very different from what we are doing here which is sticking a very 
 large value into an attribute.
 Personally my vote goes to using link rel=manifest for external manifests, 
 and meta name=manifest for internal manifests. That has a nice symmetry and 
 reuses existing elements in a proper way.
 And you can put line breaks inside attributes. They don't show up in the 
 attribute value but that seems ok here.
 And you don't have to escape quotes as long as you use apostrophes as to 
 delimit the attribute value. I.e. the following is just fine.
 meta name=manifest content='{
 a: 1,  
 b: foopy
 }'


I really don’t like this - specially messy with the single quote/double quote 
thing which is one screws it up is a huge pain in the as to debug. Structured 
content really feels like it should be in an element.  
  
  
   or
   something else. Like you said, I think it's a conversation we need to
   have with the HTML people.
   
   
   
  I’ll investigate a bit more. I’ve added a bug here:
  https://github.com/w3c/manifest/issues/91
   
  I’ll just note that having link rel=manifest and script type manifest 
  would kinda suck… if we can just have:
   
  * script type=“application/manifest+json” src=“manifest.json”/script
  * script type=“application/manifest+json”{}/script that would be great.
   
  That would be great. Reading the HTML spec, I think we can.  
 I prefer link/meta as the above is pretty verbose and a lot to remember. And 
 using link to link to external manifests just make so much sense.
 But I'll defer to you on this.

I’ll bounce it to HTMLs people and see what they say.

Re: New manifest spec - ready for FPWD?

2013-12-02 Thread Marcos Caceres



On Tuesday, December 3, 2013 at 3:01 PM, Jonas Sicking wrote:

 On Tue, Nov 26, 2013 at 1:02 PM, Marcos Caceres w...@marcosc.com 
 (mailto:w...@marcosc.com) wrote:
  The Editors would appreciate if people take a look and see if you agree 
  with the feature set.
  
  
 When we did outside-of-browser-UI web apps for FirefoxOS we quickly
 found that a lot of developers want to be able to rely on UA-provided
 UI such as the back button.
  
 Yes, the app can detect that it's running standalone and display a
 back button itself. However that was significantly more work than any
 other part of creating a standalone app, which mostly consisted in
 writing a manifest. It's especially a lot of work if you want to try
 to replicate the platform-rendered back button on all platforms.
  
 What I think we should have is something like:
  
 chrome: {
 back: true
 }


Yep, this is currently captured here:
https://github.com/w3c/manifest/issues/76

Those of us working on this still need to investigate FxOS a bit more to see 
what people are using in practice and why (e.g., how much granularity do we 
really need? to the button level “forward”/“back, or can we just say 
“navigation-bar”, etc.). Captured here:  
https://github.com/w3c-webmob/installable-webapps/issues/17  

 If the UA doesn't support any of the properties in the chrome
 section, then the UA should be required to not launch the app in
 standalone mode.

 Yeah that makes sense.  
 I also think that we need a way to put the manifest in-line in the
 main document. In part, technologies tend to be a lot easier to
 understand if you can create a single-file demo. In part, for small
 simple apps, having to separate the manifest into a separate file
 could be annoying and might drive people to stick to the existing
 meta-tags.


Would it suffice to use the API? It’s much simpler than trying to write out 
JSON by hand and wouldn’t require us to create any new special script type, 
etc.   

script
if(“requestBookmark” in navigator){

var appDetails = {name: “Awesome app!”, mode: “standalone”};
navigator.requestBookmark(appDetails).then(happy,sad);
}  
/script

It’s more or less equivalent to making it declarative and easily passes the 
“OMG! that’s so easy!” test :)  

Obviously, devs will still need to continue using a lot of the meta tags for a 
while to support legacy browsers (or any browser that doesn’t implement this).  
  
 I also think the dont-share-cookies-and-stuff thing needs more work
 before it's ready for inclusion.

Yes, totally. It’s just there for discussion.   
 So might be better to drop that for
 FPWD. But I'm fine with keeping it in for now too and dropping it if
 we can't solidify it.
  

I’m happy either way. I’ve been told by lawyer types elsewhere at the W3C that 
it’s best to pack lots of half-baked ideas into an FPWD. Gives those folks a 
better understanding of the impact the standard might have on them (… they will 
have to check again in LC, obviously, but it gives them a head start).

Re: New manifest spec - ready for FPWD?

2013-12-02 Thread Marcos Caceres


On Tuesday, December 3, 2013 at 4:34 PM, Charles McCathie Nevile wrote:  
 On Tue, 03 Dec 2013 06:40:43 +0100, Marcos Caceres w...@marcosc.com 
 (mailto:w...@marcosc.com) wrote:
  
   Yes, the app can detect that it's running standalone and display a
   back button itself. However that was significantly more work than any
   other part of creating a standalone app, which mostly consisted in
   writing a manifest. It's especially a lot of work if you want to try
   to replicate the platform-rendered back button on all platforms.

   What I think we should have is something like:

   chrome: {
   back: true
   }
   
   
   
   
  Yep, this is currently captured here:
  https://github.com/w3c/manifest/issues/76
   
  Those of us working on this still need to investigate FxOS a bit more to  
  see what people are using in practice and why (e.g., how much  
  granularity do we really need? to the button level “forward”/“back, or  
  can we just say “navigation-bar”, etc.). Captured here:
  https://github.com/w3c-webmob/installable-webapps/issues/17
  
  
  
 I'd suggest keeping the functions pretty granular. My navbar include  
 various extension buttons, and my Opera navbar included the rewind  
 function (which I loved). I think we'll set very mixed expectations if we  
 try to make general statements about what browser functionalities are,  
 that will cause more confusion than benefit.
  
 (Unless we want to do that to try and discover exactly what people expect  
 by seeing how much of all the thingz get b0rken).

  
That’s my intention. Mozilla has been shipping this feature for a couple of 
months, so there may be enough data for WebMob IG to make an assessment about 
its usage in the wild (and maybe get an idea of people’s expectations).  
  
  Would it suffice to use the API? It’s much simpler than trying to write  
  out JSON by hand and wouldn’t require us to create any new special  
  script type, etc.
   
  script
  if(“requestBookmark” in navigator){
   
  var appDetails = {name: “Awesome app!”, mode: “standalone”};
  navigator.requestBookmark(appDetails).then(happy,sad);
  }
  /script
   
  It’s more or less equivalent to making it declarative and easily passes  
  the “OMG! that’s so easy!” test :)
  
  
  
 Why wouldn't we use the API *and* allow people to write JSON if they want  
 to? Or is that what you meant?


Yes, that’s what I meant. Sorry I was not clear.  

The choices are:  

1. use a link rel=“manifest” href=“app.json” in the head.
2. call requestBookmark() with no argument (i.e., bookmark this page)

3. call requestBookmark() with a string URL (or URL object) to a manifest 
(i.e., bookmark details are here).  

4. call requestBookmark() with an object (i.e., serialize to JSON).

[manifest] orientation member

2013-11-29 Thread Marcos Caceres

TLDR; orientation is hard. We've temporarily removed it from the spec. We have 
two proposals below.  


Orientation of an application is dependent on the media features of the 
display. For example an application might need to be launched in landscape on 
phones (in order to have sufficient display width), but prefer to be in 
portrait on tablets.

When analyzing applications across various runtimes, we've found evidence that 
such applications are common (e.g., basically any application on the iPhone 
that has an iPad counterpart will be designed to constrain to a particular 
orientation based on the device being used: LinkedIn, Flipboard, GoodReads, 
etc. will all go from portrait-primary on the iPhone to allowing any 
orientation on the iPad. A more extreme example is BBC iPlayer - which supports 
portrait-primary on the iPhone, but both landscape orientations on iPad. The 
same can be seen on Android devices. Unlike native apps, Web Apps should not 
target devices/OS's - they have to be device neutral. 

In order to address the use cases, we currently have two proposals. 

Option 1: Provide a list of orientation sets in the manifest. The user agent 
uses the first one with a matching media query. The order in which the 
orientations are listed by a developer does not imply a preference for setting 
the orientation - it is always left up to the user agent to pick the best 
orientation given, for example, how the user is holding the device. In the 
example below, no orientation is given for widths of 721px or above, so the 
default is used: allowing all orientations supported by the device.

{
orientations: [{
media: max-width: 320px,
supported: [portrait-primary, landscape]
}, {
media: max-width: 720px,
supported: [landscape]
}]
}

In this example, a device with a screen width of 320px or below would start 
either portrait-primary or landscape with the abilty to be flipped 
depending on how the user is holding the device (and OS permitting). A device 
with a screen width of 321px through 720px would request to be launched in 
landscape (leaving it up to the UA to pick either landscape-primary or 
landscape-secondary, while allowing flippability), and a device with a screen 
width of 721px and above would start in any orientation chosen by the UA 
(ideally, one that matches how the user is holding the device).

Option 2: The second proposal is to remove orientation from the manifest and 
use CSS @viewport instead. This would mean:

head
style
/*set it by default to portrait primary for small screens */
@media (max-width: 320px) {
@viewport {
orientation: portrait-primary, landscape;
}
}
/*Tablet, switch to landscape only*/
@media (max-width: 720px) {
@viewport {
orientation: landscape;
}
}

/* similarly on screens with a width of 721px or more, all orientations 
are allowed */
/style
/head

Problem with using @viewport at the moment is that the specification is 
progressing a bit  slowly and no one has implemented the orientation 
descriptor. It also lacks definitions for -primary and -secondary 
contraints, which are important for various applications, and doesn't currently 
allow providing multiple allowed orientations - hopefully the CSS Device 
Adaption spec can align with the Screen Orientation spec.

Re: [screen-orientation] Locking to 'current' orientation

2013-11-26 Thread Marcos Caceres




On Tuesday, 26 November 2013 at 15:16, Mounir Lamouri wrote:

 Hi,
 
 I got some requests from different organizations to add the ability to
 lock to the 'current' orientation in the Screen Orientation API.
 
  From Javascript, that would allow writing
 window.screen.lockOrientation('current');
 instead of
 window.screen.lockOrientation(window.screen.orientation);
 Basically, a syntax sugar.

the one with JavaScript seems more clear to me (as it's more evident that it's 
dynamically derived). current is kinda weird because setting the orientation 
is an async operation, so by the time you work out what current is, it might 
not longer be the current one... so it's kind or a race condition.  
  From the manifest, writing the following
 
 'orientation': 'current',

Apps can have multiple orientations and it appears to be somewhat media query 
dependent. I'm cooking up something different for the manifest but would like 
terms to align.

Re: [screen-orientation] Locking to 'current' orientation

2013-11-26 Thread Marcos Caceres

On Tuesday, 26 November 2013 at 15:30, Kenneth Rohde Christiansen wrote:

hi,

On Tue, Nov 26, 2013 at 4:25 PM, Marcos Caceres w...@marcosc.com
(mailto:w...@marcosc.com) wrote:
On Tuesday, 26 November 2013 at 15:16, Mounir Lamouri wrote:
Hi,

I got some requests from different organizations to add the ability to
lock to the 'current' orientation in the Screen Orientation API.

From Javascript, that would allow writing
window.screen.lockOrientation('current');
instead of
window.screen.lockOrientation(window.screen.orientation);
Basically, a syntax sugar.

current is nice because it works for the manifest as well.
IMHO, it would be confusing to have an app that when you launch it the first
time locks one way... but when you launch it the next time, locks another way.

In the 300 apps we've been cataloguing for orientation [1], there is not a
single instance of that exhibits this behaviour. I've also never personally
seen any app do this on startup.

Mounir, what is the use case for locking to current on startup? Which
applications do you know that exhibit this behaviour?

the one with JavaScript seems more clear to me (as it's more evident that
it's dynamically derived). current is kinda weird because setting the
orientation is an async operation, so by the time you work out what
current is, it might not longer be the current one... so it's kind or a
race condition.

Why? If it rotating at the moment you call it, it could just fail, if
it is not, it could lock immediately. It is no different from using
the window.screen.orientation.

Sure, but it's more about setting expectations. For me personally, using
window.screen.orientation is more explicit about what I want... like:

var current = screen.orientation;
console.log(ok! locking it to:, current );
screen.lockOrientation(current);

current is more like requesting. That's just me tho.

[1]
https://docs.google.com/a/marcosc.com/spreadsheet/ccc?key=0Akv8gJijerFUdFQ4RVNibXNUNElWZU05THJ4NE9BSVE#gid=0

New manifest spec - ready for FPWD?

2013-11-26 Thread Marcos Caceres

Over the last few weeks, a few of us folks in the Web Mob IG have been 
investigating the use cases and requirements for bookmarking web apps to home 
screen. The output of that research  is this living document:
http://w3c-webmob.github.io/installable-webapps/

That (ongoing) research is helping to inform the manifest spec. A bunch of us 
have been working together on IRC, twitter, etc. on a new version of the 
manifest spec:
http://w3c.github.io/manifest/

The Editors would appreciate if people take a look and see if you agree with 
the feature set. 

** Right now, please refrain from bike-shedding! ** 

Unless anyone objects, the Editors would like to request the start of a CFC 
towards publishing a FPWD of the manifest spec. 


-- 
Marcos Caceres

[Manifest] use cases, was Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?

2013-11-01 Thread Marcos Caceres




On Friday, November 1, 2013 at 6:25 AM, Wonsuk Lee wrote:

 Hi. Marcos.
  
 I think one of big benefit with manifest format is we can use hyperlink for 
 that. User can install a web app with manifest format, no need to visit a 
 site. So manifest can provide more smooth way of installation to user. They 
 can install apps via links in blogs, twitter, facebook, extra. What do you 
 think?
I think that use case is fine, but I think it might also be orthogonal to the 
manifest. You could also achieve the same thing by declaring in HTML that a 
link is to an installable application somehow (a@rel=“webapp” or some such).   

I want to be crystal clear - I’m not saying we don’t need the manifest, I just 
think that we need to better understand exactly what bits we need. I’m 
currently undertaking that research and will share it soon so more people can 
contribute to the discussion. Will likely do that as part of Web Mob [1].  


[1] http://www.w3.org/Mobile/IG/

Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?

2013-10-31 Thread Marcos Caceres

On Thursday, October 31, 2013 at 12:51 PM, Arthur Barstow wrote:
 [ My apologies in advance for cross-posting but I think it's needed for  
 this coordination topic. ]
  
 Hi All,
  
 Last June, the Chairs of WebApps and SysApps agreed to allocate a time  
 slot @ TPAC Shenzhen for a joint meeting from 16:00-17:00 on Monday  
 November 11 [1].
  
 The one topic currently identified for that slot is the Manifest spec.
  
 Marcos - would you please summarize the overall `state` of the Manifest  
 spec (f.ex. the status, next steps, blockers, and such)? I would also  
 like to know if you think there are some related issues that could  
 potentially benefit from some meeting time, or if we can use the list  
 server instead.

  
I’m trying to figure out (or get agreement amongst those interested in 
implementing) if we should have a JSON manifest or go with the meta tag 
solution (or both) - this is a blocker. Current steps are for me to investigate 
the solutions and usage on teh Webs.  

No significant work has been done on the spec since it moved over to WebApps.   

I don’t mind if we do it on the list. But if others want me to dial in to 
discuss, I’m ok to do that.  

 All - are there any other topics to discuss?
  


Not from me.  

--  
Marcos Caceres

Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?

2013-10-31 Thread Marcos Caceres

On Thursday, October 31, 2013 at 3:04 PM, Nilsson, Claes1 wrote:

I want to say that we are interested in implementing the JSON manifest and
also to discuss additions to the manifest. Content security policies have
already been mentioned and we are looking at something similar to
http://developer.chrome.com/extensions/contentSecurityPolicy.html, which
allows inclusion of content security policies to support secure hosted apps
by defining schemes (https:) that are allowed to use for whitelisting secure
origins from which scripts should be accepted.

This is orthogonal to the manifest, as web apps can already do this. Adding
this to the manifest would only be sugar to allow developers to tighten the
CSP.
I would also like to better understand what a meta tag solution would mean.

See:
https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html

And:
https://developers.google.com/chrome/mobile/docs/installtohomescreen

So, some standardized thing of the above (without the proprietary prefixes, of
course).

However, as the manifest specification editor Marcos unfortunately is not
able to participate in TPAC I am not sure on the most efficient way to
discuss the manifest, a joint SysApps-WebApps session with Marcos calling in
or a mailing list discussion.

I’m happy to dial in, but would like to know specially what people want to
discuss about it.

My main point is to stress our interest in the manifest specification and
additions to it.

I think it’s more important to understand the use cases, and then we can
evaluate if the manifest is the appropriate place to address those.

Re: [screen-orientation] Seeking status and plans

2013-10-27 Thread Marcos Caceres




On October 27, 2013 at 12:45:26 PM, Arthur Barstow (art.bars...@nokia.com) 
wrote:

On 10/26/13 9:03 AM, ext Kenneth Rohde Christiansen wrote:

 Yes, Tizen and IE11 implements it


Thanks Kenneth.

Marcos - is the following what Mounir means re screen-orientation issues
you raised:

Yes. The TAG was supposed to expand on them, but hasn’t yet. Also, Mounir has 
addressed a bunch already. 

Please create Bugzilla bugs for these issues (if applicable).

I’ll check what is outstanding still and do that.

Re: [gamepad] Seeking status and plans

2013-10-15 Thread Marcos Caceres




On Tuesday, October 15, 2013 at 12:47 PM, Arthur Barstow wrote:

 One reason groups publish a LCWD is to use it as a signal that broader 
 review of the spec is desired, and in this case, perhaps we can ask 
 Marcos to help us reach out to the developer community he mentioned in 
 [Dev].

 
I've pinged the developer, as he works for Moz. I can reach out to a few other 
devs too. If anyone knows folks working with this API, please let me know.

Re: [gamepad] Seeking status and plans

2013-10-15 Thread Marcos Caceres



On Tuesday, October 15, 2013 at 4:01 PM, Ted Mielczarek wrote:

 On 10/14/2013 3:34 PM, Marcos Caceres wrote:
  Hi All, 
  The Gamepad API was briefly discussed at the LXJS conference.
  
  See:
  http://www.youtube.com/watch?v=ekvaKmVfjtct=5m30s
  
  It seems at least one developer is very unhappy with it. 
  
  Have we received any other feedback from developers about it? Has any 
  effort been made to reach out to other developers to get feedback? 
 Thanks for the pointer. I watched that portion of the video and it's not
 very constructive feedback. I'll reach out to him (considering he's a
 coworker) and see if I can find out more specifics.
 
 We heard from quite a few developers while implementing the first draft
 of the API and they were overwhelmingly in favor of the current design.
 I haven't heard much in the way of feedback from developers actually
 testing the implementation we've shipped, so it's possible there are
 issues with it in practice. I'd definitely like to hear more we declare
 things finished.
 


Ok, great. Let me know if I can do anything to help. 

-- 
Marcos Caceres

Re: [gamepad] Seeking status and plans

2013-10-14 Thread Marcos Caceres

Hi All, 
The Gamepad API was briefly discussed at the LXJS conference.

See:
http://www.youtube.com/watch?v=ekvaKmVfjtct=5m30s

It seems at least one developer is very unhappy with it. 

Have we received any other feedback from developers about it? Has any effort 
been made to reach out to other developers to get feedback? 
 
Kind regards,
Marcos 

-- 
Marcos Caceres


On Thursday, October 10, 2013 at 7:12 PM, Ted Mielczarek wrote:

 On 10/2/2013 12:31 PM, Arthur Barstow wrote:
  Hi Ted, Scott,
  
  If any of the data for the Gamepad spec in [PubStatus] is not
  accurate, please provide corrections.
  
  Also, if you have any new information re your plans for the spec -
  last published 29-May-2012 - or the spec's status with respect to
  being feature complete, implementation status, etc., please let us know.
  
  -Thanks, ArtB
  
  [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus
 Hi Art,
 
 Thanks for the nudge! My work on the spec (and the Firefox
 implementation) fell by the wayside for many months, but I found some
 time to work on my implementation recently. We (Mozilla) are shipping a
 very-close-to-spec implementation in Nightly builds, and it's available
 behind a preference in our current release (Firefox 24).
 
 I'd actually like to ship our implementation in release soon, I just
 have a few minor implementation bugs (with significant impact) to fix as
 well as one possible breaking spec change[1]. With those in order I'd be
 pretty happy to ship. We'd be shipping unprefixed, as is our new policy.
 
 It's my understanding that Google has been shipping a prefixed
 implementation that's also pretty close to the spec for some time now,
 but that Scott suffers from the same Gamepad is not really my full-time
 job problem that I do. He'd be more equipped to talk about this than I
 am, certainly.
 
 In terms of feature-completeness I think the spec is basically done.
 Aside from that one breaking change I'd like to make I don't think
 there's anything else we want to address right now that couldn't be done
 in a future release of the spec. We've wanted to keep the scope small
 from the beginning and I think we did okay. It definitely needs some
 more work (mostly polishing of the text, fixing the existing bugs), but
 we could certainly get out a new WD with the most recent text.
 
 -Ted
 
 1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21388

Re: [widgetsapi] reference to WebIDL

2013-10-11 Thread Marcos Caceres

On Friday, October 11, 2013, Arthur Barstow wrote:

 On 7/31/13 10:05 AM, ext Marcos Caceres wrote:

 On Wednesday, July 31, 2013 at 1:07 PM, Yves Lafon wrote:

 Thanks, indeed the CR-PR transition was made with a test suite that was
 linked to this WebIDL reference, and not the other one.

 That said, if you have tests and better, a report for a stricter
 conformance to WebIDL, it would be good to highlight them.

  No need. Let just go to REC and be done please ^_^


 Marcos, Yves - what specific things must be done to move widgets-apis to
 REC?


Update the date and should be good to go?

Re: Regarding: Making the W3C Web SQL Database Specification Active

2013-09-27 Thread Marcos Caceres




On Wednesday, September 25, 2013 at 11:39 PM, Michael Fitchett wrote:

 Dear Members of the W3C Consortium::
 
 Regarding: Making the W3C Web SQL Database Specification Active
 
 I would like to request that you make the W3C Web SQL Database specification 
 active again. The Web SQL Database Specification enables developers to build 
 web-based applications that can store, retrieve, manipulate and query against 
 data on the client machine. This technology is similar to SQLite, Microsoft 
 SQL Server, MySQL, etc. Web SQL combined with Manifest enable developers to 
 build web-based applications that work while offline.
 
 The Web SQL Database specification was on the W3C Recommendation track, but 
 the specification was stopped because Mozilla and Microsoft did not want to 
 implement a specification that lacked proper SQL definition. I know there is 
 a need for both a NoSQL and SQL solution. The two specifications (Web SQL 
 Database and Indexed Database API) that exist to date are acceptable.. 
 However, as stated above, the problem is the lack of definition for SQL. 
 Since lack of definition is the issue, I would like to recommend a remedy. I 
 know SQL experts and great documentation writers who I would gladly hire to 
 further define the Web SQL Database specification and fill in the missing SQL 
 definition. Is this something that would be possible to help revive the 
 specification and get the remaining vendors on board?

I think this ship has sailed, for better or for worst. We have IndexedDB as the 
database solution for the platform. It would be great to get help making 
IndexedDB more usable instead of working on Web SQL. 

Kind regards,
Marcos 
 
-- 
Marcos Caceres

Re: Regarding: Making the W3C Web SQL Database Specification Active

2013-09-27 Thread Marcos Caceres



On Friday, September 27, 2013 at 3:07 PM, pira...@gmail.com wrote:

 I agree with Marcos. Also, I thinks IndexedDB fits better as a
 Javascript database working in a pure object oriented way. I don't
 think WebSQL it's absolutely bad, relational databases usually are
 easier to work with, but a NoSQL one can be more efficient. I would go
 for improve IndexedDB and if so, develop a SQL database on top of it
 (it would only need just the SQL parser) as a javascript library, so
 you could get the best of both worlds and also merge queries and
 results in both ways (SQL and NoSQL) over the same database and data.
 

yeah, that would be nice. Given how low level IDB is, I'd be surprised if 
someone hadn't already tried to do this.  

-- 
Marcos Caceres

Re: [clipboard] typo in WebIDL

2013-09-18 Thread Marcos Caceres





On Wednesday, 18 September 2013 at 20:31, Hallvord Steen wrote:

  So does this imply that someone (i.e. Hallvord :)) needs to move it
  elsewhere?
  
  
  
 Nah, it just means I should be more stringent on pushing out releases and go 
 through the TR process (painful or not) so that the thingy with /TR/ in the 
 URL is as up-to-date as possible. For a spec like clipboard events, which is 
 not changing very much, it should be doable to get it to TR if I find just a 
 little bit more time to polish it.
Ha! If I had a dollar for… just put it GitHub so then you don't need to be the 
only person polishing it :) If people care about the spec, then they can just 
send you PRs.
 For a spec like, say, HTML5, Anne is right that the /TR/ version can be out 
 of date compared to the apparently ever changing editor's draft. For list 
 discussions, editor's draft is a good reference because that's the document 
 that is being changed.
  
 Hope that clears up the confusion :)
  

It won't, as people are still going to end up at the wrong version.

Re: Reminder: TTWF-Shenzhen Nov 9, F2F Meeting Nov 11-12, TP Meeting Nov 13

2013-09-17 Thread Marcos Caceres




On Tuesday, September 17, 2013 at 11:25 AM, James Graham wrote:

 On 13/09/13 14:29, Arthur Barstow wrote:
  Hi All - three threads about TPAC 2013 and WebApps' November 11-12 in
  Shenzhen.
   
  1. WebApps meeting November 11-12:
   
  * You Must register for the meeting
  https://www.w3.org/2002/09/wbs/35125/TPAC2013/
   
  * WebApps meeting page
  http://www.w3.org/wiki/Webapps/November2013Meeting. Input on the
  agenda is of course welcome (but feel free to directly edit this page).
  I have been thinking about setting aside some portion of Tuesday Nov 12
  for test case writing so any comments on that idea are welcome (perhaps
  all of Tuesday afternoon).
  
  
  
 FWIW I think the most productive use of this testing time would be to  
 spend some time getting the group up to speed on how testcase review  
 works and then trying to clear some of the review backlog. The members  
 of the WG are exactly the people who are best placed to review test  
 submissions, but at the moment this is not happening and it is causing  
 problems. Of course I will be happy if people want to spend the time  
 writing tests rather than reviewing them.

Agree… the backlog is getting silly and it's becoming a deterrent for 
submission. More people should be trained to have the ability to review and 
possibly approve tests.   
  
--  
Marcos Caceres

Re: RfC: LCWD of Web Notifications; deadline October 24

2013-09-13 Thread Marcos Caceres




On Thursday, September 12, 2013 at 5:19 PM, Arthur Barstow wrote:

 WebApps - the Web Notification WG asked WebApps to review their 
 September 12 LCWD of Web Notifications:
 
 http://www.w3.org/TR/2013/WD-notifications-20130912/
 
 Individual WG members are encouraged to provide individual feedback.
 
 If anyone in WebApps wants to propose an official WG response, please do 
 so ASAP, in reply to this e-mail so the WG can discuss it.
 
 Comments should be sent to public-web-notificat...@w3.org by October 24.

The link to the Editor's draft seems bad in the published version.

The actual Editor's draft is here, I think:

http://notifications.spec.whatwg.org/

Re: HTML as application manifest format

2013-08-01 Thread Marcos Caceres

Hi Kornel,  
Although I have complete empathy about your criticisms regarding JSON, it is 
actually quite fit for this purpose. Using HTML in the way you describe is 
kinda problematic, in that it could include scripts and other resources: 
basically, one would need to build a DOM to parse out the information - and 
even if scripts where not run, or resources loaded, one would still then need 
to make a special HTML just for this purpose (which would confuse people, as if 
you use HTML you expect to be able to have access to features of the platform). 
We are going to need a custom processor for the JSON format, but at least 
parsing is already done for us (as it was with XML, though sadly it seems that 
devs prefer JSON).   

Thanks anyway for the suggestion and for taking time to think about the 
problem! Hopefully you can continue to help us with the JSON manifest.  

--  
Marcos Caceres


On Thursday, 18 July 2013 at 14:57, Kornel Lesiński wrote:

  
 I'd like to propose using HTML as basis of manifest format, similar in  
 spirit to Web Components imports, e.g.
  
 link rel=manifest import href=/my-app-definition.html
  
 and then my-app-definition.html could contain link, meta or other  
 elements.
  
  
 Rationale:
  
 * while JSON is wonderful for automatic serialization, it's an annoying  
 format when maintained by hand (and manifest seems static and simple  
 enough to be maintained by hand).
  
 - JSON syntax is pedantic about trailing comma. Authors have to be  
 careful when adding new element to end of a list.
  
 - JSON does not support comments. Manifest is a central place of an  
 application, so may end up being modified by many team members, and it's  
 useful to comment why certain properties are the way they are, warn which  
 changes will cause breakage (again…), etc.
  
 * We already have link rel=icon sizes, meta name=description, meta  
 name=application-name that can be reused. Authors already know these  
 and it may be easier to define and understand how meta and manifest  
 properties interact.
  
 * We already have lang  hreflang attributes, so there's no need to invent  
 locales dictionaries.
  
 * It can be inlined naturally, saving a RTT.
  
 * It can be mixed with Web Components allowing applications to define  
 everything in one place if they wish to.
  
 * Simple websites can reuse homepage as their manifest file: link  
 rel=manifest href=/
  
  
  
 Here's HTMLized example from the spec:
 http://www.w3.org/2012/sysapps/manifest/#example-manifest
  
 html lang=en manifest=/cache.manifest
 meta name=name content=The Example App
 meta name=description content=Exciting Open Web development action!
 meta lang=es name=description content=¡Acción abierta emocionante  
 del desarrollo del Web!
 meta name=launch-path content=/
 meta name=version content=1.0
 link rel=icon sizes=16 href=/img/icon_16.png
 link rel=icon sizes=48 href=/img/icon_48.png
 link rel=icon sizes=128 href=/img/icon_128.png
 meta name=author content=Foo Corp.
 link rel=author href=http://example.org/dev;
 link rel=author hreflang=es href=https://example.org/dev/es-ES;
 style
 @viewport {
 min-width: 300px;
 max-width: 600px;
 }
 /style
 meta name=required-features content=touch geolocation webgl
 meta name=permissions:contacts:description content=Required for  
 auto-completion in the share screen
 meta name=permissions:contacts:access content=read
 meta name=fullscreen content=true
 meta name=release_notes:1.0 content=Bugs fixed. New exciting effects.  
 Ready for an official release!
 meta name=release_notes:0.5 content=First alpha version with still  
 some bugs but already fun!
  
  
 When writing this I was surprised how well existing functionality fits  
 (and thus how much NIH can be avoided).
  
 The only bit that didn't seem natural fit was meta for permissions, so  
 maybe a better element needs to be invented for it:
  
 permission for=contacts access=read
 meta name=description content=Required for…
 meta name=description lang=pl content=Wymagane do…
 /permission
  
 or perhaps made generic:
  
 metagroup name=permissions
 metagroup name=contacts
 meta name=access content=read
 meta name=description content=Required for…
 meta name=description lang=pl content=Wymagane do…
 /metagroup
 /metagroup
  
 --  
 regards, Kornel

Re: [widgetsapi] reference to WebIDL

2013-07-31 Thread Marcos Caceres



On Wednesday, July 31, 2013 at 1:07 PM, Yves Lafon wrote:

 Thanks, indeed the CR-PR transition was made with a test suite that was 
 linked to this WebIDL reference, and not the other one.
 
 That said, if you have tests and better, a report for a stricter 
 conformance to WebIDL, it would be good to highlight them.
 

No need. Let just go to REC and be done please ^_^  

-- 
Marcos Caceres

Re: [screen-orientation] Comments from Marcos

2013-07-31 Thread Marcos Caceres

FYI, this is now moved here: 
https://github.com/w3ctag/spec-reviews/blob/master/2013/07/OrientationLock.md

Mounir has already addressed some of the feedback.  

-- 
Marcos Caceres


On Friday, July 26, 2013 at 3:36 PM, Marcos Caceres wrote:

 
 
 On Friday, 26 July 2013 at 12:09, Arthur Barstow wrote:
 
  FYI, Marcos provided some comments on the latest Screen Orientation API 
  ED in https://github.com/w3ctag/spec-reviews/issues/7.
  
  Marcos - thanks for this. 
 No probs :) 
  Is your expectation that followups on your 
  review are made in GH or WebApps' list? (My preference is the list, 
  unless there is some specific `Web Architecture` / TAG issue.)
 
 
 
 The feedback will happen on this list, but first I was going to move 
 everything to a document on GH. Alex said he might also provide some feedback 
 (potentially also other TAG members!). I'm coordinating with Mounir a bit on 
 the review and updating the spec. 
 
 Once we have the text ready, the TAG will send it to public-webapps for 
 discussion. Will take a few more days as about 1/3 of the TAG is at a TC39 
 meeting. 
 
 -- 
 Marcos Caceres

Re: Web Widgets, Where Art Thou?

Hi Daniel, 

On Monday, July 29, 2013 at 8:22 PM, Daniel Buchner wrote:

 FWIW, I ran a dev poll last week: ~95% of respondents

What was the sample size? Who were the developers? Where was the poll run? 

 preferred a simple, separate HTML document specifically for their widget and 
 use all the existing DOM APIs and modules from across the web for things like 
 storage, localization, etc. In fact, of the only 2 respondents opposed to the 
 idea, one fundamentally misunderstood the widget concept and the other 
 accidentally selected the wrong option. Here are some of their qualitative 
 responses:

How did you select the sample of responses you sent us? 
 
Can I have access to the complete questionnaire? I need to check the validity 
and reliability of the questions as well as the overall design of the poll - as 
the ordering of the questions can influence answers as well as how the 
questions are phrased, etc.   

If it's a non-probabilistic sample (as it appears to be), we can't conclude 
anything definitive from it because it's not representative - though it can be 
indicative of something descriptively, but not inferentially. 
 Given the miniscule level of adoption/use of the current widget scheme, and 
 the fact the proposed addition of a lighter declaration via the app manifest 
 wouldn't affect use of the old spec, I'm having trouble understanding why 
 this proposal is facing such stop energy.

Please don't confuse questions for stop energy - the costs of standardization 
(social/monetary) is extremely high - specially so if we don't do it right, so 
there will be a lot of scrutiny on anything being proposed.

Re: [widgetsapi] reference to WebIDL




On Monday, July 29, 2013 at 9:15 PM, Yves Lafon wrote:

 Hi,
 In the PR [1], the text referencing WebIDL is not using one of the three 
 conformance clauses defined in WebIDL [2].
 
 Could
 This specification uses [WebIDL] to specify application programming 
 interfaces. be clarified using one of the proposed wordings from WebIDL?
 (likely 'Conforming IDL Fragments' per reading of the spec).
 Thanks,
 


Sure, I can add that if you think it will be helpful. 

-- 
Marcos Caceres

Re: [widgetsapi] reference to WebIDL




On Tuesday, July 30, 2013 at 2:20 PM, Yves Lafon wrote:

 On Tue, 30 Jul 2013, Marcos Caceres wrote:
 
  
  
  
  On Monday, July 29, 2013 at 9:15 PM, Yves Lafon wrote:
  
   Hi,
   In the PR [1], the text referencing WebIDL is not using one of the three
   conformance clauses defined in WebIDL [2].
   
   Could
   This specification uses [WebIDL] to specify application programming
   interfaces. be clarified using one of the proposed wordings from WebIDL?
   (likely 'Conforming IDL Fragments' per reading of the spec).
   Thanks,
  
  
  
  
  Sure, I can add that if you think it will be helpful.
 
 Yes, that would be helpful (hence the report), thanks.

Done. Spec now sez:
Implementations that use ECMAScript to implement the APIs defined in this 
specification must implement them in a manner consistent with the ECMAScript 
Bindings defined in the Web IDL specification [WebIDL], as this specification 
uses that specification and terminology.

 

-- 
Marcos Caceres

Re: [widgetsapi] reference to WebIDL