See also: IRC log
<trackbot> Date: 02 October 2012
<Josh_Soref> Scribe: Josh_Soref
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
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
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
<tobie> Another Canvas HTML5 benchmark: http://html5-benchmark.com/
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
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
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
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"
<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]
<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
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.
jo: straw poll... how man for dinner (6:30pm)
[ 20 people ]
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/ ?
Gavin_: MobileHTML5
tobie: +1
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/
[ 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 ]
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
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
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
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
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
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/
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
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
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
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/ 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
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
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
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/
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]
<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]
<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]
<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
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 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]
<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
<mounir> http://www.w3.org/TR/screen-orientation/
<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