See also: IRC log
<darobin> trackbot: start meeting
<trackbot> Date: 25 June 2012
<trackbot> Meeting: Core Mobile Web Platform Community Group Teleconference
<trackbot> Date: 25 June 2012
<scribe> scribe: Josh_Soref
darobin: Good morning everyone
... I'm Robin Berjon
... one of the co-chairs
... along with Jo Rabin
James: Welcome
... welcome to our warehouse
... my name is James
... I'm responsible for our Advocacy work
... this as you might imagine is not where Facebook lives
... it's the remnants of our old building
... sadly we won't be able to bring you to our new campus
... I don't think I need to tell you about Facebook
... the web at the moment is in an interesting place
... with respect to mobile
... the web has been around for a long time
... a couple of years ago Wired Magazine had an article
... saying "The Web Is Dead"
... but there's a future with mobile
... at the moment for mobile, if you want to make an app for mobile
... the Web is not your first choice
... apart from the very simplest experiences
... it isn't the runtime
... Mobile Web / Mobile HTML5 has passed the peak of excitement
... in 2012, there's a bit of disillusionment amongst developers
... if you're building a social-photo application, and you don't have access to the Camera API
... you don't have it
... if you're trying to build a music app and you don't have access to music apps, you don't have it
... if you're trying to build a game, and you don't have access to accelerated canvas
... you don't have it
... one of the reasons Facebook got excited about this group is because we feel that the world's web developers have an opportunity
... to speak to vendors
... in one voice about what they want
... the web developer community has been Defensive
... Graceful degradation,
... I want web developers to say "No, we refuse to use this stack"
... "until you provide Hardware orientation lock, audio APIs, etc."
... this group is a chance is a way for us to stand up
... say what we want from browsers/standards
... and a chance for us to put the mobile web stack back into the running
... I want to prove Wired wrong
... I look forward to seeing the results
darobin: Thank you James
... can everyone here me?
[ Yes ]
darobin: thanks a lot
... one of the things this meeting is trying to do
... is to get people to know eachother
... so we can work together
... the first step is to ask people to introduce themselves
... in addition to that, it'd be good if you had 2-3 sentences
... about what's important for you in this group
... what you hope to get out of it
... before we get started on this
... I'll ask you to say your name Clearly and Slowly
... I know you can say it really fast
darobin: I'm Robin Berjon, Freelancer, one of the co-chairs of the group
... I'm hoping to get a description of a platform that developers and XX2 agree on
... and a testing system
jo: I'm Jo Rabin
... I'm the new boy
... I'm delighted to be here
... I'm taking over for Tobie
... I'm CTO at a specialist mobile agency called Sponge in London
... specializing in mobile web apps
... prior to that I chaired Mobile Best Practices WG
... XX3
... I want to get out of this meeting
... working since 2000
... on mobile
... that hasn't happened until 2007
... I can't say it has happened yet (in 2012)
... my patience is running thin
... I'd like this to be the year of the mobile web
... let's make it happen this year
tobie: I'm Tobie Langel
... I used to co-chair this group
... I stepped down to focus on editing this spec
andreatrasatti: Hello, my name is Andrea Trasatti
... I work for Nokia
... I want to get clarity on what developers need to create great Web apps for mobile devices
DanSun: Dan Sun, from Verizon wireless
... this is my first time in the w3c community
... I'm here to hear from mobile experts
... I'd like to get APIs into level 1
wesj: I'm Wes Johnston
... working for Mozilla on Mobile Firefox
... I'm here to learn what developers need
... trying to develop the right APIs for what they need
jet: I'm Jet Villegas
... I'm the engineering manager for Gecko layout team
... we're about to ship mobile Firefox
... we'd like to accommodate UCs in future versions
Yan: My name is Yan Yu
... from mobile tab
... we make the Dolphin Browser
... I'm interested in how HTML will evolve
Dehghan: David Dehghan, representing Mobile Tab
... our goal is to find out how to prioritize HTML5 technologies in our browser
... and try to contribute to that prioritization
jfmoy: Jean-François Moy
... I work for France-Telecom Orange
... I'm here because I'd like developers to have more APIs
... I'd like test coverage for current features to be improved
Josh_Soref: I'll be your scribe for today and tomorrow
... RIM
... we're mostly interested in the Runtime/Security model
... we're worried that working on too many APIs will distract us from that work
fantasai: I'm fantasai
... I'm on the CSS WG
... I'm here basically to be the liaison between CSS WG and this CG
... help integrate our testing efforts and
... taking feedback on specs
Robert_Shilston: Rob Shilston from FT
... here to share what we've experienced building web apps
... to ensure we can make apps that work really well for end users
marcos_lara: Marcos Lara
... I'm an HTML5 developer
... I was a web app launch partner with FB in Oct of last year
... as a developer, I'm here to see where standards are going
... I can agree with James there was an amount of exuberance that stalled out
... and we want to pick that up
vidhya: vidhya gholkar
... with Vodafone
... we'd like to see how much this CG can help us with Terminal testing
... for HTML5
mansoor: Mansoor Chistie
... I'm with Texas Instruments
... working on the Web Technology Architecture Team
... first time in W3C
... interested in direction and UCs and level-1 definition
andrewhubbs: Andrew Hubbs
... web developer at Rally
... first time in W3C
... here to learn and see how I can contribute to ushering the mobile web forward
hwu: Harrison Wu at HTC
... here to see what the next step in mobile web will be
... and HTML5 platform
jshen: Julian Shen at HTC
... engineer on HTML5
... here with hwu
itai: Itai Dadon with ST-Ericson
... from the hardware side
... our cycle is much longer than the software side
Eunjoo: Eunjoo Lim from LG
... first time in W3C
... I'd like to learn the status of Ringmark
Dong-Young: Dong-Young Lee
... also from LG
... here to see about priorities in web platform
Daniel_Samsung: Soohong Daniel Park, Samsung
<Daniel_Samsung> I want to understand how to use html5 features for Samsung AllShare solution in our products
bkelley: Brian Kelley, Qualcomm innovation center
... our interests are doing what we can to further this effort
... and provide input based on what we've heard from developers
ono: Chihiro Ono
... KDDI
... a phone company in Japan
takagi: Koichi Takagi
... KDDI
... I'm interested in Video/Audio streaming for mobile phone
... and the testing process
... since its cost is rising
nghanavatian: Nima Ghanavatian from RIM, working on the browser
... Interested in using Ringmark to test and validate the spec
Wonsuk: Wonsuk Lee, Samsung
... I'm in charge of HTML5 on Tizen
... I don't know how many people know about Tizen
... it's a web OS , open source project
... I'm here Widget requirement
... is important to our platform
ytsai: Yinghau Tsai, "Patrick". I work for MediaTek
... smart phone
... Part of my team is responsible for browser development. We attend this meeting because we want to make our browser a better platform for HTML5
... applications
ming: Ming Jin, work for Samsung on Tizen platform
... Would like to find out from this F2F what is the req's for browser vendors and web developers
... Would like L1 defined ASAP
... Hope to contribute to defining L1 requirements
chrisramos: Chris Ramos, product manager for Nokia
... Work on mobile browsers
lbolstad: Lars Erik Bolstad, represent Opera Software
... Responsible for Presto engine development. Also chair W3C Geolocation WG
... Interested in what the web devs think are the most important use cases and reqs for browsers
... Hoping this group can help produce better test frameworks etc.
WaiSeto: Wai Seto, work for Nokia developer relations team
... Started 10 years ago, working with WML browser/scripts. Was fun. Now we're 10 years later working on core mobile community group
... Joined this group relatively recently. First want to make connections with all of you. Also participate in group to educate web developers on these mobile APIs
girlie_mac: Tomomi Imura, recently joined Nokia developer relations
... Worked as mobile web developer, huge passion for mobile web and web standards
... Want this to become more than a buzzword
... Want to learn more about Ringmark. Pretty new to this community.
mattkelly: Matt Kelly, work at Facebook. Work on Ringmark, helped organize coremob
... Building web my whole life, want to build web on mobile
... Worked with 100s of devs. Push for Ringmark and coremob came out of frustration of web devs
... things that have disabled people from building for mobile web
... Want to get us to agree on L1. Also would be great to have agreement on L0
... Looking for consensus, open us to working on implementation
... Also want to get a test suite out that people can test products against
jo: Interesting to hear what people are interested in. Good to hear consistency of purpose.
... Seems to me in joining the group, that there is continuing confusion between Ringmark and coremob
... Since Tobie's here since the beginning, would like some background on explaining the distinction
tobie: Coremob, first of all, is this group with all of you here. When we launched coremob earlier this year in Barcelona, we announced
... FB announced Ringmark, which is a test suite that my colleague mattkelly now works on
... Quite shortly afterwards, in 2 steps, donated the tests to W3C and open sourced the whole test suite
... That's what ringmark is
... Other side there's Coremob L1 spec
... Which is W3C CG specification
... Document we are working on
... While FB gave test suite to group as a seed for a possible conformance ...
... and quality of implementation test suite
... Group has to decide what to do with it, pursue working with it, how etc.
... L0 spec has been mentioned a few times
... worth talking about that
... One idea when we launched the project was to first get a kind of, what we felt, was a state of the world specification
... Which was to be L0
... And to have a short set of really focused goals on what was missing, what could be improved in reasonable amount of time, that was L1
... Quickly appeared two things
... First was getting consensus on what current state of the world is happened to be more difficult than expected
... Those of you that follow mailing list, seen a lot of debate about this
... 2nd thing, very difficult to make a spec that describes that which is existing
... A lot of implementations moving from HTML4 to HTML5, ECMAScript 3 to 4
... Delimiting current state of the world happened to be technically so challenging,
... I thought it better to move into a forward-looking aspirational document rather than anything describing current state of the world
Dehghan: How does Ringmark test suite correspond to coremob L1
tobie: Originally each ring corresponded to each level. But now there's this misalignment
... Need to fix
DanSun: what's the relation of levels and rings?
tobie: ... distinguish actual spec from conformance test for it
... Clarify this one last thing, important when we talk about this, have issues about this, make sure we're talking about the right things
... If it's issue with spec, talk about spec. If it's issue with test, how test is implemented, it's a test problem
?: How has contents of L1 document, where does it come from?
Robert_Shilston: Is your inspiration other W3C groups, or is it looking what you're needing at Facebook, what functionality you think you'd like to turn to in the future.
tobie: When we started on that project Q4 last year, we talked to a number of developers and number of people in industry to gather best possible picture of what first of all was the current state.
... What were devs currently basing their applications on
... That was a first step
... Second step was looking at what exactly are people requesting that is a problem
... What is missing, improperly implemented, etc.
... Talking to developers mostly, our partners
... Also looked at what applications were built, what were top 100 apps built on native platforms and what features were missing from Web platform to build those on the web platform
... Finally looked at the existing implementations and existing specifications to see what was possible and what made sense to target in a small amount of time
... That's why some are separated into L1 and what will probably become L2
... want a reasonable amount of feature in reasonable amount of time
... Once we have an L1 spec and implementations conformant to L1, then app devs can look at that and look at "now what"
Robert_Shilston: Mobile web moves really fast. What cadence do you have in mind for iterating these?
tobie: I think once a year would be awesome
jo: Looking at L1 spec, and talking about testcases
... I think it's important for us to come out of this meeting with some clearly defined objectives
... One objective would be to have a timetable in mind for completing a substantial phase of work
... So working backwards, my suggestion would be that we define for the purpose of the group, what can we do, by the end of this calendar year
... And leave some time for tidying up
... SO what can we realistically achieve here is a question for the objectives of this phase of work
... There are a lot of tests to write, seems unlikely that all will be assembled by then
... So let's define the scope of the tests
... e.g. L1 use cases
... tests can continue after that point
... I want to throw that suggestion out onto the floor, before coming to point of this meeting
jet: I have something to add to that
... As browser implementers, we submit 10s of thousands of tests to W3C,
... And we have tens of thousands of tests at Mozilla
... We are very interested in having this group leverage that
... Several years' worth of work
... We think on the mobile platform, we want to get parity with mobile and desktop and beyond
... We would like this group to work within existing infrastructure, rather than writing tests from the ground up
tobie: I agree with that, part of group's charter
... have that discussion tomorrow
darobin: Please come to that discussion having thought about what you want to get out of that discussion
... I would be interested in hearing requirements before talking about our existing system, so people aren't influenced by what we have
Dehghan: What is coremob's relationship with major providers of browsers, e.g. Apple and Google, who are not represented here?
... What do they care about?
... How seriously will they take our recommendations
fantasai: If producing good work, basically doing research for them, think they will take into consideration
... Good test suites also puts PR pressure on browsers to implement things better
... if test results are well-reported
DanSun: ...
jo: I think L1 is to say that we are done with the document Tobie has done
darobin: There's no way we'll have tests for everything in the spec by the end of the year
... The chapters that we'll have tests for by the end of the year will be extremely low
... But could have a document, and a large and growing body of tests, which would give us increasing confidence that that document is supported or not
... Probably won't have it by the end of the decade... but that's another problem
jo: So what do we want to achieve by the end of today?
... Would like to have gone through current draft line by line and for any major issues, on what should not be there, or what's missing, and what's wrong
... Work item from this meeting would be to fix all those issues
... If you have something to raise, make sure you raise it. Doesn't matter whether minor or major
darobin: Would be really good to have document in publishable state so we can push out to community with feedback
... Need sufficient consensus in group that it has the right shape overall
jo: What's not clear from the list is ...
... First point for newcomers, want .. understood by new members.
... Important to get stuff on the list, so as people join the group there's a trail of stuff that can be referred to
... People will not be able to find things on the list
... Not everything has been documented
... L0, L1 thing
... ...
... why L0 is not there, or has been shelved
... I noticed that Nokia referenced the "default delivery context"
... Something that we discussed at length in best practices WG
... Why does this cause contention? Similar to L0
... What we needed to clearly identify was that mobile best practices were not about WML
... that were about the web
... Wasn't talking about webapps, because this was 2005/6, but about old-fashioned web pages on mobile devices
... OneWeb was also something that caused a lot of contention
... All kinds of people saying, mobile web thing can't be allowed to exist, because there is only one Web
... But what some people meant by One Web was different by what other people meant
... I think that discussion is over, different representations at one URI is accepted
... we could have said this is way too contentious and avoided issue, but didn't and made progression
... I'm not averse to lifting the lid off some topics to find consensus
... If we start at L1, we start a little bit in midair, don't have our feet on the ground. Potentially dangerous.
... "Default delivery context", what is meant by a browser on a device
... Lots of people complained this was to dumb things down
... and that people would develop web pages to a least common denominator
... Device vendors wanted to exploit things beyond the LCD
... Intention was to distinguish mobile web browser from house brick
... If you fall below this level, then you can do some things but not all things that are fundamental to web
... One issue that year was "is table support mandatory in a mobile web browser"?
... Seems ridiculous now, but a bunch of browsers that supported tables in a very buggy way
... I think there's a case for saying we don't consider browsers that have lower than a certain level of support as in scope for this discussion
... L1 seems to me is a goal that has not been achieved by anybody. It's forward-looking. But we have no retrospective
... We don't have a "no, that's not a mobile web browser"
... Anyone have things to say about why L0 is a useful thing to have
vidhya: Devs don't give two hoots about this. They just want stuff to work.
... What you call it is irrelevant. We just want tests that ensure that the stuff in there work.
Robert_Shilston: I echo that, and testing is important
... We can't change what we're building based on where things are going to go
... We had a problem where local storage got purged if you got a calendar invite that was 7 lines long
... How much is defining best practices for browser and web devs to work together to make things work
... The headline of what you want to do is to enable highest number of applications short term
... Is that best done by working on a toolkit? Is that best done by ...?
jo: Does anybody care about L0?
jet: We do. Leveling in Coremob seems to imply that you build levels upon others. Have a strong foundation to build on, and then build L1
... I like that, otherwise all aspirational
... We should work on things like tables, where need a spec there. Want the foundation to be there rigorous and correct. Not just about what was in Mobile Safari last year
... We don't think that was rigorous enough
darobin: Do you have a strong notion of what how to build this rigorously?
jet: There's testing, that's single most important thing.
... Agree on a certain set of rigor on L0
... If we can apply that similar notion to ..., would be good use of time
... Both correctness and perf
darobin: What kind of resources do you have to commit to that
jet: We'll see what the need is. As said, we've already submitted thousands of tests
... To call it L0, it allows use cases to happen
tobie: Wanted to point out confusion on spec vs tests
... The problem I see was, suggestion you're making here. Tests. But test what?
... Until we define precisely what's in L0, can't test it
... What do we put in L0?
... I don't see how we can possibly have a full test suite for something we haven't defined.
... I'm very concerned that we are going to spend a lot of things make it into L0
... What's the baseline, what's not
darobin: I agree with where you're coming from but wondering, if we wrote the tests to match level 1, could we not call L0 as the subset that is passed by implementations?
... We could say L1 is what we aspire to, and L0 is the rising level of actual implementation support
... Then don't have to jump through hoops of creating another spec
... whenever the L0 line meets L1, then everyone is happy
jo: Don't see L0 as capturing state of art of current browsers
... Think L0 is reasonably some abstract feature set that majority of vendors support but probably none of them support correctly
... interop seems to serve dev community most urgently
Josh_Soref: Someone used analogy of building a house with bricks and levels. One of the things looking at Ringmark and what we have, a lot of these things are not things you build one level at a time. They're more components
... If I have an office and a stereo system and a library. For the library I need shelves, for the music room I might need just a table
... Building levels on levels doesn't seem to do much good.
... If you're building an audio app, you don't really care if canvas is doing wonderful things, unless you're also building something that's using canvas. Not necessarily useful to you
... Fighting over L0, energy spent is already too much.
... I also don't want to canonize that you must support -webkit-.
... I don't think that's the right way to go
... I don't want us to write tests that make it easier to support vendor-prefixed versions of things than to support standardized things
jo: Can we steer clear of specific implementers' technologies for now.
... ...
... Vendor prefixes not part of that discussion
Josh_Soref: I don't see any benefit in having a L0, and think we can work from defining L1.
... If someone wants to come up with a list of things that theoretically work but aren't quite there.
... Things that most browsers have some implementation, that people use, but not implementations are not correct.
... A lot of people are more interested in new features.
... I think that having people submitting tests to improve quality of implementation on old features
Dehghan: In my mind maybe we just have a classic feature prioritization issue, and if we could apply some kind of objective measure
... mentioned searching top 100 native apps, what feature sets would be needed to get there
... Fact that in L1 if we add in all of HMTL5 and CSS3, such a gigantic step, not all browsers will implement features in same order
... It's a multi-release kind of problem for any browser
... So if we could consolidate industry around implementing features in same order, then devs can rely on those features earlier on
<fantasai> Dehghan++
Dehghan: Different browsers will get to L1 at different speeds, and entire platform will be fragmented.
... Come up with some test for what should be included, search for existing usage, vote by community, etc.
[ fantasai spoke but there was no scribe to record as she was scribing this section ]
mattkelly: I think the main goal, was one drive implementations, and two, reduce fragmentation
... The goal for launching group and Ringmark, was not to say "we need all of HTMl5", but to say "this feature is important for people to build their app"
... So we're purely taking pragmatic standpoint of what are people trying to build, what can't be built and why, what features are missing and what perf problems are there
... I think L0 is important for reasons stated before
... It's what app devs are building on today
... When FB builds mobile web app, we have limited engineers that can work on it
... only a few engineers.
... We generally only test the most popular browsers: iOS and Android
... Any app dev team, is going to do the same
... Problem with not having L0 and jumping to L1, we'll say we want X perf on canvas,
... but there aren't things that people are relying on today that are missing from cutting edge browser that make web app breaks
... maybe has fast sprites, but audio doesn't work
... outside this group, would be good to understand people are building today
... web apps won't work in your browser if don't support L0
... what are people trying to build now,
... currently playing catch-up to native
... fixing those problems, and hopefully tipping point then can reach for things that will set mobile web apart
... boils down to pragmatism
... for L1, we targeted 2D games, camera apps, and ?
... That's what sells devices
tobie: Should we rename L1 spec to L0, or should we not have a level now at all until we actually work on a L2 spec and figure out whether this is a building block on foundations or different rooms
... Could very well be that the levels would be better seen as timestamps
... This is 2012 goals
... Here are 2013 goals
... Given that we actually are working on only one level spec at the moment, not two or more, why not drop level idea and bring it back when we actually have a conversation with data
... Second thing wanted to say is, I've had a deep and serious look at editing L0 and trying to make it a good picture of what's going on right now.
... It's super hard, I don't want to do it
... I think Dehghan's point about feature prioritization is exactly what we're trying to do
... What are things are really needed now, and focus on it
... So whole industry is focused on it
... one reason mobile web runtime isn't as good as it should be, and different vendors don't have a common view of what's important
... One feature requested is fast WebGL, but actually web devs want fast canvas
... Regarding HTML5, discuss as part of L1 document
... what do we include
... easier to do with CSS3, since modularized
... Want to make a compelling platform for app development
jfmoy: Imo Levels are a really good notation,
... Easy for browser to say "I'm compatible with L1"
... Helps developers to understand what browsers they can target, what features they can use for a given target
... I really like the level notation, want to keep it
fantasai: Listening to Matt Kelly, seems L1 should be the set of features that we want and need, and L0 should be about defragmenting the current mobile web
jo: Exactly, it's about what can developers expect to be there
... Expect reasonable support for these features, not being broken
... Seems to be moderate support for something that is L0, what constitutes L0 is still open to discussion
... I have a proposal that L0 represents features that we desire that have stable specs
... One can reasonably produce a set of tests that can ascertain the implementations
... The world is short of public tests. Seems browser vendors do have loads of tests they're willing to contribute
... We should encourage that
... Matt made some interesting points
mattkelly: What types of apps require what types of features?
... In rounding out this particular discussion, can you take an action to create that map
jo: My part what I'm going to do is to try and create a working discussion wiki document with a view to seeing if we can find a consensus position which is sensible about L0
... Suggest we spent rest of day talking about L1
tobie: that's an open issue
jo: Suggest making that assumption for now
... As Tobie points out, if want L0 spec, need a L0 spec editor
... So if we want an L0 spec, need an editor
... look at what resources you can bring
<fantasai> ACTION: Jo Rabin: Short document on how to get an L0 out and what it might mean [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action01]
<trackbot> Created ACTION-2 - Rabin: Short document on how to get an L0 out and what it might mean [on Jo Rabin - due 2012-07-02].
vidhya: So, what is the message to developers here?
... we're not doing L0, so what are we actually telling developers
jo: I don't think we're saying we're not doing L0. It's shelved. I'm trying to ascertain whether the group wants to take it down and take it on, or to put it in the trash.
<tobie> delta between L0 and L1 roughly described here in terms of features: http://www.w3.org/community/coremob/wiki/Specs/Coremob_Level_1
jo: It seems to me that from dev point of view, seems very useful.
... L0 is something that a dev can reasonably expect a consistency of implementation and a reasonable set of good quality tests to ensure conformance
<tobie> problem with describing L0 is current implementations are in-between HTML4 and HTML5 and ES3 and ES5 right now, and as these aren't backwards compatible, this is difficult.
vidhya: So you're saying that is the expectation a developer to have
... Are we there today?
marcos_lara: 0 is there today, I built an app today with mattkelly as my guide
jo: Who has experience with acid tests?
fantasai: Eric Meyer wrote ACID1, trying to point out the most egregious interop issues with CSS at the time
... and then many years later Hixie, while at Opera, wrote ACID2 to do the same thing
... and then ACID3 started up, but it was less strong and more random
jo: it is important to keep that in mind because ACID has been successful
... and we have a lot of the same goals
Josh_Soref: Want to point out that Acid tests have occasionally introduced bugs in the platform, because of errors in the tests
... and developers trying to match the test, and therefore mismatching the specs
... Trying to beat those problems out
[ Break for Coffee ]
<scribe> ACTION: jo to ACTION mattkelly to circulate his research on types of apps requiring types of features [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action02]
<trackbot> Created ACTION-3 - ACTION mattkelly to circulate his research on types of apps requiring types of features [on Jo Rabin - due 2012-07-02].
<tobie> http://coremob.github.com/level-1/
darobin: if people aren't happy with the abstract
... we can fix it fairly easily
... note that this document is on GitHub, you can fork and submit pull requests to the editor
tobie: a couple of things I'd like to say
... I made this document as thin as possible
... I tried to make the document as thin as possible
... I'll have another document for Requirements and Use Cases
... I'm planning to do the same kind of work that mattkelly has an action to do
... a list of applications we're hoping that Level 1 would enable
... listing the features an application will need
... the introduction restates the goals of the CG as expressed in the Charter
... same balancing idea
... between what developers would like to see in the specification
... and what's doable in a reasonable period of time
... I tried to group things in a sensible way
... I filed a number of issues on the spec which I'd like to discuss with you today
... 1. HTML5
... an implementation must support HTML5
jo: over coffee, "what is the meaning of mobile/web applications?"
... I'd like to see a link to any discussion we'd like to have
... possibly removed later
<scribe> ACTION: jo to start a discussion on "what is the meaning of mobile web applications?" [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action03]
<trackbot> Created ACTION-4 - Start a discussion on "what is the meaning of mobile web applications?" [on Jo Rabin - due 2012-07-02].
<jo> ?
jo: second, can we remove the word "Core" from the introduction
<darobin> ISSUE: Should "core features" actually be core at Level 1, or should we just consider features (in Level 1 Intro)
<trackbot> Created ISSUE-18 - Should "core features" actually be core at Level 1, or should we just consider features (in Level 1 Intro) ; please complete additional details at http://www.w3.org/community/coremob/track/issues/18/edit .
DanSun: maybe we should add the application categories we wanted to facilitate
... were we going to move the messaging application to level 2?
tobie: Rich wanted that in networking
... I don't think it's in scope for level 1
DanSun: because the technology isn't there?
tobie: both that, because the APIs to access it aren't there
... and because it isn't a core feature
darobin: we don't have Push Notifications
... Web Apps WG is working on it
... but we can't reference it
jo: can we record that SMS is a key feature of mobile
... it's a key feature for mobile
... having SMS interop outside of scope of level 1 is odd
<darobin> ISSUE: Lack of a push notification system, important feature, but no sufficient specification at this time
<trackbot> Created ISSUE-19 - Lack of a push notification system, important feature, but no sufficient specification at this time ; please complete additional details at http://www.w3.org/community/coremob/track/issues/19/edit .
DanSun: and Push
tobie: having a list of targeted applications and requirements
... is something I'm working on now in another document
... we can see if we include it directly in this document, or reference it
mattkelly: I think re Push notification / SMS
... another class is distribution of Web Apps
... getting bookmarks of web apps on the homescreen
... or more easily bookmarked
... I think it's a much harder thing to accomplish
tobie: 2.1 UAs must support HTML5
... HTML5, today, the spec is a lot smaller than it used to be
... I think supporting it is a more achievable goal
<darobin> [documentation for trackbot, for actions and issues management: http://www.w3.org/2005/06/tracker/irc]
tobie: I haven't looked to see if we could slice it into bits and pieces
... and only require support for some bits
<mattkelly> issue-19: It might be useful to expand the issue of SMS/push notifications to include other points of distribution/engagement features. E.g., bookmarking mobile web apps to the home screen, how they can be bookmarked, etc. Basically features that enable developers to get better distribution/re-engagement of their apps.
<trackbot> ISSUE-19 Lack of a push notification system, important feature, but no sufficient specification at this time notes added
<darobin> documentation for Zakim, for meeting management
tobie: in the case where we believe 1/2 or 3/4 of a spec are really useful
<Robert_Shilston> During the break, Robert Shilston, Fantasai, Marcos Lara were chatting about the structure of the ringmark. There were two aspects to this. Firstly, dividing the ring circles into wedges: As an example, this would enable developers interested in audio apps could look at the audio wedge and disregard the typography wedge. Secondly, how to capture what's currently available for developers, and this could form a L0. There was discussion as to how
tobie: and the rest not so much
... should the CG give feedback to the editors of that spec?
<Zakim> Josh_Soref, you wanted to note that subsetting specs is a disaster
vidhya: from the point of view of a developer, I don't know what it means
... <!DOCTYPE> is html5
... is it even a reasonable
... it's not even a reasonable requirement
... I'd argue
darobin: there's a difference between this spec asking the browsers to implement things
vidhya: you have the spec, it's full of optional features
darobin: no, it's not
... the html5 spec has been trimmed down to features that are thought to be interoperable
... when we looked at this with tobie recently
... they removed the future bits to the next specification
<andreatrasatti> HTML5 is still marked as a "working draft"
vidhya: so there's no SHOULDs?
darobin: there's only a few SHOULDs
vidhya: I'm happy with what you're saying
... you should say here
fantasai: it should have a conformance section
vidhya: that's clearer
darobin: perhaps we should to address your point
<Robert_Shilston> ACTION: Shilston to clarify on the wiki that the active L1 spec document is on github, and describe when things should be discussed on the wiki and when Github issues are used to further the discussion. [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action04]
<trackbot> Created ACTION-42 - Clarify on the wiki that the active L1 spec document is on github, and describe when things should be discussed on the wiki and when Github issues are used to further the discussion. [on Robert Shilston - due 2012-07-06].
darobin: we could say "whenever you see UAs MUST support Document
... it means UAs must conform to Document"
Josh_Soref: my preference is to say instead of "MUST support" say "MUST conform to the Document specification"
<jo> ?
RESOLUTION: Add a conformance section to Level 1
tobie: group gives me something, I'll use it consistently
fantasai: your question was to break down specs
... for example Values and Units, you might want to exclude Cycle
<darobin> ACTION: Tobie to add a conformance section to Level 1 that explains what it means to say "User agents MUST support Foo [FOO]" [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action05]
<trackbot> Created ACTION-5 - Add a conformance section to Level 1 that explains what it means to say "User agents MUST support Foo [FOO]" [on Tobie Langel - due 2012-07-02].
tobie: should we break them down here, or go to them
fantasai: there's no reason to say it to the CSS WG
... you may want to cut out page-break
... but CSS WG might need it
<jo> note that consensus of the group re the above resolution was that in general reference should be made to the conformance section of the referenced spec by way of specifying conformance
darobin: 1. features we might not need
... 2. features holding things from being finalized
... when we went to CSS WG, we found things were AT-RISK
... which made us happy
... we want other groups to ship their specs
fantasai: right
Josh_Soref: Mobile groups have a bad track record of subsetting specs
jfmoy: we started this discussion about reducing fragmentation
... subsetting could make it worse
... it's easier to say this is "in complete conformance"
... it sounds like it'll make the same mistake as was done before
tobie: I'm raising that as I don't have an idea of how to handle it
jo: it seems to me there's a logical disconnect between us cherry-picking
... saying "you made the wrong choice"
... in general we shouldn't subset specs
... we should say to groups "you should subset specs"
mattkelly: from the dev perspective
... it isn't introducing fragmentation to subset
... Google came out w/ Glasses
... they need WebRTC
... vs Mobile Web
... where the popular item is 2d games
... Mobile Web reduced fragmentation
... saying we don't want to push....
... it's more about not reducing fragmentation globally, but within
... saying these are the apps we're trying to build
... and saying these are the features we're trying to build
vidhya: I think the points I wanted to make have been made
fantasai: the grouping of specs
... as a group working on specs
... won't be driven by one consumer
... CSS WG takes input from you, EPUB (very different), and things that are just simple
... some you might not want browser devs to implement
... (urgently)
... it might hurt your ability to ask browser devs to focus
... the considerations we have for subsetting are not the same as you have
... you can have things you want us to prioritize when we're in DRAFT
... but it's not going to work for things closer to REC
... if you request features that aren't important to you just because they're in the same spec, that dilutes your message about what is important to you
jo: in subsetting other's specs
... aren't we diluting other people's specs
darobin: we're affecting other people's focus
jo: specs that are already baked
... it would be unreasonable to require conformance to every last one of them
... where we do subset, we should be clear at the top of the document
... that it isn't intended to subset the spec
... but the testing and urgency of work on portions of the spec
tobie: are you suggesting we'd make supporting the whole spec a requirement
... and only test a subset?
darobin: we're weasel wording our way out of subsetting
jo: anyone with a problem with articulating the thought subsetting for the reasons described
... having clarified the reasons described
<darobin> proposed RESOLUTION: Subsetting is undesirable and will be avoided as much as possible; however it is pragmatically required in some cases. When subsetting does happen, it should not be understood as a subsetting of the specification itself but rather as a prioritization of our testing efforts
[ No objections ]
RESOLUTION: Subsetting is undesirable and will be avoided as much as possible; however it is pragmatically required in some cases. When subsetting does happen, it should not be understood as a subsetting of the specification itself but rather as a prioritization of our testing efforts
tobie: I added as notes QoI issues in relevant sections
... for html5 spec, the main issue is poorly implemented audio playback
... playing sounds in parallel and latency
... I identified sub 10ms latency
... if someone has a better number
jo: say you're doing DOM Tree Traversal
... are you interested in performance?
... you almost certainly need it to be reasonable
mattkelly: we need to avoid surface area testing
<Zakim> jo, you wanted to talk about quality of implementation issues
mattkelly: saying "audio is supported"
... saying you can support one file
... in mobile browsers, you get popping / audio artifacts
... a 2d game developer doesn't want that
... say <canvas> is supported, but how many sprites can you do @30fps?
... but you can't build Angry Birds/Words With Friends
... the hard part is understanding where those gotchas are
... it's hard for nuanced bugs in browsers
... on Android, there's an issue where if you animated something horizontally/vertically, it was accelerated
... but if you animate diagonally, it drops (frames/perf)
... it's important to test QoI
jo: what would your proposal be?
mattkelly: it's hard
... in a doc
... it's easier in a test suite
... you can also evolve it
... there are 2 ends
... incredibly detailed
... or preface to the doc "QoI is expected"
... performance/avoiding artifacts
lbolstad: for this doc/spec
... it's useful on one level
... but it needs to address QoI
... with ACID3, it doesn't address QoI
... you need to be able to animate with a certain speed
... but it quickly becomes hardware / device dependent
... there's certain iOS/Android
jo: it seems it's very hard given device dependencies
DanSun: I don't think we should depend on Hardware
... it depends on the hardware/application
jet: despite the difficulty of hardware stacks
... I like the idea of supporting games
... getting games to run well gets everything else to run well
... I want to encourage the group to look at it
Robert_Shilston: I want to show a demo based on jsFiddle to test a browser bug
[ Demos 2 browsers running concurrently ]
Robert_Shilston: we thought it was a hardware constraint
... until we got to browsers on the same and distilled it
bkelley: any perf test, it's impossible to factor out hardware
<Robert_Shilston> My example URL was http://jsfiddle.net/v7C4a/
darobin: I think we can survive this by defining a particular hardware
... such as Galaxy S2
... on a feature phone 120 sprites @60 fps
... is understandably not going to work
... users understand this
... we should be able to try to work our way out of the slippery slope
jfmoy: do you want to write out the hardware into the spec?
darobin: not in the spec
... if we have a QoI Test Suite
... I'd write that into the test
... if you have hardware with roughly these specs
... you should do this well
jfmoy: do you want Pass/Fail, or a score?
darobin: I'd like to get into them, but not now
jo: I find it seriously problematic to have numbers
... because they quickly become obsolete
... rather than specific numbers
... you have cross browser comparisons
... I'd rather relativistic nature
... than a specific numeric measurement
Robert_Shilston: I object
... in some areas, only iOS performs reasonably
... and in others, only Android performs reasonably
... you'll drag down the result
... it's reasonable to compare multiple browsers on a single Android device
... but what do you do comparing across different hardware (iPad, Galaxy Tab)
tobie: that metric is Requirement driven
... ask a game developer
... he'll say they have a sound file in the background
... and game triggered events
... 8 will work for most games
... maybe eventually 12 might be used
... but the number won't generally change
jo: I think it's problematic to code in numbers
tobie: 2 games is a certain case
... an audio synthesizer is different
bkelley: how would we phrase a relativistic test as a requirement
RESOLUTION: there is no strong interest in producing relativistic tests at this point in the group, we will keep focusing our Quality of Implementation efforts on absolute measures
jo: I'm trying to explore taking these outside the test domain entirely
... a matter of public record
bkelley: in terms of a specification?
...
RESOLUTION: The group has no taste for making qualitative issues into relative measurement and wishes to continue to try to formulate specific objective tests
tobie: I want to thank Vanessa for organizing everything
[ Applause ]
tobie: ... to close up on HTML5
... issue 1 ... about AppCache
... there was a Workshop organized by Vodafone
... where we talked about the problems with AppCache
... it didn't work very well with content generated on the server
... an index page of a blog would always display a cached version and not a live one
... that issue was fixed in the living HTML spec... worked on by WHATWG
... I think it's a critical issue
... the question is whether this group should lobby the HTML WG to include that in the HTML5 document
andreatrasatti: what is the time frame
... if the group wanted to lobby for it for HTML5
... if we also pushed for people to implement it
... you or darobin said HTML5 is basically stable
<jo> PROPOSED RESOLUTION: The Coremob CG requests the HTML WG to move fixing AppCache to the current version of HTML5
darobin: it's a very good question
... in this case, the problem is serious enough
... browser vendors have indicated they're willing to update it
... we could lobby the HTML WG to reopen
... at the cost of delaying
... we could ask HTML WG to move to a separate document
... but it would allow it to progress on REC track w/o holding things up
tobie: AFAIK,
... HTML5 will probably have a second LC
<jo> PROPOSED RESOLUTION: The Coremob CG requests the HTML WG to move fixing AppCache to a separate document and progress apace with moving that document down Rec Track
tobie: I don't think that particular issue would change timings of the spec
... of course, if everyone asks for changes, that would delay it
vidhya: we know this is important
... we know we need this
... what's being asked for?
tobie: there's an issue filed in HTML WG against the spec for that feature request
... it was fixed in the WHAT WG spec
... but the issue was closed by the HTML WG as "wontfix" for HTML5 as it's in LC
... and they don't want to add what they technically consider it to be a new feature
vidhya: AppCache needs to work, and it needs to work properly
darobin: do we want to leave the somewhat broken in HTML5?
... or delay HTML5?
... or split it up?
vidhya: maybe I don't understand process
... I don't understand what this group can do
darobin: first ...
... can we live with the broken version?
... I think the answer is not
vidhya: I don't think we can live with it
... if we can encourage the group to fix it
darobin: if we can't live with it
<jo> PROPOSED RESOLUTION: The Coremob CG considers the current version of AppCache to be damaging and requests that the HTML WG does not progress to Rec without fixing it
darobin: then we need to negotiate w/ the HTML WG
tobie: is this change in itself sufficient to make AppCache not broken?
... my feeling is "kind of"
... which is another aspect to consider
vidhya: looking at Blogs, how people are talking about this
... people look at this and say "let's not use AppCache at all... because it's so useless"
... so hosted apps become irrelevant
jo: Robert_Shilston, do you want to add input?
Robert_Shilston: from our perspective
... one vendor, 80% of devices in the wild
... never request the manifest
... so we use appcache for a bootstrap process
... and use it as a bootstrapping which does its own caching in storage
... the spec as it stands is ok
... it's just the implementation
jo: so you're saying you don't agree w/ tobie that it's broken
Robert_Shilston: I agree it could be improved
... but it's perfectly usable as is
... we can build an app today
... an app robustly implemented could work
<Zakim> Josh_Soref, you wanted to favor splitting it out of HTML5
Robert_Shilston: I think suggesting AppCache separate from the HTML5 spec is preferable
... it gives the most flexibility
jo: the shades are
... asking to remove it from the spec
... fixing it in the spec
... leaving as is
... - and quickly coming out with an update
... is it damaging to have what's currently in?
lbolstad: Robert_Shilston: did you mean that there isn't anything wrong with the spec
Robert_Shilston: the problem we have is an implementation (QoI) detail
lbolstad: mandating some degree of stability to HTML5
... to what extent should this document be very specific
... in addition to mandating support for a spec
darobin: if the requirements we have require that spec to be supported
... there's little reason to go into detail in the spec itself
... outside of the test suite
... the reason AppCache is listed as an issue in the document
... if you look at developer blogs, what they're saying about AppCache is different from Robert_Shilston's perspective
tobie: Facebook started using AppCache and stopped because of this issue
jo: what support is there in this group for removing AppCache from the current spec?
darobin: rather than straw poll on the variations
... I'd rather say to the html group is "here is the issue, could you do something about it?"
tobie: it's an extra feature
... which is why it's a wontfix
darobin: HTML WG is in LC
... and refuses to accept Features since that immediately voids LC
jo: if we ask them to do something that ruins their time scales
Robert_Shilston: tobie is saying Facebook doesn't use AppCache because of the additional feature they want in HTML5
... adding a feature to HTML5 would enable you to use AppCache in the way we need
tobie: it's more complicated than that
... this fix fixes some UCs, but not all of them
... we have extra challenges
... as we push new versions of our web site on a daily basis
... we have a lot of servers
... pushing a new version takes time
... on a daily basis we have 2 versions
... you can get into a state where the AppCache thinks it's correctly synchronized
... but its manifest is v49 and the code is v50
... I don't know that just solving that problem would make it work
... but I know that something like that would make it work for MS Hotmail
... it isn't implemented right now
... if you don't specify the master entry in the spec
... it's always loaded live
... MS solved it for Hotmail
... the app renders the cached index page
... the contents have to be the same
... otherwise you bust the cache
... the app checks the manifest in the background
jo: who does not feel qualified to make a contribution to this discussion?
[ 18 ]
jo: who does feel qualified to discuss this issue?
[ 7 ]
darobin: of people who feel qualified
... who wants to make a suggestion to HTML WG
... can the html spec keep the current version?
Josh_Soref: if we leave it alone, could we publish a doc explaining how to work around it, based on Rob's solution
lbolstad: are the only options a change or not
... or maybe create a test suite demoing the behavior
... as we go through specs
... some may be averse to changes
... the next, MC, easier to change
... Geolocation is unreceptive
... talking to that group isn't going to help
darobin: never has
[ laughter ]
lbolstad: do we always resolve by talking to the WG?
darobin: no
... sometimes it's a QoI item
... we write a test, and show people
... sometimes it's a relatively mature spec
... where we might want a spec change
... we won't have this discussion for each item
tobie: which is why we don't want to go meta
darobin: I think AppCache is broadly classified as broken
... do we ask for a change or live with it?
jo: even those of us who aren't qualified from a technical perspective
... may feel that we have input to this question
... yada yada yada
darobin: i.e. Everyone can/should vote
vidhya: +1
bkelley: can we live with it *and* lobby for a fix
darobin: if you ask the html WG to change it
... you're still allowed to have a hack in your app
Josh_Soref: HTML.next already has a fix for this
jo: do we as a group for substantive technological or reputational reasons
... think it'll obstruct the web
jfmoy: at TPAC in Nov
... that was the biggest problem on the mobile web
... personally I think pushing for that in HTML5 is important
... it's really important that it's fixed ASAP
darobin: who votes in favor of leaving it as is?
[ Hands ? ]
jo: who votes in favor of asking for a change?
[ 17 ]
Robert_Shilston: can we distinguish between finding AppCache not specified as is
... some people are able to use it
... others find it not fit for their purpose
vidhya: I don't quite agree with that formulation
... you can make a lot of things work
... that doesn't mean
... - This thing is not right
tobie: +1
RESOLUTION: CoreMob notes that many developers find AppCache as currently specified to be broken for their requirements or to require workarounds and requests that the HTML WG consider resolving this issue before shipping (either by fixing it in the specification, or by splitting it off to a separate specification that can be fixed standalone)
tobie: MC (DAP+WebRTC) is working on this in a TF
... it looks bad initially
<darobin> ACTION: Robin to talk to the HTML WG about fixing/splitting AppCache [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action06]
<trackbot> Created ACTION-6 - Talk to the HTML WG about fixing/splitting AppCache [on Robin Berjon - due 2012-07-02].
tobie: but the more you look at it, the better it seems to be
... it's the spec that enables camera access
... there are 2 issues
... it's a WD
... there's a bug against HTML5 spec for direct inclusion
darobin: I'd ignore the merge into html
... it might happen, but it'll happen later
Josh_Soref: +1
darobin: if it's adopted
... whatever is done will be integrated
... the reason it's a WD is we're waiting on implementer feedback
... once we get feedback
... we'll move forward
... we've started getting feedback, notably from webkit
... and it can quickly move to REC
... I don't know if lbolstad has been working on it
lbolstad: why is it a problem that it's a WD?
darobin: the concern is that it might change
fantasai: if the concern is that you need feedback, why not issue an LC?
darobin: it's an option
... would implementers be concerned with an LC
wesj: we have an accept attribute
tobie: mounir+jonas are working on Accept
darobin: I'm happy to ask DAP to issue a LC
Josh_Soref: I've a feeling that you sent it to the wrong list
... You sent it to DAP
some confusion over mailing lists and stuff
jo: What do we ask the group?
tobie: Is the fact that it's WD an issue?
darobin: Depends, in some cases it's an issue and others not
Josh_Soref: different vendor classes care differently about status of specs
jo: Proposed to close issue 3
RESOLUTION: Close issue 3 wrt media capture being a WD
<darobin> ACTION: Robin to ask DAP to push HTML Media Capture to LC [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action07]
<trackbot> Created ACTION-7 - Ask DAP to push HTML Media Capture to LC [on Robin Berjon - due 2012-07-02].
<jo> trackbot: close ISSUE-3
<trackbot> ISSUE-3 HTML Media Capture is just a Working Draft closed
tobie: HTML Media Capture introduces the 'capture' attribute
... let's developer specify what kind of capture device to present to the user
... take a picture, record something, etc.
... Currently in the spec this is mentioned as a hint
... Feel that if this is a hint, spec has not much meat, so started a thread on DAP group about this
... Suggest to change that requirement is stronger
<Zakim> Josh_Soref, you wanted to note to tobie that UAs will let users select files (i need to reply to your thread)
Josh_Soref: So supporting capture attr is fine and dandy, but for device that doesn't have such an input device, or user who wants to take an existing file, should allow file picker
... I've been worried about how things are written, that might overspecify
tobie: If this change is made to the document, no need to say anything here
RESOLUTION: Drop note about capture attribute
<darobin> close ISSUE-4
<trackbot> ISSUE-4 HTML Media Capture `capture` attribute is just a "hint" closed
jo: One thing we discussed over lunch is devices that don't fundamentally support a feature
... so have to think about that
... E.g. a TV likely doesn't have file storage or a camera, so what's conformance for that device on capture?
tobie: using SVG 1.1....
jo: I've got SVG rocks, they're uncomfortable to sit on
... is everything in SVG
... SVG requirements will point to the MANDATORY SVG elements
... are we sure we want to point to the whole thing?
darobin: having wasted 5 years on SVG
... subsetting it
... I think we want to take the whole thing
<Zakim> Josh_Soref, you wanted to warn about SVG tiny subsetting
<darobin> ISSUE: We need to have a way to express how conformance interacts with the availability of hardware
<trackbot> Created ISSUE-20 - We need to have a way to express how conformance interacts with the availability of hardware ; please complete additional details at http://www.w3.org/community/coremob/track/issues/20/edit .
<darobin> ACTION: Robin to come up with some text for ISSUE-20 [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action08]
<trackbot> Created ACTION-8 - Come up with some text for ISSUE-20 [on Robin Berjon - due 2012-07-02].
RESOLUTION: we take all of SVG 1.1. ed2
darobin: can we have a meta discussion about that?
tobie: it's describing the viewport with a weird syntax
... inside the meta element
... using meta elements for that is specified in HTML5 or HTML@HTMLWG
... with a reference to a HTML Wiki
... which references a CSS WG page
... which is marked as exploratory
... it's awkward
... everyone building for the mobile web strongly relies on it
... but the specification is very lousy
... I want to bring it up because of that problem
... I'd argue against objections to this requirement
... since we have a CSS WG liaison here
... fantasai
... do you have anything to say about this
fantasai: sorry, what?
... CSS-ADAPTATION
... what's holding back is a review of the spec
... to give us some confidence that it has been reviewed
... and is in a good state
... I think Opera and IE might have exploratory impls
... it's pretty unstable
... but if people want it to progress
darobin: I think people wants everything in that spec except CSS syntax
fantasai: I don't know how that is
... it depends on how much the spec matches implementations
darobin: css-syntax probably matches only experimental implementations
jo: it seems like
darobin: a test suite on the html bits
... there's a suite of examples by Andreas Bovens (Opera)
... which we could steal
<darobin> simple HTML pages with various viewport and media query settings
Josh_Soref: we could send review feedback
... and test resources/reports
... to help CSS have confidence to move it forward
<darobin> close ISSUE-5
<trackbot> ISSUE-5 CSS-ADAPTATION spec currently marked as exploratory closed
RESOLUTION: we don't care that CSS-ADAPTATION is marked "exploratory" as it will happen anyway
tobie: App Config is something I've been trying to push for, for a while
... it's metadata
... name, icons
... there's a different standard for everything
... each vendors has done their own
Josh_Soref: the PlayBook actually uses this for its apps
tobie: Widget is a silly name, and in a language everyone loves to hate
Josh_Soref: +1
tobie: the idea is to move WebApps to JSON, because everyone loves JSON
... it would pretty much piggy back on the existing work
... there's a lot of movement in that area
... nothing much to point to
... we could have a resolution to close
lbolstad: what's the reason this group can't point to widgets spec
tobie: this group doesn't believe it's the right solution going forward
... mostly, most vendors don't agree to implement it
... outside of Opera
... Nokia's WebKit
Josh_Soref: RIM's WebWorks implemented this
darobin: there are 40-80 implementations of widgets implementation
... it has failed to get market traction
... most major browser vendors haven't implemented and don't plan to implement
... it also has issues defining runtime
... I say this as an author of this
... specification
... there's no vendor behind it
... no implementation plans
... putting this in the spec will not make it happen
tobie: and it has a silly name
darobin: I don't think there's any point in pushing it
jo: it isn't in any sense desirable for browser vendors to support it
darobin: it'll come out of web apps "pretty much soon"
jfmoy: so you're confident that this will be ready before we're done
vidhya: I agree
RESOLUTION: the group asks the editor to update ISSUE-6 to mention that there is replacement technology on the way and that we'll point to it
[ Break for Coffee ]
<tobie> Orientation Lock Use Cases and Requirements
tobie: depending on the level/support
... it could end up a property of a config file
... it's important, but there's no spec
... it's similar
... to Full Screen
tobie: we had a discussion on the list w/ chaals
... about splitting full screen and chromeless-ness
fantasai: there are specs
tobie: the problem is that they don't do what we need
... what fits best is "floating"
... which doesn't make sense to me
... and it won't fare well w/ devs to suggest "floating" for mobile-web apps
darobin: I don't think floating was meant to do that
tobie: the outcome
... of my discussion w/ chaals
... is to have distinct things
fantasai: there's two things
... "my thing should be in"
... "is my thing in"
tobie: this is signaling a preference
darobin: we already have a way to ask for is-my
... what's missing is a way to say "i would like to run chromeless"
tobie: similar to apple's mobile-web-app-capable meta tag
fantasai: it's similar to viewport-meta
darobin: we'd like a WebApps Application Configuration to be able to express the preference
Robert_Shilston: wondering about SSL/browser padlocks
jo: Robert_Shilston, do you have a proposal?
Robert_Shilston: no
Josh_Soref: "it's a bad idea to have this discussion here, or anywhere else"
<Wonsuk> Concerning to View Orientation, there is a WD of The Screen Orientation API, http://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html
darobin: WebAppSec had this discussion and lost 3 years
... I'd rather leave that as a QoI for implementers
Josh_Soref: +1
darobin: I don't think the padlock worked in the first place
jo: it's a legitimate concern
... but it seems like we can delegate that to WebApps
... or Native Web Apps
Robert_Shilston: could we pass a REQUIREMENT to the WebApps group to ensure they consider PCI requirements
<darobin> proposed RESOLUTION: CoreMob asks WebApps to include "chromelessness" in its configuration document, and to take PCI requirements into account there
RESOLUTION: CoreMob asks WebApps to include "chromelessness" in its configuration document, and to take PCI requirements into account there
Josh_Soref: the SSL only item could be suggested to DAP for its best-practices document...
jo: do we want to take a resolution that View Orientation/Full-screen be listed as essential
darobin: not full-screen, but chromeless
<darobin> proposed RESOLUTION: both View Orientation and Chromeless are essential requirements and we would like WebApps to include them in configuration
RESOLUTION: both View Orientation and Chromeless are essential requirements and we would like WebApps to include them in configuration
<darobin> ACTION: Tobie to s/full-screen/chromeless/ [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action09]
<trackbot> Created ACTION-9 - S/full-screen/chromeless/ [on Tobie Langel - due 2012-07-02].
tobie: I don't do as much CSS as I used to
... thankfully
... slightly more rusted
... help is welcome
... we split the sections into Core, Layout, Typography, Animations and Transitions
jet: how many pages is CSS2.1?
fantasai: something like 300
... anyone developing web sites today
... assuming all of 2.1 is implemented everywhere
... excluding page breaks
... people will probably depend on most of it
jet: is it reasonable to expect printing
... which is a chunk of 2.1
... to work
... I've never seen a phone try to print
fantasai: that might be an exception
jet: could we say it's not a requirement
darobin: if your phone is able to print
... should it not support pages media?
lbolstad: there are UCs for paged media other than printing
jo: a tablet could be paged medium
Josh_Soref: I know that Mozilla has the ability to generate PDFs, and other groups are capable as well
... While printing to a dead tree is slightly more rare, printing to a persistent medium and push it off somewhere else isn't a useless requirement
... I have a number of cases where I want to do that
... E.g. a receipt generated on the fly
darobin: or printing your boarding pass
Josh_Soref: precisely that
<darobin> ACTION: Tobie to document that we have printing use cases in the UC&R document [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action10]
<trackbot> Created ACTION-10 - Document that we have printing use cases in the UC&R document [on Tobie Langel - due 2012-07-02].
<tobie> ACTION: tobie to add subsection numbers. [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action11]
<trackbot> Created ACTION-11 - Add subsection numbers. [on Tobie Langel - due 2012-07-02].
tobie: CSS3 backgrounds and borders
... if you have something to say, please speak up
fantasai: people will depend on most of those
... the exception is box-decoration-break
... which is AT-RISK
jo: objections?
[ None ]
tobie: CSS Color?
... straightforward
jo: objections?
[ None ]
tobie: CSS Values?
fantasai: Values and Units will go to CR once we finish DoC
... what would be useful to the CSS WG is
... if people took a stab at figuring out prioritization
... and addressed UCs
... this is a collection of features that can be independently in any order
... if CoreMob has feedback on implementation order
darobin: we want rem and calc()
fantasai: what about viewport units?
darobin: nice to have, but less important
<darobin> ACTION: Robin to propose priorities for CSS Values parts, get agreement from CG, send to CSS WG [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action12]
<trackbot> Created ACTION-12 - Propose priorities for CSS Values parts, get agreement from CG, send to CSS WG [on Robin Berjon - due 2012-07-02].
tobie: Image Values and Replaced Content
fantasai: again, a handful of features implementable in any order
... would be helpful to have a prioritized list to focus testing efforts, lobbying efforts
darobin: we want gradients
fantasai: yeah, I think that's on everyone's list
<darobin> ACTION: Robin to propose priorities for CSS Image Values and Replaced Content parts, get agreement from CG, send to CSS WG [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action13]
<trackbot> Created ACTION-13 - Propose priorities for CSS Image Values and Replaced Content parts, get agreement from CG, send to CSS WG [on Robin Berjon - due 2012-07-02].
tobie: Media Queries
... I think that reached REC two days ago
issue-11?
<trackbot> ISSUE-11 -- No spec effort around momentum scrolling -- raised
<trackbot> http://www.w3.org/community/coremob/track/issues/11
tobie: a core request is momentum scrolling
... probably 100 libraries that fake that
darobin: poorly
tobie: there's no spec effort at this point
fantasai: I do :)
... one would be to start a thread on www-style explaining what you want
... we don't have any open requests on the list
... so the ability to turn on momentum scrolling somehow
darobin: without scripting
fantasai: said a note
<ming> we need to check whether momentum scrolling has anything to do with patent
wesj: can you explain this
... how does this different from overflow:scroll
Robert_Shilston: on iOS, you need two fingers
... instead of 1
wesj: is that a bug?
darobin: it's the difference between panning and scrolling
wesj: in our implementation, we try to figure it out
<darobin> ACTION: Tobie to send use cases about overflow scrolling to www-style [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action14]
<trackbot> Created ACTION-14 - Send use cases about overflow scrolling to www-style [on Tobie Langel - due 2012-07-02].
tobie: as far as I'm concerned, it can be an implementation issue
Dehghan: I think hardware issues will influence what can be done
<darobin> ISSUE-11?
<trackbot> ISSUE-11 -- No spec effort around momentum scrolling -- raised
<trackbot> http://www.w3.org/community/coremob/track/issues/11
<darobin> ISSUE-11: Tobie has ACTION-14 on this
<trackbot> ISSUE-11 No spec effort around momentum scrolling notes added
<darobin> ACTION-14: this relates to ISSUE-11
<trackbot> ACTION-14 Send use cases about overflow scrolling to www-style notes added
<darobin> ISSUE-9: Robin has ACTION-10 on this
<trackbot> ISSUE-9 CSS Values is still a WD notes added
<darobin> ISSUE-10: Robin has ACTION-13 on this
<trackbot> ISSUE-10 CSS Image Values is a CR notes added
jfmoy: I have a comment on MQs
... as a developer, I'd like to be able to have a way for resources not to be downloaded
... for inactive MQs
tobie: are you saying implementations should only be downloading stuff that's in the MQ that's active?
darobin: that's a thorny issue
... imagine you have a MQ that triggers off rotation
... you now need to load stuff for landscape
... for wrong res resources
... you don't want that
... on the other hand, if your device is 800x600, know you won't need resources for sizes above that
... This is probably a quality of implementation issue
<tobie> What features are your top priorities to have in mobile browsers?
Josh_Soref: why not just ask consumers two specify resources once in a preload area
Robert_Shilston: why not ask for a way to a specify "only download if X is active"
darobin: that's what I was thinking
... but I don't think we want that to be normative
... I think we can publish a NOTE
... if you want to take an ACTION to draft something like that
... it doesn't have to be long
... maybe a two page document describing how this can work
... I can help
... circulate it among implementations
jo: I don't think it's this group's responsibility to do it
... we could suggest app producers to do things server side to suggest preloading
... from the CSS WG perspective, is "Core" the right word
... is there a preferred term?
fantasai: I don't understand what you're trying to say
tobie: I bucketed layout, typography, animation
... and had something left over
fantasai: I don't see Selectors 3
... it's a Core thing, it's done
<darobin> ACTION: Shilston to draft a non-normative document with Implementation Notes about how to load assets depending on MQs that can never become true (with help from Robin) [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action15]
<trackbot> Created ACTION-15 - Draft a non-normative document with Implementation Notes about how to load assets depending on MQs that can never become true (with help from Robin) [on Robert Shilston - due 2012-07-02].
fantasai: it's a REC and has been a while
... I think you can split this into Graphical and Processing
... values, units, selectors, MQs are processing
... color, backgrounds and borders, image values are graphical
<jo> ACTION: Tobie to split section 3.1 per fantasia's suggestion [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action16]
<trackbot> Created ACTION-16 - Split section 3.1 per fantasia's suggestion [on Tobie Langel - due 2012-07-02].
fantasai: I split things in CSS3 into graphical, typographic, layout, processing
<jo> ACTION: Tobie to add CSS-3 selectors to section 3.1 [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action17]
<trackbot> Created ACTION-17 - Add CSS-3 selectors to section 3.1 [on Tobie Langel - due 2012-07-02].
tobie: => chairs, and add Selectors, which is an oversight
<fantasai> These are the categories I had in a presentation I wrote:
<fantasai> Processing Power, Decoration, Typography & Internationalization, Layout
issue-17?
<trackbot> ISSUE-17 -- Resolution-friendly image format (for responsive images) -- raised
<trackbot> http://www.w3.org/community/coremob/track/issues/17
<fantasai> (Animations might be another category)
<darobin> ACTION-15: jfmoy also wants to participate
<trackbot> ACTION-15 Draft a non-normative document with Implementation Notes about how to load assets depending on MQs that can never become true (with help from Robin) notes added
tobie: I pasted a link on IRC from Paul Irish on Chrome
... asking for input from web developers
... asking what they were missing in mobile browsers
... one thing missing was
... a way to have pictures
... different size/resolutions selected automatically
... there was a CG that worked on it
... what came out was a proposal overloading src
fantasai: Flexbox should be in CR by end of July
... w/ 4 implementations by end of the year
tobie: "srcset"
jo: what do you want from this group?
tobie: this is something developers are requesting as something they really need
... members of this group have expressed the network info API could be a solution
... I don't think it is
Josh_Soref: it isn't <period>
tobie: it's an issue developers are facing
... given the scope of this group
Josh_Soref: tobie could write an informative note explaining what network info won't help
<darobin> ACTION: Tobie to write up an informative note about why Network Information API does not solve the responsive images issue [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action18]
<trackbot> Created ACTION-18 - Write up an informative note about why Network Information API does not solve the responsive images issue [on Tobie Langel - due 2012-07-02].
tobie: CSS Flex Box
Robert_Shilston: can we add CSS3 Regions to this?
fantasai: I don't think you want to do that.
tobie: haven't 2d and 3d transforms been merged into the same spec?
fantasai: yes, they have
... and they're moving forward
... there doesn't seem to be consensus in CSS WG that regions in the current state is what we want
... so I'm not sure it's a good idea to include it here
tobie: I'm not sure what the status of flexbox is
... my understanding is Mozilla implemented and speced a while back
... it was sent to W3
... and then redone by webkit
fantasai: the spec was sent to w3 a while back
... a couple of years ago Tab from Google and Alex from MS have been working on it
... LC will be ending next week
... comments need to be sent now
... Opera, Mozilla, WebKit, MS are all implementing
... expect Impls and CR by end of year
<jo> close ISSUE-12
<trackbot> ISSUE-12 Flexbox is a WD closed
lbolstad: since 3d transforms is part of the same spec
... is it intentional to reference it as required in the same way as 2d?
tobie: I don't have an opinion
jo: anyone have an opinion?
... would 3d be performant on the devices that interest us?
lbolstad: 3d transforms have other requirements on underlying hardware
tobie: I think 3d transforms are in there
... I think originally only 2d transforms were in there
<jo> ISSUE: Is 3D in scope under 3.2 Layout?
<trackbot> Created ISSUE-21 - Is 3D in scope under 3.2 Layout? ; please complete additional details at http://www.w3.org/community/coremob/track/issues/21/edit .
tobie: when I was writing the document
... I saw it was going to be folded in there
... so I saw an easy solution to just reference the single document
tobie: CSS Fonts, WOFF, CSS Text
... there's an issue w/ CSS Text
... darobin and I looked at it
... the only thing we needed was text-shadow
fantasai: I recall ringmark also wanted word-break
... I'm wondering why that wound up in ringmark
... maybe it's a typo for word-wrap
tobie: I don't know
<darobin> ISSUE-13?
<trackbot> ISSUE-13 -- CSS Text is in WD -- raised
<trackbot> http://www.w3.org/community/coremob/track/issues/13
fantasai: I think subsetting CSS Text is what you want to do
<darobin> ISSUE-13: do we need word-break as in the tests?
<trackbot> ISSUE-13 CSS Text is in WD notes added
Josh_Soref: Does Ringmark know why it's adding tests for something?
... Can we have an explanation of why things are added?
tobie: I think this is best asked tomorrow morning
... with mattkelly answering
<girlie_mac> word-break is needed for Asian chars, probably?
<Dong-Young> I don't think word-break is needed for Asian chars
jet: same comments as lbolstad apply for animations
<jo> ISSUE: do we consider 3D in scope under 3.4 Animations?
<trackbot> Created ISSUE-22 - Do we consider 3D in scope under 3.4 Animations? ; please complete additional details at http://www.w3.org/community/coremob/track/issues/22/edit .
Robert_Shilston: could people think about how we'd test performance on animations?
tobie: are we ok w/ ECMAScript 5.1?
tobie: are we ok w/ DOM4?
... are we ok w/ Selectors?
jet: Touch Events had a PAG
tobie: I believe the PAG concluded
darobin: those patents were /mocked/
tobie: ... as non-essential
darobin: I'd like to add a section "for each thing that is hardware dependent"
Robert_Shilston: this SHOULD is for hardware-dependence?
[ Yes ]
darobin: you don't want SHOULDs because otherwise you'd need a should for CSS in case a monochrome couldn't support 'red'
DanSun: can we expand storage to include quota management?
<darobin> ACTION: Tobie to throw in Quota API [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action19]
<trackbot> Created ACTION-19 - Throw in Quota API [on Tobie Langel - due 2012-07-02].
Josh_Soref: I believe some browser vendors don't agree with direction filewriter is going in
... There are several specs evolving in diff directions that not everyone agrees with
... What are they trying to do, do we need all of them
tobie: Should be trivial to implement on top of IndexedDB
... Would like to pose this as an area where there is no agreement in terms of what spec is going to do what and what implementers are going to do
jo: Is your suggestion that we should include, or should come back to it when it becomes clearer?
DanSun: What's the alternate solution?
jo: Let's raise an issue then on including file writer API or an alternate solution in this spec
<darobin> ACTION: Tobie to include FileWriter or an alternative to the spec [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action20]
<trackbot> Created ACTION-20 - Include FileWriter or an alternative to the spec [on Tobie Langel - due 2012-07-02].
<darobin> ISSUE: is there an alternative to FileWriter? FileSaver? Something else?
<trackbot> Created ISSUE-23 - Is there an alternative to FileWriter? FileSaver? Something else? ; please complete additional details at http://www.w3.org/community/coremob/track/issues/23/edit .
Josh_Soref: There are at least 3 APIs running around
tobie: Any other issues with this section?
... Moving to 4.4 Networking
... i.e. XHR
... Opened an issue because there used to be 2 specs, L1 and L2. They're folded together in the editor's draft
... not reflected in /TR yet
... it's an editing issue
... Question about web sockets
... Not that many use cases for it that have been brought up
... A lot of .. among implementations due to protocol problem
... I still stand that it's great to do demos at this point, but I don't think there's a compelling use case for mobile apps today
... However if every implementation has it, and agreement on the spec, could add it. Don't have a strong opinion
wesj: Seemed useful for mobile gaming and multiplayer apps, chat, etc.
<fantasai> ACTION: Wesley Jonston to do something useful [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action21]
<trackbot> Created ACTION-21 - Jonston to do something useful [on Wesley Johnston - due 2012-07-02].
<darobin> ACTION: Wesley to provide use cases for WebSockets [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action22]
<trackbot> Created ACTION-22 - Provide use cases for WebSockets [on Wesley Johnston - due 2012-07-02].
vidhya: Notifications used for activity streams etc., I've written code to do that. Haven't done it with mobile, but you can.
... Whatever you say here, it will be widely supported. Will be de facto capability
tobie: 2s background on why this is not in the spec
... We were targeting existing browsers, and those don't support websockets
... We picked up features not supported yet
... Some things that are de facto standards didn't make it in
... If there are ubiquitous in near future, then yes should be in the spec
vidhya: It's de facto now
... Think it's much more in gaming. It's only one use case.
jo: interest of time...
tobie: web messaging API and web workers
... I have an issue with webworker mostly because of shared webworkers
... I'm not sure.. I thought there were some issues with implementing shared workers ~ security
... Not sure there are plans to implement them or not
... Feedback on that would be useful
jo: Noted that Tobie would like feedback on that. Anything else to say on that?
... Not sure what's the difference between networking and network here, and can we include online state and network information?
darobin: Network info API? If people want it...
jo: Seems useless to me
tobie: It was in L1 before, but removed from spec
... use cases, other than an app that tells you what your network status is, better solved by other things
darobin: doesn't even tell you [...]
tobie: there was a Mozilla proposal and another, confusing on which would do what
... if there was consensus on what to ship, will add. But if not, want use cases
jo: I asked for use cases and nobody came up with any
Josh_Soref: You can't give something particularly useful on average
... The quality of service I have to one service and to another service might be totally different.
... We talk in the US about Net Neutrality
... it's relevant to this
... If I'm on a network that's fast, doesn't mean my connection to a particular service is fast.
... The only way to get a relevant answer is timing your own traffic
DanSun: From ? perspective, in certain perspectives, want to pick network you want traffic to go out on
Josh_Soref: This API doesn't help at all
darobin: you'd want something at the sysapps level
... currently DAP has dropped what kind of network you're on
... dropped pretty much everything except notion of bandwidth, which is useless
... and also notion of metered which is also useless
... because roaming might be expensive in e.g. Europe, but cheap in Africa
... Wouldn't include it here, because don't know where it's going
tobie: only use case I've heard is switching to 3G to get location info for payments
Josh_Soref: That's the use case??!
jfmoy: Not only use case, also about ...
DanSun: What about online state?
darobin: it's in HTML5
Robert_Shilston: That should be deprecated. We should advocate that that be deprecated.
<darobin> ACTION: Shilston to draft a proposal to drop online events from HTML5 [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action23]
<trackbot> Created ACTION-23 - Draft a proposal to drop online events from HTML5 [on Robert Shilston - due 2012-07-02].
Robert_Shilston: HTTP1.1 has proxy-switching features
... that could be used for some of these use cases
<darobin> ACTION: Jean-Francois to send a note with the actual real use cases for Network Information (with help from Dan Sun) [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action24]
<trackbot> Created ACTION-24 - Send a note with the actual real use cases for Network Information (with help from Dan Sun) [on Jean-Francois Moy - due 2012-07-02].
tobie: Sensors should be pretty straightforward.
darobin: There are no two browsers that will return the same info for DeviceOrientation, and none of them matches the spec
DanSun: Can we include the proximity sensor?
Josh_Soref: There's a spec for that in DAP
tobie: what are vendors going to do about that?
...
darobin: it's about not pressing buttons when on a call
tobie: not valid use cases
<darobin> ISSUE: Should we require Proximity Events?
<trackbot> Created ISSUE-24 - Should we require Proximity Events? ; please complete additional details at http://www.w3.org/community/coremob/track/issues/24/edit .
Josh_Soref: I question whether either use cases was used for app as opposed to runtime/device
tobie: 2 items: canvas2d API and timing animations API
... quality of implementation issues there
darobin: I would rather not rat hole in the note, deal as part of testing
DanSun: web audio APIs?
darobin: I don't think they have anything that's anywhere near stable enough
Josh_Soref: does any implementer plan to implement it?
DanSun: 2 levels - 1 is prioritizing features for the browsers, another is to prioritize features for w3c to make a spec
darobin: The web audio WG has as its one and only priority to do this
... reason not more finalized is because it's actually a hard problem. They've been working reasonably fast, but will take 1-2 years before what they have is anywhere near ready
... gathering a lot of implementation experience, moving forward, but not mature enough
... Everything in that spec will change over the next few months and years
DanSun: Contacts and calendar?
tobie: new proposal a day and a half ago, didn't have time to look into it
darobin: Just to be clear, in this case we would not include support for calendar or ?, because all UA needs to do is support WebIntents
... question is, do we want to include that in L1
tobie: a lot of questions around that spec
... Mozilla shipped proposal just 1.5 weeks ago on web activities
DanSun: ... still think it's super early to include it in there and hope to have implementations within the timeframe of the spec
fantasai: What is the timeframe for the spec?
tobie: Q4
fantasai: And implementing the spec?
tobie: Q4
<darobin> ISSUE: Should Level 1 include Web Intents?
<trackbot> Created ISSUE-25 - Should Level 1 include Web Intents? ; please complete additional details at http://www.w3.org/community/coremob/track/issues/25/edit .
fantasai: Seems like you might want to revisit some of these, especially ones that you're including that don't have a spec
...
darobin: For notification vibrations, you don't want vibration API -- that's for games. For notifications you want the notification API
<darobin> ISSUE-25: use cases include contacts and calendar for instance
<trackbot> ISSUE-25 Should Level 1 include Web Intents? notes added
darobin: that being said, vibration API might be something to consider
tobie: consider implementation state
darobin: in webkit and gecko already, don't know about Opera
tobie: ok, let's open an issue and try to get developer feedback
<darobin> ISSUE: Should we include the Vibration API?
<trackbot> Created ISSUE-26 - Should we include the Vibration API? ; please complete additional details at http://www.w3.org/community/coremob/track/issues/26/edit .
<darobin> ISSUE-26: we should ask developers
<trackbot> ISSUE-26 Should we include the Vibration API? notes added
<darobin> ISSUE: Should Level 1 include SSE?
<trackbot> Created ISSUE-27 - Should Level 1 include SSE? ; please complete additional details at http://www.w3.org/community/coremob/track/issues/27/edit .
tobie: one thing not in there, don't remember why, is event source
darobin to track it
tobie: No comments on this section? Move on to network?
... this is the last section
... if anyone can help me find the OMA mmsto spec, that'd be helpful
jo: I think we need to look at HTTP1.1 in more granularity
Josh_Soref: data is a problem
... there's a number of browsers get things wrong with it
... need testcases
... but can't assume it'll be fixed quickly
jo: HTTP1.1 tests will be hard to write
darobin: but that won't be solved by referencing HTTP1.0
Josh_Soref: reference bis
... and SPDY / HTTP 2
jo: Do we want to mandate the whole of 1.1?
Josh_Soref: I am concerned about testing difficulty of writing tests
tobie: I think that's not a reason to include/exclude a thing that devs need
... whether it's hard to test is orthogonal to whether it's required to build a certain app
jo: conformance is measured by conformance test suite of referenced spec
... There isn't one here. And a lot of HTTP that isn't necessary here
... I don't want to spend any more of my life on that rfc...
<darobin> ACTION: Jo to write something about conforming to HTTP/1.1 [recorded in http://www.w3.org/2012/06/25-coremob-minutes.html#action25]
<trackbot> Created ACTION-25 - Write something about conforming to HTTP/1.1 [on Jo Rabin - due 2012-07-03].
<Dong-Young> this seems to be mmsto spec: http://openmobilealliance.org/technical/release_program/docs/uri_schemes/v1_0-20080626-a/oma-ts-uri_schemes-v1_0-20080626-a.pdf
<darobin> ISSUE: Should the HTTP11 reference go to bis?
<trackbot> Created ISSUE-28 - Should the HTTP11 reference go to bis? ; please complete additional details at http://www.w3.org/community/coremob/track/issues/28/edit .
jo: Let's thank authors of this document for preparing it so that we could review it
RESOLUTION: thanks for the authors
jo: would like to also thank our wonderful scribes for today and look forward to their scribing for tomorrow
... ditto hosts
RESOLUTION: thanks to our wonderful scribes, we look forward to more of their scribing tomorrow
RESOLUTION: many thanks for Facebook for excellent hosting
[ Meeting closed. ]