Re: [fileapi] Pull Request on GitHub

2016-08-16 Thread Marcos Caceres
On August 16, 2016 at 6:31:31 PM, Zhen Zhang (izgz...@gmail.com) wrote:
> Hi,
>
> I have a PR on GitHub regarding some issues of wording in current File API 
> spec: https://github.com/w3c/FileAPI/pull/42
> , but nobody ever responded me there.
> I wonder if I should discuss the patch somewhere else?

It seems that no one has touched that API for about 8 months.

Marijn, are you still editing that document? I guess Jonas won't be,
but not sure about Arun.



RE: Quick update on WebIDL "Level 1"

2016-07-10 Thread Marcos Caceres
On July 9, 2016 at 6:24:56 AM, Domenic Denicola (d...@domenic.me) wrote:
> From: Travis Leithead [mailto:travis.leith...@microsoft.com]
>
> > The purpose of the “Level 1” document is to serve as a stable reference for 
> > W3C specs that
> link to WebIDL. It contains a subset of the WebIDL syntax that is considered 
> stable (as
> verified by interoperable tests). Implementations should not use the Level 1 
> document
> as a guide, but instead track changes to the editors draft. We expect to 
> follow-up Level
> 1 with a Level 2 as additional editor’s draft syntax and behavior stabilizes, 
> are implemented
> as part of other specs, and shown to be interoperable.
>
> Why is it acceptable for specs to reference a version of Web IDL that nobody 
> should implement?

This is a totally valid question, but we've had this debate 1001
times. Perhaps a better question is: how can we get patent protection
(making this subset of WebIDL royalty free for society), but without
harming the ecosystem by confusing implementers and developers by
publishing on the "/TRash" space (as most of us now unfortunately
referring to it).

We need a way to clearly indicate that, for a subset of documents,
RECs on TR represent a royalty free set of ideas (as kindly and
honorably granted by the W3C Membership) - and should only be referred
to by patent lawyers and government officials. That it's for those
groups should be stated and promoted proudly, not disparagingly. And,
that implementers should be looking at the living document instead.
The value of TR need not be diminished - in fact: it should be
correctly used to published the documents that enshrine the royalty
free status of particular specifications.

Perhaps we need a new space just for documents that represent and
agree to set of royalty free ideas? (i..e, if it's a REC, it does into
this new space - and gets clearly marked for the appropriate target
audience, which is not implementers or developers - but patent lawyers
and government officials)...

I think we've also had this debate 10001 times too... but we need to
do something folks, as the division between the forks and the reality
of how web specs are developed is hurting everyone :(

Kind regards,
Marcos



[manifest] Status

2015-10-23 Thread Marcos Caceres
(please cc me if you want a response from me. I don't subscribe to *any* 
mailing lists anymore.)

On October 22, 2015 at 6:32:44 PM, Arthur Barstow (art.bars...@gmail.com) wrote:
> what,  if anything, is blocking the spec's progression;

No blockers. Just waiting on implementations. 

> what, if anything,  do you need from the group/staff/chairs to help the spec 
> make progress; 

Not much... reviews, comments, PRs etc. are always nice tho. 

> what is the status and plan for the test suite; what is the rough timeline  
> for the next publication; 

The spec is auto published whenever we commit stuff. However, if you mean, 
"when will it progress to CR?", I would hope sometime next year. Chrome already 
implements the spec, and Gecko too... we should hopefully see it being used in 
Gecko-based products in Q1 2015 (fingers crossed!).  

> what data in [PubStatus] needs to be updated;  
> etc.

None. 



Re: [admin] Web Platform WG is the new WebApps

2015-10-12 Thread Marcos Caceres




On October 12, 2015 at 8:23:25 AM, Arthur Barstow (art.bars...@gmail.com) wrote:
> Hi All,
>  
> On October 10, the consortium formerly started the Web Platform WG
> [Charter] thus terminating WebApps.
>  
> My expectation is this change will have little to no impact on any work
> started in WebApps. That said, please note the charter indicates
> WebApps' less developed specs (f.ex. the Editing specs) need some
> "incubation" before they may proceed on the Recommendation track.
> However, that was effectively how WebApps operated so I don't see this
> as a change - a spec still needs implementation commitments before
> advancing to the later Recommendation stages.

For incubation, members are welcomed to bring their specs Web Incubator CG:
http://github.com/wicg

The WICG can help members get specs into shape and connect them with developers 
and other implementers. It's a fast, IPR friendly way, to get ideas road-tested 
before formal standardization. 

> The WPWG has its own Github repo [Github] and the group will not use
> W3C's wiki. (Only a small number of WebApps' Editors actively use W3C
> wiki documents (primarily IDB v2 features, Pointer Lock v2 features,
> Gamepad v2 features, and D3E) and I will work with those Editors to move
> their relevant wiki information to their spec's repo.)

Please please please (please!), don't use a single repository as a dumpling 
ground for spec - it makes it impossible for people to follow individual work 
items, file bugs, etc.. Please use separate repositories for each work item.

I would suggest maybe making your own organization on Github, and then managing 
your specs through that. Again, see:
http://github.com/wicg
 





Re: Stability of Widget DigSig

2015-05-08 Thread Marcos Caceres
On Friday, May 8, 2015, Anders Rundgren anders.rundgren@gmail.com
wrote:

 On 2015-05-08 14:50, Arthur Barstow wrote:

 On 5/8/15 8:47 AM, Anders Rundgren wrote:

 On 2015-05-08 14:32, Frederick Hirsch wrote:

 no objection, the referenced document is a Recommendation, isn't it?

 http://www.w3.org/TR/widgets-digsig/


 This seems to be a rather theoretical discussion:

 https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/widget


 FYI, the usage of widget in widgets-digsig is not at all related to
 the use of widget in the MDN resource reference above.


 Just for my understanding, is the W3C Widget TR generally supported then?


Yes. For example, PhoneGap/Cordova which is used to target every platform.



 Anders



 -AB






Re: Stability of Widget DigSig

2015-05-08 Thread Marcos Caceres
On Friday, May 8, 2015, Arthur Barstow art.bars...@gmail.com wrote:

 [ + Marcos and Frederick ]

 Hi Andrew,

 The group stopped working on XML Digital Signature for Widgets several
 years ago and there is no plan to resume work (except to process errata as
 required).

 Marcos, Frederick - this spec's namespace document includes the following
 statement:

 [[
 http://www.w3.org/ns/widgets-digsig/

 Implementers should be aware that this document is not stable.
 ]]

 Any objections from you or anyone else to remove this statement?


None. It's stable.





 -Thanks, ArtB

 On 5/7/15 5:55 AM, Andrew Twigger wrote:


 ATSC and CEA are developing standards that include the ability to
 download digital signed applications. Their current specifications
 reference the W3C Recommendation for XML Digital Signature for Widgets (18
 April 2013).  However, the associated Widgets Digital Signature Namespace (
 http://www.w3.org/ns/widgets-digsig/) contains a statement that
 “Implementers should be aware that this document is not stable.” which has
 raised questions as to the stability and suitability of referencing Widget
 DigSig.  The alternative would be to reference XAdES with the C and T forms
 to allow for the inclusion of timestamp and certificate revocation
 information which are not included in Widget DigSig.

 I would be pleased to receive any information regarding the stability of
 Widget DigSig and whether referencing XAdES would provide a better
 alternative.

 Thank-you,

 Andrew Twigger





Re: Permissions API vs local APIs

2015-05-06 Thread Marcos Caceres



On May 6, 2015 at 2:38:06 PM, Mounir Lamouri (mou...@lamouri.fr) wrote:
   Marcos|Mounir, do you two have any thoughts on this?
  
 I agree with Jonas: we should delegate the check to the Permissions  
 API. However, I don't see how I can enforce that if the Push API doesn't  
 want to. I would be more than happy to have the spec specify the
 PermssionDescriptor for Push, FWIW.

What Mounir said. I guess we can also help add this to Push via a PR.



Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

2014-09-25 Thread Marcos Caceres




On September 18, 2014 at 6:53:38 AM, Mounir Lamouri (mou...@lamouri.fr) wrote:
 On Tue, 16 Sep 2014, at 08:28, Jonas Sicking wrote:
  I think it's likely to result in many implementation bugs if we rely
  on this being defined buried inside an algorithm rather than at least
  mentioned at the definition of the property.
  
 I think it's good feedback. I could probably make this more visible.
 Would you mind opening an issue marked as Enhancement and may go with
 a proposal of what you believe would be easier to find. I don't want to
 have you do the editor work but given that the problem isn't that the
 information is missing but that it is not well exposed, fresh eyes would
 be better to help with that ;)

Filed: 
https://github.com/w3c/screen-orientation/issues/79





Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

2014-09-24 Thread Marcos Caceres




On September 24, 2014 at 8:43:10 AM, Anne van Kesteren (ann...@annevk.nl) wrote:
 On Tue, Sep 23, 2014 at 2:33 AM, Arthur Barstow wrote:
  Anne - would you please confirm if your comments have been adequately 
  addressed?
  
 I disagree with the prioritization of creating a snapshot over
 defining (even to an approximation) what implementers actually have to
 do. I said as much on GitHub and IRC, but it seems my comments have
 been deferred nonetheless.

Anne is, unfortunately, right. There is no point in putting anything on /TR/ 
until the W3C fixes the ability to have documents sync with what is on GH. 
Otherwise, we will just find ourselves here again in a few months. The 
stability of the document doesn't have any correlation to it appearing on the 
/TR/ space, and hence, it would misguided for us to push for its publication 
until the snapshots issue is fixed. 

 



PSA: publishing new WD of URL spec

2014-09-11 Thread Marcos Caceres
On Thursday, September 11, 2014, Robin Berjon ro...@w3.org
javascript:_e(%7B%7D,'cvml','ro...@w3.org'); wrote:

 On 10/09/2014 18:48 , Marcos Caceres wrote:

 This is a formal objection to publication of this specification.
 The rationale for the objection was already sent to the wwwprocess list.


 Would you lift yours if Domenic lifted his?


Only once I have clear answers to the following (and see actual proof). I
know you already addressed some of this in your previous email to Dominic.

1. How will the spec be kept up to date? i.e., what technical means will be
put in place by the w3c to assure that the latest is always on TR.

2. How will the W3C determine when a spec is ready for LC/CR?

3. How will the W3C cope with changes occurring to the living document
after CR? (See Boris' emails)

4. Will the W3C prevent search engines from finding the copy/pasted
document? Particularly any static snapshots.

5. What indicators (e.g., the big red box) will be put into the spec to
indicate that the WHATWG version is the canonical version?

6. Out of respect for both the Editor and the WHATWG as a standards
consortium, how will the W3C attribute authorship of the documents and well
as show that the document originates from the WHATWG?

(Ps: Your claim about 12 step programs have been debunked by science. See
[1] :))

[1]
http://www.npr.org/2014/03/23/291405829/with-sobering-science-doctor-debunks-12-step-recovery


Re: PSA: publishing new WD of URL spec

2014-09-10 Thread Marcos Caceres



On September 10, 2014 at 12:43:02 PM, Arthur Barstow (art.bars...@gmail.com) 
wrote:
 [ Sorry for the cross-posting but this is about a joint WD publication
 between WebApps and TAG. ]
  
 This is heads-up (aka PublicServiceAnnoucement) about the intent to
 publish a new WD of the URL spec (on or around Sept 16) using this ED as
 the basis:
  
 As previously agree, and codified in WebApps' current [Charter], the WD
 will be published jointly by WebApps and the TAG.
  
 I realize some people do not support W3C publishing the URL spec, so as
 reminder - as defined in WebApps' off-topic discussion policy
 ([OffTopic]) - if anyone has any _process-type_ comments, concerns,
 etc. about this publication - please send that feedback to the
 public-w3process list [w3process]. Please do _not_ send such feedback to
 public-webapps nor www-tag.

This is a formal objection to publication of this specification. 

The rationale for the objection was already sent to the wwwprocess list. 



Re: Proposal for a Permissions API

2014-09-05 Thread Marcos Caceres
On Friday, September 5, 2014, Kostiainen, Anssi anssi.kostiai...@intel.com
wrote:

 On 04 Sep 2014, at 23:18, Marcos Caceres mar...@marcosc.com
 javascript:; wrote:

  Absolutely, we should be addressing them at the API level.

 I guess you mean each API should address this in a way that fits the
 design of the particular API the best?


Correct. Sorry if I wasn't clear.



 And something like permissions.js could then be used to abstract away the
 differences and provide an API similar to that proposed by Mounir?


I would hope we wouldn't need that, but sure. It's a risk (reality?) that
we end up with inconsistencies across APIs.



  For instance, adding a way to determine if the permission has been
 granted in Geo without actually needing to use the API.

 It seems as if Mounir’s proposal addresses exactly this requirement, but
 not at the “[Geolocation] API level”.


Which I'm personally not a huge fan of.



 Thanks,

 -Anssi


Re: Proposal for a Permissions API

2014-09-04 Thread Marcos Caceres


On September 4, 2014 at 4:14:57 PM, Florian Bösch (pya...@gmail.com) wrote:
 This is an issue to use, for a user.
  
 - http://codeflow.org/issues/permissions.html
 - http://codeflow.org/issues/permissions.jpg

This sets up an unrealistic straw-man. Are there any real sites that would need 
to show all of the above all at the same time? 

 - In firefox it's a succession of popup
  
 It's also an issue to use for a developer, because the semantics and
 methods for requesting, getting, being denied and managing permissions
 differ. Sometimes permissions aren't query able.

It is more worthwhile addressing the above, so to avoid the sequence of 
pop-ups. 

 It's my stated opinion that ignoring these issue will not make them go
 away. And delaying addressing UX and consistency issues just contributes to
 a proliferation of bad UX and inconsistent and difficult to use APIs.

Absolutely, we should be addressing them at the API level. For instance, adding 
a way to determine if the permission has been granted in Geo without actually 
needing to use the API. 





Re: Proposal for a Permissions API

2014-09-04 Thread Marcos Caceres


--  
Marcos Caceres


On September 4, 2014 at 4:24:56 PM, Florian Bösch (pya...@gmail.com) wrote:
 On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres wrote:
  
  This sets up an unrealistic straw-man. Are there any real sites that would
  need to show all of the above all at the same time?
  
 Let's say you're writing a video editor, you'd like:
  
 - To get access to the locations API so that you can geotag the videos
 - Get access to the notifications API so that you can inform the user
 when rendering has finished.
 - Get user media to capture material
 - Put a window in fullscreen (perhaps on a second monitor) or to view
 footage without other decorations

A developer can then have a Let's get started! screen, where they explain why 
they need each feature before they request it.  

 Of course it's a bit contrived, but it's an example of where we're steering
 to. APIs don't stop being introduced as of today, and some years down the
 road, I'm sure more APIs that require permissions will be introduced, which
 increases the likelihood of moving such an example from the realm of
 unlikely to pretty common.

Absolutely. I the above, a dev could still ask for each API as needed. Like:

Ok, let's get your camera working. We need you to grant us access to it. 

Get user media 

Great! will you want to geotag your videos? If so, confirm the prompt. You can 
always turn this off in the app later.

geolocation 

(or a checkbox-like option in their app - this can be enabled during recording 
even!) 

fullscreen is just a button in the UI: works just like it does today. 

None of the above e require all permissions to be asked at once. 

There is a great article that discusses this approach:
http://techcrunch.com/2014/04/04/the-right-way-to-ask-users-for-ios-permissions/





Re: RfC: pre-LC version of Screen Orientation; deadline August 18

2014-08-14 Thread Marcos Caceres



On August 14, 2014 at 3:23:23 AM, Dominique Hazael-Massieux (d...@w3.org) wrote:
  HTH,

It does! thank you. I've filed a bug for each on GH. 

https://github.com/w3c/screen-orientation/issues/

Hope to fix 'em up soon! 



Re: My requirements for the Manifest for Web Applications

2014-08-07 Thread Marcos Caceres
Hi Mark, 

On August 6, 2014 at 5:22:01 AM, Mark Taylor (mark.s...@base88.com) wrote:
 My main feedback/concerns is that it is currently as inherently inflexible as 
 the cache  
 manifest file, rendering it useless in many use cases:
  
 Specification assumes that the entire app is self contained and requires a 
 consistent  
 display mode

True for v1 :( Trying to fix this in v2.  

 Most web apps will have both internal links (to other parts of the web app), 
 and external  
 links to elements outside of the web app.

True. 

 External links often do not contain a route back  
 to the web app, so the preferred behaviour is either for it to 
a) launch in the web browser,  

True.

 or b) launch within the app, with a navigation element allowing users to 
 return to the 
 web app.

True. I guess by navigation element you mean: 

1. iframe
2. window.open()
3. a href= target=_blank 

 Traditionally this has been hacked into web apps using an iFrame. But there 
 are so many  
 inherent problems with iFrames on mobile. Viewport settings permeate through 
 to iframe  
 document (e.g. pinch to zoom setting), width/height, scrolling, gestures, 
 cross browser  
 issues etc etc etc, the list goes on. So I don’t see this as a 
 desirable/suitable solution.  

Ok, these are either browser bugs or developer bugs tho - so, we have to assume 
those will be fixed. But you are correct nonetheless.  

 I would like to see this specification address this common use case.

So, part of this is addressed by the scope property.

See: 
https://github.com/w3c-webmob/installable-webapps/issues/48 

tl;dr: it defines what URLs are part of the app (and implies which are not). So:

```JSON
{
  scope: //foo.com/myapp/
}
```

So, everything in the https://foo/com/myapp/; directory is my app. Open 
everything else in the browser.

If you navigate from foo.com/myapp/, to bar.com, then bar.com will have its own 
display mode (and you'll be jumping to a new app, if bar.com is installed). If 
bar.com doesn't have a display mode, then bar.com is just shown with browser 
chrome.  

 Specification assumes a simple application in one orientation
  
 Many web apps include mixed content, often from third-parties. In some cases, 
 the content  
 is delivered in mixed orientations.

Interesting, would like to see some concrete examples of this. 

  Imagine a list of widgets, each widget that can be  
 launched may be better suited in a different orientation. And so it makes 
 sense to allow  
 the web app to define the orientation at any given moment in time, not just 
 on initial load.  

This is already supported. As the spec says:

Once the web application is running, other means can change the orientation of 
a top-level browsing context (such as via [SCREEN-ORIENTATION] API). 

Thus, you can change the orientation to whatever the device supports after. 
Unlocking returns you back to what is defined in the manifest.

The more serious problem the spec has is that it assumes one particular 
orientation for all screen sizes. See:
https://github.com/w3c/manifest/issues/168

Basically, we need to be able to do this to support tablets/phones properly:

{
  orientation: any,
  some-condition-device-width-or-watevas: {
      orientation: portrait
  }
}


 Specification assumes combined use of cache manifest file?
  
 I can’t see any reference to a splash screen / loading sequence control.

True about splash screen. We are still debating if we want to support that. 
See: 
https://github.com/w3c/manifest/issues/9


 This is often  
 the most difficult part of a web application. Different media is required 
 based on many  
 variables including device, screen size, browser, locale, language, other 
 more specific  
 variables. The only way to meet these requirements is to use Javascript, and 
 once all  
 of these required resources are identified and sourced can we display the app.

Correct. We are working on various other specs to deal with that. For example, 
Resource Hints:
https://igrigorik.github.io/resource-hints/

And Resource Priorities:
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html

There are other specs in the works too... like Client Hints:
https://github.com/igrigorik/http-client-hints 

 The inherent inflexibilities in the cache manifest mechanism mean that it is 
 not used  
 by anyone i know. If your app is large, the cache manifest is too inflexible. 
 If your app  
 is small, it’s too small to need/benefit from a cache manifest. I would like 
 to see this  
 area addressed. How can the web developer ensure a smooth/seamless loading 
 sequence  
 for his/her dynamic web app when updated content is required.

My friend:D you are in luck! let me introduce you to the service worker. It's 
everything you asked for and so much more:
https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md

In the manifest, you will be able to declare a service worker using the 
service_worker property:

Re: Screen orientation API feedback

2014-08-05 Thread Marcos Caceres


On August 5, 2014 at 6:33:46 AM, Anne van Kesteren (ann...@annevk.nl) wrote:

snip

This is great feedback - thanks for this Anne! I've captured each of the issues 
you raised in the bug tracker on GH [1] (and cc'ed you on them). We will 
address them in the next few days. 

https://github.com/w3c/screen-orientation/issues/ 





RE: pre-LC version of Screen Orientation; deadline August 18

2014-08-04 Thread Marcos Caceres


On August 4, 2014 at 8:36:21 AM, Paul Cotton (paul.cot...@microsoft.com) wrote:
  Section 6 [1] refers to bug 25310 [2] and suggests that the HTML5  
 sandboxing material could be changed. The current specification  
 refers to HTML5.0 [3] which is currently in its last CR period  
 before progressing to Proposed Recommendation.
  
 If a change is required in the HTML specification then it is more  
 likely that this would occur in HTML 5.1 [4].


Thanks Paul. Will be sure to address this before LC. 

-- 
Marcos Caceres





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

2014-05-28 Thread Marcos Caceres
On Wednesday, May 28, 2014, Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, May 28, 2014 at 12:20 PM, Mounir Lamouri 
 mou...@lamouri.frjavascript:;
 wrote:
  Then, it might make sense to have the manifest same origin as the web
  page because obviously making start_url same origin as the manifest
  would be moot if the manifest doesn't have to be same origin with the
  web page ;)

 I think we have a winner.


Yep! Will update the spec. Thanks for all the good input.




 --
 http://annevankesteren.nl/




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

2014-05-27 Thread Marcos Caceres

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

2014-05-27 Thread Marcos Caceres


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

2014-05-27 Thread Marcos Caceres


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

2014-05-27 Thread Marcos Caceres


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

2014-05-27 Thread Marcos Caceres
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?

2013-12-03 Thread Marcos Caceres


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?

2013-12-03 Thread Marcos Caceres


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?

2013-12-03 Thread Marcos Caceres



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?

2013-12-03 Thread Marcos Caceres


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?

2013-12-03 Thread Marcos Caceres
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?

2013-12-03 Thread Marcos Caceres



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?

2013-07-30 Thread Marcos Caceres
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

2013-07-30 Thread Marcos Caceres



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

2013-07-30 Thread Marcos Caceres



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

2013-07-30 Thread Marcos Caceres


On Tuesday, July 30, 2013 at 5:46 PM, Marcos Caceres wrote:

 
 
 
 On Tuesday, July 30, 2013 at 2:20 PM, Yves Lafon wrote:
  
  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.
 


Whoops. Seems I misunderstood. The spec actually now says:
The IDL blocks in this specification are conforming IDL fragments as defined 
by the WebIDL specification. 









Re: [screen-orientation] Comments from Marcos

2013-07-26 Thread Marcos Caceres


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?

2013-07-23 Thread Marcos Caceres



On Monday, July 22, 2013 at 11:54 PM, Daniel Buchner wrote:

 To clarify, I am proposing that we make a simple app manifest entry the only 
 requirement for widget declaration: widget: { launch_path: ... }. The issue 
 with viewMode (https://github.com/w3c/manifest/issues/22), is that it 
 hard-binds a widget's launch URL to the app's launch URL, forever tying the 
 widget to the full app. I'd like to give devs the option to provide a 
 completely different launch path for widgets, if they choose. As for the 
 finer points of widget declaration, why force developers to generate two 
 separate files that regurgitate much of the same information? -- this looks 
 a lot more complex than adding a launch path to an existing file and a few 
 media queries for styling: http://www.w3.org/TR/2009/WD-widgets-reqs-20090430/


The thing here is that you are adding an explicit role or type for an 
application (by declaring widget:). We view the representation of the 
application as being more responsive than that through a view mode. What you 
propose explicitly encourages two different applications to be created, instead 
of a single one that adapts to the context in which it's being displayed. 
Again, take a look at how Opera's speed dial was making use of view modes.

However, I can see how splitting the two application classes into different 
resources can be appealing at first… but it goes against the principles of 
responsive design: it would be like telling people to build a separate desktop 
site and mobile site, instead of responsibly adapting the content to fit the 
layout. Using view mode media queries works naturally with the way modern web 
applications are designed today - they fit naturally into just being another 
break point.  

   while taking advantage of natural synergies that result from reusing
   a common base.
   
   
  I think I agree, but can we be explicit about the things we think we're 
  getting?
  
 Many mobile apps include widgets, and users are beginning to think: Hey, I 
 wonder if this app has a widget?; some users even seek out apps that provide 
 a companion widget in addition to the app itself. Using an app manifest for 
 packaging is easier on developers, and aligns with user perception of the 
 output.
Sure, that might be fine. In the case of W3C Widgets, one simply said:

widget viewmodes = floating/

Which indicated to the UA that floating mode was supported (i.e., you can 
widgetized it on a home screen).   

In hosted apps, we are proposing to have the same thing. See:  
https://github.com/w3c/manifest/issues/22


{
…
viewModes: [fullscreen, maximized]
...
}


  

  For example, many browsers now use some form of JSON to write a manifest 
  that (other than the syntax) is almost identical to the XML packaging used 
  for widgets. And as JC noted there are actually numerous systems using the 
  XML Packaging and Configuration.
   
   I see widgets as a web page (perhaps the same page as a full app,if the 
   dev chooses) with near-zero additional, cognitive overhead.
   
  I'm afraid I have no idea what this means in practice.  
  
 I was referring to the choice (detailed above) a developer has to use the app 
 launch path, or an different URL, as their widget path, and to do so via a 
 common declaration vehicle. That simplifies the declaration side. On the code 
 side, I would stay away from adding any mechanisms (other than display 
 helpers, like widget-specific media queries) to the widget context - the 
 message: just use the same APIs you would use for any other app/page. With 
 today's web, are these APIs really necessary? -- 
 http://www.w3.org/TR/widgets-apis/
Yes, they are totally required unless you want developers do deal with i18n 
things themselves. It takes away the pain of finding out which localized values 
the app is using from the manifest.   

   - I believe we should retool efforts in this area to focus on sharing the 
   app packaging vehicle and reducing complexity to near-zero (besides 
   things like widget-specific media queries)
   
  This is where it is critical to know what you think is near-zero 
  complexity. Having seen a couple of systems deployed based on JSON 
  packaging (Google and Mozilla), and a bunch of them based on the current 
  XML Widget Packaging, I personally find the latter far less complex. But I 
  realise not everyone thinks like I do.
  
 If you asked the average client-side web developer, who lives primarily in 
 HTML, CSS, and JS, I would bet a trillion dollar coin that the overwhelming 
 majority prefer JSON for description, packaging, and data transmission - 
 consider: web app manifests, NPM, Bower, and nearly every client-consumed 
 web-service API launched in the last 4 years.  
Sure. Again, being biased, I don't think we had a single complaint from devs 
about the format being XML while I was at Opera (we built an extremely robust 
parsing algorithm based on HTML5's parser, which made it much easier to work 
with 

Re: Web Widgets, Where Art Thou?

2013-07-23 Thread Marcos Caceres



On Tuesday, July 23, 2013 at 1:56 PM, JC Verdié wrote:

 Hi Marcos,
  
 Obviously as you point out, digsig were a nightmare. May be it was us,  
 but the spec was not really straightforward to implement and we found it  
 difficult.

As lead Editor, I'm really very sorry about this - I strive to make specs as 
accessible to everyone as possible, and I'm sorry if what was written was 
confusing/difficult to interpret. If there are bits that should be clarified, 
then please let me know and I'll see what I can do to improve it.  

 On widgets itself, our main issue came from our own constraints (TV  
 browser with no chrome ui), it lead to some inconsistencies to handle to  
 overall UX. For instance, the impossibility to handle user events on a  
 global level so that buttons used for exit or any immediate actions are  
 not caught up by the widget, but by the root application. We hacked in  
 several ways to achieve this but it was a disappointing point.

Right, but this is a platform/system issue (how events traverse through the 
system). This was outside the scope of the work.
 I guess what I'm saying is we missed a wider view of how widgets are  
 handled, run, die, and interact with the browser itself.
  
 Despite this, it's been very useful to us and we have deployed many  
 solutions based on it, so anything that keeps compatibility with widgets  
 is good to us
  

Happy to hear.  




Re: Web Widgets, Where Art Thou?

2013-07-23 Thread Marcos Caceres


On Tuesday, July 23, 2013 at 2:29 PM, JC Verdié wrote:

   
  Right, but this is a platform/system issue (how events traverse through the 
  system). This was outside the scope of the work.
  
 Agreed. But it's been a hurdle and I don't know how many companies just  
 gave up about widgets because of this.

I think this will come up if one moves to using hosted-web apps in TV like 
environments too (sounds like an overall architectural problem for the Web 
platform). If you can describe the problem more fully, I think we should 
absolutely look into this and then see where it needs to be fixed. When 
replying, please change the subject of the email appropriately.  




Re: Web Widgets, Where Art Thou?

2013-07-23 Thread Marcos Caceres


On Tuesday, July 23, 2013 at 4:12 PM, Marcos Caceres wrote:

 So, I guess the thing would be to try to quickly dig up a few of the old 
 sites that are using view mode media feature targeted at presto and see if 
 they have a separate page or if they use the same page. That should at least 
 be indicative of who is more right?

I tried looking for some sites, but failed. You are free to do a search also. 
Otherwise, we will need to find some other way to move forward on this. 
 
-- 
Marcos Caceres






Re: Web Widgets, Where Art Thou?

2013-07-23 Thread Marcos Caceres



On Tuesday, July 23, 2013 at 3:06 PM, Daniel Buchner wrote:

  
 On Tue, Jul 23, 2013 at 4:44 AM, Marcos Caceres w...@marcosc.com 
 (mailto:w...@marcosc.com) wrote:
   
  On Monday, July 22, 2013 at 11:54 PM, Daniel Buchner wrote:
   
   To clarify, I am proposing that we make a simple app manifest entry the 
   only requirement for widget declaration: widget: { launch_path: ... }. 
   The issue with viewMode (https://github.com/w3c/manifest/issues/22), is 
   that it hard-binds a widget's launch URL to the app's launch URL, forever 
   tying the widget to the full app. I'd like to give devs the option to 
   provide a completely different launch path for widgets, if they choose. 
   As for the finer points of widget declaration, why force developers to 
   generate two separate files that regurgitate much of the same 
   information? -- this looks a lot more complex than adding a launch path 
   to an existing file and a few media queries for styling: 
   http://www.w3.org/TR/2009/WD-widgets-reqs-20090430/
   
   
  The thing here is that you are adding an explicit role or type for an 
  application (by declaring widget:). We view the representation of the 
  application as being more responsive than that through a view mode. What 
  you propose explicitly encourages two different applications to be created, 
  instead of a single one that adapts to the context in which it's being 
  displayed. Again, take a look at how Opera's speed dial was making use of 
  view modes.
   
  However, I can see how splitting the two application classes into different 
  resources can be appealing at first… but it goes against the principles of 
  responsive design: it would be like telling people to build a separate 
  desktop site and mobile site, instead of responsibly adapting the content 
  to fit the layout. Using view mode media queries works naturally with the 
  way modern web applications are designed today - they fit naturally into 
  just being another break point.
  
 In theory, responsive design seems like the clear answer for widgets - I love 
 making my apps responsive so they work for phone/tablet/desktop etc. However, 
 there are issues with the widget case. In phone/tablet/desktop views, apps 
 still use most or all of an app's data/features, the major differences tend 
 to be in DOM arrangement and style of the content they present. It's easy to 
 think of widgets as a logical next level to that - but that can devolve into 
 the impractical quickly.  
I guess here we would need to see actual data. Like I already mentioned, while 
I was at Opera, we did not see any issues with partners/devs who made use of 
this feature.  
 Widgets are (generally) by nature, small presentations of a sliver of app 
 content displayed in a minimalist fashion that update a user to the state of 
 something at-a-glance. Also, many widgets can be in active view at once - 
 consider a home screen with nine 1x1 widgets. If each widget was itself the 
 full app, with the addition of responsive styles, it would be a recipe for 
 crippling performance. Imagine nine Gmail tabs on a screen, nine Facebooks, 
 etc.

Memory management is a shared responsibility between the developer and the UA. 
You can make both widgets and apps that perform badly in the same way that you 
can make apps that can run effectively as widgets. In other words, putting 
things in a separate file won't save a device from a bad developer.   
  
 The obvious retort will be: well devs are smart, they'll proactively 
 structure their app, have tiered checks for assets, and place conditions 
 throughout their code to ensure they are catching the *very different* widget 
 use-case everywhere in their app -- I'd assert that this is not practical, 
 and in many cases, devs would welcome a clean document they knew was intended 
 specifically for their widget.

The belief that this is not practical has to be supported with data. The same 
argument could have been made about mobile websites (and in many cases it's 
true - some organizations have opted to make a mobile variant of their site). 
The question remains, can a solution that doesn't require additional changes to 
what we have be used to achieve having different documents for this? If not, 
then yes - we might need to add a mechanism as you suggest - but I don't think 
we've exhausted all options here.  
  
  
 while taking advantage of natural synergies that result from reusing
 a common base.
 
 
 
I think I agree, but can we be explicit about the things we think we're 
getting?

   Many mobile apps include widgets, and users are beginning to think: Hey, 
   I wonder if this app has a widget?; some users even seek out apps that 
   provide a companion widget in addition to the app itself. Using an app 
   manifest for packaging is easier on developers, and aligns with user 
   perception of the output.
  Sure, that might be fine. In the case of W3C Widgets, one simply said

Re: Web Widgets, Where Art Thou?

2013-07-22 Thread Marcos Caceres


On Monday, July 22, 2013 at 9:16 AM, JC Verdié wrote:

 Hi Daniel
  
 While widgets were (unfortunately) not widely adopted, a few companies  
 (including mine) are using it and it does the job for many simple  
 issues. It's true that the complexity of the spec vs the service  
 provided was not really a good deal.

As editor, I'm interested about the complexity aspect of widgets (aside from 
digital signatures, what other complexities have been faced?). Can you provide 
some more details about that? Obviously, we want to avoid similar issues with 
the packaged apps and hosted apps efforts.   
  







Re: Kickoff application manifest work

2013-06-18 Thread Marcos Caceres
Ping… anyone wanna work with me on this?


On Tuesday, 14 May 2013 at 11:47, Marcos Caceres wrote:

 While we transition the application manifest spec from SysApps to WebApps, 
 I'd like to kick off discussion by encouraging people to either discuss the 
 current proposal here or over on GitHub.  
  
 The current proposal can be found here:  
 http://manifest.sysapps.org/
  
 Repo is here:
 https://github.com/sysapps/manifest
  
 Things that we need to discuss:  
  
 * what's the problem we are trying to solve? (scope for the work).
 * what actual manifest properties are useful? are any missing?  
 * do any members need to be refactored to better meet the use cases?  
 * how do we associate a manifest with a web page?  
 * More open issues: https://github.com/sysapps/manifest/issues
  
 Following in the footsteps of Navigation Controller and DOM Futures, it would 
 be ideal to have a core group of individuals helping out with this effort. If 
 you want to be part of a core team, please let me know and I can add you on 
 GitHub (or just add your self to watch the repository on 
 https://github.com/sysapps/manifest) and file bugs/ask questions as you see 
 fit.  
  
 If you want to discuss the proposal directly with me, I'm marcosc IRC on both 
 freenode (#whatwg) and w3c (#webapps).  
  
 Kind regards,
 Marcos  
  
  
 --  
 Marcos Caceres






Re: A very preliminary draft of a URL spec

2013-05-21 Thread Marcos Caceres


On Tuesday, May 21, 2013 at 10:12 AM, Stian Soiland-Reyes wrote:

 If you go for standardizing an API for dealing with URIs (probably a
 good idea if you go down this route) - then I would recommend being
 inspired by the API of Java's java.net.URI
 
 http://docs.oracle.com/javase/7/docs/api/java/net/class-use/URI.html
We (the Web community) have had pretty bad experiences trying to apply Java's 
API idioms on the Web (e.g., the gawd awful DOM APIs). The Java URI also 
suffers from a lot of the same issues: great if you are working in Java, not so 
great for JS.

Far more JS idiomatic examples:

http://medialize.github.io/URI.js/
http://nodejs.org/api/url.html







Kickoff application manifest work

2013-05-14 Thread Marcos Caceres
While we transition the application manifest spec from SysApps to WebApps, I'd 
like to kick off discussion by encouraging people to either discuss the current 
proposal here or over on GitHub. 

The current proposal can be found here: 
http://manifest.sysapps.org/

Repo is here:
https://github.com/sysapps/manifest

Things that we need to discuss: 

* what's the problem we are trying to solve? (scope for the work).
* what actual manifest properties are useful? are any missing? 
* do any members need to be refactored to better meet the use cases? 
* how do we associate a manifest with a web page? 
* More open issues: https://github.com/sysapps/manifest/issues

Following in the footsteps of Navigation Controller and DOM Futures, it would 
be ideal to have a core group of individuals helping out with this effort. If 
you want to be part of a core team, please let me know and I can add you on 
GitHub (or just add your self to watch the repository on 
https://github.com/sysapps/manifest) and file bugs/ask questions as you see 
fit. 

If you want to discuss the proposal directly with me, I'm marcosc IRC on both 
freenode (#whatwg) and w3c (#webapps). 

Kind regards,
Marcos 


-- 
Marcos Caceres






  1   2   3   4   5   6   7   8   9   10   >