See also: IRC log
<kotakagi> Intro presented by Natasha
<schuki> action Natasha to speak to marcos re having no teleconfs
<trackbot> Created ACTION-76 - Speak to marcos re having no teleconfs [on Natasha Rooney - due 2013-11-21].
<mounir_> ScribeNick: mounir_
schuki: we are going to discuss a
few topics that we discussed before because we believe they are
important for the web and mobile
... we will discuss the history of these topics, the issues that exists in current proposals/implementations and new work/potential issues
... we want to make sure we get some outcome from this work
... we will have some guest speakers for some topics
... lets begin with the first topic, which is offline
... it has been a hot topic here at tpac
... if anybody has extra insights, please feel free to raise your hands
<scribe> Scribe: mounir_
schuki: <describes appcache
... <describes what IndexedDB is>
... regarding the issues, appcache is hard to use, especially for large applications
... appcache has a fallback system when there is no network
... this method is assumed to be broken
... people expect to use the cache first and download in the background
... this creates strange issues
... lot of times with appcache, you have to declare things in the server
... which is a bit hairy sometimes
... local storage seems robust enough but can only use strings
mounir_: the main issue is that it is actually doing sync operations
schuki: regarding IndexedDB, the
main problem is the learning curve
... I will go to the new proposals to solve offline
... the first one is Service Worker, proposed by Alex, from Google
... <showing the GitHub project>
... service worker is more robust that appcache
... it is solving the issues so far
... my personal opinion is that we should go and implement that solution
... and I would encourage every one to follow the repo
... so, how can WebMob help with that?
... we could write a testing demo app
... any question or comment to the offline conversation?
... we will break for 45 minutes because the next topic involves Bryan Sullivan and he is not here yet
... thank you everyone
<dka> Scribe: Dan
<dka> ScribeNick: dka
NR: We are evolution of the CoreMob group.
NR: [presents the CoreMob
... Since the report was published, geolocation and video are "interoperable".
dan: what does that mean? can we wait until marcus comes online to clarify?
koichi: [speaking of yesterday's geolocation session]
koichi: [making reference to yesterday's TPAC breakout on geolocation - and nest steps for geo API]
NR: I will add this as a note to
... Marcus has raised a number of issues associated with the coremob report. He's flagged a few of them as needing review - meaning priority is higher. This give us the opportunity to make further comments.
NR: is this report applicable to what we do, or should we create something else?
dka: I think we should not issue a new report, but rather we should move forward on the basis of this report. Possibly we should consider the issues raised and issue a new version.
NR: [more description of CoreMob
... [ presenting www.w3.org/Mobile/mobile-web-app-state/ ]
... this is a way to keep up to date with the specifications...
... [going through some additional comments]
<schuki> 3 options to move forward:
<schuki> 1. continue to build the report
<schuki> 2. leave the report as it is and work on a new coremob 2013 / 2014 doc
<schuki> 3. leave the report as it is and work on www.w3.org/Mobile/mobile-web-app-state/
tobie: having edited coremob
report. There is some overlap between coremob report and Dom's
report (mobile web app state). One reason I started it was to
have the info in one place on status of specs and
implementations that we care about for mobile.
... I don't think publishing a document is the best thing - rather something with a shorter lifespan. Maybe something slightly different - a central place that people can look at - what's missing, what's the state and what should people look at? I would try to merge these two documents.
NR: A document is pretty static...
tobie: another point - I've been building infrastructure to make a document be a more live doc - there is info on the state of specs available via an API - a document could have fresh data on the state of certain APIs and so be up to date all the time.
NR: that would be awesome.
NR: any suggestions on keeping up to date with implementations?
tobie: this is related to running tests - I am leading this effort to have a system to make it easy to run the test suites people are building for each stack and make it easy for mobile industry to run these tests internally, in a single place, with an API - which could be build upon to show what the "state of the union" is - we need resources to continue to this work.
<tobie> dka: we should wait for dom to make a decision on this
Mounir: if you go to chromestatus.com you have a huge list of features you can reference in chrome.
<tobie> … also see if there are info from the current vendors available we could leverage.
NR: we could pull this kind of thing into automatically update the document that we choose...
dka: what does it mean to have a live document?
NR: I'd like to choose one or the
other - my preference would be to continue with the webapp
... we can manually add to it in the short term, incorporate material from other sources with the goal having it be completely automated.
<schuki> action Natasha to check coremob and webappstate doc include the same spec
<trackbot> Created ACTION-77 - Check coremob and webappstate doc include the same spec [on Natasha Rooney - due 2013-11-21].
dka: do we update the coremob doc to point to mobile web app state? and does mobile web app state contain all the same specs as coremob?
<schuki> action natasha to check with dom whether we can discontinue coremob and just work on webappstate
<trackbot> Created ACTION-78 - Check with dom whether we can discontinue coremob and just work on webappstate [on Natasha Rooney - due 2013-11-21].
<schuki> action natasha to check status of chromestatus + testing effort and see if we can add apis to manage the webappstate document automatically (long term goal)
<trackbot> Created ACTION-79 - Check status of chromestatus + testing effort and see if we can add apis to manage the webappstate document automatically (long term goal) [on Natasha Rooney - due 2013-11-21].
NR: if people are interested in working on webapp state document or coremob doc - then please let us know.
dka: how are we going to continue the work of coremob? e.g. for new use cases, new features, new specs, etc...
NR: we are going to work on focus topics, e.g. offline, spec is service worker, service worker spec will be included into this document...
dka: where will we document the use cases that come out of the focus topics?
NR: there is no need to work on
use cases or requirements for these focus topics...
... we can continue to write scenarios such as in the coremob document - we can say "we thing web apps should be able to do XYZ in the future"... but we need people to write those scenarios down.
... the only way it will happen with people being busy is if its a regular recurring action / topic.
... sometimes the answer might be we don't have any new ones - or new ones may arise, e.g. with augmented reality.
dka: does that document become a document of this working group?
NR: in some cases we don't need
to create requirements - e.g. offline where they already have
use cases and requirements. We need to find out what is missing
and then put it in.
... the wiki describes the group in better detail. We can add use cases and requirements.
<schuki> action Natasha to add to DELIVERABLES: adding use cases / requirements section to coremob / mobilewebapp state document and add use cases / requirements to regular meetings
<trackbot> Created ACTION-80 - Add to deliverables: adding use cases / requirements section to coremob / mobilewebapp state document and add use cases / requirements to regular meetings [on Natasha Rooney - due 2013-11-21].
NR: I'm going to add "the document" to our deliverables and add use cases and requirements to our regular meetings - a regular deliverable for us.
dka: cordova is starting to produce stats about what apis apps produced with cordova actually use.
tobie: we worked on this at
Facebook 2 years ago - it's a good exercise [analyzing top 100
apps]. I saw work on the mailing list that did some not manual
work - automated analysis of android APIs. the output of that
data is wrong, and brings the focus on the wrong feature set.
Intrepreting the data is the tricky thing. The permissioning
model of android is different from android - a lot of the key
APIs that came out of that discussion don't transpose to the
... you need to do some manual work.
dka: I don't disagree.
NR: we will talk about that in closing the gap with dom tomorrow as well.
<tobie> Phonegap data looks like a great source of information
NR: Any other comments?
CP: did anyone look at business models?
NR: We want to do that - it's key
to organizations who are members - especially from
... business models are important - use cases might dip into that.
... we could have business use cases.
CP: I was more thinking that native apps have business models - they are sold or have something sold in them [in-app].
NR: One of the focus topics is on payments - which is related. It's different with apps - it's a "closing the gap" topic. There is an easy way for a native app developer to [monetize].
Mounir: there is business on the
web and also you can sell webapps...
... i don't feel there is much technical solution / [discussion] we need to have there...
tobie: when we started the
coremob CG - we were looking at 3 aspects.
... one is closing the gap
... two is the business model. You need to have developers who are making money.
... the last is distribution - app markets, search, social channels...
... making money building web applications is a problem - it is solved to some extent through ads and through payments. One thing that hasn't been addressed yet is to think about carrier billing - these apps are running on devices that are connected to users' phone bills?
mounir: is carrier billing something that people use out of developing countries.
dka: Telefónica has direct-to-bill payments rolled out with Microsoft and Google (app markets) in Spain and for Microsoft app market in the UK. It is effective when it can be done. There are challenging regulatory and integration issues which have held them back.
NR: I like the idea. Dave Ragget will come talk about web payments tomorrow.
dka: I am co-chairing the upcoming workshop on web payments happening in March - a core part of this will be mobile payments.
NR: one thing we could do in this IG is to work on use cases and requirements.
CP: not everyone is looking for financial payment - focusing on payment might be limiting.
CP: social reach, branding
... other economies -
NR: the Web naturally reaches
more people than native platforms...
... lots more web users - I will find the research.
<Zakim> tobie, you wanted to comment on biz models and to
tobie: interesting - about other
incentives - but that said it would be good for this group to
answer the question of precisely what part of the ecosystems
are needed for there to be a turning point where mobile web is
good enough to compete with native.
... what's missing is the quality applications and premium content on mobile which is not accessible on the web right now.
<Zakim> tobie, you wanted to comment on mobile strategies
dka: star trek example - star trek poster on the underground says "download our app" at the bottom - there is a reason they put that there to engage the end user to go to the cinema to watch a movie - what's stopping them from putting "go to our web site"?
tobie: use case for looking up
flight times in genevva - couldn't access landing times for
planes from an iPhone... so what was wrong with the airport?
after that, I saw "gvapp" - the airport's mobile strategy is
"let's have an IOS app and an android App".
... an international traveler going to download an app just to get airport info? doesn't make sense. Companies are trying to have a mobile strategy and they hire someone to build apps - and the only thing they know because it's cool and trendy is IOS and Android. But for a ton of use cases which would be better served by the web - this a key item to discuss. We need a strategy to address this.
NR: this will get taken up as closing the gap.
tobie: it's not a technological
problem - it's educating developers and also addressing the
business-level people - giving the message out that the web
solves a bunch of use cases better than native.
... having an add with "download this app to engage" is a daft strategy,
... it's hurting businesses - there is a strong business case to be made for the web in lots of scenarios.
Mounir: from a tech standpoint we are mostly ready - but people are not used to using web apps on the mobile - it's a mind-set issue. If you go back a couple of years ago, it was "IOS app" now it's "android and IOS" so hopefully it will change...
dka: as the number of platforms increase will the interoperability story of the web start to resonate more?
Mounir: do we know how much cordova is used - e.g. in the android app stores?
tobie: I believe it is something like 4% - so 1000s of apps.
<schuki> action Natasha to add 'education to devs on how the web solves your app use cases' to things we want to work on, as maybe the gap in development is due to education as well as other factors
<trackbot> Created ACTION-81 - Add 'education to devs on how the web solves your app use cases' to things we want to work on, as maybe the gap in development is due to education as well as other factors [on Natasha Rooney - due 2013-11-21].
tobie: still today a lot of
content in the native Facebook app is HTML5 - one of the reason
we expanded the native element was the performance issue.
... I will dive deeper into this - e.g. scrolling performance - later today.
... the technological gap needs to be addressed. Companies that have enough resources are handling the technical challenge by going native and handling the multiple code bases problem by keeping as much code as possible as html5.
... not addressing the cross-operating system thing that much. what they are addressing is that it's difficult to ship a new application. On the web you ship the code and agile companies are shipping code to production many times a day - you can't do that with native. Outside of this particular issue which is applications that have requirements to be native - there are a lot of use cases that would be better for everyone if they were a [expletive deleted] web site.
NR: I've added education as an action.
tobie: also education to c-types; to business guys.
NR: lunch now
... back at 2
<tobie> OWP on mobile has a branding problem
<sangwhan> scribenick: sangwhan
[Self introduction time]
Natasha: this afternoon we will
be covering several topics
... as on the screen (wiki page)
... we are doing some small task forces to help developers write mobile apps
... if you have questions add yourself to the queue
... please use the irc if possible
... tobie will talk a bit about scrolling, and sangwhan might add some commentary
tobie: i looked into this a bit,
while i'm not the best candidate to talk about this
... before working testing in w3c i worked on mobile related matters
... one of the reasons why we did a transition between web/native was scrolling performance
... smoothness is key, and smooth scrolling is a difficult problem to solve
... apart from gaming, it is one of the most intensive operations on mobile platforms
... i've been trying to get the css working group to find a solution to this
tobie: some of the suggestions i
got from fb engineers have been shared on the coremob
... while i don't have a solution this group should definitely look into this
... infinite scroll is something i would like to see in future applications
... this isn't particularly easy due technical challenges of how browsers work
... the big problem is that devs are implementing these features in js
mounir_: Does using a worker to fetch data help?
<dka> Good example of infinite scroll: qz.com - also one of the companies /web sites on the forefront of the progressive mobile web.
tobie: workers are pretty much
what everyone uses
... but it still doesn't help because layout et al is done in the main thread
... cloning the dom tree into a worker might be one approach
... you could possibly bind processors to particular elements in the dom
... neither i nor the group should be the ones who come up with the solutions
... and we should bring the problems to the groups and have them solve it
Dan: the web is a page, with a
top and a bottom - and infinite scrolling is a different
... there are clear philosophical differences between the initial design and infinite scrolling so far is a hack that goes on top of it
... has this been discussed or is this a tag issue?
tobie: probably tag
... ever since i started working with the w3c the market has already changed from documents to applications
<bryan> +1 the infinite scrolling ship has already arrived in port
tobie: scrolling through a lot of content is something that we would want to do
Dan: I was talking about a page,
where a end of the page is the end of the page
... what i was noting is that you are bringing up that now the end of a page isn't really the end of the page
tobie: Ads probably influenced
... but on a mobile device scrolling and swiping is a natural ux
schuki: thanks for the input
<schuki> sangwhan: appending things to the dom comes with a memory problem, so there needs to be some work on garbage collection
sangwhan: mobile devices have
limited memory, and while infinite scrolling is a natural ux
you'll eventually run out of memory
... e.g. explicit gc of elements that have left the viewport
tobie: while you have a point and this is necessary, this is not necessarily gc but there should be a solution
bryan: re what tobie posted to the coremob list, we researched those issues and verified many of them, e.g. particularly for HTML5 games - Scrolling and UI fluidity, touch events/tracking, Hardware acceleration control, Multiple audio tracks for background & effects, Audio sync with animation & video
christine: i consider the
infinite scrolling problem as a infinite map
... we should think about this in a approach where this is a map, not a list
tobie: good point
... it should be made so that there are components that can be used
<bryan> these items I listed are on our performance priority list for WebMob re closing the gap with native
tobie: if you have a blob of data
that you want to look at, you want the native layer to do the
... a lot of data in a small screen, we just need to figure out the most sound technical solution to address this
<bryan> we need to document the gaps on the wiki with links to examples and analyses that people can reference
tobie: there are a lot of things
that fall into the scrolling category
... not sure if css wg has looked into this
<dom> has anyone brought up CSS OM View yet?
mounir_: @@@ has been trying to address this problem
tobie: we should come up with the problems and approach the wgs
mounir_: nowadays, browsers are doing off the main thread scrolling/compositing, if you use those modern browsers, workers and be mindful with memory usage (do not keep the entire newsfeed in the DOM), maybe things could already be better? I feel that there are some experiment that could be done here.
tobie: if you keep adding stuff
at the end of the dom you'll hit problems
... the reason why devs get it "wrong" is because it's not a simple problem
... browsers should try to address this
schuki: we need to move on to the
... next topic is testing
... which is also covered by tobie
[Tobie asking people if they are familiar with the testing efforts]
<schuki> action scrolling use cases should be documented, also make notes as we may need user agent action as well as developer-focused options
<trackbot> Error finding 'scrolling'. You can review and register nicknames at <http://www.w3.org/Mobile/IG/track/users>.
<bryan> how to continue the CoreMob focus on setting priorities for testing of features
tobie: those who are unfamiliar feel free to ask questions
tobie: wrt testing is that it's expensive and companies need to fund it
<schuki> action Natasha (to reassign) scrolling use cases should be documented, also make notes as we may need user agent action as well as developer-focused options
<trackbot> Created ACTION-82 - (to reassign) scrolling use cases should be documented, also make notes as we may need user agent action as well as developer-focused options [on Natasha Rooney - due 2013-11-21].
<bryan> we need to know what the users need, and focusing the effort to analyze priorities will help optimize the ROI for mobile stakeholders
<bryan> we need to measure what users need explicitly through outreach, polls, etc. depending just upon what the insiders think will only take us so far
<bryan> the WebMob group can help focus this effort as a community of interest
<bryan> we need a WebMob 2014 document or something similar, to help frame the current thought on key testing goals. Our position at the close of CoreMob was that CoreMob 2012 was not a "one and done"
mounir_: We discussed testing APIs that are hardware related a few months ago, like battery api or a messaging api. It is hard to test because you do not have access to the hardware to verify if what should happen happen. Do you have any update on this?
schuki: next topic will be covered by bryan
bryan: if we want someone to fund
the mobile testing we need to make sure that people understand
that we will make good use of it
... the spec you are seeing is a working draft of the push api, from 4 months ago
bryan: we are currently going
through a pag
... we had some other work in att going on to send notifications
... what we have here is similar to that, but the current spec needs a prior agreement
... there was wap, but for the web we needed something simpler
... for this we came up with a api that is delivery system independent
... the spec doesn't talk about what the transport mechanism is, and that was part of the goal
... in the spec we mention a couple standard transport methods, but there are many non-standard methods as well
... the toc in the spec gives you a pretty good outline
... the security model is based on the DAP approach
... initially we did not use promises, but now most specs including ours has changed to make use of promises and service workers
... there are some things we need to work on, i don't have a very good understanding of service workers
<JonathanJ> Service Worker - https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md
[Q&A about technical details of Service Workers]
DanS: my understanding of SW is
that it won't work when there is no browser
... how to make this transport independent?
bryan: that is what the spec
looks like as it is
... it's explained to some extent in the flow chart (in spec)
... how the push registration would work we'll need the UAs to figure out
... the current api lets implementations even work completely offline
tobie: what do you mean by offline?
bryan: mobile phones can have
... there is a signalling system that lets you make phone calls
... i was mentioning this
tobie: the next step should be to take the spec and look at which parts of the spec can be implemented using service workers
<anssik> +1 to tobie's suggestion
<anssik> re push & ServiceWorkers, see https://gist.github.com/slightlyoff/7fae65a908ac318f69a3
<JonathanJ> I think that ServiceWorker likes active service manager, Push API likes passive service manager
<schuki> action Natasha (tp reassign) in push api doc there are use cases, we should map them against the push use case in service worker and see what the gap is between the two
<trackbot> Created ACTION-83 - (tp reassign) in push api doc there are use cases, we should map them against the push use case in service worker and see what the gap is between the two [on Natasha Rooney - due 2013-11-21].
bryan: we had two considerations when designing the spec, one is scalability
mounir_: i disagree with your
position regarding privacy
<bryan> +1 to Eduardo's support (the major contributions so far actually)
<JonathanJ> +1 me too
bryan: is this group interested in discussing unresolved questions of the push api
<schuki> action Bryan to send email to public mailing list about anymore work to be done on push api
<trackbot> Created ACTION-84 - Send email to public mailing list about anymore work to be done on push api [on Bryan Sullivan - due 2013-11-21].
<bryan> ScribeNick: bryan
natasha: discussion on the list
led by Marcos and Ernesto on homescreen bookmarking
... link is http://w3c-webmob.github.io/installable-webapps/
dka: are they looking at the
... in FFOS we have a manifest based upon the W3C Widgets Manifest format
... this is where we think things re going, to install via manifest via an appstore
... looking at FT (Financial Times) on FFOS, it uses the API FFOS exposes to check if installed, and offer to user to install if not. It's a hosted app with a JSON manifest.
<JonathanJ> web manifest - http://www.w3.org/2008/webapps/manifest/
dka: those are our use cases. we've seen Chrome implement a similar functionality. So it would be a mistake just to focus on the iOS save to homescreen capability
schuki: our focus is not limited to that
dka: we should document that set
of use cases as described
... documenting the user experience that is wanted should be part of the document
schuki: all of the approaches
should be included; some action on the TF to ensure that, may
need some help
... other call for any more collaborators, please let Marcos and Ernesto know. we need people to help out
<wonsuk> Use Cases and Requirements for Installable Web Apps: http://w3c-webmob.github.io/installable-webapps/
bryan: we should get actual user input on what the install experience should be or would be nice, with some example/demo videos on which we could get user feedback
schuki: developer events may be one way to get that input
dka: someone could step up with money to do a user mockup testing
bryan: maybe thru ADA?
kenneth: maybe a google+ group since there are a lot of devs there; also for getting feedback on issues to avoid
schuki: if anyone wants something
else they need to get involved
... next is to setup a google+ or github group for comments on ideas
<schuki> action Marcos check whether you have firefoxOS included in the installable web apps doc, and if not add it, ask Dan A for help
<trackbot> Created ACTION-85 - Check whether you have firefoxos included in the installable web apps doc, and if not add it, ask dan a for help [on Marcos Caceres - due 2013-11-21].
<schuki> action Natasha setup a github repo / google+ group to canvas opinions from devs on this topic
<trackbot> Created ACTION-86 - Setup a github repo / google+ group to canvas opinions from devs on this topic [on Natasha Rooney - due 2013-11-21].
bryan: we could also include some demo code in the doc to show how devs currently and in the future might use the features (maybe it's already there)
dka: you may have read this
report from vision mobile, sponsored by Telefonica
... the idea was to canvas the dev community and tools vendors on key gaps between native and web on mobile
... one key finding was around performance
... as an issue its on the radar as a key focus area; tobie was addressing performance earlier;
... but other urgency is on APIs - there is some controversy around this re bringing it to par with native
... devs go native to get access to APIs not available on the web; this is changing, and the more APIs we have, the stronger the argument about embracing the web
... e.g. the starwars poster with a QR code linking to an app store vs a web app - fgor now they say it wont work and go away
... Jo feels that to a certain extent the web will never catch up to native
... e.e. latest dark matter or alien detection API
... the argument I would like to put forward is that we need a major shift in how users use the web on mobile devices
... a UI that is from the 80s e.g. mouse/pointers, is not aligned with a world of touch screens
... kids learn how to use a mouse at school as they did not grow up with it.
... the point is that accelerated of development in the platform is not sustainable; we will go thru further shifts but should expect that the touch interface and APIs will be around for a while
... with these key APIs and knowing which are popular, let's add them to the web; native will still be attractive to those that need what the web can't provide, but let's add the core features we can
... the point is what is the relative priority on APIs that are currently in the gap
... Tobie raised some issues around how to survey; but let's have some discussion on what's important on that list
<dka> Popular Cordova APIs
dka: e.g. talked to Phonegap on
that are the popular APIs in that platform; through tht product
they have been able to ID what are popular APIs in the system
... this is initial data, popular APIs that Cordova devs are requesting
... interesting that net info is a highly requested API; its been a persistent question in W3C e.g. whether this is a short term issue
<JonathanJ> Standards for Web Applications on Mobile - http://www.w3.org/2013/09/mobile-web-app-state/
dka: I would argue that devs are
still requesting this API, IMO this falls under the category
that "the device knows about it but we are not letting the
webapp know about it" - why?
... I asked about the use cases for offline and knowledge of the net info ... (missed the rest)
... going on, some are contentious - some are already in scope for W3C e.g. battery
... hoping to bring more voices into this, and to put this into a report
christine: I've been working closely with different stds orgs, one common question e.g. with Kronos, WebGL, WebCL are available for devs
christine: Khronos would like to
make all these APIs available to devs on the web; Khronos do
not do the web so need help
... on Dan's list, 7 of 10 are known/used by the Khronos APIs
... camera is being worked on; a new one is stream input on devices capturing sensor data; Khronos would like to ensure these APIs are supported by lower-level silicon APIs
... several meetings so far but no actions have been taken
<schuki> bryan: we have a problem getting APIs built in w3c
<schuki> ... sys apps has picked up some stuff, DAPs is still running with stuff
<schuki> ... network information: I wrote a report about the saga on this
<schuki> ... we don't need to know what network we're connected to
<schuki> ... we should express what the developer wants
<schuki> ... dev wants to deliver a request effectively
<schuki> ... network info api is good for network efficiency
<schuki> ... another way to say to the browser "get me the resource within the next 10 mins"
<schuki> ... another idea is to get the resource, and i don't care how, just get it
<schuki> ... network info api as a way to promote efficiency has other approaches
<schuki> kenneth: service worker can do this
kenneth: that works pretty well with the service worker concept
dka: looking at the vision mobile report, limited access to hardware APIs is second only to performance issues
<dka> Vision mobile report says 37% of developers don't choose Mobile Web (HTML5) because of lack of API support.
wonsuk: I am curious why power and wifi APIs are in here
dka: this is one source of info in looking at most popular APIs. programmatic research was used to determine which APIs are popular, but also there was a lot of 1-on-1 interviews of devs and tools vendors
wonsuk: we can consider which APIs e.g. power and wifi are possible based upon this input
dans: I am surprised that FFOS have so many APIs, in slide 6, 98% of Android apps can be implemented in FFOS in terms of the APIs they use
<schuki> bryan: when we started doing wac we found a few number of webapps used no APIs at all
<schuki> ... so we could just package them
dka: many FFOS APIs are not
standard, and support animated games for example. the 98%
figure needs to be verfied
... some games e.g. do not need APIs
schuki: going back to Kenneth's comment on service worker, we will take data-driven approach rather than a documentation approach (captured correctly?)
dka: the idea of the report is to make this data public through the group, so we can point to it when we need to. we need work on the backup data, but when people ask for research this is a data source
schuki: Dom will give us an
overview in the closing the gap report in a later session
... suggest we defer the UI Primitives topic to tomorrow
some suggestions for tomorrow on WebMob focus - Help review and improve mobile-focused info on http://docs.webplatform.org/ - Linking to WebMob from http://www.w3.org/Mobile/ - Helping Dom maintain the info on http://www.w3.org/Mobile/