[![W3C][1]][2]

# Core Mobile Web Platform Community Group Face to Face (Mozilla-London)

## 02 Oct 2012

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Josh_Soref, Elika_Etemad(fantasai), Dominique_Hazael-Massieux, Jo_Rabin,
Bryan_Sullivan, Tobia_Caneschi, Tomomi_Imura_(girlie_mac), Matt_Kelly,
Shuhei_Hub, Markus_Leutwyler_(hptomcat), Wonsuk_Lee, Gavin_Thomas,
Tobie_Langel, Jean-Francois_Moy, Giridhar_Mandyam, Jonathan_Watt,
Jennifer_Leong, Max_NTT, Natasha_GSMA, Robert_Shilston, Mounir_Lamouri,
Lars_Erik_Bolstad, Dan_Sun, Jet_Villegas

Regrets


Chair

    Jo_Rabin

Scribe

    Josh_Soref

## Contents

  * [Topics][5]

    1. [Welcome][6]

    2. [Introductions][7]

    3. [Good Morning][8]

    4. [Agenda][9]

    5. [Objectives: Uncertainties as to what this group is here to do][10]

    6. [Dinner][11]

    7. [What we are][12]

    8. [CoreMob 2012 Document][13]

    9. [Dinner][14]

    10. [XXQ][15]

    11. [Getting Requirements Document][16]

    12. [Agenda Adjustment][17]

    13. [CoreMob 2012 Current Draft Review][18]

  * [Summary of Action Items][19]

* * *

<trackbot> Date: 02 October 2012

<Josh_Soref> Scribe: Josh_Soref

### Welcome

jo: Since everyone doesn't know everyone

... it'd be nice if you construct place cards with your names

jet: We have markers

jo: Good morning everyone

... welcome to CoreMob F2F

... Fire assembly point outside with green something

jet: don't use the flip chart markers on the whiteboard

### Introductions

jo: I'm Jo, I'm your chair for today+tomorrow... Welcome

mattkelly: Matt Kelly, Facebook

Robert_Shilston: Robert Shilston, Financial Times

Wonsuk: Wonsuk Samsung Electronics

Gavin_: Gavin Thomas, Vodafone

Josh_Soref: Josh Soref, RIM, scribe

fantasai: Elika, Mozilla, scribe

jwatt: Jonathan Watt, Mozilla

dom: Dominique_Hazael-Massieux, W3C

bryan: Bryan Sullivan, AT&T

tobie: Tobie, Facebook

hub: Shuhei Hub, ARC

girlie_mac: Tomomi Imura, Nokia

gmandyam: Giridhar Mandyam, Qualcomm

Natasha: Natasha, GSMA

Max: Max, NTT Docomo

hptomcat: Markus, HP, webOS Developer Relations

JenniferLeong: Jennifer Leong, AT&T (bridge)

jfmoy: Jean-François Moy, France Telecom

tobia: Tobia Caneschi, Bonjourno, part of Docomo

... working on a marketplace creating with HTML5

... developers can monetize with direct operator connection

... i work on the front end side, software architect

... my first time @w3, my pleasure being here

### Good Morning

jet: Good morning, welcome

... we talked about fire escape

... i wanted to address the group

... by coming here today, we're signing up to advance the mobile web

<bryan> are slides available on the web e.g. wiki?

jet: i hope the group will come together and leave with a shared vision

[ Jet will drop a link ]

<fantasai> [http://junglecode.net/coremob/coremob.html][20]

<tobie> Another Canvas HTML5 benchmark: [http://html5-benchmark.com/][21]

dom: Do you think we should work on benchmarks or test suites?

jet: I think both are useful.

... The W3C test suites we use aren't very user-friendly. They take hours to
run, and the results are not very digestible.

[discussion of browsers changing over time]

Wonsuk: ... Mozilla have to conform the compat of web application across
different vendors product, right?

... For compliance, they provide some kind of test suite like CTS compliance
test cases

... ... develop product based on Android, have to validate their product

... by Google

jet: We're trying to sidestep that by being an open web stack

... don't have to recompile, e.g.

... Practically speaking, features get added, deprecated, security fixes
change things, etc.

... ...

Wonsuk: For browsers, ap developer is responsible for app compatibility

... So you mean this context would be for Firefox OS as well?

jet: Yes

Wonsuk: So app developer is responsible for compatibility

... vendors \n jet: My hope is you don't really have to do that

jet: Our hope is that there will be very little additional testing, by virtue
of using a web OS

jo: Some things struck me about that presentation, esp. wrt perf

... At Palo Alto f2f, we resolved that although perf was important, we would
focus on functional compatibility before we did that

... We also got a little confused, b/c day 1 we said absolute perf
measurements, day 2 said relative were better

... There are other groups working on perf, so we can leverage what they're
doing

### Agenda

jo: I want us to have a quick look at the agenda now, so that we can be clear
on what we're going to cover

... First, we have a discussion of objectives. Seems there is still great
uncertainty as to what this group is going to do.

... Why are we here, what's our relationship with e.g. Ringmark etc.

... So let's discuss that this morning

... We need to think about what are our actual deliverables

... And what is a realistic timeline for these

... I will keep returning to the issue of resources. We won't make any
progress without that.

... Reality check.

... We owe a debt of gratitude to Tobie, for producing tangible stuff

... I know ppl contribute to discussions, but that is not the primary output
of this group.

... Some criticism of this group as being driven by FB, but as long as only FB
is doing any work, that perception will not change.

... 3 other major objectives

... Coremob-2012 spec, that Tobie's been diligently working on

... I would like us to come to some firm conclusions on that.

... Fundamental decisions about what gets left in / out of that spec, based on
what we see the point of that spec being.

... What would it mean to conform to Coremob-2012

... Would like us to resolve to publish this document

... by the end of this meeting, preferably by end of this day

... Tomorrow, we'll discuss a test framework, and then tests to run in the
framework

... I think I was recorded on the last teleconference as saying it's like the
difference btw roads and vehicles that run on the roads

... Tobie has written a document which he will introduce tomorrow

<jet> [Certifying The Core Mobile Web][20]

jo: Those are the objectives for this meeting. Anyone have anything to add?

[ jo off his proposed schedule ]

jet: surrounding meeting rooms are available for breakouts

tobie: There's a small project FB HP and Nokia are working on, I'd like to
present tomorrow afternoon

### Objectives: Uncertainties as to what this group is here to do

jo: There's a big thing missing from our writeups, which is in plain language,
why did God put Coremob here on this Earth?

... I don't think that question is clearly address.

... There's a history here, coremob came out of FB effort with Ringmark

tobie: Matt started at FB, we started talking to some of our partners, e.g.
Samsung

... Given the traction we're seeing behind it, decided to bring it to a CG

... That's pretty much what coremob is

... Ringmark is a test suite that was developed on the side, as a parallel
project, with the intent of giving it to the group

... and maybe seeding the group's test suite with it

mattkelly: Before we launched this at Mobile Web Congress, we'd been working
with a doze dev to build on top of FB apis

... Working with Zynga, Huffington Post, etc. to build mobile apps that had
deep social integration

... Decided as a group that best way was to build on the Web

... Allows us to build quickly and deploy across many devices

... Major feature of the platform is usable everywhere

... worked with them for about a year

... altogether, ~14 mobile web apps built from scratched

... It quadrupled the mobile web ap ecosystem

... Along the way we learned a lot, one being that the Web is really hard, for
a bunch of reasons

... Particularly, esp from Zynga's standpoint, development was straightforward
and simple

... But trying to get it to run across all Android devices at the time, b/c
behind the curve,

... Half the project was figuring out why things were so slow, or why couldn't
be built

... Once we launched we had a bunch of mobile web apps out there

... Decided a bunch of issues to make this a reality

... Our APIs work everywhere, so would be great if these apps could work
everywhere

... We also have our own incentive to build our own app and have it work
everywhere

... We took these issues and started talking to Samsung and other OEMs

... And that's the basis behind coremob, and the priorities we decided were
important for the mobile web

... Ringmark was a separate but parallel effort, these are the top things that
are important to web developers

... Hopefully coremob takes it over

... So I think that's the full history, where we're coming from and what our
priorities are

... One important note, we launched ~14 apps, and looking at how many are
still live and running... only ~3 are.

... Some were killed off b/c didn't think the user experience was good enough,
too slow, etc., couldn't expand in ways good for users.

... Some companies went bankrupt

... Others maintenance costs was more than revenue

... You see the current market conditions, they're not quite right yet.

jo: the group is grateful for its genesis from the Facebook initiative

... it isn't tied to it

... it treats all input equally

... as i've observed, Facebook is the biggest contributor, so it has the
biggest voice

... it must change.. in order for the group to be successful

... I think we have been extremely unclear

... there is no Idiots Guide to CoreMob

... we do need a simple statement

... I'd like to write a statement in 5 minutes

... In simple terms: CoreMob is here for making the Mobile Web a reasonable
platform for developing Mobile Applications

... it is not that today, it's much too hard

... with limited exceptions

... i think it's important to bring a set of features minimally needed to
produce an application

... we made a start on this route

... with thanks for bryan/AT&T for pushing that

<fantasai> s/biggest group/biggest voice/

<dom> [Dom's (handwavy) view on "what is a Web application"][22]

<Zakim> JenniferLeong, you wanted to purpose: We're here to improve the mobile
web experience for developers and end users

tobie: this start is literally word for word the beginning of the charter

... but we're having real issues communicating that

... i'm wondering if a writeup is a good solution

... i'm wondering if the W3C community tool is awful

jo: do you have a recommendation for W3C to make it better?

tobie: I think we could have our own page

... we could use the coremob domain to point to it

... i'm happy to cede the name

fantasai: once you start producing things that are interesting

... it'll be much clearer what you do

... if you just talk about what you want to do

... if you're just talking, it's less clear

... but once you produce things, it'll be clear what you do

jo: i've had discussions with people interested in joining

... but they're unclear about what it's trying to achieve

<scribe> **ACTION:** Leong to propose text summarizing the discussion on the
list, i.e. what we propose as the "mobile web app" characteristics [recorded
in [http://www.w3.org/2012/10/02-coremob-minutes.html#action01][23]]

<trackbot> Created ACTION-66 - Propose text summarizing the discussion on the
list, i.e. what we propose as the "mobile web app" characteristics [on
Jennifer Leong - due 2012-10-23].

dom: you only need to define it as much as you're trying to do

Robert_Shilston: surely it's far easier for people to say that CoreMob is the
output of what the industry thinks is needed

... and people should be able to follow its output to know what could work

tobie: it's easy for small companies

... but it's hard for others

... if we want more resources from members

... we need something they can bring to their companies

hptomcat: how do we differ from SysApps?

tobie: it's a Working Group

... it produces new technologies

hptomcat: do we focus on mobile technology in the web browser?

tobie: the key difference in layer in the stack

... Sys Apps WG is lower in the stack

... we're focusing applications

<Robert_Shilston> I said: "We've recently been asked to share our product
roadmap with a prospective tool supplier. I countered that as a tool supplier,
the best thing for them to strategically do is follow the coremob 2012 spec as
that captures the distilled requirements of mobile developers. "

tobie: they're focusing on applications that sit in a native-web system

dom: CoreMob references existing specifications that a Web Browser would
implement

... whether CoreMob could reference a Sys App spec

<Robert_Shilston> Tobie then suggested "That's fine for small companies, but
many of the people round the table are big companies, and need to work out how
to convey back to our organisations what coremob is"

dom: do we focus on Sys Apps APIs too?

tobie: CoreMob doesn't produce new technology

<bryan> or a question of when? for sysapps - I think the question of "whether
it's in scope" should be yes at some point

hptomcat: "we could test it?"

tobie: testing is supposed to be done by the group that produces the spec

<Robert_Shilston> I replied "Maybe coremob should act as a broker. If you're a
small developer who needs things, then get those suggested to coremob. If
you're a big company / vendor / supplier and here at coremob as your company's
representative, then you can go back to your company and say 'Coremob is the
route by which developers and the community are telling us what they need'.
That's why coremob is important - it's brokering information between
developers, vendor

Josh_Soref: Our target audience is web developers, and sysapps is not actually
producing things that will be available through the web. So no.

<dom> (I think the answer is "not yet")

Josh_Soref: That could change, but at least for the next 2 years, it's a no

<Robert_Shilston> @tobie, Did I capture that right?

<tobie> Robert_Shilston, yup

bryan: i think it's a matter of when

... but we should avoid looking too far down the horizon

<bryan> focus on what is short term achievable based upon the web baseline in
web browsers particularly focused on mobile use cases

dom: how do we communicate this effectively?

jo: i think the document needs to say what the group is not

... saying what it's is, and what it isn't are both important

... perhaps an FAQ style document to accompany it would be useful

... I'll make a draft proposal

... 1. our objective is...

... - constituencies are other groups in W3C and other Standards bodies

... - then constituencies who build things on W3C standards

... these two overlap

... - say we're here to represent the voice to groups who need it

fantasai: there's 2 directions that you're trying to broker

... industry and what they want

... communicating that to the WG/Vendors who are building the platform

... the aspirational set isn't helpful to people building content today

... the working set isn't useful to people building the platform today

jo: the aspirational part not helping developers today

... i agree it's true

... but i think other groups are building that document

... i think we can say "caniuse is doing a good job"

... why repeat their work

fantasai: if all you want is aspirational, then you don't need a test suite

... a test suite is for things that are designed

tobie: it's important to ensure the implementations get it right

dom: test suites used right can be a pressure tool

bryan: the experience we had in WAC

... in trying to define a baseline

... developing test suites to validate

... we decided we shouldn't make vendors implement features which aren't
coming from Mozilla/WebKit

... in the process, defining a baseline becomes a useless exercise

jo: so it's a useless exercise?

bryan: it'd be very useful to build a tool that could do testing

<Zakim> bryan, you wanted to suggest that the "what is supported" aspect is
being addressed by public sites, and the toolset and directional influence
that CoreMob can bring is the key

jet: i was hoping we could get resolution on the technology transfer from
Facebook

... that would clear up Ringmark is/is-not CoreMob

... and also the coremob.org

... let's not start from 0

jo: let's talk about that tomorrow afternoon

... i think we should be open to taking tests from a number of sources

... that requires are test architecture we'd discuss tomorrow morning

... right now the bit on the wiki is caveated

jet: we should do that on this meeting

jo: we should establish criteria for tests

... not all tests are equal

tobie: there's more to talk about on that

... we noticed when mattkelly + I started working on this project

... mobile browsers, unlike desktop browsers, have a lot more relation to the
hardware they're on

... one thing we've noticed

... is there's little agreement between OEMs, Chipmakers, Carriers, Vendors

... about what to focus on

... i think that's also a way this group could be very effective

... it's important

... its goal is to acknowledge we should think about it

... "Focus on the same things across the industry"

jo: so, broaden the scope to those groups?

tobie: i think it's one of the big differences between mobile and desktop

dan_: i think the test suite is more urgent

... we all agree there's no good/comprehensive test suite

... if we could evaluate the best test suite for a given area

... identifying that would be helpful

jo: i agree with that

<dom> [The State of Web Apps techs for mobile has some info on W3C test suites
availability][24]

jo: if CoreMob 2012 is "features needed to build a minimal set of applications
running on the framework"

... then we have 3 parts moving at different speeds

... some bits which we need tests for will never have tests

... we should ensure we have a consistent view in this group

... i haven't talked about:

... we need a statement of what's required

... we need a framework

... we need tests to verify things running in the framework to verify things
are implemented

... what that framework looks like, we'll talk about tomorrow morning

... where tests come from, and how to assess whether they're any good

... one things fantasai + Josh_Soref emphasized was that test suites could be
wrong

... and send things in bad directions

... i'd like to focus on why we're here

... focusing on tobie 's document

[ time check ]

bryan: we'd like the test system be able to collect data on a per-device basis

<bryan> we would like to ensure that test results can be collected and
published on a per-device basis

<Robert_Shilston> @bryan note that it's also important for people to be able
to privately run tests on devices / firmware which might not yet have general-
availability.

### Dinner

jo: straw poll... how man for dinner (6:30pm)

[ 20 people ]

### What we are

jo: purpose - a forum for developers to express their needs

... to produce a document, either by amendment or by a further version

... with a note about capturing current state

... my own view is that we don't really have the resources to do that

... even if we wanted to

... i'd like to address which other groups are relevant to our work

... and whether we should establish formal/informal liasons

... other initiatives might include CanIUse, RoboHornet

mattkelly: : when we come up with this spec, it'll feed into WGs

... Orientation Lock is half baked

... : Modernizer

... HTML5Test.com

tobie: some specs are really good

... but it's unclear to developers about what they should use it for

... HTML 5 Capture

... some have said "it sucks", "use getUserMedia instead"

... but for some things, it's the right thing

... it seems someone could write explanations to help developers understand
when they should use a Spec

mattkelly: : i think having UCs would help identify when to use a Spec

... saying "GetUserMedia wouldn't be targeting this UC" could be valuable

... beyond that, a test suite

tobie: i think the project i'll describe tomorrow kind of addresses that

girlie_mac: BrowserScope.org

jo: aside from tobie, who's in W3 WGs?

jet: CSS

gmandyam: DAP, Audio, GeoLoc

tobie: WebApps

jfmoy: DAP

bryan: DAP, WebApps, HTML

dom: DAP, WebRTC

fantasai: CSS, I18n

Josh_Soref: DAP

lbolstad: GeoLoc

Wonsuk: DAP, WebApps, HTML, SysApps

mounir: DAP, WebApps, HTML, SysApps

jo: DAP seems to win

... Who is participating/has active knowledge in RoboHornet?

mattkelly: : (me)

tobie: TestTheWebForward

<bryan> other CG member from AT&T active in WebRTC and WebAppsSec (Dan Druta)

jet: +1

fantasai: +1

dom: +0.5

mattkelly: : CanIUse

... : BrowserScope

tobie: +1

<bryan> What about [http://mobilehtml5.org/][25] ?

Gavin_: MobileHTML5

tobie: +1

### CoreMob 2012 Document

tobie: document hasn't moved much in the last month

... if you looked recently, there shouldn't be many surprises

... once we've gone through the document today

... we should discuss how and when to publish

... with our main goal being to improve the overall platform

... this is a strategic decision

... we had a number of Action Items/Issues tied to the document

<bryan> link to current version?

tobie: i think i've fixed all/most of them

... i think we went over it on the telco a few weeks ago, with things approved
in bulk

... changes i've made

... section 2

<bryan> [http://coremob.github.com/coremob-2012/][26]

[ jo projects ]

tobie: the box is a bug in the tool

... the tool/database may have moved, so i lost track of where to go to get it
fixed

bryan: i have a question about getting that fixed out to darobin

tobie: i added a conformance section

... you can't ask for a browser to be conformant to something which is
impossible

... e.g. color on a black-and-white display

<fantasai> jo: Should we say something wrt conforming to a spec vs. passing
tests ?

<dom> (technically, a device without a touch screen conforms to the Touch
Event specs by virtue of the truth of predicates applied to the empty set)

gmandyam: i see references to specifications in different stages

... what's the overriding philosophy

... GeoLoc is in CR

... DD is DD1

... File is Draft

tobie: W3 has strict rules

dom: a related issue

... do we only refer to the spec as a whole or a subset?

jo: the resolution at last meeting was in almost every case: As a whole

tobie: the slicing should be the work of the WG and not us

jet: Compass

tobie: like device orientation?

jet: a device can do something

... but the OS doesn't allow privileged access

... the device is not necessarily the gatekeeper

jo: so expand the definition to include system libraries

... this wording straight from a CSS spec

tobie: with the caveat that the only word changed was "device"

jo: if we tweak "device" to "device and associated software"

tobie: are we making developer's lives easy

... or make vendor's lives easy

... Do we handle a Gaming device w/o SMS

... a Kindle that isn't a Gaming device

dom: i think we wait to tweak until someone wants to conform, but can't
because of the wording

... i'm suggesting to leave it as is, until someone brings a real life problem

jo: change Device to Device and Associated Runtime and raise an issue?

fantasai: i'm not sure i agree with that change

... if both Safari and Chrome run on the same system

... and Safari has access to hidden apis

... the capabilities of Safari and Chrome on the device are very different

... that should be communicated

<bryan> its a matter of choice; if chrome had a choice to implement then its a
nonconformance if they do not

jo: you're saying it's important to name+shame

dom: i think anything below the browser is a black box

mounir: if you use an API from iOS

... then if you everything you can do, but the API doesn't work

... then you shouldn't be able to say "that's conforming"

... if i can't do touch events because the device doesn't have touch

... if the UA does everything possible, then it is

... i agree with fantasai

fantasai: if Google has a problem, they should Shame Apple

tobie: is it better for the group's end goal

<bryan> or negotiating the access they need in order to remove the
nonconformance?

tobie: for Chrome to be able to claim conformance

... or better to be able to complain

<fantasai> ... that they can't conform because the APIs are not open

mattkelly: : ultimately it's because developers can build an experience

... if i can't get the camera api and i'm building instagram

... google building Chrome on iOS, can't get the access

... they can't conform, they should shame apple

tobie: that was my initial view

<bryan> so a capability that is not exposed to after-market browsers can be a
non-conformance? we might need at least a way to explain the non-conformance
e.g. a reason code in the test results database

tobie: but last time the pendulum swung the other way

fantasai: i think the text is fine as is

jo: do we want a conformance section in our document?

... saying it's aspirational

... these are the features device managers, browser vendors

... should bare in mind

... this document will be ready before a test framework is ready

... before the tests, even before the spec

... conformance to this document is moot right now

... it lives in Cloud-Cuccuo land

<bryan> would removing conformance take any motivation away from development
of the test framework? If not, I agree focusing on aspirational text would
defer the conformance definition question

fantasai: you're building a wish-list

... for what you wish you had in 2012

dan_: some features are not just stable enough

jo: the target of people making standards

... saying that "if you don't make these things the web won't be competitive
to native apps"

... "which specs are finished/not finished"

... shouldn't be dealt with until we go through the list

dan_: if a spec isn't stable enough, then we wouldn't include it

jo: i think we should be making a list of features that a reasonable developer
would like to have

... to develop now

... existence of a standard isn't important

... i'd like to see the spec as a reference of requirements

... with references to specification work

... and indications of where there's no work

fantasai: you need to be clear that you want the features, but not necessarily
a spec that's under flux

tobie: how do you spec a feature if the feature doesn't exist somewhere?

jo: the precise nature is up to the WGs

tobie: i don't disagree

... i just don't know how to do it

dom: one way is to describe requirements, not features

... a specification that "provides a way to access white balance"

<Zakim> dom, you wanted to say that a wishlist is toothless, probably less
impactful for developers

dom: i'm hearing various things

... not sure how they relate

... 1. a Wishlist

... 2. let browser vendors compete on Conforming (but avoid that word)

... 3. define relatively clearly the features for the wish list

... 4. the wish list seems very aspirational

... #2 seems to require conformance

... the thing you guys did on the top 100 native applications

... looking carefully at what it means to get access to the camera

tobie: when we looked at the existing native app ecosystem

... while there's a lot of stuff you can do on native that you can't do on web

... most apps don't rely on them

... look at Games

... most top grossing on mobile use 2D

... they're casual games, not hard-core gamers

... we found the smallest set of stuff to be able to build most apps on
native, but using web tech

... then, let's look at what's on the web, in implementations, in specs,
implemented/not implemented

... a good 3/4 of the specs are finished + implemented (at least the useful
parts)

... then, there's a small set of features not in a complete state

... the big question is on strategy

... how to publish/define it

... cut on features (because there's no spec)

... publish non-spec'd features as a different document (a UC document?)

Josh_Soref: So, I think one of the ways to do use cases is to look at apps,

... or to build an app, and say "insert X here, missing this one thing to make
this ap really work"

... If you build an app today, want to make sure it works in 2 years

... One way or the other, and probably way to do it is to take real apps and
make a mockup of them

... You can publish that, and then ppl can mock up an implementation

<Zakim> bryan, you wanted to suggest that if removing conformance focus did
not affect likely efforts to assess conformance (or analyze and publish test
results in a conformance light) by

bryan: ... 3rd party sites, then it would be OK to refocus the doc

<dom> (people would still say that a given browser "conforms" to whatever we
define)

jo: my view is that conformance comes later

bryan: removing conformance doesn't block people from doing things

jo: conformance waits for tests

... this document should be published in say 6 months

... we should publish a different document to drive people to make this
document testable

dan_: i think we can split this document into two parts

... one part that's ready by the end of the year

... one for the wish list

tobie: if we look over the list and decide the majority aren't ready

... we should pause it

dan_: can we for each item, identify which is the best thing to test each?

[ dan explains the history of CoreMob documents ]

[ and how each document gets shelved ]

tobie: we should release something now

... showing activity is a valid goal

... but it's a different goal

<bryan> to summarize my point: if others could/would still analyze and publish
test results in a conformance light, then it would be OK to defocus
conformance in the doc, while retaining focus on test development in the CG

tobie: identifying the best test for a spec is important, but different

lbolstad: on the topic of removing things

... to Opera as a browser vendor

... the interesting thing was the starting point

... identifying what's needed

... removing stuff because a spec is lacking is going in the wrong direction

jo: as dom said, regardless of existence, it's important to identify what's
needed

[ TIME CHECK ]

jo: "What would developers like in their stockings at Christmas?"

tobie: this document has been useful to push groups to do things

jo: would people like lunch?

<bryan> devs will surely want more than they currently can get, so just
measuring based upon current apps would be short-sighted; we need some
aspirational use cases as well - where do we find them?

[ Lunch ]

### Dinner

jo: i couldn't get a reservation for 6:30pm

... i get it for 7:30pm

... go left onto St. Martin's Lane

... up to 7 dials

... take 2nd right

... "earlham st"

... Belgo Centraal

... is the restaurant

### XXQ

jo: Requirements

... then, what standards/recs are needed

... related: what's the state of them

... then what tests are needed to verify those have been implemented

... then, a test framework, to address what's needed to run tests

... allowing contributed runs, or excluding a run from being contributed (for
private runs)

... Excluded from this: Speed, Memory

... theoretically in scope, but unobtainable

... then, the question of what conformance means

... Conformance to Requirements

... means an appropriate set of Standards/Recommendations has been chosen

... that meets the express needs of the rquirements

... Conformance to Standards

... means that features/detailed aspects of the standard are claimed to have
been implemented in an appropriate manner

... All the MUSTs, some of the MAYs, maybe some SHOULDs

... Conformance to Tests

... means that an implementation passes the tests

... We've been discussing what part of the flow chart tobie's document covers

... and whether it's a top down or bottom up thing

tobie: you've described Conformance as having a meaning at all of these steps

... i've never heard that definition of Conformance in W3C

dom: Conformance is to a Test Suite for a Specification

lbolstad: but it's really to verify implementability

jo: i think in non technical language, it makes sense to conform to
requirements

Gavin_: we're trying to build a platform

<dom> "Fulfillment by a product, process, systems, or service of a specified
set of requirements." [http://www.w3.org/TR/qaframe-spec/#glossary][27]

Gavin_: but you could have multiple specs that conform to a requirement

jo: Requirements => Standards / Recs => Tests => Test Framework

... either CoreMob 2012 is a collection of Requirements

... or it is a list of Standards / Recs that meet these

tobie: at CoreMob Palo Alto, I said I was working on a Requirements/UCs
document

... it's common form for W3C specs to have a UC/Req section

gmandyam: my confusion, relates to how you take this to an automated suite of
tests that you can run

... e.g. DeviceOrientation spec

... Ringmark was more of an existence test

... not conformance

... i'd have to hold it, and rotate it

jo: i think your point is relevant

... but i'd like to divide the discussion

<dom> (automated testing necessarily limits the depth of testing we can
achieve)

jo: whether a test is automatable belongs to Testing/Test Framework

... Conformance exists independently of how the test is executed

<hptomcat> (just a quick note regarding testing discussion at lunch: crowd
sourcing given raw data and specification)

tobie: you could have a Conformance requirement that isn't testable within a
scope

... but that doesn't make something which doesn't do that Conformant

dom: a test suite lets on assess whether something could be conformant

... but it doesn't address completeness

... what we want to define is Usable Conformance

... beyond just Existence

... but less than complete checking

... the definition/discussion is a difficult one

... but something we should confront later

jo: Tests = "What tests are needed to verify that claims are true"

<tobie> [http://dev.w3.org/html5/decision-policy/html5-2014-plan.html][28]

jo: Test Framework = What's needed to execute these tests in a subset

... because multiday testing is too long

<dom> (more than verifying their truth, we want to verify some level of
truthiness, ideally a level that is informative enough for developers to make
choices)

jo: [inserts in Tests] Can we say what automated/non-automated tests are
automatable

<tobie> [http://coremob.github.com/coremob-test-approach][29]

dom: there's a range of options

... in terms of what kind of testing can be done

jo: in Palo Alto, we said we needed a way to have sources w/ subsets

... and some database that recorded results

... and a way to render results

... like caniuse/browserscope/...

... we failed to communicate that this is the basic idea

[ scribe failed to transcribe picture ]

jo: and some way to record things like hard to test (orientation)

tobie: it'd be really useful if people read the document

... and also useful is the html5 2014 plan

... describing how they want to test/focus+test the html5 spec

... it seems like a very sane strategy

... we should look at it closely

... and use...

jo: ... returning to tobie 's document

... it exists near Specs/Recs

... conformance is what it says in the document

... conformance will mean conformance to those documents as conformant to
those documents

... what i'd like is:

... 1. where are the requirements?

... 2. how to decide in/out for document

dom: the underlying hard question is how to determine what's in / out of the
requirements

jo: i'd suggest a digression

[ jo + mattkelly: rotate the whiteboard for lack of the crank needed to flip
it ]

Potential Requirements

<dom> [CoreMob Mobile Web App Profile][30]

mattkelly: : this was a first attempt at finding missing features

... we looked primarily at native apps

... and how people used their phones

... which apps they used actively

... came up with prioritization

... based on time spent

... and then features that were missing

... which seeded ringmark/tobie's spec

... we went through the exercise a handful of times

... it boiled down into a couple of categories

... 1. 2D games

... the vast majority of time on phones today

... we'd worked with Zynga and some others

... for 2D gaming, features aren't missing, they're just slightly broken or
have bad perf

... <canvas> technically has the technical features necessary

... but it wasn't performant

... 2. Audio

... audio needs to happen instantly, and not choppily

... Zynga had tried <audio> for sounds for words but they ripped it out,
because it was too bad

... 3. Audio-Video Apps

... Spotify/Audio-Diezer

... Hulu/Netflix/YouTube

... what's interesting about those

... adaptive streaming

... audio guys don't need it

... they queue up the next song at a lower bit rate if they need it

... Video guys can't do that, since a video could be hours long

... then, companies have contractual obligations relating to DRM

... even with Adaptive streaming, they couldn't build their apps

... without some form of loose content encryption

... The other part was codecs

tobie: given there was no standard codec

... to support every browser, you have to encode your content differently

... or encode it on the fly

... either paying a CPU cost or a storage cost

... it's a big problem for Facebook

mattkelly: : 4. Photo Apps

... Instagram, Food Spotting

... Camera apps couldn't be built on the majority of browsers

... Android had a file input for camera

... iOS didn't have it, it got it in iOS 6

... <file input {camera}>

... at the time, there were 3 competing camera specs

... people cringe at <file input>

... but for all those UCs

... all they want is a photo

... for the native apps, they use the native camera app

... they use the photo they got back and apply a filter

... : we also needed XHR2

tobie: and you needed IndexDB

... you needed some File API

... you probably needed CORS2

... you probably also need "Application Cache"

dom: was this part of the analysis?

... this analysis seems like a good document to be published in prose form

tobie: this analysis was part of the first level 1 spec

... when there were two specs, a level 0, and a level 1

... there was a requirement and what was needed

gmandyam: ... even if you make a claim that WebRC is an incomplete WD, we have
other incomplete WDs as well.

... How much of this ranking is really subjective?

... Would I come up with a different list?

... FB needs a camera API, but don't need it for ...

jo: The point of this group is to capture the excellent work by FB, put it out
in the public domain, and say to developers, OK, this is Facebooks' view. Do
you agree? What have they missed?

gmandyam: My idea is to get away from genres, just pick existing apps

mattkelly: People are spending the majority of their time in these apps

... top ten apps are not the same

... 2D games isn't the largest group of where people spend their time on
mobile devices

gmandyam: Your ranking of the APIs that exist today, don't consider genres,
are you sure your list would be the same

dom: You're saying this is FB list, their view. We need to move from that to a
document that represents this group's perspective as a whole

gmandyam: List what individual apps need, instead of genres. E.g. this is what
FB needs, this is what FB needs

mattkelly: This lists that info here ...

jo: It doesn't matter how you do it. It seems this is a what's popular today /
tomorrow, may not be the same thing

... We're trying to capture what people are trying to build and failing to
build.

... We need to start somewhere, and this is a good list to start from

... What you *want* to build isn't reflected in popularity, because it hasn't
been built yet.

tobie: That's why we looked at native apps

gmandyam: Bunch of popular games that don't use WebGL, and others that aren't
as popular that do

tobie: We looked at what are the stuff we are missing, what would adding this
feature enable.

... WebRTC is a good example. At the time we started looking at it, a year
ago, no clear path of where it was going

... The only thing out of that list that WebRTC would help was Skype, so we
said, not really useful atm

... The main problem with the mobile web platform atm is that there are plenty
of specs, and no one really knows where to focus energy on moving things
forward

... If we can all agree on a subset, and get that to move forward, then the
rest will fall into place

... How can we, minimum cost, change the opportunity of mobile web apps

... Of course this is biased and organic. Takes the data we could find and
tries to make a coherent analysis.

... Can it be improved, yes.

jo: we talked about a few specific technologies

... But we're discussing requirements, not technologies

<dom> as a reminder, the charter of the group explicitly calls out the
popularity filter ("It is necessary for building a class of applications that
has significant market share in native mobile environments")

jo: So WebGL or not is not a question in ths dicussion

... What you seem to be saying is that you don't consider FB's list to be
vlaid.

... I'm asking you, on what basis do you consider this list invalid?

gmandyam: 2 ways to interpret data. One is based on most popular apps, other
is based on genres.

... My question is ...

tobie: Oh. We made the output based on both approaches

... We ...

dom: The charter calls for the criteria of selecting features, it is necessary
for building a class of apps that has significant market share in native
applications

... So it can't be just one application

... The goal is to enable several applications that can achieve a given class

jo: Time to bring this discussion to a close

... Although the process FB went through is undoubtably subjective, it gives a
clear document

... Wehther it's important that Skype is enabled by this is a separate
discussion

tobie: I'd like to point us back to the charter, which as criteria Dom
mentioned

<tobie> [http://www.w3.org/community/coremob/charter/][31]

tobie: i'm happy with the coremob charter

... i wrote it

Josh_Soref: and everyone who joined the CG read it and signed off on it

mattkelly: : this is our methodology

... we probably talked with all the people in this room

[ noise from others entering the room finishing some meal ]

tobie: i'm afraid of losing focus

dom: we need to start with something

... i think what you've provided, is a good starting point

... i think we need something concrete

jo: i agree

... this spreadsheet needs to be turned into a document

tobie: UCs and Requirements

jo: i'm looking for resources to work with you

... to create that document in the shortest possible time

Josh_Soref: One thing Tobie and I spoke about over lunch is, they looked over
popular apps, and one popular app was a battery monitor

... Not used by any other app except to show battery monitor status

<tobie> first stab at UA + req:
[http://tobie.github.com/COREMOB-1-REQ/index.html][32]

Josh_Soref: We exclude battery because it turned up in this one app

... It's a failing of the OS

... We also talked about ruling out Skypes use case, because it's only used by
1 app, which is a minority of the 100+ apps we looked at and doesn't enable a
class of use cases

tobie: out of the top-most-used-applications

... how many apps were of a category

... we didn't measure total time for individual apps against categories

... it wasn't super scientific

### Getting Requirements Document

tobie: it's started, it's very empty

jo: do you need help?

tobie: yeah sure

jo: how?

tobie: a breakout session

... to discuss how the document should be best authored

... there's very few examples of such documents in W3C

Josh_Soref: there's one by Travis Microsoft for Media Capture

... [http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-
capture/scenarios.html][33]

dom: i'm hearing people interested in things being successful

... but not committing time

bryan: [AT&T] we've signed up for an Action Item

dom: so small contributions?

bryan: yes, but we're not sure we're ready for being an Editor

gmandyam: i'm interested in Editing Requirements

lbolstad: I'm interested in Editing Requirements

jo: how do we avoid slippery slope

Gavin_: one page

... no wish list

... get 80%

... beyond the 3 surviving apps

dom: two levels

... UCs

... [applications that do stuff]

... Requirements

... - derived from the UCs

... App Cache should let web applications work offline

... but it doesn't

... there's a difference between what's said and what's done

... if we want to go back to a WG

... and say "you didn't do the right thing"

... we need to be able to go back with UCs and Reqs

... and say "it doesn't quite work"

gmandyam: i think a gap-analysis makes sense

Josh_Soref: We can't go back to other WGs, when these groups are way past reqs
stage, that they didn't do their job

... We're not even the peer of a WG

... We can't go back without a clear explanation and just say they didn't do
their job

... What you will do, since you three have volunteered for this, is you will
take the list of 100 apps

... and write up how the list came to be, what the categories are, what the
use cases those apps cover, and what requirements exist to address those use
cases.

... Then someone can publish a gap analysis between the existing spec and
what's needed

jo: i think that's past coremob-2012

tobie: Problem is, use cases for these specs either don't exist or were lost
in the mailing list somewhere

... I asked hixie for use case for appcache, and he says "to make webapps work
offline

Josh_Soref: [and in Hixie's head]

tobie: Finding existing stuff will take at least 2 years

... To go back to original points you made, this work for us is difficult
because it's not clear at what level we should go

... how deeply into reqs and use cases we should go

... Something I've been struggling with; defining that is useful

dom: this group can provide

... a platform overview

... instead of feature specific

... we aren't looking to "enable p2p communication on the web"

... we're looking to enable mobile apps to be developed on the web

... acquiring assets, storing assets, managing payments

... for various reasons these things are addressed in individual groups

<Zakim> dom, you wanted to point to the one of the specificities of this
group:w e look at an integrated platform level

jo: Summary

... using mattkelly: 's spreadsheet as starting point

... tobie , gmandyam , lbolstad , will work on a short document

... to capture UCs in categories

... and consequential feature requirements for those UCs

... it will avoid slippery slopes

... ready in first draft by what time?

tobie: action item to have a deadline by end of f2f

Gavin_: the spec becomes a dependency on that?

jo: i don't want people to say "the requirements were unduly influenced" by
any individual group

Gavin_: how big is the concern

jo: it's the people not around this table

... let's be sure we're completely clear that it's from the group

Gavin_: i thought we were going to agree the spec today

tobie: i think it was an idea of jo's, but i didn't want to do that

jo: my proposal is that we try as hard as we possibly can to get this
requirements iteration done within a couple of weeks

... to say that the coremob 2012 document meets those requirements

... does App Cache meet those requirements?

... no, because it doesn't work

... as an objective to get this document to an equivalent of LC

... i think that's been "unpicked"

... but we've decided we need to publish requirements

... and coremob 2012 is based on the requirements

dan_: i'd agree with Gavin_

... but maybe we can do this for the next round

jet: this meeting feels like the meeting in Palo Alto

... i won't be able to justify a third meeting if we don't publish something
at this meeting

... i'd propose stripping the first draft to only CR specs

... exist, tested, known good, stable

... and promise to work again on the next version

... CR specs assume Conformance, Existence, UCs

Josh_Soref: (some Specs are silly)

dom: what does that fulfill?

jet: it fulfills a need

dom: i think the UCs document would be valuable

jet: a big subset of this spec isn't up to debate

dom: most of these aren't in CR

jet: a lot of it is HTML, CSS, DOM

dom: CR eliminates HTML5

... you lose <video>

jet: i assert you can do that today

Josh_Soref: publish "FPWD" of Requirements by 2 weeks

... publish "LC" 2 weeks later

... publish final edition at end of year

... publish a draft of the other document nowish

... with an extra section stating that we're publishing a Requirements
document late

... apologizing, explaining that we'd encourage other groups which forgot to
publish Requirements

... to publish them late, as we've done

... and encourage future groups to actually publish their Requirements

... and noting that we're publishing our Requirements

jet: it seems we need some decision making process

jo: the firm basis for things in CoreMob 2012

... is based on a Requirements Document

... i wanted the CoreMob 2012 LC equivalent

jfmoy: i agree w/ jet

... a lot of things we discussed last time

... we said we'd formalize things

... but as we get new people, the same discussion happens each time

... but we need to move forward

... but we need to have real output, not endless debates

dan_: last time we discussed which we relatively stable

... maybe jet's point is too strict

tobie: i asked to do that from the first hours this morning

dan_: if we don't get this document, i don't think my manager would let me
join the next meeting

... if we miss something, we can do it for a future document

... it's important to get it out

lbolstad: i agree we seem to have repeated a lot of the discussions from last
meeting

... i'm concerned i'm making the same point i made earlier

... i'm concerned if we reduce the content of the spec in the interest of just
showing something

... if it's more important to publish something than the content

... i don't think it matters if a spec is in CR or not

... there's a reason for the specs that were chosen

... if we assume [accept] that the list of inputs is relevant

... and the analysis is valid

... then we shouldn't reduce the list just to publish

Josh_Soref: +1

lbolstad: if just publish the list of docs in CR

... what's valuable of that?

Josh_Soref: dom already has that document

<Zakim> bryan, you wanted to say that I agree with Jet except for the
expectation of CR status - the "current state" vs the aspirational set of
features - these are two different and both

bryan: ... valid objectives

<dom> (I'm happy to contribute [http://www.w3.org/2012/08/mobile-web-app-
state/][24] as a source of input matching features with specs, with some
(relatively subjective) assessment of their stability, and links to their
existing test suties and implementations)

tobie: i know we have to go back to companies showing we did something

... it's also important to go to other groups, possibly giving inputs or small
snippets for other groups to drive them forward

... this is clearly important

<dom> (I think beyond editorship, this means that one type of commitment
people could make to this group is to serve as advocate to other groups)

jo: there's a frustration

... a need for a deliverable, and some backtracking

... an egg, but no hen to lay it

<dom> (in terms of tasks that I have identified for this group: editing
documents, hunting information (use cases, test suites, etc), advocating our
results to other working groups, publicizing our work to people outside W3C)

mattkelly: : everyone broadly agrees, with the exception of jet

jet: Apple isn't here, Google isn't here, Microsoft isn't here

mattkelly: : Google and Microsoft are in the group

... i feel we're in a good enough state

... we put to the mailinglist

... get the feedback from the people who aren't here

... give them a week, and lock it down

jo: Core Mob 2012 which nominally depends on that other Doc

... can proceed in parallel

... we need to press the button, saying we're done

... it won't be quite aligned, but we'll worry about that later on

### Agenda Adjustment

jo: i propose slipping the end time to 5:30pm

... we've agreed we need a UC document

... we've agreed a draft form will be produced within the next couple of weeks

... the UCs are tactically understood to meet with the CoreMob 2012 document

Josh_Soref: so we add a paragraph with our apology

... and publish a LC of sorts

**RESOLUTION: We publish CoreMob 2012 as a LC at this F2F w/ that apology
paragraph**

### CoreMob 2012 Current Draft Review

tobie: i'd suggest we only look at Open Issues

<jo> Current Draft is at: [http://coremob.github.com/coremob-2012/ED-
coremob-20120924.html#conformance][34]

bryan: there are 4 inclusion criteria in the charter

... i don't know we could in one session be able to conclude things about
inclusion/exclusion

tobie: i think those 4 are example criteria

... not all are required

... fulfilling one is enough

<dom> The feature is already widely deployed,

<dom> It is necessary for building a class of applications that has
significant market share in native mobile environments,

<dom> It significantly improves performance across a variety of applications,
or

<dom> It significantly lowers developer cost.

<dom> [http://www.w3.org/community/coremob/charter/][31]

jo: bearing in mind that these are indicative criteria

<dom> "Features whose implementation is compromised by substantial obstacles
(such as known security problems or patent licensing issues) will very likely
not be included in a specification until the issues have been resolved. The CG
will aim to carefully balance developer needs and implementation constraints
to ensure timely progress of the Specification."

[ tobie projects coremob 2012 ]

tobie: HTML5

... one issue, HTML5 ... AppCache is horribly broken

... there are changes, but it's not clear when

... there's a "fix app cache CG"

... i personally would think that having a couple of weeks to make a decision
on what to say about this would be best

ack mattkelly:

mattkelly: : could we slice HTML5?

tobie: it's a big task

mattkelly: : i think it would be useful

jo: we've previously resolved to take specs as a whole or not at all

tobie: testing html5 is covered by their plan2014

... slicing html5

... what is in html5 that is not widely deployed and not needed

<dom> **ACTION:** Bryan to propose a feature in HTML5 that is both not widely
deployed nor useful to a large share of applications [recorded in
[http://www.w3.org/2012/10/02-coremob-minutes.html#action02][35]]

<trackbot> Created ACTION-51 - Propose a feature in HTML5 that is both not
widely deployed nor useful to a large share of applications [on Bryan Sullivan
- due 2012-10-09].

gmandyam: ... app cache

... UC: web developer needs persisted data

... but App Cache isn't the only solution for persisted data

tobie: App Cache is the app working at all when the device isn't online

<hptomcat> things like localstorage,websql,indexdb are used for data
persistance

jo: feature is loading an app to a device and being able to use it on the tube

... mattkelly: + bryan : you want to slice html5?

tobie: i'd want to do it in html5

jo: so "some aspects of html5 are incredibly important"

... we'd like html-wg to slice html5

tobie: new editor for 2 weeks, new editors for 4 weeks

... question is what to do w/ App Cache, and Responsive Images

... their plan seems to be to push to HTML.next

<dom> (I think <input type="date"> is an example of a feature that is not
widely deployed, nor widely useful to a large class of applications)

jo: do we care where the spec is for App Cache/Responsive Images?

... we just want it somewhere

tobie: absolutely

jo: so, we say that if html5 doesn't have these features, then we want it plus
a spec which has those specs

<mounir> (I think <input type="color"> or <input type="month"> is a better
example than <input type="date"> actually)

Robert_Shilston: issue-1 if html5 doesn't have app cache, then we want
whatever thing that fixes app cache

<dom> (<input type="color"> is a good one indeed :)

<bryan> questionable HTML5 features re support include drag and drop,
datalist, modal dialogs. I welcome any discussion as to the importance of
these features (we think they are important BTW), but in my testing they are
poorly supported in mobile devices.

<dom> I came up with a classifications per feature this morning, that I find
hard to mould in this per-spec approach:

<dom> What features are needed to make the mobile Web successful

<dom> * features that are not defined in any spec

<dom> * features that are supposedly defined in any spec, but don't match our
requirements

<dom> * features that are defined but not currently tested

<dom> * features that are ready

<Robert_Shilston> Issue-1 App cache as currently implemented and described in
HTML5 isn't working well for mobile developers. The Fix app cache community
group is working to define a solution, and it is anticipated that this group
will support the solution and refer to its output.

<dom> Issue-1: App cache as currently implemented and described in HTML5 isn't
working well for mobile developers. The Fix app cache community group is
working to define a solution, and it is anticipated that this group will
support the solution and refer to its output.

<trackbot> ISSUE-1 AppCaches fix planned for HTML.next only notes added

<dom> ScribeNick: mattkelly:

tobie: html5 note is non-normative

jo: what does the group thing? leave note in, or move to appendix?

bryan: Don't be overly prescriptive of the notes. It's useful to retain them.

mounir: Should we we recomment games use webaudio?

tobie: we didn't mention web audio because of multiple specs

... key requirement from game devs was for the audio tag to work properly--
we're not doing anything fancy

... they're just doing background music and audio on user input

... audio tag was ok from a tech perspective, just not from an implementation
perspective

mounir: I feel that web audio API will fix these issues.

gmandyam: Qualcomm make the chips that go on the smart phones. Web audio
doesn't map well to the underlying chipsets, and so the hardware optimisation
isn't possible.

dom: We are, in this case, with a problem with two solutions. HTML5 audio tag
and the Web audio api. Which of these is used depends on your viewpoint.

tobie: To address this, we should think about developers. Their main concern
surrounding the quality of implementation. They weren't interested (then ) in
the feature set of the web audio API.

... That was one factor. The second factor was that there was no clarity as to
where the specs were going - both Chrome and Mozilla had implementations /
specs.

dom: This question of several specs being possible solutions to a single
requirement is likely to be an ongoing challenge to the group. We ought to
establish a way to work out which to select. Should we support the first one?
The one that's most implemented?

tobie: I think this is mostly solved now.

dom: iOS 6 has the web audio API

<Zakim> dom, you wanted to ask about more detailed requirement (e.g. audio
perf)

tobie: I think this sort of thing should be discussed on a case by case basis,
not a cookie-cutter approach

mattkelly: Motion to suggest for now we just stick with advocating the <audio>
tag.

tobie: If someone wants to review the audio options and come back with a piece
of text to explain what is best for the group.

... then please go ahead.

jo: We're going to stick with advocating <audio> tag. Any objections? None.

<Zakim> bryan, you wanted to ask isn't the latency question related to an
informative note anyway, thus should just be a further clarification/caveat on
that note?

bryan: Quality of implementation is important, and the note should remain.

jet: Everyone wants low latency, so that requirement should be retained.

<dom> PROPOSED ISSUE: Should we recommend also or instead the Web Audio API
for low-latency audio?

**RESOLUTION: We want low latency audio from the audio tag and we want it
now.**

tobie: HTML media capture - any comments?

jo: No objections - so we move on to SVG

mattkelly: Do we really want to review which bits of SVG are required?

tobie: I can give good use cases of SVG. We had to build ringmark using
canvas, but then it wasn't supported on early Android so we had to move to
SVG.

Robert_Shilston: no, but we don't need to if there's not a compelling reason
to include it

... I'm saying that none of the spec isn't needed

dom: If the goal of this document is to advocate forthe most popular
applications, then it's not clear that ringmark or charting requirements are
really present in applications

tobie: Remember that SVG wasn't in the spec before the previous F2F, but then
got added as it was widely implemented.

girlie_mac: SVG is useful for handling retina screens.

jo: Shall we resolve to retain SVG in the spec for the last time

<bryan> +1 to retain SVG

<dom> **ACTION:** Tobie to right use cases that document the advantages of the
Web in multi-screen/multi-devices scenario (e.g. that would justify CSS, SVG)
[recorded in [http://www.w3.org/2012/10/02-coremob-minutes.html#action03][36]]

<trackbot> Created ACTION-52 - Right use cases that document the advantages of
the Web in multi-screen/multi-devices scenario (e.g. that would justify CSS,
SVG) [on Tobie Langel - due 2012-10-09].

jo: We're going to get use cases on SVG and in the meantime we'll retain it.

tobie: Device adaptation (things that are put in the viewport meta tag). At
the moment, there's no spec for it. Whatwg allows for this to be documented on
a wiki. This is a good example of where we want to slice and dice portions

bryan: You don't need a full spec for the viewport tag - it's just a section
of the spec

lbolstad: It's very new and not widely implemented... it's a working draft

dom: I've just noticed that this is talking about a subset of the spec.

tobie: Should we reference to a specific section number?

<jo> **ACTION:** Tobie to amend 3.4 Device Adaptation to reference the section
number applicable. [recorded in [http://www.w3.org/2012/10/02-coremob-
minutes.html#action04][37]]

<trackbot> Created ACTION-53 - Amend 3.4 Device Adaptation to reference the
section number applicable. [on Tobie Langel - due 2012-10-09].

mattkelly: We need to ensure use cases for this are captured

tobie: You'll struggle to build a mobile web app without constraining the
viewport. As it's widely deployed, it should be in this spec

<Wonsuk> There is meta bug for implementing the Device Adaptation spec in
webkit.org [https://bugs.webkit.org/show_bug.cgi?id=95959][38]

dom: viewport is widely deployed. In this case, the spec for viewport is just
a part of the CSS-ADAPTATION.

Robert_Shilston; the rest of the spec isn't not especially relevant to apps
right now, so that's why this spec is not refering to the whole of CSS-
ADAPTATION.

tobie: Perhaps someone should take an action to take the viewport spec from
CSS-ADAPTATION to the HTML5 group and ask them to include it, as that's the
only bit that's needed now.

... It's hard to freeze this spec that's work in progress and not having a lot
of traction, so is unlikely to get adoption. We should be careful about
pointing to a small portion of a spec that might be at risk.

<jo> dom suggests re 3.4 that we take the meta viewport question to HTML WG

dom: I'll take an action to improve the phrasing of coremob 2012 section 3.4

<jo> however no one steps forward to take that up

<trackbot> Created ACTION-54 - Propose improved phrasing for "Device
Adaptation" so that it's clear what parts of the CSS-ADAPTATION spec we need
[on Dominique Hazaël-Massieux - due 2012-10-09].

tobie: Application configuration: A simple way for the developer to spec the
name / icon / homescreen behaviour of an app. Very similar to a widget
configuration file

... My feeling is that we should have a note saying that we would like to see
convergence of the proprietary APIs / implementations, but that it's
unfortunate not much work is happening at the moment

<dom> ACTION-54: proposal: User Agent MUST implement viewport adaption based
on <meta name="viewport"> using the algorithms defined in CSS-ADAPTATION]

<trackbot> ACTION-54 Propose improved phrasing for "Device Adaptation" so that
it's clear what parts of the CSS-ADAPTATION spec we need notes added

gmandyam: What exactly is the action? Is it that there's some work languishing
that's needed for the adoption of web apps

tobie: There's definitely work with Google, Mozilla and Opera about having a
JSON format to define apps.

jo: Is the lack of a manifest preventing web apps being used?

Robert_Shilston: Yes. People don't know to open a browser when offline to
access web apps. Having a manifest to add the icon to the homescreen is
essential in helping users access web apps.

Max: It's important to have a canonical manifest format

girlie_mac: Currently this is done by Google, Opera and others but this is
proprietary. If we're to support installable web apps, then it's hard at the
moment. We need a standard.

Max: A simple use-case is the provision of a app store, then it's hard at the
moment as there's different security models for each platform's apps. Having a
standard approach would be better.

<dom> (there is a <meta name='application-name'> defined in HTML5 IIRC)

Josh_Soref: When I bookmark a site, it gains an icon and a title. I can change
the title, but rarely can I change the icon. I can then access these from my
browser home page and/or my desktop or homescreen.

<dom> -> [http://dev.w3.org/html5/spec/the-meta-element.html#standard-
metadata-names][39] HTML5 includes definition of <meta name="application-
name">

Josh_Soref: Google and RIM already have a way for users to put icons into
specific places.

Robert_Shilston: This leads on to sysapps, but they're out of scope.

Gavin_: The use case, that the developer wants, which is bookmarking to the
home screen. I feel that the functional requirement should be there, but there
are different ways that device vendors are implementing it. That's our
problem, but it's unlikely to be one we can solve. We should keep the
reference to WebApps-Manifest-API.

<dom> **ACTION:** Gavin to write up the need for application configuration
[recorded in [http://www.w3.org/2012/10/02-coremob-minutes.html#action06][40]]

<trackbot> Created ACTION-55 - Write up the need for application configuration
[on Gavin Thomas - due 2012-10-09].

tobia: there is also the other part which is to engage the user and help the
developer encourage the user to add to the home screen. Perhaps with
screenshots and a description.

mattkelly: I think there's a number of groups of issues. We've been talking
about implementation issues first. There's other issues such as monetisation.
We're now touching on distribution and engagement - push notifications,
notification centres, or whatever else will emerge in future OS releases.

... Distribution is important, and I feel that we should focus on the
implementation issues as a priority over the distribution.

... I'm in favour of keeping our focus on implementation issues.

gmandyam: I'm in favour of avoiding normative requirements that are near the
app-store space. Challenges of monetisation, upgrades etc which are all hard
in the native world and aren't harmonised are things that are premature to put
into the coremob spec.

jo: If we want ot make mobile web apps as compelling as native apps, then not
including app config would be a serious problem. If on the toher hand we're
saying we can't do everything, and what's the most important bit, then I can
see the value of deferring from this.

Robert_Shilston: How about postponing this to a 2013 document

dom: Let's focus on implementation as that'll enable us to get good results
sooner rather than later. We shouldn't forget these issues, and postponing
them to the future probably makes sense. For example, user-envagement, good
user-experience surrounding web apps shouldn't be lost entirely.

<jo> PROPOSED RESOLUTION: Focus on implementation in 2012 but note that user
engagement, application lifecycle, deployment and other issues are important
and specifically call that out in the document with reference to App Config as
a specific example

tobie: Two things: Chromeless mode has to be attached to some point in the
spec. App config is a good place to have this. The other thing is to use the
manifest to track permissions surrounding quota etc.

... Having compatible implementation for chromeless and quota control is
really useful.

<jo> PROPOSED RESOLUTION: Focus on implementation in 2012 but note that user
engagement, application lifecycle, deployment and other issues are important
and specifically call that out in the document with reference to App Config as
a specific example

<jo> PROPOSED RESOLUTION: Focus on implementation in 2012 but note that user
engagement, application lifecycle, deployment and other issues are important
and specifically call that out in the document with reference to App Config as
a specific example - hence strike 3.5 and move it to an appendix saying the
foregoing

<hptomcat> +1

Josh_Soref: Pre-authorising the size requirements for an app is hard, as
different people have different requirements. Hard coding a quota limit is
unlikely to be a good solution. If I use Picassa, then should the manifest as
for 1MB or 1TB? If it's 1MB, then I'll exceed it quickly. If it's 1TB, then
device will say it's not possible.

mounir: The mozilla manifest is only used if you install the app from a
marketplace or a webpage.

jo: Any objections to the resolution?

Gavin_: I've concerns about chromeless mode.

dom: It's an ongoing debate of features vs specs.

tobie: Chromeless mode is a thing that a developer wants to make the app run
occupying all screen real estate.

... This is not the same as the full screen API, which is about making an
arbitrary DOM element fill the screen.

<dom> (there is also a further question about "chromeless" vs "fullscreen":
some mobile native apps have a fullscreen mode where the OS "chrome" [i.e. in
general the top bar] disappears)

tobie: This is a feature request. There's no spec.

... A developer might build an app with with navigation, and doesn't need the
browser to help supply it.

<jo> PROPOSED RESOLUTION: Focus on implementation in 2012 but note that user
engagement, application lifecycle, deployment and other issues are important
and specifically call that out in the document with reference to App Config as
a specific example - hence strike 3.5 and move it to an appendix saying the
foregoing

<jo> PROPOSED RESOLUTION: Focus on implementation in 2012 but note that user
engagement, application lifecycle, deployment and other issues are important
and specifically call that out in the document

<gmandyam> I think 3.7 Chromeless Mode is already met by the WebApps widget
spec. I do not believe a new spec needs to be defined by the WebApps WG. If we
are to keep this requirement in, then we can point to existing widget specs.

<jo> PROPOSED RESOLUTION: Focus on implementation in 2012 but note that user
engagement, application lifecycle, deployment and other issues are important
and specifically call them out in the document

Josh_Soref: +1

tobie: I'm concerned about this resolution

dom: Maybe we should consider "implementation" to be technologies the browser
provides, rather than ...

Gavin_: Browsers don't exist outside their device implementaiton

<jo> PROPOSED RESOLUTION: This document will focus on features that need to be
implemented by vendors to support functionality of apps rather than features
that are important and necessary for lifecycle, user engagement, deployment or
other aspects that are not core to the intrinsic operation of the applciation

dom: The ability for the user to bookmark the web application on their home
page in a controlled way is something that we deem to be out of scope for
something we are trying to do right now. We are trying to do a more general
characterisation. It's not the exact workflow of bookmarking, or how the web
app is awoken outside the browser experience, or how the user pays for the
application. These are the things that are not in focus for 2012; for this p

... for this particular iteration of this document.

tobie: To Gavin - when talking about 3.7 and chromeless mode: We're just
trying to emulate the Apple homescreen meta tags.

<jo> PROPOSED RESOLUTION: This document will focus on features that need to be
implemented by vendors to support intrinsic operation and functionality of
apps rather than ancillary features that are necessary for lifecycle,
monetisation, deployment or other aspects that are not core to the intrinsic
operation of the application

<bryan> +1

<jo> PROPOSED RESOLUTION: Strike 3.5

tobie: Mozilla proposed a new spec for orientation lock

<jo> PROPOSED RESOLUTION: Add a note that being able to lock orientation is
essential for some classes of app (e.g. games) so add a link to Mozilla's
specs and say it appears to offer the features we need

<hptomcat> [https://wiki.mozilla.org/WebAPI/ScreenOrientation][41]

<mounir> [http://www.w3.org/TR/screen-orientation/][42]

<jo> PROPOSED RESOLUTION: Add a note that being able to lock orientation is
essential for some classes of app (e.g. games) so add a link to Mozilla's
specs and say it appears to offer the features we need, however at the present
time it's not clear what support this has any prospect of adoption

dom: the note about orientation lock essentialness belongs to the use case
document, not to coremob-2012

... number ways to achieve what we want-- reference it, push a WG to do it, or
push vendors to look at and respond

<jo> PROPOSED RESOLUTION: Remove section 3.6 on the basis that there is no
specification that fulfils the requirement that we require

dom: this document makes us focus on specifications, but we're interested in
features

tobie: the problem with speaking in terms of features is that we'll have to
write specs

<jo> PROPOSED RESOLUTION: Remove section on View Orientation on the basis that
there is no specification that fulfils the requirement

jo: we can't reference specs that were written on a back of a napkin

<hptomcat> we have it implemented for installed apps (setOrientation)

<fantasai> ...

jo: Can we make progress on 3.6 and 3.7?

tobie: Not today or tomorrow

... I propose we merge the two specs

jo: I don't agree with that

dom: I don't think we're going to get consensus on how to move forward on
these documents tonight

[ Adjourned ]

trackbot, end meeting

## Summary of Action Items

**[NEW]** **ACTION:** Bryan to propose a feature in HTML5 that is both not
widely deployed nor useful to a large share of applications [recorded in
[http://www.w3.org/2012/10/02-coremob-minutes.html#action02][35]]

**[NEW]** **ACTION:** dom to propose improved phrasing for "Device Adaptation"
so that it's clear what parts of the CSS-ADAPTATION spec we need [recorded in
[http://www.w3.org/2012/10/02-coremob-minutes.html#action05][43]]

**[NEW]** **ACTION:** Gavin to write up the need for application configuration
[recorded in [http://www.w3.org/2012/10/02-coremob-minutes.html#action06][40]]

**[NEW]** **ACTION:** Leong to propose text summarizing the discussion on the
list, i.e. what we propose as the "mobile web app" characteristics [recorded
in [http://www.w3.org/2012/10/02-coremob-minutes.html#action01][23]]

**[NEW]** **ACTION:** Tobie to amend 3.4 Device Adaptation to reference the
section number applicable. [recorded in [http://www.w3.org/2012/10/02-coremob-
minutes.html#action04][37]]

**[NEW]** **ACTION:** Tobie to right use cases that document the advantages of
the Web in multi-screen/multi-devices scenario (e.g. that would justify CSS,
SVG) [recorded in [http://www.w3.org/2012/10/02-coremob-
minutes.html#action03][36]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][44] version 1.135 ([CVS
log][45])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]:
http://www.w3.org/community/coremob/wiki/Meetings/F2F_2012-10-02_and_03/Agenda

   [4]: http://www.w3.org/2012/10/02-coremob-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #item09

   [15]: #item10

   [16]: #item11

   [17]: #item12

   [18]: #item13

   [19]: #ActionSummary

   [20]: http://junglecode.net/coremob/coremob.html

   [21]: http://html5-benchmark.com/

   [22]: http://people.w3.org/~dom/archives/2010/08/what-is-a-web-application/

   [23]: http://www.w3.org/2012/10/02-coremob-minutes.html#action01

   [24]: http://www.w3.org/2012/08/mobile-web-app-state/

   [25]: http://mobilehtml5.org/

   [26]: http://coremob.github.com/coremob-2012/

   [27]: http://www.w3.org/TR/qaframe-spec/#glossary

   [28]: http://dev.w3.org/html5/decision-policy/html5-2014-plan.html

   [29]: http://coremob.github.com/coremob-test-approach

   [30]: https://docs.google.com/spreadsheet/ccc?key=0AuIhlK0fCwP4dEFPR1pUWHk1
QVczcV9xbFAtX19CMXc

   [31]: http://www.w3.org/community/coremob/charter/

   [32]: http://tobie.github.com/COREMOB-1-REQ/index.html

   [33]: http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-
capture/scenarios.html

   [34]: http://coremob.github.com/coremob-2012/ED-
coremob-20120924.html#conformance

   [35]: http://www.w3.org/2012/10/02-coremob-minutes.html#action02

   [36]: http://www.w3.org/2012/10/02-coremob-minutes.html#action03

   [37]: http://www.w3.org/2012/10/02-coremob-minutes.html#action04

   [38]: https://bugs.webkit.org/show_bug.cgi?id=95959

   [39]: http://dev.w3.org/html5/spec/the-meta-element.html#standard-metadata-
names

   [40]: http://www.w3.org/2012/10/02-coremob-minutes.html#action06

   [41]: https://wiki.mozilla.org/WebAPI/ScreenOrientation

   [42]: http://www.w3.org/TR/screen-orientation/

   [43]: http://www.w3.org/2012/10/02-coremob-minutes.html#action05

   [44]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [45]: http://dev.w3.org/cvsweb/2002/scribe/