Re: Art steps down - thank you for everything
So long, Art, and thanks for all the fish. --tobie On Thu, 28 Jan 2016, at 16:45, Chaals McCathie Nevile wrote: > Hi folks, > > as you may have noticed, Art has resigned as a co-chair of the Web > Platform group. He began chairing the Web Application Formats group about > a decade ago, became the leading co-chair when it merged with Web APIs to > become the Web Apps working group, and was instrumental in making the > transition from Web Apps to the Web Platform Group. (He also chaired > various other W3C groups in that time). > > I've been very privileged to work with Art on the webapps group for so > many years - as many of you know, without him it would have been a much > poorer group, and run much less smoothly. He did a great deal of work for > the group throughout his time as co-chair, efficiently, reliably, and > quietly. > > Now we are three co-chairs, we will work between us to fill Art's shoes. > It won't be easy. > > Thanks Art for everything you've done for the group for so long. > > Good luck, and I hope to see you around. > > Chaals > > -- > Charles McCathie Nevile - web standards - CTO Office, Yandex > cha...@yandex-team.ru - - - Find more at http://yandex.com >
Re: Custom Elements: is=
On Sat, Jun 13, 2015, at 18:52, Alice Boxhall wrote: Doc in progress at https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Type-Extensions.md Sent a pull request your way[1]. --tobie --- [1]: https://github.com/w3c/webcomponents/pull/117
Re: Custom Elements: is=
On Fri, Jun 12, 2015, at 19:41, Léonie Watson wrote: Is there a succinct explanation of why the is= syntax is disliked? The info on the WHATWG wiki explains where is= breaks, but doesn’t offer much on the syntax issue [1]. Esthetics aside, the main issue it is takes the concept of inheritance developers are familiar with and stands it on its head. The idea with inheritance is that you build a new object and it happens to inherit from another one, so for example: my-button extends=button makes a lot of sense. Clearly, you're building a new element that extends the capabilities of the existing button object. With the is= syntax, however, what it is you're doing isn't clear at all: button is=my-button What's the message here? Oh this is just a button. Oh wait no it's not, it's a my-button. But does it actually inherit from button? Mmm. Not clear from the syntax. Further more, what about when you add a bunch of extra attributes in there: button value=45 class=button button-large is=my-button id=cta / It becomes hard to spot that this element isn't actually a traditional button. Things get easily lost when scanning code. I'm also concerned developers will mistakenly write: my-button is=button As it is much closer in form to what they want to achieve (see the extend=parent syntax I wrote earlier). So in summary it's ugly, has a high cognitive load, doesn't express the developers intent (actually even expresses the opposite), is hard to spot when reading code, and is error prone. Hope this helps. :) --tobie
Re: [IndexedDB] link to Editor's draft is a 404
On Wed, Feb 4, 2015 at 8:37 AM, Tobie Langel tobie.lan...@gmail.com wrote: On Wed, Feb 4, 2015 at 3:35 AM, Michael[tm] Smith m...@w3.org wrote: Arthur Barstow art.bars...@gmail.com, 2015-02-02 08:47 -0500: Archived-At: http://www.w3.org/mid/54cf7fe0.6090...@gmail.com On 2/2/15 7:14 AM, Tobie Langel wrote: Would recommend redirecting to the ED of the next version of the spec. That makes sense to me. Yup, sorry about thatーI forgot a step when we migrated the repos. But I've now set up the redirects and things should be working as expected. If not lemme know. Thanks! But it looks like you redirected it to the GitHub repo rather than the spec itself: $ curl -I https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html HTTP/1.1 302 Found Date: Wed, 04 Feb 2015 07:34:26 GMT Server: Apache/2.2.16 (Debian) Location: http://w3c.github.io/IndexedDB/ Vary: Accept-Encoding Content-Type: text/html; charset=iso-8859-1 Mind fixing that? Ignore the above. Everything is working properly. I'm an idiot. Sorry for the noise. --tobie
Re: [IndexedDB] link to Editor's draft is a 404
On Wed, Feb 4, 2015 at 3:35 AM, Michael[tm] Smith m...@w3.org wrote: Arthur Barstow art.bars...@gmail.com, 2015-02-02 08:47 -0500: Archived-At: http://www.w3.org/mid/54cf7fe0.6090...@gmail.com On 2/2/15 7:14 AM, Tobie Langel wrote: Would recommend redirecting to the ED of the next version of the spec. That makes sense to me. Yup, sorry about thatーI forgot a step when we migrated the repos. But I've now set up the redirects and things should be working as expected. If not lemme know. Thanks! But it looks like you redirected it to the GitHub repo rather than the spec itself: $ curl -I https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html HTTP/1.1 302 Found Date: Wed, 04 Feb 2015 07:34:26 GMT Server: Apache/2.2.16 (Debian) Location: http://w3c.github.io/IndexedDB/ Vary: Accept-Encoding Content-Type: text/html; charset=iso-8859-1 Mind fixing that? Thanks again, --tobie
[IndexedDB] link to Editor's draft is a 404
Hi, Heads-up that the link to the Editor's Draft of the IndexedDB spec is now a 404. Not sure whether that is on purpose or an accident. Would recommend redirecting to the ED of the next version of the spec. Thanks, --tobie
Re: [editing] Responsive Input Terminology
On Thu, Dec 11, 2014 at 8:47 PM, Ben Peters ben.pet...@microsoft.com wrote: There has been a lot of debate [1][2] about the correct name for device independent events [3] as a concept*. We have considered Intention Events, Command Events, and Action Events among others. I believe we now have a good name for them- Responsive Input Events. The reason for this name is that it is the corollary to Responsive Layout: for input instead of output. Together these two concepts can help form the basis of Responsive Design going forward. I'd be extremely wary of naming a category of DOM events after a term that has a high buzz factor. Now I'm not suggesting RWD itself is a fad, but that the term itself will slowly fade away as the technology becomes mainstream and the focus moves beyond (or elsewhere), e.g. on card-based design[VINH], context-aware design[SPOOL], or adaptive web design[FROST]. In five years, Responsive Input Events will sounds as weird as HTML5 App Events would today. --tobie --- [VINH]: http://www.subtraction.com/2014/08/26/what-is-a-card/ [SPOOL]: http://www.uie.com/articles/context_aware/ [FROST]: http://bradfrost.com/blog/post/the-principles-of-adaptive-design/
Re: [editing] Responsive Input Terminology
On Fri, Dec 12, 2014 at 1:00 PM, Arthur Barstow art.bars...@gmail.com wrote: What is your counter-proposal? Heh. Fair enough, I guess. :) These seem related to what Java calls semantic events [JAVADOC], so I'd give that a try to see if it fits the model. If not, would abstract events or simply high-level events work? Sorry if these have already been discussed and dismissed (haven't had much time to look through the archives, tbh). --tobie --- [JAVADOC]: https://docs.oracle.com/javase/tutorial/uiswing/events/generalrules.html#twokinds
[service-workers] SW event syntax and Cache API
Hi folks, Couple of issues I've bumped into recently while looking at Service Workers more closely. 1. e.respondWith + e.waitUntil. I feel like those are strong code smells we haven't found the right design for yet. I have a suggestion for waitUntil[1]. None yet for respondWith, but plan to tinker with it in the upcoming weeks. I like Anne's express.js inspired suggestions. 2. Cache.add feels misnamed and/or heavily magic. - I'm not sure handling atomic fetches should happen at this layer. - Doing so shouldn't be too difficult to build given the right primitives (fetch + Promise.all) - It's unclear whether the promise returned by Cache.add is resolved with responseArray or with void (WebIDL reads Promiseany, algo doesn't mention resolving ith responseArray). Same issue for Cache.put. 3. It should be a lot easier to prime the cache after a cache miss. Currently the solutions I've tried are less than desirable[2]. Would like something like this[3] to work. Not sure what the best medium is to discuss/help with these issues. Maybe in person? LMK. --tobie --- [1]: https://github.com/slightlyoff/ServiceWorker/issues/256#issuecomment-47878042 [2]: https://gist.github.com/tobie/0689c5dda8f6d49d500d#file-gistfile2-js-L25-L32 [3]: https://gist.github.com/tobie/113280d3b3db714dc199#file-gistfile1-js-L27
Re: Fetch API
On Thu, May 29, 2014 at 4:58 PM, Marcos mar...@marcosc.com wrote:
enum RequestMode { same-origin, tainted cross-origin, CORS,
CORS-with-forced-preflight };
I think these are badly named (even though they use the names used in HTML
and Fetch). It's going to be annoying to type these out for developers.
I would change them to:
enum RequestMode { same-origin, cors, cors-tainted, cors-preflight
};
I like those better.
We want consistency with lowercasing or uppercasing cors/CORS in enums,
though.
--tobie
[push-api] No clear mention of privacy implication of sending data through push service
Hi, Was just skimming through the Push API spec. I'm aware that no payload is sent with push message for privacy reasons (as push service is most certainly a third party), but that isn't mentioned in the spec. I suggest adding a non-normative note that: 1. describes the reasons of this architectural decision (the privacy concern), 2. describes a possible work-around (xhr request to App Server to get the data), 3. eventually mentions some of the benefits (e.g. payload can be always up to date even if notification is stale). Secondly, the very helpful sequence diagram contained in the spec could be amended like so (to hint at this work-around): ++ ++ ++ ++ | webapp | | user | | push | | app | || | agent | | server | | server | ++ ++ ++ ++ || | | |-register--| | | || | | | (user accepts) | | || | | ||-setup push service-| | || | | |---success-| | | || | | |--activate service with PushService attributes-| || | | || |--push notification-| || | per service API | || | | || (match to user agent) | || | | ||--push notification--| | || per service protocol | | || | | |(match to webapp) | | || | | |---system message--| | | || | | |--XHR GET Request---| || | | |---Payload--| || | | Best, --tobie
Re: Testing Pointer Lock
On Thursday, October 3, 2013 at 11:04 PM, Charles McCathie Nevile wrote: On Thu, 03 Oct 2013 22:50:21 +0100, Vincent Scheib sch...@google.com (mailto:sch...@google.com) wrote: Pointer lock is tricky to automate tests for. Consider some examples: - Upon lock, no pointer should be visible. That might be tested using a reftest[1]. - A user gesture is required to lock when not in fullscreen. That might be tested using a WebDriver test (we haven't agreed on a way to write or run those yet). - Transitioning to fullscreen and pointer lock then exiting fullscreen should maintain pointer lock. (User gesture required to enter fullscreen) This might also be feasible using WebDriver. - While locked, moving the mouse indefinitely in any direction must continue to provide non zero movementX/Y values. That could be automated using WebDriver. I'm considering starting some pointer lock tests with testharness.js. The only solution I see is to provide instructions in many tests for manual actions and observations. If there's interest on your side to explore the WebDriver-based option, I'm happy to start a discussion on how those tests should be written in the relevant channel (public-test-in...@w3.org), but that really depends on what your main goal with this effort is (move the spec along the REC track, or improve interop) and what your timeline's like. If you want to ship the spec quickly, going the manual route with testharness.js is probably your best option. You'll always be able to revisit later (you could even do both in parallel). --tobie --- [1]: http://testthewebforward.org/docs/reftests.html
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
On Thursday, July 4, 2013 at 4:20 PM, Mounir Lamouri wrote: On 24/04/13 11:13, Tobie Langel wrote: While some of the original use cases required dynamically modifying orientation lock (e.g. the Game within a game experience[5]), key use cases simply require a declarative, page-wide setting, as described by David Bruant on the WHAT WG mailing list[6]. (First, I am so sorry for the huge delay...) Np. Thanks for getting back to me on this. :) I think we should not use CSS Device Adaptation to set the orientation. I am actually not sure how well CSS would handle media queries to have rules based on the orientation and setting the orientation from CSS. Wouldn't we risk to end up in an infinite loop? Seems this is handled in section 7 of the spec[a]. Honestly, I don't have enough background in this area to assess how well. In addition, with the current work of having manifest files applying to regular web pages [1], we can hope that web pages that want to have a specific orientation could simply use a manifest file. I think using a manifest could be a good solution for that kind of use cases [2]. I don't really have an opinion here, except I'd love to see implementors converge on a solution and implement it. :) This said, how do you expect the orientation to work when set declaratively? Should the declaration be set as soon as authorised (on Firefox Android, that means being fullscreen [3])? It might provide an odd user experience. An alternative would be to only fulfil the declarative orientation if the page is allowed to set it at load time. If authorization is required, I'd imagine the app would be launched fullscreen with a modal dialog / overlay requiring user authorization. If denied the browser would fallback the regular display mode (with chrome). Best, --tobie --- [a]: http://dev.w3.org/csswg/css-device-adapt/#media-queries
Re: Kickoff application manifest work
On Wednesday, June 19, 2013 at 6:56 AM, Anne van Kesteren wrote: It might be though that maybe we should put the boundary for applications on the web on the origin level. It would certainly be extremely convenient and allow for a whole bunch of simplifications. I feel the same way. It would be interesting to list the downsides of this approach to see if the tradeoff is worth making. --tobie
Re: Kickoff application manifest work
On Wednesday, June 19, 2013 at 8:35 AM, Anne van Kesteren wrote: On Wed, Jun 19, 2013 at 3:13 PM, Tobie Langel to...@w3.org (mailto:to...@w3.org) wrote: It would be interesting to list the downsides of this approach to see if the tradeoff is worth making. Downsides: * More DNS queries. * More effort to deploy a simple one page application. * Incompatible with existing web application infrastructure. Unresolved either way: * Finding the navigation controller for a given URL * Finding the event worker for a given URL * Finding the page/window associated with an end-user notification So other than better sandboxing it would not solve all that much and potentially be a hindrance for people trying to adapt new features. Thanks. That really helps. --tobie
[shadow-dom] spec markup
Hi folks, Attempting to parse the shadow-dom spec to gather test coverage data. Turns out the markup significantly departs from other specs. Not sure if the spec is edited using a special tool or by hand. Regardless, adding a className of idl to WebIDL blocks would go a long way. Think that's doable? Thanks, --tobie
Re: [shadow-dom] spec markup
Done: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22254. Thanks. --tobie On Tuesday, June 4, 2013 at 12:00 AM, Dimitri Glazkov wrote: On Mon, Jun 3, 2013 at 9:34 PM, Tobie Langel tobie.lan...@gmail.com (mailto:tobie.lan...@gmail.com) wrote: Regardless, adding a className of idl to WebIDL blocks would go a long way. Think that's doable? Sure thing! Please file a bug so we don't forget. It's easy -- click the File a bug button in the top right corner of the spec. :DG
Re: [File Api]: How to Test input type=file ?
On Thursday, May 30, 2013 at 3:18 PM, Fabian Raetz wrote: I'm searching a way to unit test file uploads but i can't find any solutions to that problem on the web. That's work in the scope of the Browser Testing and Tools WG. Afaik, there's ongoing discussions on how to best support that, but there's nothing in the Webdriver spec[2] yet. --tobie --- [1]: http://www.w3.org/testing/browser/ [2]: http://www.w3.org/TR/webdriver/
[screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
Hi, Screen orientation lock is critical to a whole set of mobile games (especially those which rely on the accelerometer to control the gameplay). It's great that it is now considered for specification and implementation. I had collected some use cases a while back[1], some of which led to use-cases[2], requirements[3] and suggestions[4] in the Coremob report. While some of the original use cases required dynamically modifying orientation lock (e.g. the Game within a game experience[5]), key use cases simply require a declarative, page-wide setting, as described by David Bruant on the WHAT WG mailing list[6]. The current proposal[7] only targets the dynamic setting through a JS API and leaves the more declarative approach to other specs[8]. It mentions the Web Application Manifest Format and Management APIs[9] and CSS Device Adaptation[10]. Now, CSS Device Adaptation, as used in the Viewport META element[11] is ubiquitous on mobile. It seems like a natural fit for a declarative orientation lock, so much so that it's already specified in the spec[12]. However, the syntax to dynamically read or modify the Viewport META element is cumbersome and error prone (you're talking document.cookie-like string splitting/concatenation with unspecified separators, etc.[12]). Instead of providing a dedicated API to cater strictly for the screen orientation lock use case, wouldn't it make more sense and be more consistent to provide a CSSOM[14] API for the whole Viewport META element, and use matchMedia listeners[15] instead of orientationchange events? This would allow declarative setting through the Viewport META element, dynamic modification through the CSSOM API, and event handling through the matchMedia interface, all of which are well known and commonly used by developers. Thanks for your time. --tobie --- [1]: http://tobie.github.io/ORIENTATIONLOCK-UCR/index.html [2]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#play-a-2d-game [3]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#req-orientation-lock [4]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#screen-orientation [5]: http://tobie.github.io/ORIENTATIONLOCK-UCR/index.html#game-within-a-game-experience [6]: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/0078.html [7]: https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html [8]: https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html#declarative-orientation-locking [9]: https://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html [10]: http://dev.w3.org/csswg/css-device-adapt/ [11]: http://dev.w3.org/csswg/css-device-adapt/#viewport-meta [12]: http://dev.w3.org/csswg/css-device-adapt/#the-lsquoorientationrsquo-descriptor [13]: https://developer.mozilla.org/en-US/docs/Mobile/Viewport_meta_tag#Background [14]: http://dev.w3.org/csswg/cssom/ [15]: http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
On Wednesday, April 24, 2013 at 1:00 PM, Kenneth Rohde Christiansen wrote: Hi there, CSS Device Adaptation should hopefully be enabled on all browsers (desktop and mobile) unlike the viewport meta tag, which cannot be enabled on desktop browsers easily as many desktop sites actually comes with a viewport meta tag which is ignored. Having that not being ignored breaks the sites. *Sigh* MS already enabled a subset of the CSS Device Adaptation spec in IE10 desktop. I support adding some CSSOM API's for CSS Device Adaptation, but I would not do so for the viewport meta tag, which has its share of issues. Understandably given the above. Outside of the IE10 implementation mentioned above, have other implementors committed to implement the CSS part of CSS Device Adaptation? I would also like the CSS Device Adaptation, orientation lock and Fullscreen to integrate. Especially it would be nice to click on an element in portrait and have it go fullscreen in landscape mode and lock, all with a nice animation. Agreed. These should work together as much as possible. Thanks for your comments. --tobie
Re: [admin] Testing and GitHub login names
X-posting to public-infra for those that have missed the conversation going on in WebApps on the subject of test review within the web-platform-tests repository on GitHub. On Tuesday, April 23, 2013 at 9:55 AM, James Graham wrote: On 04/23/2013 08:43 AM, Robin Berjon wrote: On 22/04/2013 13:12 , James Graham wrote:On Mon, 22 Apr 2013, Arthur Barstow wrote:The only thing that we ask is that pull requests not be merged by whoever made the request. Is this to prevent the `fox guarding the chicken coop`, so to speak? If a test facilitator submits tests (i.e. makes a PR) and everyonethat reviews them says they are OK, it seems like the facilitator should be able to do the merge. Yes, my view is that Robin is trying to enforce the wrong condition here. No, I'm just operating under different assumptions. As I said before, ifsomeone wants to review without having push/merge powers, it's perfectlyokay. I don't even think we need a convention for it (at this point). Ido however consider that this is an open project, so that whoeverreviews tests can be granted push/merge power. Why? Because the alternative is this: you get an accepted comment fromsomeone on a PR. Either you trust that person, in which case she couldhave merge powers; or you don't, in which case you have to review thereview to check that it's okay. Either way, we're better off making thatdecision at the capability assignment level since it only happens once per person. FWIW I'm used to a situation in which the opposite approach is generally taken; that is a reviewer is responsible for reviewing, but the submitter is responsible for doing the final integration of their changes.Here, the final integration consists of clicking the merge button followed by clicking the are you sure? button. Hardly a place where you'll catch a mistake. Generally, OS projects using the GH workflow tend to leave integration to the reviewers, as they're the only ones able to have access to merging content to the canonical repo. I suggest we do the same and grant collaborator access to anyone who has had one contribution merged in the canonical repo OR is a WG member. This is based on the Pull Request Hack system[1] described by Felix Geisendörfer. Here's a short FAQ around this proposal: 1. Who can review an merge content? Repo collaborators. 2. Who can become a repo collaborator? Anyone that fulfills either one of the below conditions: a) be a member of any WG which has tests in the web-platform-tests repo, OR b) have had at least one contribution to web-platform-tests be merged in the main repo. 3. How do you become a repo collaborator? Right now, ask Robin or myself. We're hoping to get tooling to simplify this in the near future. 4. Who is responsible for checking the CLA has been signed? The reviewer when merging a contribution (if the contributor is not a repo collaborator, no point if he/she is). We'll have tooling to help with this. --tobie --- [1]: http://felixge.de/2013/03/11/the-pull-request-hack.html
Re: [admin] Testing and GitHub login names
On Tuesday, April 23, 2013 at 9:55 AM, James Graham wrote: On 04/23/2013 08:43 AM, Robin Berjon wrote: On 22/04/2013 13:12 , James Graham wrote: On Mon, 22 Apr 2013, Arthur Barstow wrote: The only thing that we ask is that pull requests not be merged by whoever made the request. Is this to prevent the `fox guarding the chicken coop`, so to speak? If a test facilitator submits tests (i.e. makes a PR) and everyone that reviews them says they are OK, it seems like the facilitator should be able to do the merge. Yes, my view is that Robin is trying to enforce the wrong condition here. No, I'm just operating under different assumptions. As I said before, if someone wants to review without having push/merge powers, it's perfectly okay. I don't even think we need a convention for it (at this point). I do however consider that this is an open project, so that whoever reviews tests can be granted push/merge power. Why? Because the alternative is this: you get an accepted comment from someone on a PR. Either you trust that person, in which case she could have merge powers; or you don't, in which case you have to review the review to check that it's okay. Either way, we're better off making that decision at the capability assignment level since it only happens once per person. FWIW I'm used to a situation in which the opposite approach is generally taken; that is a reviewer is responsible for reviewing, but the submitter is responsible for doing the final integration of their changes. Here, the final integration consists of clicking the merge button followed by clicking the are you sure? button. Hardly a place where you'll catch a mistake. Generally, OS projects using the GH workflow tend to leave integration to the reviewers, as they're the only ones able to have access to merging content to the canonical repo. I suggest we do the same and grant collaborator access to anyone who has had one contribution merged in the canonical repo OR is a WG member. This is based on the Pull Request Hack system[1] described by Felix Geisendörfer. Here's a short FAQ around this proposal: 1. Who can review an merge content? Repo collaborators. 2. Who can become a repo collaborator? Anyone that fulfills either one of the below conditions: a) be a member of any WG which has tests in the web-platform-tests repo, OR b) have had at least one contribution to web-platform-tests be merged in the main repo. 3. How do you become a repo collaborator? Right now, ask Robin or myself. We're hoping to get tooling to simplify this in the near future. 4. Who is responsible for checking the CLA has been signed? The reviewer when merging a contribution (if the contributor is not a repo collaborator, no point if he/she is). We'll have tooling to help with this. --tobie --- [1]: http://felixge.de/2013/03/11/the-pull-request-hack.html
Re: Fixing appcache: a proposal to get us started
On Tuesday, March 26, 2013 at 12:12 PM, Bjoern Hoehrmann wrote: (I take it the fixing-appcache mailing list has since been closed in http://www.w3.org/community/fixing-appcache/ favour of discussion here.) Yes, see: http://lists.w3.org/Archives/Public/public-fixing-appcache/2013Feb/0005.html --tobie
Re: IndexedDB, what were the issues? How do we stop it from happening again?
On Friday, March 15, 2013 at 4:11 AM, Jarred Nicholls wrote: On Thu, Mar 14, 2013 at 10:19 PM, Alex Russell slightly...@google.com (mailto:slightly...@google.com) wrote: On Thu, Mar 14, 2013 at 6:36 PM, Glenn Maynard gl...@zewt.org wrote: Workers exist explicitly to allow you to do expensive synchronous stuff without janking the main thread. (Often, the expensive synchronous stuff will just be a bunch of calculations, so you don't have to explicitly break it up into setTimeout-able chunks.) The entire reason for most async (all?) APIs is thus irrelevant in a Worker, and it may be a good idea to provide sync versions, or do something else that negates the annoyance of dealing with async code. My *first* approach to this annoyance would be to start adding some async primitives to the platform that don't suck so hard; e.g., Futures/Promises. +1. Libraries cover that fairly well; albeit I think we all would enjoy such things to be first-class citizens of the platform. I've seen some good looking implementations and some decent control flow libraries. I use https://github.com/caolan/async a lot in node projects. Saying that you should do something does not imply that doubling up on API surface area for a corner-case is the right solution. I agree. It may have seemed like a good and simple idea at first - well intentioned for sure - but upon reflection we have to admit it's sloppy, a greater surface area to maintain, and the antithesis of DRY. It's not what I personally would expect from a modern, quality JS api, and I'm probably not the only web dev to share that feeling. At the risk of making a blanketed statement using anecdotal evidence, I would claim that overindulgence from modern libraries in existence today has raised the expectations of web devs in how the web platform architects new apis. Node.js comes with sync and async APIs (for good reasons) and I haven't heard anyone complain that this wasn't DRY. --tobie
Re: IndexedDB, what were the issues? How do we stop it from happening again?
On Thursday, March 14, 2013 at 7:54 PM, Alex Russell wrote: On Wednesday, March 6, 2013, Tobie Langel wrote: Sync APIs are useful to do I/O inside of a Worker. I don't understand why that's true. Workers have a message-oriented API that's inherently async. They can get back to their caller whenevs. What's the motivator for needing this? There's no need per se. Sync API are easier to handle, and given you're already out of the UI thread, blocking in that context isn't much of an issue. They're also critical for data consistency in some scenarios, e.g. updating the database after a successful xhr request when a worker is about to be terminated. Unload-catching is a known bug in much o the web platform. Why would we enable it here? Nevermind. The Web Worker termination process (now?) says scripts get aborted anyway. --tobie
Re: IndexedDB, what were the issues? How do we stop it from happening again?
On Wednesday, March 6, 2013 at 5:51 PM, Jarred Nicholls wrote: This is an entirely different conversation though. I don't know the answer to why sync interfaces are there and expected, except that some would argue that it makes the code easier to read/write for some devs. Since this is mirrored throughout other platform APIs, I wouldn't count this as a fault in IDB specifically. Sync APIs are useful to do I/O inside of a Worker. They're also critical for data consistency in some scenarios, e.g. updating the database after a successful xhr request when a worker is about to be terminated. --tobie
Re: [webcomponents] Making the shadow root an Element
On Monday, February 18, 2013 at 10:12 PM, Dimitri Glazkov wrote: On Mon, Feb 18, 2013 at 1:01 PM, Anne van Kesteren ann...@annevk.nl (mailto:ann...@annevk.nl) wrote: On Mon, Feb 18, 2013 at 8:57 PM, Dimitri Glazkov dglaz...@google.com (mailto:dglaz...@google.com) wrote: Still unclear. Are you saying this: if we have API members on ShadowRoot that aren't on DocumentFragment, then ShadowRoot should not be a DocumentFragment? No. all I'm saying that we made a conscious choice not to have innerHTML on DocumentFragment and that therefore we should not introduce it on ShadowRoot either (until we either revisit the DocumentFragment decision or someone shows that decision is not applicable to ShadowRoot somehow). Ah, got it. Well... The innerHTML is necessary for ShadowRoot. It's not a matter of API taste or consistency. If you look at any shadow DOM code today (however experimental), you'll see most of it using innerHTML to populate the shadow tree. FWIW, one of the the most common use of doc fragment implies inserting a div into it to be able to use the div's innerHTML. For example, in jQuery: https://github.com/jquery/jquery/blob/master/src/manipulation.js#L452-L457 --tobie
Re: DRM nonsense in HTML
On 2/12/13 5:05 PM, Florian Bösch pya...@gmail.com wrote: DRM does not belong into HTML, nor into any kind of W3C standard. [...] This is the wrong mailing list. You might want to look at http://www.w3.org/html/wg/lists/. --tobie
Re: Allow ... centralized dialog up front
On 2/2/13 12:16 PM, Florian Bösch pya...@gmail.com wrote: Usually games (especially 3D applications) would like to get capabilities that they can use out of the way up front so they don't have to care about it later on. This is not an either / or problem. First, lets clarify that the granting of a permission (and for how long it is granted) can be dependent on a variety of factors defined by the user and or the user agent and is out of control of the developer and of any spec body to standardize. Different User Agents will behave differently depending on what market they target. Different users will react differently depending on their security and privacy thresholds, the trust relationship they have with the URL they're visiting, etc. The permission to carry out a certain task on the user's behalf (such as taking a picture) might change at any time for any number of reasons (such as the device's camera being unplugged or broken). There's only one solution to this: code defensively. APIs that require specific user permissions are designed so that the user's can be prompted every time the API is required to be used. Whether the device chooses to do so or not is implementation specific (and again, depends on external factors such as user settings, etc.). Generally, this solution has proven to be both flexible and secure. Handling permissions up front has three unwanted effects: 1. Users tend to not read the upfront permission settings that much thus often accidentally granting more privileges than they would like to. That's a security and privacy issue. 2. Users tend to reject apps which have too many permission requests or permission requests that feel out of scoop of the app. Eg. A chess game asking for permissions to use the camera is rather off-putting until you realize it uses it to take snapshots of a chess-board and suggest next moves. This awareness generally comes with app usage, or because you're aware of the feature set of the app through information provided by the developer (marketing) or third parties (reviews, friends, etc.). 3. Upfront permission lists rapidly get out of sync with real application requirements. What happens then? In fact, Upfront permission requirement only really makes sense when the user has already built a relationship of trust with the developer of the application or trusts a third party that has means of enforcing good behavior from the app developer (e.g. through an app store system). A hybrid approach that considers upfront permissions as hints of permission requirements to come offers the best of both worlds. It allows developers to ask permissions upfront for things that make sense given the context (e.g. a camera app would require camera access upfront) and at a later stage for features that might not be so obviously connected to the app's main use case or present a bigger risk for the user. It also allows the User Agent to treat these hints as it wishes, e.g. by prompting the user upfront, by automatically granting some permissions using various kinds of heuristics, or by deciding to only prompt the user when the feature is actually going to be used. It is worth noting that the developer will still need to code defensively for such an approach, as the user (or user agent) might very well not grant all permissions upfront and still require prompting at a later stage. Previously granted permissions might also be recalled at any time. This approach doesn't require the User Agent to let the developer know which permissions the user has granted upfront nor would that be useful given permissions can change at any time. --tobie
Re: Allow ... centralized dialog up front
On 2/4/13 1:35 AM, Florian Bösch pya...@gmail.com wrote: So how exactly do you imagine this going down when an application that uses half a dozen such capabilities starts? Clicking trough half a dozen allow - allow - allow - allow - allow - allow, you really think the user's gonna bother what the 5th or sixth allow is about? I don't understand what in my previous email makes you think this is the suggestion I'm making. Quite the contrary, actually. Nothing in my suggestion prevents a User Agent from combining permission requirements in a single prompt. Nothing even prevents a dedicated gaming device (for example) from granting access to a slew of clearly gaming related features without prompting the user for permission at all. Nothing prevents a user from authorizing his User Agent to switch to full screen without prompting. Or to switch to fullscreen without prompting for websites that have been recommended by his friends. Or whitelisted by the user. Or the user agent. Or a third party website. Etc. etc. etc. --tobie
Re: Proposal: moving tests to GitHub
On 2/1/13 5:52 AM, Arthur Barstow art.bars...@nokia.com wrote: On 1/31/13 3:18 PM, ext Rebecca Hauck wrote: Since I'm not in the webapps working group, I had to first get access to the repository. I was told that that to get write access, I (probably) had to join the working group [1]. Yes, it certainly would have been easier if Adobe was a member of WebApps. Think we all agree that given tests are completely unrelated to IP concerns, there are no reasons to warrant WG membership in order to be able to contribute them. Any process around test contributions that works better for group members than it does for non-members hinders our ability to obtain external contributions. One of my goals during my fellowship is to find solutions around these issues. --tobie
Re: Proposal: moving tests to GitHub
On 2/1/13 4:23 AM, Arthur Barstow art.bars...@nokia.com wrote: One of things I wondering about is - after you leave your Fellow position [BTW, that's totally wicked so congrats on that!], and Robin has moved on to `greener pastures` and Odin has moved on to be CEO of Opera - if/when there are problems with GH, who are we gonna' call? Hg, despite its shortcomings, is backed by the W3C's crack SysTeam. Do we get an equivalent service from GH? This is a valid concern we need to address. We need to define the benefits, risks and risk mitigation strategies of moving to GitHub and decide whether or not this is something that makes sense. I'm going to start a doc on this that I'll use across WGs and socialize here first. I'd really like to see input on this from GitHub doubters so we can really address their concerns. If crowd-sourcing is part of our strategy to get more tests, (and the testing meeting we had this week seems to imply it is), then moving to GitHub is a requirement. Yes, those are good points and I'm wondering if there really needs to be a binary choice here or if there could be advantages to using both. For example, set up a skeleton structure on GH and if/when tests are submitted, the Test Facilitator could review them and copy the `good ones` to Hg. I have very large doubts about strategies that involve hum a intervention to sync resources across different versioning systems. --tobie
Re: Proposal: moving tests to GitHub
On 1/31/13 9:13 AM, Arthur Barstow art.bars...@nokia.com wrote: As I said during one of the testing breakouts in Lyon, ultimately I suspect the saying beggars can't be choosy will trump. However, AFAIK, currently, only one of WebApps' thirty active specs actually has an outside contribution. As such, and without any information about a relatively high probability we will get contributions from others, this move still seems like a lot of make work. Ultimately, that's a chicken and egg problem. Moving to GitHub doesn't guarantee external contributions (there are aspects beyond using Git(Hub) to involve and retain outside contributors), but the current solution clearly prevents those. If crowd-sourcing is part of our strategy to get more tests, (and the testing meeting we had this week seems to imply it is), then moving to GitHub is a requirement. --tobie
Re: Proposal: moving tests to GitHub
FWIW that looks good to me. At risk of bikeshedding, I think that calling a repo with tests for non-HTML specs html-testsuite is confusing and will make the repository harder to find, especially since the people who are aware that html is not a catch-all term are also the people most likely to be writing tests. Some more generic name like web-platform-testsuite seems better. Couldn't agree more. --tobie
Re: Proposal: moving tests to GitHub
On Jan 24, 2013, at 1:24 PM, Odin Hørthe Omdal odi...@opera.com wrote: Arthur Barstow wrote: Before we start a CfC to change WebApps' agreed testing process [Testing], please make a clear proposal regarding the submission process, approval process, roles, etc. as is defined in [Testing] and its references. (My preference is for you to document the new process, expectations, etc. in WebApps' Public wiki, rooted at http://www.w3.org/wiki/Webapps/). I've written (well, copied and changed) a document at: http://www.w3.org/wiki/Webapps/Submitting_tests It might not have everything required right now, but I think it's a good start. :-) This is awesome. Thanks for writing it. --tobie
Re: Proposal: moving tests to GitHub
On 1/22/13 11:53 AM, Odin Hørthe Omdal odi...@opera.com wrote: Hi! We just had a small discussion on webapps-testsuite [1] about the possibility of moving the webapps tests. I was wrongly under the impression that we had discussed this before (hey, confusion is not a crime ;) ). We had such a discussion in testing a while back.[a] Now that HTML has done the move, I think it is time for us to look at it too. Ms2ger and Robin, which did most of the HTML testsuite [2] move were happy to help [3]. Ms2ger proposed merging our repository with HTML at the same time and not necessarily having one repository for each group. I was already thinking such a move might be beneficial to do for webapps and webappsec, but it might be even more simple to also have html testsuite in that merge. There are benefits to both approaches. I would be in favor of having a repository per spec (named tr_shortname-testsuite). This will make it a lot easier to securely give scoped commit rights to external contributors when the need arises. Robin wrote an email describing what they did for the HTML move, some of which should be relevant for our potential move too [4]. Of particular interest the possibility for having tests in folders by section of the spec, and making submissions pull requests. I'm interested in such a move because it'll make our tests more visible, and easier to contribute to. Just this weekend the Server Sent Events spec got 6 pull requests from a GitHub user Yaffle [5]. Note that that particular repository will be moved into however our new test repository structure will be, so it probably won't remain as a separate repository. More thoughts here: http://tobie.github.com/w3c-testing-plan/unofficial-w3c-testing-plan-201201 16.html#transition-test-repositories-to-github --tobie --- [a]: http://lists.w3.org/Archives/Public/public-test-infra/2012JulSep/0027.html
Re: Proposal: moving tests to GitHub
On 1/22/13 12:20 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jan 22, 2013 at 12:11 PM, Tobie Langel to...@fb.com wrote: There are benefits to both approaches. I would be in favor of having a repository per spec (named tr_shortname-testsuite). This will make it a lot easier to securely give scoped commit rights to external contributors when the need arises. Given how we relatively frequently move features around and have not exactly figured out the overall architecture I don't think that's an approach that scales. That's definitely something to keep in mind. How frequent is it that a feature moves from one spec to another (that, is outside of the continuous flow of features that migrate from HTML5 to WebApps)? Is your concern about history loss? --tobie
Re: Proposal: moving tests to GitHub
On 1/22/13 12:37 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jan 22, 2013 at 12:30 PM, Tobie Langel to...@fb.com wrote: That's definitely something to keep in mind. How frequent is it that a feature moves from one spec to another (that, is outside of the continuous flow of features that migrate from HTML5 to WebApps)? Is your concern about history loss? My concern is 1) make work and 2) overhead of deciding what has to be tested where. Figuring out precisely what it is you are trying to test is the crux of the work. Having a repository per specification lightens the cognitive load, not burdens it more. Especially for external contributors which might not be aware of which WG handles what specs. E.g. tests for the ProgressEvent interface test quite a bit of IDL related requirements, where do they go? Well, in that case[1], it seems the decision to put it under the ProgressEvent directory has already been made. I don't see how this folder being the root of a git repository or a subfolder is relevant. With regards to the specifics of WebIDL requirements testing, there's work going on to parse WebIDL and generate assertions out of it. Where that isn't sufficient it seems a set of dedicated assertions (added to testharness.js) would greatly simplify testing and answering the question as to where these should go. From a distance it might all appear modular, but it really is all quite interconnected and by creating artificial boundaries that interconnectedness might not get testing. These boundaries are created at the spec level. I see no harm in replicating them at the test level. And there's certainly nothing artificial in doing so. That said, I agree integration testing is key, but it should be done explicitly and methodically, not by relying on accidental coverage that's hard to measure. The fun part about integration testing is it actually tests the specs more than it tests the implementations themselves. --tobie --- [1]: http://w3c-test.org/webapps/ProgressEvents/tests/submissions/
Re: Proposal: moving tests to GitHub
On 1/22/13 2:23 PM, Robin Berjon ro...@w3.org wrote: On 22/01/2013 13:27 , Odin Hørthe Omdal wrote: I'm not really sure if that is needed. If we can trust someone in one repository, why not in all? I'd add to that: the odds are that if someone is screwing things up, it's better to have more eyes on what they're doing. But what wins me over, is really the overhead question. Do anyone really want to manage lots of repositories? And for what reason? Also, we want more reviewers. If I'm already added for CORS, I could help out for say XMLHttpRequest if there's a submission/pull request languishing there. I think Odin makes convincing arguments. For me it's really the outreach argument. Just one repo, carrying its one setup and one set of docs, can easily be pitched as the One True Place to Save The Web. It's a lot easier to explain at a conference or such: just go there, and patch stuff. Yes, I guess what I want to avoid at all costs is the split per WG which has boundaries that partially happen at IP level, rather than strictly at the technology level. Whether we end up as: w3c-tests/ deviceorienation/ html5/ pointerevents/ progressevent/ xmlhttprequest/ or: deviceorienation-tests/ html5-tests/ pointerevents-tests/ progressevent-tests/ xmlhttprequest-tests/ Doesn't really matter (though I do find the former more readable). What bothers me however is how had to parse per-WG-organization is for newcomers. --tobie
Re: Proposal: moving tests to GitHub
On 1/22/13 4:45 PM, Robin Berjon ro...@w3.org wrote: On 22/01/2013 14:48 , Tobie Langel wrote: Yes, I guess what I want to avoid at all costs is the split per WG which has boundaries that partially happen at IP level, rather than strictly at the technology level. My understanding is that we don't have to care about spec-IP issues in test suites because when you contribute to a test suite you're not contributing to the spec's essential claims. That's correct. You *do* need to make the proper commitments for the test suite, but those are much lighter and can easily be extended to all. Moving to GitHub should be an excellent occasion to revisit how the CLA works and provide better integration, e.g.: by using something like CLAHub[1]. That's why we're proposing to ditch per-WG anything here. The way html-testsuite is set up, we already have subdirectories for html, canvas2d, and microdata. Those are all from the HTML WG, but they're just listed as the individual specs. We can keep on adding more specs in there (the Web Crypto people are looking to do that). That sounds good to me. It's the per WG siloing I'm opposed to, not the one repository to rule them all idea. --tobie --- [1]: https://github.com/jasonm/clahub
Re: Proposal: moving tests to GitHub
On 1/23/13 12:48 AM, Julian Aubourg j...@ubourg.net wrote: I love the idea of moving to github. The one-repo idea, while much simpler from a maintenance point of view, could easily be a burden on users that subscribe to it. Even more so for people who can merge PRs (and thus will receive an email for a PR initiated for any spec). Not saying it is blocking but it's something to keep in mind. Mail filters can go a long way here but filtering out specific specs kinda defeats the purpose of having so many eyes looking at everything. It's also worth thinking about which solution will have more chances of fostering a community of external contributors and reviewers. Strong but very specialized contributors might not get noticed. Being the biggest contributor to the XHR test suite might carry a lot more value than being the 50th biggest contributor to W3C tests in general. --tobie
Re: [ambient light events LC] Feedback ( LC-2736)
On 1/17/13 11:36 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Jan 17, 2013 at 8:15 AM, frederick.hir...@nokia.com wrote: Dear Tab Atkins Jr. , The Device APIs Working Group has reviewed the comments you sent [1] on the Last Call Working Draft [2] of the Ambient Light Events published on 13 Dec 2012. Thank you for having taken the time to review the document and to send us comments! The Working Group's response to your comment is included below, and has been implemented in the new version of the document available at: https://dvcs.w3.org/hg/dap/raw-file/tip/light/Overview.html. Either this link is incorrect, or something is broken in your tooling, as it sends me to a very raw HTML file with no styling, headers, or anything else. This makes it difficult to read or review. Try running it in Firefox. Seems recent Chrome releases refuse to run JS served over HTTP on pages served over HTTPS. --tobie
Re: Editor change for Web Application Manifest Format and Management APIs specification
On 11/26/12 2:35 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Wed, 21 Nov 2012 18:58:02 +0400, Mounir Lamouri mou...@lamouri.fr wrote: Hi, Anant stepped down as an editor of Web Application Manifest Format and Management APIs specification [1] but Mozilla is still interested in this specification so I will replace Anant as an editor. However, given the feedback we got on this specification [2], we are merging it with the Runtime and security model specification that will happen in the System Applications Working Group [3]. We are not against keeping the specification in this WG but we fear that it might not gain much traction as-is. Hi Mounir, Yandex is interested in this spec. So is Facebook and Coremob. --tobie
Re: CfC: publish WD of XHR; deadline November 29
On 11/23/12 5:36 PM, Adam Barth w...@adambarth.com wrote: However, we should be honest about the origin of the text and not try to pass off Anne's work as our own. Or better yet, provide a canvas where Anne is able to do his work as part of the WebApps WG. --tobie
Re: [quota-api] Need for session storage type
On 10/31/12 6:03 PM, Eric U er...@google.com wrote: I think the bigger question is What's a session? Does it end if I: * close the window? * close the last window in this origin? * close the last window in this browser profile? * quit the browser? - With or without continue where I left off/load my same windows from last time? - Due to an update that caused a restart? - Due to a crash, with automatic crash recovery? * switch to another app on my phone/tablet? * use enough other apps on my phone/tablet that the browser gets purged from memory? I doubt browsers are consistent in all these situations, given that current Chrome doesn't behave the same as the Chrome of a year ago. So saying it should act like session cookies doesn't work. It seems there would/could be value in determining precisely what a session is, and/or coming up with an API to allow application developers to close sessions on a per origin basis and benefit from related security/privacy guarantees (wiping-out session storage, cookies, etc.). --tobie
Re: [quota-api] Need for session storage type
On 11/5/12 6:47 PM, Brady Eidson beid...@apple.com wrote: And/or coming up with an API to allow application developers to close sessions on a per origin basis and benefit from related security/privacy guarantees (wiping-out session storage, cookies, etc.). Sites can already clean up individual session-ey nuggets on a case-by-case basis. I'm not sure I like the idea of giving them the nuclear option as they'll just start using that liberally instead of thinking things through. This could cause excess i/o and/or lock contention where such semantics are defined. Nuclear options have privacy guarantees which other options don't have. That's also something to consider. --tobie
Re: CfC: publish LCWD of File API; deadline October 22
On 10/17/12 3:29 AM, Arthur Barstow art.bars...@nokia.com wrote: All - this is a Call for Consensus to publish a Last Call Working Draft of the File API spec http://dev.w3.org/2006/webapi/FileAPI/. Note bug 17125 ([1] below) is open and Arun proposes it be postponed for v.next. Additionally, Arun notes below bug 19554 ([2] below) is a related feature request for HTML and he proposes the LC comment period be used to gather input on that bug. This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] The proposed LC review period is 4 weeks. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by October 22 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. -Thanks, AB +1 --tobie
Re: [widgets] Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) is a Proposed Edited Recommendation
On 9/28/12 10:18 AM, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Thu, 27 Sep 2012 23:55:37 +0400, Tobie Langel to...@fb.com wrote: On 9/27/12 9:35 PM, Arthur Barstow art.bars...@nokia.com wrote: W3C Advisory Committee members are asked to Please review the specification and indicate whether you endorse it as W3C Recommendation or object to its advancement by completing the following questionnaire https://www.w3.org/2002/09/wbs/33280/widget2e/. I'm getting the following error when answering the questionnaire: Hopefully it is fixed now (Dom++) It is. Thanks, Dom! --tobie
Re: [widgets] Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) is a Proposed Edited Recommendation
On 9/27/12 9:35 PM, Arthur Barstow art.bars...@nokia.com wrote: W3C Advisory Committee members are asked to Please review the specification and indicate whether you endorse it as W3C Recommendation or object to its advancement by completing the following questionnaire https://www.w3.org/2002/09/wbs/33280/widget2e/. I'm getting the following error when answering the questionnaire: Saving failed with error Program error: a widget must be loaded before creation Saving failed with error Program error: a widget must be loaded before creation Saving failed with error Program error: a widget must be loaded before creation Saving failed with error Program error: a widget must be loaded before creation Saving failed with error Program error: a widget must be loaded before creation Saving failed with error Program error: a widget must be loaded before creation --tobie
Re: [quota-api] API change suggestions
On 9/11/12 11:13 AM, Kinuko Yasuda kin...@chromium.org wrote: I think I like this idea, but I'm also concerned with the fact that Chromium has been shipping Quota API some time now and there're some consumers of the old API. Wasn't aware. Does't seem to be in Chrome, even prefixed, however. Since we've already made several changes in the API there's no reason that we cannot make further changes, but I want to be a bit conservative about this. Sure. Is the existing implementations based on the current Editor's draft of the spec on previous material? I would like to examine: if we have obvious pros/cons in the current and proposed API (like feature detection in the past API changes), and also would like to wait a bit more to see if anyone has feedbacks/comments. Absolutely. --tobie
Re: [quota-api] API change suggestions
On 9/11/12 12:29 PM, Kinuko Yasuda kin...@chromium.org wrote: It's prefixed, and based on the previous (original) proposal. Which is why I didn't find it (I was expecting it to hang off of the navigator property of the window object). --tobie
[quota-api] Need for session storage type
Hi all, Following a recent conversation with Jonas (and contrary to what I initially claimed here) there's value in adding a third storage type to the Quota API: Session storage. Contrary to temporary storage which might not get wiped across UA sessions, Session storage MUST get wiped when the session is closed. Happy to provide patch if there's agreement this is a valuable addition to the spec. Best, --tobie
[quota-api] API change suggestions
Hi,
I'm very happy with the API changes we where able to make to the Quota
API, but there's a method name we have left untouched and that I haven't
figured out how to tackle until today: queryUsageAndQuota.
The name is horrendous and is going to make developers cringe. It's also
not very extensible should need arise to provide extra information in the
future.
Here's a suggestion to fix it:
1) create a new StorageQuotaInfo interface:
WebIDL:
interface StorageQuotaInfo {
readonly attribute unsigned long long quota;
readonly attribute unsigned long long usage;
};
2) Rename StorageUsageCallback to StorageInfoCallback and pass it a
StorageQuotaInfo instead of two ints:
WebIDL:
callback StorageInfoCallback = void (StorageQuotaInfo storageQuotaInfo);
3) Rename queryUsageAndQuota to getInfo:
WebIDL:
interface StorageQuota {
void getInfo (in StorageInfoCallback successCallback, in optional
StorageErrorCallback errorCallback);
...
};
The examples in the spec would be rewritten as shown here:
https://gist.github.com/3690242
Thoughts?
Again, happy to contribute those changes if there's interest.
Best,
--tobie
Re: [XHR] Setting the User-Agent header
On 9/5/12 12:33 PM, Robin Berjon ro...@w3.org wrote: On 05/09/2012 06:03 , Mark Nottingham wrote: That's unfortunate, because part of the intent of the UA header is to identify the software making the request, for debugging / tracing purposes. Given that lots of libraries generate XHR requests, it would be natural for them to identify themselves in UA, by appending a token to the browser's UA (the header is a list of product tokens). As it is, they have to use a separate header. Do you have a use case that does not involve the vanity of the library's authors? :) I would think Caja[1] would legitimately want to change the User Agent String of ajax requests that got through it. The capabilities the Caja runtime provides to cajoled code are so different than those of its host environment that it makes complete sense for the User Agent string to be different. It's really a browser within a browser. --tobie --- [1]: http://code.google.com/p/google-caja/
Re: Lazy Blob
On 8/1/12 10:04 PM, Glenn Maynard gl...@zewt.org wrote: Can we please stop saying lazy blob? It's a confused and confusing phrase. Blobs are lazy by design. Yes. Remote blob is more accurate and should help think about this problem in a more meaningful way. --tobie
Re: Lazy Blob
On 8/2/12 2:29 PM, Robin Berjon ro...@berjon.com wrote: On Aug 2, 2012, at 10:45 , Tobie Langel wrote: On 8/1/12 10:04 PM, Glenn Maynard gl...@zewt.org wrote: Can we please stop saying lazy blob? It's a confused and confusing phrase. Blobs are lazy by design. Yes. Remote blob is more accurate and should help think about this problem in a more meaningful way. Actually, you need both to be accurate. With the current stack you can have lazy blobs, and you can have remote blobs, but you can't have both at the same time. If we're going to be strict about naming this, we're talking about remote lazy blobs. What's a remote blob in the current stack? --tobie
Re: Feedback on Quota Management API
On Jun 27, 2012, at 9:14, Ms2ger ms2...@gmail.com wrote: On 06/27/2012 05:44 PM, Tobie Langel wrote: On Jun 27, 2012, at 6:44 AM, Glenn Maynardgl...@zewt.org wrote: Unrelated, screaming-caps on RFC2119 terms (eg. MUST) is jarring and unnecessary. I'd suggest dropping the em.rfc2119 style. That's what HTML, DOM4, etc. do, and it's much more readable. How do you distinguish between 'MUST' and 'must' then? I agree the style is jarring, but maybe that can be fixed rather then completely removed. Specifications must not use RFC2119 keywords to mean anything else than the meaning RFC2119 assigns to those keywords. HTH Ms2ger Wasn't aware. Thanks for the clarification. --tobie
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On 6/20/12 12:05 AM, Sylvain Galineau sylva...@microsoft.com wrote: [Daniel Glazman:] That's also the reason why I asked to explain requestFullscreen(). It can sound obvious, but it's not. And in fact, we should _never_ introduce a new syntax, API, whatever w/o saying _what it does_ from a functional point of view before explaining how it works. To the extent possible I think specs should document some of the core use-cases and scenarios they are derived from e.g. as an informative intro or appendix. Extra points for covering scenarios that are explicitly out of scope for the current version. This would be especially valuable for new specifications. I don't think people who don't live in WHATWG/W3C mailing lists and/or make browsers for a living can read a document like this one - or, say, CORS - and hope to figure out what problems they are/aren't trying to solve. (I'm not sure they're even that obvious for people who do) Can't agree more. Unpublished / hard to find use cases makes everyone's life harder and worsens the perception authors have of spec writers and implementors. Calling them authors doesn't help, either. :-/ --tobie
Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out
On Jun 8, 2012, at 11:03 AM, Rafael Weinstein rafa...@google.com wrote: Yehuda, Can you help clarify here whether jQuery's behavior is intentional (i.e. use cases drive the need for executability), or if it's a side-effect of the implementation? I can't speak for jQuery, but in Prototype.js, this behaviour is intentional. --tobie
[QUOTA] Misleading example in Quota handling in storage API section
Hi, In section 5 of the Quota Management API (Quota handling in storage API)[1], the last sentence of the first bullet point reads: For example, Application Cache may silently discard or fail to cache data when it is hitting quota limit. This is actually incorrect, AppCache is atomic and hitting the quota limit would trigger a cache failure as per step 17.5 of the application cache download process[2]. If the user agent is not able to store the resource (e.g. because of quota restrictions), the user agent may prompt the user or try to resolve the problem in some other manner (e.g. automatically pruning content in other caches). If the problem cannot be resolved, the user agent must run the cache failure steps. In turn, this would fire an error event and bust the cache. Best to pick another example. --tobie --- [1]: http://dvcs.w3.org/hg/quota/raw-file/6085f376620a/Overview.html#quota-handl ing-in-storage-api [2]: http://dev.w3.org/html5/spec/single-page.html#application-cache-download-pr ocess
Re: Feedback on Quota Management API
On 6/6/12 8:33 AM, Kinuko Yasuda kin...@chromium.org wrote: Based on the feedbacks I've updated the draft: http://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html - Got rid of string enum, instead introduced navigator.persistentStorage and navigator.temporaryStorage - Some interface name changes (just for IDL) QuotaStorageEnvironment - StorageQuotaEnvironment StorageInfo - StorageQuota StorageInfoQuotaCallback - StorageQuotaCallback StorageInfoUsageCallback - StorageUsageCallback StorageInfoErrorCallback - StorageErrorCallback I'd like to finalize these naming/interface details while we're here. Thanks for making those changes. This is shaping up quite nicely. I still think queryUsageAndStorage is quite a mouthful but can't think of anything more succinct for now. --tobie
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On 6/6/12 2:10 AM, Arthur Barstow art.bars...@nokia.com wrote: I don't recall the group discussing the UCs and requirements the spec addresses. Perhaps it would also be useful to step back a bit and try to get agreement on some high level requirements before proceeding. Agreed. --tobie
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On 6/6/12 10:27 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: Having looked again at this, I think the easiest approach would not be to publish WebApp Manifest as is, but simply to publish a new draft of the Widget Interface[1] and do a search/replace on widget with webapp. Republishing the same spec with only this modification and observing adoption would be an interesting social experiment in itself. But I digress. We can then add a section on JSON serialization as a manifest media type, and then take each of the proposed model extensions from Mozilla on their own merit. That shouldn't prevent us from looking at use cases and requirements. Mozilla's proposal seems to essentially target applications distributed through app stores. We'd like to see a solution that also enables providing meta data to bookmarked apps similar to how meta tags work in iOS. --tobie
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On 6/6/12 3:35 PM, Marcos Caceres w...@marcosc.com wrote: On Wednesday, June 6, 2012 at 9:51 AM, Tobie Langel wrote: Mozilla's proposal seems to essentially target applications distributed through app stores. We'd like to see a solution that also enables providing meta data to bookmarked apps similar to how meta tags work in iOS. I've not much experience with the iOS meta tags, so is there anything missing in W3C Widget's config.xml or in Moz's JSON? Not in the configuration file itself (what Mozilla calls the Web Application Manifest), but it is not specified how it is delivered to the client in that case. Would be cool if one could just do: !-- gimme config in accepted format (xml or json) -- meta config=/config That way, there is no need to repeat meta tags in every page... just repeat it onceŠ Absolutely, or: html manifest=/path/to/config.webapp and combine appcache and config into a single format. The AppCache manifest format works beautifully in JSON (and I'm sure it would do equally well in XML). See how the sample manifest files provided in the HTML5 spec[1] would look like in JSON: https://gist.github.com/2881982 or doing something like a fav.ico equivalent that is loaded automagically. I'd rather we avoided simultaneously adding an extra http request to all the web pages in the world **and** filling server logs with garbage 404 requests. --tobie --- [1]: http://www.w3.org/TR/html5/offline.html#some-sample-manifests
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On 6/6/12 5:02 PM, Marcos Caceres w...@marcosc.com wrote: On Wednesday, June 6, 2012 at 2:58 PM, Tobie Langel wrote: Absolutely, or: html manifest=/path/to/config.webapp and combine appcache and config into a single format. The AppCache manifest format works beautifully in JSON (and I'm sure it would do equally well in XML). See how the sample manifest files provided in the HTML5 spec[1] would look like in JSON: https://gist.github.com/2881982 yep, that could also workŠ though I wonder if it's too late to be swapping manifest formats. The two manifest formats could very well co-existing. Furthermore, since only the structure of the data differs, the AppCache algorithm wouldn't need to change. --tobie
Re: Push API draft uploaded
On 6/6/12 6:05 PM, SULLIVAN, BRYAN L bs3...@att.com wrote: Here is the thread for the set of use cases I submitted for this API during the rechartering: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008.html. Additional use cases are welcome, and we can capture them and derived requirements on the Webapps wiki. I created a page for this: http://www.w3.org/2008/webapps/wiki/Push_API Thanks for the links, Bryan. Will add use cases. --tobie
[Process] Publishing use cases and requirements as official docs
Hi, I recently stumbled upon a number of use case and requirements docs (such as MediaStream Capture Scenarios[1] or HTML Speech XG[2]) that were published as officially looking W3C documents (for whatever that means, at least, it's not a page on a Wiki). I think that's tremendously useful, especially for authors who can have a much better understanding of the purpose of a specification that way (and therefore use it the right way and for the right purpose). It's also a smart way to get authors involved without corrupting them into thinking like spec writers or implementors. What are the WebApps WG's plans with regards to that (if any)? Thanks, --tobie --- [1]: http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html [2]: http://www.w3.org/2005/Incubator/htmlspeech/live/draft-20110203-requirement s.html
Re: CfC: publish FPWD of Quota Management API; deadline June 13
On 6/6/12 2:01 PM, Arthur Barstow art.bars...@nokia.com wrote: Having seen no negative responses to the Is the Quota Management API spec ready for FPWD? thread [1], this is a Call for Consensus (CfC) to publish a First Public Working Draft (FPWD) of the Quota Management API using the following ED as the basis of the FPWD: https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this specification at the time of publication; it does not necessarily mean there is consensus on the specification's contents. Please send all comments regarding this CfC to the public-webapps@w3.org mail list by June 13. Please note silence will be considered as agreement with the proposal. If you support this CfC, a positive response is preferred and encouraged. -Thanks, AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0940.html We support this. --tobie
Re: [Process] Publishing use cases and requirements as official docs
On Jun 6, 2012, at 8:46 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: (Starting a new thread by replying to a mail and then changing the subject and quoted text is not a good idea; just start a new mail.) Guilty as charged. Sorry, won't happen again. I recently stumbled upon a number of use case and requirements docs (such as MediaStream Capture Scenarios[1] or HTML Speech XG[2]) that were published as officially looking W3C documents (for whatever that means, at least, it's not a page on a Wiki). Only documents under http://www.w3.org/TR/ are official publications as far as Working Group's Technical Reports go. Can't WG release notes? --tobie
Re: [Process] Publishing use cases and requirements as official docs
On Jun 6, 2012, at 10:04 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Tobie Langel wrote: On Jun 6, 2012, at 8:46 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: Only documents under http://www.w3.org/TR/ are official publications as far as Working Group's Technical Reports go. Can't WG release notes? Working Groups can publish Working Group Notes as Technical Report, they would go under http://www.w3.org/TR/ aswell. OK, but the process is lighter, no? --tobie
Re: Push API draft uploaded
On 6/5/12 4:00 PM, Mounir Lamouri mou...@lamouri.fr wrote: On 05/31/2012 03:28 PM, Tobie Langel wrote: I'm probably missing something here, but notifications don't seem to be going through a system- / browser-wide notification panel from which the user can decide whether or not to navigate to an application. In other words, it looks like we're considering server -- app push notifications, rather than server -- user push notifications. If that's case, how are we planning to handle waking up application A without disrupting the experience of the user currently busy using application B in the foreground (thinking essentially of mobile here)? Are we going to wake up application B but run it as a background app? If so, where is that behavior defined? Is that akin to a WebWorker or more of a headless window? What's the life-cycle of such an app? Also, how can this app alert the user that it has something new for him? Do we also have system level notifications in the work? If a given notification's sole purpose is to advise the user of some information he may or not want to act upon (e.g.: you have new mail), what are the benefits of waking up the application (or even spawning a worker) to do so? That seems like it would drain the battery of mobile devices for little purpose. Finally, aren't we conflating the notion of background work following a remote server or system event with that of push notification to the user? An example of background work following a remote server event would be the background update of daily news for a newspaper application. A remote server would send an event to the system / browser which itself would launch a WebWorker, that worker would perform the necessary io to upload the fresh content and save it in a db. An example of background work following a system event would be a location change event spawning a background worker which itself either stored the coordinates in a db or sent them to a remote server, e.g. for a cycling app tracking your rides. Example of push notifications for the user are things like You've got a new message, It's Emma's birthday today, etc. The user can decide to act upon them (i.e. follow the provided link) or not, but until he does, there's no reason to launch an app or even a worker. Note that similar notifications would also need to be issued by background workers / windows. E.g. The worker spawned above to upload fresh content for the newspaper app would be able to send a notification to the user when it's done (e.g. Today's news are been downloaded.) Sorry if the above feels a bit like a brain dump. I'm really struggling to understand the scope of this proposal. :-/ Actually, our System Message API [1] seems to answer most of those questions: an application will be able to specify a worker or a page to use when handling a message so it will be able to just run stuff in the background and depending on what happened do something like show a notification (via Desktop Notifications) or update a DB, or whatever. [1] https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/a3 c6e4c31d04b663/ Thanks for the link! While it's possible to display push notifications to the user via this proposal (push notification spawns a worker which notifies the user via Desktop Notification), on mobile it's probably a quantifiable waste of battery life compared to push notifications that are directly aimed at the user. For applications built in a more traditional way (with server side rendering, etc.), it still feels like providing the data in query params should be investigated before it's dismissed. Overall, I feel like writing down use cases and requirements would be something useful to do at this point. What do you think? --tobie
Re: Feedback on Quota Management API
On 6/1/12 12:07 PM, Kinuko Yasuda kin...@chromium.org wrote: Makes sense, ok let's keep it. Then we will have symmetric four methods, request and query for each type. Following up on the conversation on Quota Management API and the recent changes which were agreed upon, I'm wondering whether we shouldn't also consider the following: Instead of: navigator.storageInfo.queryPersistentUsageAndQuota navigator.storageInfo.queryTemporaryUsageAndQuota navigator.storageInfo.requestPersistentQuota navigator.storageInfo.requestTemporaryQuota what about: navigator.persistentStorageInfo.queryUsageAndQuota navigator.persistentStorageInfo.requestQuota navigator.temporaryStorageInfo.queryUsageAndQuota navigator.temporaryStorageInfo.requestQuota i.e. instead of having the `QuotaStorageEnvironment` interface define a single `storageInfo` attribute off of which all 4 methods hang, what about having it define two attributes of type `PersistentStorageInfo` and `TemporaryStorageInfo` respectively, each of which would only have a query and request method? Finally, I feel it's slightly misleading to have an interface called info which enables changes (through `requestQuota`). Wouldn't settings or similar be more appropriate? As in: navigator.persistentStorageSettings.queryUsageAndQuota navigator.persistentStorageSettings.requestQuota Thoughts? --tobie
Re: Feedback on Quota Management API
On 6/4/12 11:17 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jun 4, 2012 at 11:01 AM, Tobie Langel to...@fb.com wrote: Finally, I feel it's slightly misleading to have an interface called info which enables changes (through `requestQuota`). Wouldn't settings or similar be more appropriate? As in: navigator.persistentStorageSettings.queryUsageAndQuota navigator.persistentStorageSettings.requestQuota Thoughts? That seems way long. navigator.storage would be better I think. Or even defining the relevant methods directly on navigator. Agreed. Whether you're targeting persistent or temp storage still needs to appear somewhere, however. So it's either: navigator.persistentStorage.requestQuota or: navigator.storage.requestPersistentQuota or: navigator.requestPersistent(Storage)Quota I'd favor the first one. --tobie
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On 6/2/12 6:54 AM, Fabrice Desre fabr...@mozilla.com wrote: On 06/01/2012 02:36 PM, Tobie Langel wrote: On Jun 1, 2012, at 9:58 PM, Marcos Caceres w...@marcosc.com mailto:w...@marcosc.com wrote: Sounds good. AFAICT, Moz's proposal doesn't really cover packaging either ... Not in the sense of wrapping the app using zip or something. More metadata, feature control (potentially relevant to requiring certain SysApps API), and lifecycle management. Agreed. I'd be curious to see how it's planning to interact with AppCache (if at all). Also whether integration with a JSON version of AppCache has been considered. We're working on pre-loading the appcache at install time when the appcache path is specified in the manifest. See https://bugzilla.mozilla.org/show_bug.cgi?id=702369 for the b2g support, and https://bugzilla.mozilla.org/show_bug.cgi?id=753990 for desktop support. That sounds nice. How do normal web pages link to their own config file? I haven't seen that mentioned in the spec draft. --tobie
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On 6/4/12 6:41 PM, Fabrice Desre fabr...@mozilla.com wrote: Hi Tobie, On 06/04/2012 03:03 AM, Tobie Langel wrote: On 6/2/12 6:54 AM, Fabrice Desré fabr...@mozilla.com wrote: We're working on pre-loading the appcache at install time when the appcache path is specified in the manifest. See https://bugzilla.mozilla.org/show_bug.cgi?id=702369 for the b2g support, and https://bugzilla.mozilla.org/show_bug.cgi?id=753990 for desktop support. That sounds nice. How do normal web pages link to their own config file? I haven't seen that mentioned in the spec draft. What do you call the config file here? The Web Application Manifest. (Sorry for the confusion, the Widget spec calls roughly the same thing a configuration document.) --tobie
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On 6/4/12 9:16 PM, Fabrice Desre fabr...@mozilla.com wrote: On 06/04/2012 10:38 AM, Tobie Langel wrote: On 6/4/12 6:41 PM, Fabrice Desre fabr...@mozilla.com wrote: Hi Tobie, On 06/04/2012 03:03 AM, Tobie Langel wrote: On 6/2/12 6:54 AM, Fabrice Desré fabr...@mozilla.com wrote: We're working on pre-loading the appcache at install time when the appcache path is specified in the manifest. See https://bugzilla.mozilla.org/show_bug.cgi?id=702369 for the b2g support, and https://bugzilla.mozilla.org/show_bug.cgi?id=753990 for desktop support. That sounds nice. How do normal web pages link to their own config file? I haven't seen that mentioned in the spec draft. What do you call the config file here? The Web Application Manifest. (Sorry for the confusion, the Widget spec calls roughly the same thing a configuration document.) It's not linked directly in a link or other tag, but passed as a parameter to the .install() method. Right, in the app store model. Surely, you're also planning to support background installs of apps when visiting the apps URL in conjunction with AppCache. In this case, how will the Web Application Manifest work? How will it be referenced by the document? Are you planning on something like: html webapp_manifest=path/to/config.webapp manifest=path/to/manifest.appcache --tobie
Re: Feedback on Quota Management API
On 6/1/12 10:34 AM, Kinuko Yasuda kin...@chromium.org wrote: If we go along the line we will have four methods on StorageInfo: queryPersistentUsageAndQuota queryTemporaryUsageAndQuota requestPersistentQuota We could also think of 'requestTemporaryQuota', a variant of requestQuota, but by the nature of temporary storage UA will not secure/reserve space for temporary storage and I don't think requesting quota for temporary storage makes a good sense. (Objections welcome, we could also leave it to UA and allowing it to return unsupported error) The fact that a UA can expire temporary data when it detects it has limited storage space is orthogonal to the amount of said storage the author might want to have access to. And given temporary data is capped the same way persistent data is, there needs to be an equivalent API to request its augmentation. Your draft spec already caters for the case where not enough space would be available (successCallback may return a smaller amount of quota than requested.), so I don't think that's a concern. It's also much better in terms of API consistency. --tobie
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On Jun 1, 2012, at 7:50 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: I'd be interested in implementing support for the JSON manifest format in Apache Wookie/Apache Rave, but really want this to be properly harmonized with the Widgets specs rather than a competing incompatible spec. My feeling exactly. --tobie
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
--tobie On Jun 1, 2012, at 9:58 PM, Marcos Caceres w...@marcosc.com wrote: On 1 Jun 2012, at 18:18, Adam Barth w...@adambarth.com wrote: On Fri, Jun 1, 2012 at 6:43 AM, Marcos Caceres w...@marcosc.com wrote: On 31 May 2012, at 23:23, Adam Barth w...@adambarth.com wrote: Is anyone besides Mozilla interested in implementing this specification? I think people are just trying to work out what it does and if it brings value to particular communities. Having said that, the only other really big (i.e. in terms of millions of users right now) candidate for implementation is Google as this proposal is supposed to harmonise the Chrome store approach to installable Web apps with Moz's go at entering the same market (and sharing apps across stores/browsers). Adam, as you are associated with Google, can you find out if Google's chrome store team are interested in moving it forward? My understanding is that standardizing the package format isn't very high on the team's priority list. They're more interested in standardizing the security model and associated APIs, which is why we're interested in forming the SysApps working group. Sounds good. AFAICT, Moz's proposal doesn't really cover packaging either ... Not in the sense of wrapping the app using zip or something. More metadata, feature control (potentially relevant to requiring certain SysApps API), and lifecycle management. As an example, http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html has a required_features field, which makes some implicit assumptions about the security model. It seems premature to work on a format for declaring this sort of information without having nailed down the security model. I agree. If I were running the show, I'd take up this work in the SysApps working group after we'd made some progress on the security model and at least a handful of APIs. Then we'll have something concrete to describe in the manifest. Seems reasonable. Having said that (and I can check with the team if you'd like a definitive answer), I doubt they'd oppose folks working on this topic. I just wouldn't expect much feedback from them in the near term. That would be appreciated. Might save some cycles and help priorities... Adam On Wed, May 30, 2012 at 11:36 AM, Arthur Barstow art.bars...@nokia.com wrote: Hi All, Besides the thread below that Anant started a few weeks re the Webapp Manifest spec, Marcos also started a few threads on this spec ... What are people's thoughts on whether or not the Quota Management API spec is ready for First Public Working Draft (FPWD)? A rule of thumb for FPWD is that the ED's scope should cover most of the expected functionality although the depth of some functionality may be very shallow, and it is OK if the ED has some open bugs/issues. -Thanks, AB On 5/12/12 2:02 PM, ext Anant Narayanan wrote: Hi everyone, I recently joined the webapps working group and I'd like to introduce myself! I work at Mozilla and for the past year or so have been working on our Apps initiative [1]. Our goal has been to make it very easy for developers to build apps using web technologies that can go above and beyond what one might achieve using native SDKs on platforms like iOS and Android. We're also trying to make it really easy for users to find and acquire these apps, and use them on any device they happen to own regardless of platform. As part of this work we have devised a simple JSON based manifest format to describe an installable web app, in addition to a few DOM APIs to install and manage these apps. We have a working implementation of the entire system in our latest Nightly builds. The manifest and corresponding APIs are described in an early draft at: http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html We'd like to propose using that draft as the basis for a FPWD on this topic. I look forward to your feedback! FAQs -- There are a few questions I anticipate in advance, which I will try to answer here, but we can definitely go in more depth as necessary on the list: Q. Why not simply reuse the widgets spec [2]? A. Aside from naming (we're talking about apps, the word widget seems to imply an artificial limitation), and replacing XML with JSON; the other fundamental difference is that the widget spec describes packaged apps, whereas our manifest describes hosted apps. We think hosted apps have several interesting and unique web-like properties that are worth retaining. Hosted apps can be made to work offline just as well as packaged apps with AppCache (which is in need of some improvement, but can be made to work!). Packaged apps do have their own advantages though, which we acknowledge, and are open to extending the spec to support both types of apps. Q. Why is the DOM API in the same spec as the manifest? A. One success condition for us would
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On Jun 1, 2012, at 9:58 PM, Marcos Caceres w...@marcosc.commailto:w...@marcosc.com wrote: Sounds good. AFAICT, Moz's proposal doesn't really cover packaging either ... Not in the sense of wrapping the app using zip or something. More metadata, feature control (potentially relevant to requiring certain SysApps API), and lifecycle management. Agreed. I'd be curious to see how it's planning to interact with AppCache (if at all). Also whether integration with a JSON version of AppCache has been considered. --tobie P.S. sorry for the blank email I posted minutes earlier. Hit the wrong button.
Re: Push API draft uploaded
On 5/30/12 11:14 AM, Mounir Lamouri mou...@lamouri.fr wrote: * I guess the idea of |onmessage| is that the PushService instance will get an event when the backend will push a notification to the webapp. However, I wonder how you do handle the situation when the application is actually not being ran. Or should we wait for it to be launched? Anyhow, coupling the URL request and the event handling at the same place seems weird. bryan Not at all. This is the way that EventSource works for example (the message handler is overtly associated with the request to a specific service URL). I'm not sure what you mean by when the application is actually not being ran... if you mean when the app is not running, the answer is yes, the app should be started and the event then delivered to it. Running a webapp/website then sending an event to it seems a rather hard task. This is actually what motivated the System Message Handler API. bryan I'm not sure how it's hard; the Webapp just arranges for Push message delivery when it is invoked, and events are delivered to the object that represents the service arrangement (whether connection-based or connectionless or whatever). I may be missing your counterpoint. I wasn't clear I think. If you start an application because of a particular event, the application has no way to know it has been started because of the event until the event is actually sent. But the event will be sent at a point during load (or after) and in the meantime, the application might show a UI as if it was simply started by the user. So you might have a weird UI flickering where something will be shown and very quickly will be changed to something else because of the push notification coming. Agreed with Mounir here. While passing an event to a running app makes sense (and already exists in the form of EventSource) it really doesn't for apps which are not running. Passing the event data as query params seems more suitable in that case. * If we want want a |wakeup| attribute, this might need to live in the manifest as Jose suggested. In general, I wonder if that should be something the UA requests. I would understand why the UA would ignore |wakeup = true| but I wouldn't understand why it should always follows the passed value. bryan The wakeup feature might be turned on by the app through an interface with the user, and used sometimes and others not per the needs of the app and preferences of the user (app managed). If it's in the manifest, it's fixed. I don't believe the UA should ignore the requirements of the app, when the user has given their permission for its operation as needed (both by browsing/installing the app, and overtly by approving Push service use). I'm not sure I understand how the user would give its permission here. bryan By navigating to the Webapp (implicitly, in the case that the Webapp had previously been permitted access to Push services by the user), and by accepting the UA's prompt as to whether this app should be allowed to receive Push messages the first time the user navigates to it (explicitly). So the user doesn't really give its permission to the app to wakeup the device but to the app to be able to receive push notifications. Then, the app is the only one deciding if it will wakeup the device or not. I'm not a big fan of that approach but I don't really have a better idea for the moment. I'm probably missing something here, but notifications don't seem to be going through a system- / browser-wide notification panel from which the user can decide whether or not to navigate to an application. In other words, it looks like we're considering server -- app push notifications, rather than server -- user push notifications. If that's case, how are we planning to handle waking up application A without disrupting the experience of the user currently busy using application B in the foreground (thinking essentially of mobile here)? Are we going to wake up application B but run it as a background app? If so, where is that behavior defined? Is that akin to a WebWorker or more of a headless window? What's the life-cycle of such an app? Also, how can this app alert the user that it has something new for him? Do we also have system level notifications in the work? If a given notification's sole purpose is to advise the user of some information he may or not want to act upon (e.g.: you have new mail), what are the benefits of waking up the application (or even spawning a worker) to do so? That seems like it would drain the battery of mobile devices for little purpose. Finally, aren't we conflating the notion of background work following a remote server or system event with that of push notification to the user? An example of background work following a remote server event would be the background update of daily news for a newspaper application. A remote server would send an event to the system / browser which itself would launch a WebWorker, that worker
Re: [admin] Mail List Policy, Usage, Etiquette, etc. Top-posting
On 5/31/12 11:58 PM, SULLIVAN, BRYAN L bs3...@att.com wrote: bryan How about a practical suggestion for the (probably many) of us that have to use Microsoft Outlook? From: http://wiki.whatwg.org/wiki/FAQ#Mailing_List If you use Outlook or Outlook Express, you can use either Outlook-QuoteFix [1] or OE-QuoteFix[2]. These plugins fix several of Outlook's problems with sending properly formatted emails. --tobie --- [1]: http://home.in.tum.de/~jain/software/outlook-quotefix [2]: http://home.in.tum.de/~jain/software/oe-quotefix
Re: [admin] Mail List Policy, Usage, Etiquette, etc. Top-posting
On 5/29/12 6:52 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 29, 2012 at 9:28 AM, Jean-Claude Dufourd jean-claude.dufo...@telecom-paristech.fr wrote: On 29/5/12 17:56 , Julian Reschke wrote: On 2012-05-29 16:53, Glenn Maynard wrote: On Tue, May 29, 2012 at 9:22 AM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: * Messages should be encoded usingplain text http://en.wikipedia.org/wiki/Plain_text No, messages should have a plaintext *version* (MIME alternative). It's common and useful to use HTML messages, especially when posting about actual spec text, where being able to use italics and bold is extremely useful. This is quite a relic; I havn't heard anyone make the emails should only be in plain text claim in a decade or so. Emails should only be in plain text. JCD: It would be easier for me to comply with this rule if I understood the rationale. My perception is that this rule is not relevant any more. Against this rule, I claim that the readability of replies in text-only threads is much worse, unless the replier spends ages paying attention to text formatting by hand which is not acceptable. At least, that was the case the last time I tried. There are several fairly simple reasons supporting Glenn's point (Julian's is simple excessive): You forgot an important one: the archives don't support HTML. A great deal of information might get lost if you're relying on HTML formatting to convey your message. --tobie
Re: Feedback on Quota Management API
On 5/30/12 6:30 PM, Kinuko Yasuda kin...@chromium.org wrote: Thanks for the feedback! On Tue, May 29, 2012 at 11:07 PM, Tobie Langel to...@fb.com wrote: On 5/17/12 11:02 AM, Kinuko Yasuda kin...@chromium.org wrote: For context for others, I assume they are comments for the draft pushed at: https://dvcs.w3.org/hg/quota/Overview.html I'm super excited to see an API for this is in the works. It's been a much wanted feature by developers. Couple of thoughts/questions (sorry for the late feedback, I was on parental leave): 1. My experience with measuring maximum storage quota in existing implementations shows that while some implementations share a common quota across different data stores (e.g. 10 MB for both localStorage and AppCache on iOS last time I looked), not all do. What's the reasoning behind enforcing this (is it easier for implementors? Better for developers?) and is there agreement across implementors that this is the way forward? I believe this is for developers and users. (I don't think this would make it easier for implementors) Today we have multiple API options to store data locally, but most users wouldn't care which API an app is using. They might be interested in how much data is stored by an app or why my disk is getting tighter, but wouldn't be interested in I'm ok with API X storing B bytes, but not for API Y. Similarly I can imagine developers would care about how much more they can store for their app, but they wouldn't want to care about multiple quota values for each API. Overtime they may want to switch storage APIs, but if the switch requires quota adjustment across storage that sounds very awkward. This idea has been discussed several times on this list before, and in my belief there's some consensus we want to have a single quota across different storages (some pointers from past discussion: [1][2]). [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0400.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0357.html Makes sense and thanks for the pointers. 2. If the case is that we're going for a binary choice (i.e. persistent vs. temp data stores) why not create specific methods for each rather than pass a constant (or string) as first argument: e.g.: navigator.storageInfo.queryTemporaryUsageAndQuota and navigator.storageInfo.queryPersistentUsageAndQuota That'll avoid having to deal with typos in the first arg, error handling in that case, etc. I haven't thought about this before, nor have a strong opinion on this, but I remember that in the past someone has commented that only two storage types might not be enough. I don't think we want more storage types right now, but keeping it as enum or constant would make it easier to add more storage types in a future. What do you think? I can't think of a storage type (or anything else, for that matter) that would be neither persistent nor temporary. Also: http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html --tobie
[IndexedDB] Normative content arguably informative in IndexedDB LC draft
Hi, Section 6 (Privacy) and 7 (Authorization) of the IndexedDB LC draft[1] feel very informative, yet they're not marked as such. Is there ground to keep them as normative content or should we explicitly mark them as non-normative, remove their usage of the RFC 2119 MAY keyword, and mark the linked references ([COOKIES]) as informative? Best, --tobie --- [1] http://www.w3.org/TR/2012/WD-IndexedDB-20120524/
Re: Feedback on Quota Management API
On 5/30/12 9:03 PM, Eric U er...@google.com wrote: On Wed, May 30, 2012 at 11:59 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/30/12 2:05 PM, Eric Uhrhane wrote: How about session, which is guaranteed to go away when the browser exits Should it go away if the browser crashes (or is killed by an OOM killer or the background process killer on something like Android) and then restarts and restores the session? Should it go away if the user has explicitly set the browser to restore sessions and then restarts it? Off the top of my head, I dunno. I was just giving examples to explain that I can't think of any other storage types isn't a very solid argument that there will never be any more. I'm not actually proposing that we implement any of these at this time. Agreed, that's orthogonal. I was trying to make two points. The first, pedantic, that the union of persistent and temporary storage was the universe and thus that all future data stores would fit in either one of those (e.g. Session goes in temporary, document-local would necessarily have to be one or the other (or in both), etc.). The second, that avoiding the first parameter would make the API more readable, more weby, more robust, and still as extensible (nothing prevents adding a `navigator.storageInfo.querySessionUsageAndQuota` property). Also, having read Robert's blog post now, I think he makes some good points, especially w.r.t. feature detection. Yeah, that was a timely finding, bumped into it minutes after my first email. --tobie
Re: Feedback on Quota Management API
On 5/17/12 11:02 AM, Kinuko Yasuda kin...@chromium.org wrote: Thanks for the feedback! For context for others, I assume they are comments for the draft pushed at: https://dvcs.w3.org/hg/quota/Overview.html I'm super excited to see an API for this is in the works. It's been a much wanted feature by developers. Couple of thoughts/questions (sorry for the late feedback, I was on parental leave): 1. My experience with measuring maximum storage quota in existing implementations shows that while some implementations share a common quota across different data stores (e.g. 10 MB for both localStorage and AppCache on iOS last time I looked), not all do. What's the reasoning behind enforcing this (is it easier for implementors? Better for developers?) and is there agreement across implementors that this is the way forward? 2. If the case is that we're going for a binary choice (i.e. persistent vs. temp data stores) why not create specific methods for each rather than pass a constant (or string) as first argument: e.g.: navigator.storageInfo.queryTemporaryUsageAndQuota and navigator.storageInfo.queryPersistentUsageAndQuota That'll avoid having to deal with typos in the first arg, error handling in that case, etc. Best, --tobie
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 9:54 PM, Travis Leithead travis.leith...@microsoft.com wrote: Glenn, isTrusted is the indicator that helps the web developer distinguish between an event fired by the UA, or one fired by JavaScript (e.g., dispatchEvent). From: Glenn Maynard [mailto:gl...@zewt.org] What's the point of isTrusted, anyway? You have to trust other scripts running in the same page anyway. Does it come into play with cross-origin iframes or something? See http://www.w3.org/TR/DOM-Level-3-Events/#events-event-type-isTrusted --tobie
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 10:00 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Apr 24, 2012 at 2:54 PM, Travis Leithead travis.leith...@microsoft.com wrote: Glenn, isTrusted is the indicator that helps the web developer distinguish between an event fired by the UA, or one fired by JavaScript (e.g., dispatchEvent). I know what it does; I'm asking what its purpose is. When is this useful? Are you asking about the purpose of exposing the property or the purpose of trusted events? The latter's obvious: prevent visited content from triggering actions the UA wants to allow only after a user action. The former I'm not sure. --tobie
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 11:04 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/24/12 5:02 PM, Boris Zbarsky wrote: Oh, and that's before we get into default actions implemented by extensions. And one more thing: extensions _definitely_ want to know whether events are trusted or not. This doesn't necessitate a web-exposed API, obviously; the property could only be visible in extension code. But it does necessitate the internal flag. So is it exposed to web content to fulfill particular use-cases? --tobie
Re: Draft report for offline apps workshop
On 4/7/12 1:42 PM, Arthur Barstow art.bars...@nokia.com wrote: I kinda' recall there was a proposal in the HTML WG to move the app cache functionality to a separate spec. Does anyone know the status of that proposal? I don't know what the status is, but we'd be highly supportive of such a split. --tobie
Re: publish Candidate Recommendation of Web Workers; deadline April 11
On 4/4/12 5:37 PM, SULLIVAN, BRYAN L bs3...@att.com wrote: I support the publication as a CR. +1
Re: publish Candidate Recommendation of HTML5 Web Messaging; deadline April 11
On 4/4/12 5:37 PM, SULLIVAN, BRYAN L bs3...@att.com wrote: I support the publication as a CR. +1
Re: Regarding app notification and wake up
I second Bryan's request. Having apps that need to monitor remote events each spawn a (shared)worker to do so could drain a phone's battery very quickly. There needs to be a system-level way to do this. --tobie On 3/12/12 11:47 PM, SULLIVAN, BRYAN L bs3...@att.com wrote: Karl, excellent questions. Re (1), there are various systems of device addressing in use today, largely dependent upon the notification delivery system. An assumption to start with is that barring any optimizations which enable seamless switching between SSE connections and connectionless delivery (which requires a delivery agent/client on the device, feasible but still an optimization - we can table that for now, in this discussion), is that the webapp coordinates whatever connectionless/shared delivery system is to be used along with the appropriate addressing scheme and address, with the webapp server prior to the switch (or in the setup of the original connection). Without getting too deep in to specific system designs I can say that this does work and can demo the concept pretty soon (I'm implementing a demo now). Re (2), since the webapp creates a specific eventsource object (using SSE as the model), there is a direct thread back to it from the user agent. What is needed for the user agent to deliver only the specific events that the webapp desires, is that there needs to be some filter criteria that is negotiated with the webapp server (or delivery system) e.g. as part of the original eventsource object creation. In OMA Push, we have an Application ID header that is used for this purpose (it can carry any arbitrary value, and be used by the user agent or a local Push Client to filter out events other than those desired). Webapps can also use any arbitrary application-layer data to filter or apply trust to incoming events, but this is a convenient thing to do by a UA or Push Client and that's why we included that in the OMA Push design. Other notification delivery systems probably have similar features. The goal is not however to reference delivery-system specific features directly in the W3C API, but to describe how such app addressability is possible in general, and at most to all generic filter criteria mechanisms to the API (e.g. this header equals that value, or more generically this token is present with that value). Re (3), I think the web authentication system (same-origin policy and CORS) is strong enough for what is needed here. Beyond that, apps can use any high-order security for authentication/authorization tokens to be included in the application data or as headers (in delivery systems that follow the HTTP header+body model, ala OMA Push). There's probably a lot in the above statements that need to be unpacked in more detail. That's why we proposed this for the charter update. We have been involved in Push-based enabler and service design since pre-2000, and with that background I think we have a good foundation to resolve the questions you noted. Thanks, Bryan Sullivan -Original Message- From: Karl Dubost [mailto:ka...@opera.com] Sent: Monday, March 12, 2012 2:04 PM To: SULLIVAN, BRYAN L Cc: Ian Hickson; Stefan Hakansson LK; public-webapps@w3.org Subject: Re: Regarding app notification and wake up Le 9 mars 2012 à 19:43, SULLIVAN, BRYAN L a écrit : This is different from the earlier discussion on extending SSE to connectionless event sources, as there's no assumption the Webapp is running in this case. If the Webapp *is* running, it's within the scope of what we have discussed earlier as SSE extensions (and not technically a wakeup). If I understood the use case, it means that 1. the device is addressable (except for customers with a subscription to a Mobile Operator, not sure how we would do that. Any ideas? Maybe on local network that would be feasible but doesn't answer the use case it seems.) 2. the software is addressable (more than one software able to process a specific request. Think about Opera and Firefox on the same device.) 3. that also requires a strong authentication system I can see the appeal, but I balance it with spam at large scale too. The UX model of SSE is that the user is still initiating the call. Related to the initial mail http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008 http://bkaj.net/w3c/eventsource-push.html -- Karl Dubost - http://dev.opera.com/ Developer Relations, Opera Software
Re: CfC Re: Charter addition proposal: screen orientation lock
In the Screen Orientation API draft, I don't see any references to locking. Is this by design? It's in the abstract: The Screen Orientation API's goal is to provide an interface for web applications to be able to read the screen orientation state, to be informed when this state changes and to be able to lock the screen orientation to a specific state. --http://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html --tobie
Re: CfC: Proposal to add web packaging / asset compression
I'm not particularly set on one direction to solve this problem. I just want to get it solved, and if SPDY, along with a much improved programmatically controllable appCache is the preferred solution, let's go for it. I, along with probably plenty of other web developers, am still inexperienced with SPDY, and thus, maybe we should take this conversation into a different direction, trying to come up with a backward-compatible SPDY demo that solves every issue of asset delivering and caching. Here's a rough list of things it needs to do: You should grab a copy of Chris Strom's The SPDY Book (http://pragprog.com/book/csspdy/the-spdy-book). Best way I found to get up to speed (pun intended) on SPDY (and I'm usually not a fan of tech books). --tobie
Re: Numeric constants vs enumerated strings
On Wed, 15 Feb 2012 14:57:00 +0100, Harald Alvestrand
har...@alvestrand.no wrote:
*This is a call for help from the WEBRTC working group.
We are defining a new API
(http://dev.w3.org/2011/webrtc/editor/webrtc.html) about:blankwhich
has a number of cases where it needs to use arguments, or expose state
variables, that can take only a limited set of values.
Unless there are strong ties to certain legacy APIs I would suggest using
strings. They are easier for developers to author, easier for developers
to maintain, easier in the future to extend, and have practically no
drawbacks.
I second that. Authors barely ever used the defined constants (for good
reason, some implementations were missing them) preferring to use integers
directly.
Instead of seeing the verbose but descriptive:
if (node.nodeType == Node.ELEMENT_NODE) { ... }
one came across the following more often than not:
if (node.nodeType == 1) { ... }
to which:
if (node.nodeType == element) { ... }
should be preferred.
Constants would only have practical benefits over strings if they were
defined in the global scope, as in:
if (node.nodeType == NODE_ELEMENT_NODE) { ... }
as typos would be caught early on (undeclared variables throw
ReferenceErrors).
--tobie
Re: Enabling a Web app to override auto rotation?
Device-level orientation lock deals with different use-cases than the ones we are discussing here. It let's the user force the device into either of portrait or landscape mode whatever the physical orientation of the device actually is. The main reason for this need is that orientation of the device is relative to the Earth's gravitational field and not to the physical position of the user. That's typically annoying when you want to read while lying down on your side. If the device's orientation was obtained relative to the user's face (e.g. by means of a camera doing facial recognition) the need for a device-level orientation-lock might not even exist. Document-level orientation lock is different. It isn't so much about enabling applications to change orientation as it is about signaling to the UA that UI only exists in one of portrait or landscape mode. A good analogy is to think of photos or movies. The device's orientation (or the dimensions of the screen) on which they are displayed won't suddenly modify their characteristics. A picture in portrait mode is a picture in portrait mode. Rotating it sideways won't suddenly turn it (hah!) into a picture in landscape mode. How the device decides to display it (cropping it, surrounding is with black bars, asking the user to rotate the device) is an orthogonal issue. Of course there are a number of points of friction (e.g. how do you handle document-level and system-level oreientation-locks conflict, what happens when you browse through a series of documents which have different document-level orientation-locks, etc.), but these are best discussed as part of the WG's work rather than in a preamble to decide whether or not this is worth adding to the charter. --tobie On 2/10/12 6:28 AM, timeless timel...@gmail.com wrote: Personally I consider this a QoI issue for UAs. There will be lots of web pages that won't support / use this auto-rotation suppressor. UAs will need and want to let their users deal with this. The BlackBerry PlayBook for instance has an item for it: swipe in from top right corner, tap the orientation widget, select lock orientation, tap the application content area, move on with life. I'm not saying it's perfect, and I've been planning to write out more detailed proposals for more advanced things, but sometimes adding a web-API doesn't really help the user. This isn't a web page problem, it's a system problem, and the user will benefit from having a *single* and *consistent* method for addressing it across all applications, native, web, and web written by other people who decide to put buttons and widgets in places the user won't expect. Disclaimer: while my employer isn't endorsing my opinion, I'm happy to use its products. On 2/8/12, Tobie Langel to...@fb.com wrote: The general use case is any UI that's been designed exclusively for portrait or landscape mode because displaying it in the other mode either doesn't make any sense (e.g. most platform games), requires some artifice that the designer wanted to avoid (e.g. to function in landscape mode, e-readers rely on the book metaphor), or isn't cost effective (i.e. it requires designing two radically different UIs instead of one). --tobie On 2/8/12 9:16 AM, Marcos Caceres w...@marcosc.com wrote: On Wednesday, 8 February 2012 at 07:39, Charles Pritchard wrote: In case it's needed; use case: User is drawing a sketch on their mobile phone and their rotation is intentional as if they are working with a physical piece of paper. or a car game where the driving is controlled by how much the device is rotated (you want the orientation locked, probably to landscape)Š There are other games, like Rolando [1], that make use of both portrait, landscape, and a kind of fixed modeŠ where the orientation is fixed no matter what way you rotate the screen (think of rotating a video cameraŠ the world in the view finder stays fixed) [1] http://rolando.ngmoco.com/ -- Sent from my mobile device
Re: Enabling a Web app to override auto rotation?
Absolutely. This is currently handled at the application level by the games themselves, which is ridiculous. If there was a proper way for a game to specify in what orientation it was supposed to be played, then conflicts between the game's needs and the device's current orientation could be handled at system level and be consistent across all applications. --tobie On 2/10/12 8:29 AM, Jordan Dobson jordandob...@gmail.com wrote: One way people do this today already is to use media queries to hide the UI when it's rotated into an orientation they don't support. Example: * http://mrgan.com/pieguy/ * http://cl.ly/E5fw * http://cl.ly/E56V Hope this helps if anyone is looking to do anything similar in the near future. - Jordan On Thu, Feb 9, 2012 at 9:28 PM, timeless timel...@gmail.com wrote: Personally I consider this a QoI issue for UAs. There will be lots of web pages that won't support / use this auto-rotation suppressor. UAs will need and want to let their users deal with this. The BlackBerry PlayBook for instance has an item for it: swipe in from top right corner, tap the orientation widget, select lock orientation, tap the application content area, move on with life. I'm not saying it's perfect, and I've been planning to write out more detailed proposals for more advanced things, but sometimes adding a web-API doesn't really help the user. This isn't a web page problem, it's a system problem, and the user will benefit from having a *single* and *consistent* method for addressing it across all applications, native, web, and web written by other people who decide to put buttons and widgets in places the user won't expect. Disclaimer: while my employer isn't endorsing my opinion, I'm happy to use its products. On 2/8/12, Tobie Langel to...@fb.com wrote: The general use case is any UI that's been designed exclusively for portrait or landscape mode because displaying it in the other mode either doesn't make any sense (e.g. most platform games), requires some artifice that the designer wanted to avoid (e.g. to function in landscape mode, e-readers rely on the book metaphor), or isn't cost effective (i.e. it requires designing two radically different UIs instead of one). --tobie On 2/8/12 9:16 AM, Marcos Caceres w...@marcosc.com wrote: On Wednesday, 8 February 2012 at 07:39, Charles Pritchard wrote: In case it's needed; use case: User is drawing a sketch on their mobile phone and their rotation is intentional as if they are working with a physical piece of paper. or a car game where the driving is controlled by how much the device is rotated (you want the orientation locked, probably to landscape)Š There are other games, like Rolando [1], that make use of both portrait, landscape, and a kind of fixed modeŠ where the orientation is fixed no matter what way you rotate the screen (think of rotating a video cameraŠ the world in the view finder stays fixed) [1] http://rolando.ngmoco.com/ -- Sent from my mobile device -- Jordan Dobson ? Designer / Developer ? 425-444-8014 ? JordanDobson.com http://JordanDobson.com
Re: Installing web apps
On 2/9/12 1:21 PM, Marcos Caceres w...@marcosc.com wrote: On Wednesday, February 8, 2012 at 10:33 PM, Adrienne Porter Felt wrote: I agree that the current UI is not great. However, I disagree about everyone clicking through permission grants. I've done two user studies and found that about ~18% of people look at permissions for a given installation, and about ~60% look occasionally. We found that most have no idea what they really mean -- but that is a separate problem pertaining to the presentation. Also, about 20% of people have in the past avoided apps that they considered bad because the permissions alerted them to something that they didn't like. Did you publish this research somewhere? Would be interested to know your sample size and type, response rate, etc. It's in submission, but I can put together a tech report if you are interested. Results are from two studies: self-reported data from 308 online Android users (recruited via Admob), and confirmed by an observational study of 25 Android users in the bay area (selected from a large pool of Craigslist applicants so that they match the overall Android population by gender, age, etc.). At Facebook, we use a pretty fine-grained permission system for users to grand third party apps access to their data, rights to post on their behalf, etc. The correlation between the number of permissions requested by the app and the percentage of users which will avoid using the app altogether is strong, so much so that we're warning devs against asking for too many permissions upfront: There is a strong inverse correlation between the number of permissions your app requests and the number of users that will allow those permissions. The greater the number of permissions you ask for, the lower the number of users that will grant them; so we recommend that you only request the permissions you absolutely need for your app. --https://developers.facebook.com/docs/authentication/ Only ask for the permissions you actually need; the more you ask for, the less likely users will grant them. Users may join your app and automatically trust their friends, but the first hurdle is trusting your app when first prompted with the permissions dialog. --https://developers.facebook.com/socialdesign/personalize/ Instead, we advocate a permissions model which lies somewhere in the middle of what has been discussed here so far: There's an initial request of permissions done prior to the app being first used. If these permissions are granted, they are granted indefinitely (or until the user revokes them). If they are not, the app just can't be used. After that, the application has the possibility to ask extra permissions any number of times. This is typically done following a user action that the existing permissions won't allow. Permissions granted that way (and this is key difference with the models discussed so far) are also granted indefinitely. Best, --tobie
