WebApps F2F Meeting -- 30 Oct 2012

<ArtB> ScribeNick: ArtB

<scribe> Scribe: Josh_Soref

Date: 30 October 2012

<Lachy> scribenick: Lachy

<ArtB> ScribeNick: Lachy

chaals: we'll begin, first, figure out what's left on the agenda

… Process stuff to continue with

Agenda Bashing

… real discussions: Offline app cache, widget packaging, proposals, etc.

… IME, Selectors API 2. Short, do together in a session

… Testing.

… We have a session on web intents at 16:45

IDL2. Do people want to get into technial discussion?

… Maybe/

… It's possible that next year's TPAC will be in Asia.

We are proposing to have an F2F in Silicon Valley for HTML and WebApps

We did it in May this year. Think it was worth doing

… Anyone object?

… Assuming people want to turn up. The current idea is the week of April 22. HTML gets a couple of days, webapps gets a couple of days.

… Who would be likely to turn up in CA in April? [Dozen or so hands raised]

…One of the things worth thinking about is that we have virtually no joint meetings at this F2F. TPAC is where we can invite other groups to talk to us.

… We should think about the groups who we should be talking to.

… Templates. Are we going to make any progress today? Worth continuing?

… No. Drop it off the agenda.

… Paul suggested yesterday that a zip archive API would be useful. There have been proposals before.

… It's probably not in our current charter.

… The rule is that we have to change the charter to work on new work. Complicated process.

… Do we think it's worth doing?

sicking: We just shipped an API for this.

… We think it would be useful.

<bryan> +1 to considering zip archive API

<sgodard> +1 for ZIP archive API

tobie: When we talked about App cache in London, there was a lot of use cases that could be fulfilled by the archive API.

Chaals: does anyone object?

maciej: Can someone give a brief pitch about why it's useful for the platform?

<adrianba> s/XXX/tobie/

<ArtB> Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=772434

sicking: The requests have come from the gaming community. They make a single request to download resources for a game. Want to be able to extract specific files as needed from the package.

… Reduce number of requests, getting compression from zip.

maciej: has anyone done any testing to see if zip performance is better than other approaches?

sicking: no.

<bryan> the use cases I am thinking of are similar, e.g. generically the ability to download content as a package and store locally for use in the app

… I don't think it's just performance. Convenient for deployment to have a single file.

chaals: Chair hat off. One of our metrics is developer convenience

… People are used to working with zip archives, have tools for it.

… Could argue that HTTP pipelining is an alternative approach, but working with zip is something people are used to doing and won't be difficult.

sicking: We did do an API and got feedback saying it wasn't the right approach. There are many ways to do it, difficult to get right.

maciej: For the use cases, it seems useful to download a zip and then reference its resources by URL.

sicking. It would be useful to have a zip protocol handler.

… It could possibly work with a URL, like jar handler.

maciej: Is there a list of these use cases?

sicking: I can get them.

chaals: We need to go through formal call for concensus.

… The decisions in this meeting aren't binding; call for concensus on mailing list.

… The next step will be to send a proposal to the list, make a formal work item, have call for concensus on the list.

… We can get into the technical details then.

<scribe> ACTION: Chaals: Get the ZIP archive proposal on the table as a formal work item. [recorded in http://www.w3.org/2012/10/30-webapps-minutes.html#action01]

<trackbot> Created ACTION-673 - Get the ZIP archive proposal on the table as a formal work item. [on Charles McCathie Nevile - due 2012-11-06].

maciej: I want to the use cases on the table.

chaals: We will. That comes with the proposal. Discussion about it will take place over several weeks.

… Testing. We had this as an agenda topic.

… We could spend a lot of time looking in details, or we could spend the extra time actually making tests.

Testing

Chaals: We need a test facilitator.

… It's useful to have a person overseeing the creation of the testsuite. Not necessarily writes all the tests themselves.

… I have a list of specs that currently don't have a test facilitator.

… I'm going to read them out, ask for volunteers.

Art: People can think about it and get back to chaals or I.

Chaals: The list of things we want is someone to co-ordinate things for DOM Parsing and Serialisation

… All of the file specs.

… XHR

… Full screen API

… Gamepad

… Templates

… Progress events

… This is a pretty small thing, but kind of annoying because you need another spec to test them in.

… Push API.

… Pointer API

… Server sent events.

… Screen orientation

… Streams

… App Manifest

jgraham, The point of the test facilitator is not that you have to write the tests. You take responsibility for making sure there is a test suite.

julian: I volunteer for XHR

sgodard: I volunteer for App Manifest

chaals: I have a proposal for something that falls into the App Cache area. Not sure if this is the right group. Called Prefetch.

… It allows a site that uses a lot of resources again and again, give a manifest of files to prefetch.

… Not sure if I'm going to propose it as a work item.

Introductions

Norbert Lindenberg working on ECMAScript Internationalization API under contract for Mozilla.

[inaudible]

XXX, Telefonica, used to be AC Rep. Push API

<ArtB> s/XXX, YYY/Norbert Linbenberg/

IME

Kenji Baheux I would like to talk about IME API.

… Today I would like to show use cases, explain what IME is.

… It would help if I could present something on the screen.

Chaals: We had a discussion about IME. Someone started making a sales pitch about why it's a great thing. Don't give us the sales pitch, give us the usecases.

Kenji Baheux: Starting with the use cases

… The first one is on search websites, there are suggestions for what the user is currently typing.

… Bad overlap from the IME suggestions and the search suggestions.

… A lot of complaints from Chinese and Japanese users.

… Suggestions shown based on Kanji.

… Overlapping suggesitons shown on screen.

… Try to find a better way to combine search suggestions and IME suggestions.

… Second category. Games.

… Two use cases. 1. On Windows, if you play a FPS game, and you press one of the IME keys, it creates problems. Need to avoid IME menu interferring with game.

… 2. Entering a name in a game, native UI for IME suggestion doesn't fit with game design UI.

… Third; Presentation software. Editing text in fields using IME interfers with live preview.

… Sample API shown on screen.

chaals: There is a discussion in HTML about Input Mode.

… When you have an input for text or phone numbers, right now, it's kind of painful. Being able to give a hint about expected input is useful.

… e.g. If I have my keyboard set to Russion, username in russion, password in english. Is that usecase related?

Kenji Baheux: Somewhat related.

chaals: What's the implementation status?

Kenji Baheux: No implementation.

Chaals: Would anyone like to work on it?

adrianba, I recognise the use cases. I wasn't completely clear on the scope of the proposal. Can you clarify for me which use cases are solving with the current spec?

KenjiBX: Currently in scope: Composition stream.

… Also get the different boundaries.

… Can also render your own composition text.

<odinho_> The @inputmode attribute in HTML

… You can let the browser know what's happening so it can avoid the system IME or adapt the site design and behaviour to the IME.

… Custom IME design for games case not covered by the spec.

… Presentation case is covered.

adrianba, You mentioned the JavaScript API for disabling the IME. For a long time in IE, we've had IME mode CSS mechanism for disabling IME.

<chaals> [Sorry Dmitry, but it was when you started getting impassioned that it started turning into a sales pitch… I thought you had explained your technical perspective well enough to let people think about the ideas...]

… It's in one of the draft specs. Have you considered that and is it similar?

KenjiBX, There is a function for that to hit at that. Similar to CSS, but in JS.

adrianba, maybe we could consider if we need both.

adrianba: Microsoft is interested in improving this general area, but highest priority is the the use case around positioning.

… Seems like it's not currently covered by the spec.

… If we add that, it would be substantial scope change.

… that's the place where we'd most like to work on this. What are your priorities?

KenjiBX: I'm interested in that. Thought about it.

mounir: First use case is like a UA implementation details.

… The UA could just show it correctly and not have the two UIs.

… I was wondering for the styling use case. Have you considered CSS?

KenjiBX: Yes.

[could not hear answer properly]

mounir: Why don't you think it's a UA implementation detail?

KenjiBX: I think it's better to let the web app decide on the best UX for this case.

maciej: I think there might be a misunderstanding. The candidate window is provided by the OS, the suggestions are provided by the web app.

… Need to tell the IME system where to put the IME popup.

… I agree with Microsoft about what the most important use cases are. Avoiding candidate window and overlap.

… The other cases seem periferal.

… It seems to be designed solely for the purpose of implementing their own input methods. I don't think that is a good idea. JS implementations are not likely to work across devices.

<MikeSmith> pbakaus, we're talking about IME here in webapps

KenjiBX: The current draft says the UA can get the current position of the candidate window. [???]

chaals: chair hat off: In many ways I agree that JS is a terrible way to handle user input in general. Handling keyboard input breaks accessibility, etc.

… Except that we use it because the Operating Systems don't make things easy.

… In Yandex Translate, we provide an input method for converging latin characters into Russian, or vice versa.

… So I'm nervous about focussing on the use case of a site being able to build its own IME.

… The overlapping of the suggestion and IME is a bigger problem.

… Agree with mjs.

… A lot of assisted input systems fake being a keybaord. Concerned about the interaction with this API.

… Authors make assumptions about the user's keyboard that are not true.

… This is an area where I would expect comments about robustness.

… This is a warning of things I've seen go wrong

mjs: For touch screen devices that have touch screen keyboards, if you've written a custom IME that works for keyboards, it's most likely going to break on the iPad virtual keyboard.

… I think using JS for this is intrinsicly not cross platform.

chaals: True, but my TV doesn't have a russion keyboard option.

Alex: I think it's interesting that there is a battle for control between the OS and JavaScript.

chaals: More technical comments?
... Break. No coffee for 30 minutes. 15 minute break. Then short session on selectors API 2.

<jcdufourd_> nick jcdufourd

Selectors API Level 2

<mjs> ScribeNick: mjs

LH: I'll start by giving an overview
... functionality of the find and matches methods is pretty stable
... test suite has many tests
... hopefully we can get implementations soon
... I'm hoping we can settle the naming issue for the methods find and findAll
... Issue for parsing comments in selectors still needs to be addressed - hopefully CSS WG can address it in Selectors 4
... there was a brief discussion with Anne about merging Selectors API v2 with DOM4
... and possibly introducing extra functionality
... I wanted to discuss the return type for the findAll method
... NodeList, Array, or some new object that provides a combination of functionality
... Use cases:
... (1) get a collection of elements as a result of the query
... (2) run methods that apply collectively to all the elements
... right now you have to iterate individually
... (3) filter the list or run additional queries on the list
... (4) do method chaining, just like in jQuery
... possible solutions:
... (a) normal JavaScript array - would give normal Array functionality but could not add selectors-specific methods (e.g. having a new .findAll() make a union)
... (b) return a NodeList; but no Array-like functionality
... (c ) define a custom object which imports functionality from Array and NodeList, but adding Selectors-specific stuff

AR: I'm from ECMA TC39; hard to add Array functionality due to NodeList because of closures
... I'd prefer to define an Array subtype or to recast NodeList as an Array
... there's a preference to make these things Arrays from the pov of developers and JavaScript

CMN: I'd like to address names
... everyone likes find(), findAll(), right?

(no objections heard)

CMN: that's straw consensus and it's a non-technical issue

LH: that about covers it

CMN: as an implementation question, what about compatibility?

LH: the problem with converting NodeList to an Array is that NodeLists are generally live in many uses so you can't import mutable methods from Array

AR: I actually don't think that's a big problem
... Mozilla, first, the liveness is a feature of someone else holding an API
... this is not something that is foreign
... but for the question of adding new invariants, we can model that with proxies

CMN: any other comments, questions?

LH: matches() is implemented with a prefix in all browsers
... no one implements scope or reference nodes yet

CMN: any other implementor notes?

TL: just an observation that the extra functionality for chaining seems like a much more generic feature - maybe should not be specific to Selectors API, maybe should be in DOM 4

CMN: back to agenda
... working backwards, at 16:45 we have Web Intents - can't change that time, dial-in
... session on testing, James has agreed to lead
... the goal is to sit in the room and write tests - hands-on session
... will end at 16:45 and will begin when we finish everything else
... after lunch, short session on the Web Platform effort
... those guys do documentation, that's useful
... closer to the concerns of this group, a session on web driver
... test harness for browsers to avoid manual tests
... at 11:15 (which means 11:30) we are going to have a session on appcache, offline cache, manifest formats, etc
... at 10:30, coffee break
... it's 10:30 now, coffee break

<krisk> jgraham - let me know when you pushed the opera websocket tests and I'll help convert so of them

<ArtB> ScribeNick: ArtB

AppCache, Offline, Packaged WebApps, App Manifest, ...

CMN: we have a couple of specs in our charter

… e.g. Widgets

… and application manifest

<timeless> scribe: Josh

<timeless> scribenick: timeless

chaals: in html, there's AppCache
... loved by everybody
... because it allows you to do the same thing
... with wonderful functionality
... so wonderful that darobin will describe it
... mozilla has a json based manifest
... i tossed into an email the prefetch stuff we're looking at

<ArtB> ED for App manifest is: http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html

chaals: i don't know if this group is interested in this stuff
... we are
... because it gives big improvement in load times
... this is a free form discussion
... where are we at
... what are the pieces of this stuff and who are using it
... people are building widget systems
... can we unify it
... should it be our problem, html's problem, someone else's problem
... a lot of the people who can give input are in this room-group
... i'd like to start this discussion with what is html's appcache doing

darobin: AppCache - a small group of people have been meeting in corners to take it to the WG
... something will start happening "very soon"
... as soon as html enters CR
... so in a few weeks
... i'd be happy for someone else to take it

sicking: mozilla organized one of these dark corners
... we're very interested in making appcache work

<bryan> is there a doc ready to be shared from the dark corners, soon?

sicking: from our point of view -- it doesn't
... from our point of view, how much back compat we keep is up for discussion
... we haven't had anyone to put together a proposal
... and we haven't found a good venue
... i'm reluctant to have someone submit a proposal to the HTML ML
... i'd prefer to have a separate ML
... a separate ML is required

<Zakim> chaals, you wanted to try and squash the naming issue

sicking: i'd prefer to do it somewhere else
... either in this WG
... i believe it's still in our charter
... we can transfer from HTML to this WG
... or do it in a CG

<Zakim> mjs, you wanted to talk about venue

mjs: w/ my HTML WG cochair hat
... i don't have a strong opinion about this WG or that WG
... there's definitely precedence for WebApps taking up when it's more non-markup level
... there's also precedence for adding apis on, such as data-cache api
... i don't think HTML WG would object
... i think HTML WG would support extensions to HTML
... w/ my vendor hat on, i'm ok w/ either group
... i'm also happy to see the proposal in super sketchy form
... i've heard of the proposal
... but without details to know if we, Yandex, would be interested

darobin: i had 2 questions for sicking / anyone else
... you mentioned potential backwards compat breaking changes
... i'm not sure it's a good/bad idea
... i'm wondering how serious you are about that

sicking: we don't have a proposal
... we haven't figured out a cohesive idea

<adrianba> here are some of the ideas -> http://lists.w3.org/Archives/Public/public-html/2012Sep/0060.html

sicking: the most tangible thing i can say is
... we want to get rid of this whole master entry idea
... add more JS API to it
... so you can add/remove to-from the AppCache
... and create an appcache for an origin
... re:back-compat because we don't have anything more tangible, it can go either way
... i think we can do most things w/o breaking
... but if getting rid of master entries breaks it, then...

darobin: re:venue
... i can understand why you'd be reluctant to work w/ html
... we're trying to make this WG a friendly venue
... the way it's broken now is shameful
... if whomever @mozilla would like to sit down with me,

<tobie> https://etherpad.mozilla.org/appcache-london, https://etherpad.mozilla.org/appcache

darobin: i'm happy to share it with the group

tobie: there's output from both meetings which i shared

slightlyoff: we're interested in all of this
... we have similar thinking
... about optionality of master
... we want to make camping of a domain more controllable

pbakaus: we have such a mess right now
... i think it's important to have a workshop w/ industry leaders
... i count us as one of them, we really want this

<Zakim> mjs, you wanted to talk about compatibility

mjs: i'd like to make a plea for compat
... it doesn't have to be fully back-compat w/ syntax and features
... maybe there's versioning
... we do have content that uses the current format
... it's more common on mobile
... mobile apps seem to tend to try half backed tech
... i see the great importance of providing a better model
... it's clear from web-dev feedback that current app cache doesn't meet their needs and isn't a good design
... i'm interested in seeing ideas which improve it
... even breaking the model

adrianba: agree w/ mjs
... and about compat
... it's inevitable that we'll have to make breaking changes
... we're keen on making sure that existing content keeps working
... ms is interested in working on this as well
... i pasted the link ms sent to html-wg a little while ago
... in IE10, we supported an additional mechanism that extends the manifest
... we provided it in the html5 bug database
... which allows you to change the way the manifest works
... this was essential to making Exchange offline mail work

sicking: not breaking existing content seems like a requirement
... arranging a workshop or something
... i feel like we should get to the point of having concrete proposals to discuss
... they always reached a halt when it comes to coming up w/ proposals for fixing it
... it takes too much time to come up w/ proposals

chaals: 12 months ago, there was a workshop on exactly this topic
... they concluded exactly what we just said

timeless: [Scribe: why did i have to minute this whole thing if that workshop did this already?]

chaals: there's position papers...
... i keep on hearing this, yeah we want to do these things
... it seems we're really in a position where writing a proposal is less work than spending two days in a workshop
... we could make the workshop unpleasant to encourage writing a proposal
... perhaps the venue question is part of the issue
... talking about it here, it's in scope for this WG
... we really do have on our charter the ability to do this
... you can bring your proposal here
... i'd like to do something
... AppCache is one part of this
... metadata stuff around an app
... widget configuration/packaging
... or mozilla's proposal
... which was just sat on for a few months
... a JSON based more or less equivalent functionality
... is in this WG as a listed item
... i'd like to understand if it's worth working on this stuff
... as a vendor, yandex has stuff which does apps based on a JSON package
... as our app is built from Chromium, it uses the same JSON as Chrome
... which is similar to Mozilla
... there's the dark corner of widget spec backers
... mutterings is
... given there's roundtripping between JSON and XML
... unifying that isn't really difficult
... wondering if people from those corners are interested in that as a workitem
... i don't think it's scope creep
... it's a fairly straightforward is a simple conversion of values
... just as mozilla-chrome is straightforward
... Q: what are the workitems we should take up
... do we think doing it here is the right place

<bryan> yes, it should be done, and here

ArtB: art barstow, nokia
... about venue
... i'm mostly indifferent about here, HTMLWG or a CG
... (which was already created)
... but in considering venue, we need producers/consumers of appcache to be comfortable to come in and give feedback
... i think a CG may be more comfortable for them
... hashing out multiple drafts there may be easier before a WG

paulc: interested in knowing if anyone is in this WG
... that isn't in HTML WG
... wants to do this work here
... HTML WG is about to be rechartered
... we'd like this to be clarified before we're rechartered
... if you don't clarify today
... before we meet Thu/Fri
... an AC question
... if we proposed Yes/No for doing AppCache in our charter
... will there be objections from Member companies in this room
... that aren't in our group?

sicking: i can't speak officially for mozilla
... i'm not sure we'd object for it to be in charter
... i'd personally prefer WebApps WG or a CG
... i feel so far
... we've had an easier time talking about these things on webapps ML
... i feel like this isn't super tied into HTML as a Markup Language
... scope wise, it makes as much sense here as HTML
... i don't think we'd object to it being in HTML WG

chaals: Yandex, first preference is doing it in Web Apps WG
... second preference is the Native WebApps CG
... which is dormant
... third preference is HTML
... if it doesn't work out like that, we're not going to object
... we have a strong preference, but won't spend our life arguing about it

adrianba: Adrian, Microsoft
... i proposed to continue this discussion in the HTML WG
... because it's already in the spec
... MS has no objection for doing it here
... we had the data-cache discussion
... we prefer one WG or the other
... [i.e. not a CG]

chaals: how many people feel we shouldn't do this work anywhere

mjs: stop trolling the WG

chaals: how many people couldn't care less where the work takes place
... how many people have a preference for where the work takes place?
... i'll pass the mic around, and ask you to state your preference

pbakaus: Zynga, web apps because i believe most of the apis should be in js

hsivonen: XXX, webapps, good track record of WG

adrianba: MS, i gave my preference, but guess it'll be in WebApps

darobin: HTML, because i think we'll fix that group, and it'll rock

[ laughter ]

SimonPieters: Opera, WebApps because it's a functional group and HTML currently isn't

sicking: first preference is "Fix AppCache CG"
... second preference is WebApps WG

smaug: WebApps, what hsivonen said

rafaelw: Google, WebApps it makes sense here

chaals: this is the side that doesn't care

odinho_: Opera, WebApps

<bryan> webapps, because we see this as related to app packaging and synergistic with the webapps experience with widgets, and other APIs that webapps may consider (e.g. offline webapp support in general)

bryan: AT&T, WebApps, we see this related to webapp packaging, synergistic w/ widgets
... and offline in general

chaals: ignoring darobin (good idea)
... there's a strong preference here to do it here
... for the people who care
... if we said, hey paulc, we think we'll do it here
... tell HTML WG that WebApps wants to do it here, and themselves
... will we have a turf war?

paulc: i don't know the answer, we'll find out on thursday

chaals: message to HTML WG is "we want it here, if that's ok with you guys"

paulc: chairs should take an action to send a message to the html wg

<npdoty> wasn't mjs's comment earlier that he didn't expect that to be a particular problem?

paulc: the question applies to html wg too
... is there anyone in html and not in webapps who'd object to it not being in html
... i took the silence as "no one objected to it being in html"

sicking: i'll object to do it in the html wg on the main ML

<ArtB> ACTION: barstow respond to HTMLWG's question re WebApps has a strong preference to work on AppCache in WebApps WG [recorded in http://www.w3.org/2012/10/30-webapps-minutes.html#action02]

<trackbot> Created ACTION-674 - Respond to HTMLWG's question re WebApps has a strong preference to work on AppCache in WebApps WG [on Arthur Barstow - due 2012-11-06].

sicking: but wouldn't object to it being its own ML

<mjs> npdoty, I don't expect it to be a problem but paul is correct that there could be people who would have strong feelings about doing it in html wg that have not spoken up yet

chaals: we'll send an email to HTML we'd like to do it here
... what are issues other than lack of concrete proposals

<npdoty> mjs, understood, thanks for clarifying

chaals: appcache
... without anyone speaking up, we don't care

pbakaus: for the record, we, Zynga, think it's worth doing

chaals: we could entertain the question
... within JSON based metadata

<bryan> AT&T thinks its worthwhile to evolve and converge the widget specs with whatever comes out of the appcache evolution

chaals: we'd like to see JSON convergence

sicking: when we submitted, we didn't hear any response
... so i'm surprised to hear
... and happy to hear, if that's no longer the case

<bryan> the lack of response may be simply a bandwidth issue

sicking: we were planning on submitting it to sysapps
... along with a runtime
... i think runtime+packaging go together
... they're co-dependent
... i'm wondering if group is working on packaging format + runtime
... feedback from google people on mozilla's spec
... was we don't understand the security implications
... it fits strangely in my mind with "but we're shipping an app store solution based on it"
... what is it with this
... are you just not interested in convergence

slightlyoff: our format creates a separate origin
... to the extent that they're independent, we don't have the same problems we'd have as when we join it with the rest of the web

sicking: google's answer was "it doesn't make sense to define a packaging format before you have a runtime"
... the packaging format describes what you put into the runtime
... my question is "should we do that work here"
... otherwise, it's in the sysapps charter
... i'm fine with it in either
... but discussions will happy in sysapps regardless

chaals: i here myself and sicking saying we'd like convergence on JSON

<ArtB> here is a related email from Adam Barth http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1017.html re Manifest and SysApps WG

chaals: pbakaus saying they'd like to see convergence for XML w/ JSON (for packaging)
... onus would be on us to produce a convincing proposal

darobin: or just do the work

chaals: right
... so we might end up in sysapps w/ manifest
... which brings us back to appcache

timeless: i will protest if i'm minuting this discussion next year

chaals: appcache
... we note the lack of concrete proposals

pbakaus: an implementation detail
... i'd like to make sure it works w/ file system apis we discussed yesterday
... our main goal is to limit the number of requests we make
... it needs to be highly dynamic

[ silence ]

shepazu: is the queue empty because people don't think app cache is needed

sicking: problem is we don't have any proposals to discuss

odinho_: what sicking said [+1]

chaals: my impression too

<slightlyoff> what sicking said

<bryan> we havent seen into the dark corners yet, once there are proposals it will be good to consider and discuss them.

<slightlyoff> (I've been working on something for months and it's nearly out, but not there yet)

pbakaus: maybe we can get a wishlist about what we want this to cover

<odinho_> bryan: The stuff on the mozilla etherpad exist.

<odinho_> [2] https://etherpad.mozilla.org/appcache

<odinho_> [3] http://www.w3.org/2011/web-apps-ws/

chaals: we could, i've sat through two of those already
... any proposal that would be accepted would have to point to a wishlist/requirements reference

<odinho_> Appcache London

<ArtB> ScribeNick: ArtB

<odinho_> AppCache second meeting

Josh: we need some requirements work first

… before we start on the spec

<timeless> chaals: +1 from a WG member

<odinho_> s,[2] https://etherpad.mozilla.org/appcache,,

<odinho_> s,[3] http://www.w3.org/2011/web-apps-ws/,,

<timeless> s/work first/work - published - first/

<scribe> ScribeNick: timeless

<odinho_> s|s,[3] http://www.w3.org/2011/web-apps-ws/||

<odinho_> s|s,[2] https://etherpad.mozilla.org/appcache,,||

chaals: add an XHR update after lunch
... i won't be here after lunch

ArtB: displaying tentative agenda this afternoon
... come back @1:30pm
... shepazu will talk about web platform docs
... i was hoping Simon Stuart would talk about WebDriver

<odinho_> s|[3] http://www.w3.org/2011/web-apps-ws/||

ArtB: jgraham to talk about testing

s/Stuart/Stewart/

<odinho_> s|[3] http://www.w3.org/2011/web-apps-ws/||

jgraham: i guess, what we do depends on what people are interested in
... good time to gauge that
... how many are interested in hearing about testing at all?

[ nearly half ]

shepazu: who isn't interested in testing?

chaals: if you don't want to talk about testing, you can skip most of the afternoon

jgraham: sounds like TestTheWebForward w/ liam
... introduction on how to write tests
... get people writing tests

<odinho_> s|w/ liam|Lyon|

jgraham: maybe an opportunity to have a discussion amongst the people who have to run the test

ArtB: thanks jgraham

<odinho_> s|[2] https://etherpad.mozilla.org/appcache||

<ArtB> ScribeNick: ArtB

Web Platform Docs

Doug's presentation: http://www.w3.org/Talks/2012/10-lea-webplatform/wpd-talk/#intro

http://www.webplatform.org/

Testing (James Graham)

<scribe> ScribeNick: lachy

Testing the Web Backwards, Lyon

jgraham: I will talk for up to 30 mintues. Then we will get people writing tests.
... In the past 12 to 18 months, the testing situation at the W3C has improved a lot.

… When CSS 2.1 was going to REC, there was a big panic about there being no tests.

… Now we are starting to have some agreement about what format to write tests in.

… The same format for WebApps, HTML, etc.

… The tests are all in mercurial repo.

… http://dvcs.w3.org/hg/webapps/

… [Showing the repo website on the screen]

… We have a folder for each spec, containing all of its tests.

… For each, there is an "approved" directory and "submitted" directory.

<ArtB> http://w3c-test.org/webapps/

… This is a bit annoying right now, so we are going to try and develop a system much like they have in CSS, where the spec can be annotated with relevants tests.

<ArtB> Example of approved tests: http://w3c-test.org/webapps/WebSockets/tests/

<ArtB> … http://w3c-test.org/webapps/WebSockets/tests/approved/

jgraham: the situation now is that we are accepting tests in 3 formats, depending on what you're trying to test.

… For this group, we want to test DOM APIs, so we can write tests using JavaScript.

… testharness.js framework for writing tests.

… Similar in idea to others like QUnit, etc.

<ArtB> … https://github.com/jgraham/testharness.js

… For cases where rendering is important, we use reference tests. You two files. One uses the thing being tested. One creates the same rendering using different techniques.

… If the two look the same, then you assume it works. If they're different, the test fails, something is broken.

… We also have self-describing tests.

… This is basically a list of steps that describe what to do and what the result should be.

<ArtB> … testharness tutorial by Robin Berjon: http://darobin.github.com/test-harness-tutorial/docs/using-testharness.html

… I will now go through the features of testharness.js. Then in the next session, people can try writing some tests.

darobin, I suggest we put that documentation on w3c-test.org

jgraham: [Slides on screen, from testing the web forward event in paris]

… For testing JS, no manual interaction

… Two types of tests.

… 1. Synchronous tests.

… [Showing boilerplate test file on screen]

… The function called test takes another function as a parameter. The inner function runs the actual test, with various assertions. e.g. assert_true(…)

… [Showed example assertion from a spec]

… [Now showing an example testing function that tests this assertion]

… 2. Async tests.

… Some tests depend on waiting for events, network responses or other non-synchronous features.

… Test authors should write using the normal event handlers for the feature being tested and include test functions within those event handlers.

… [Example on screen showing an asynchronous test function called by setTimeout]

… t.step() takes a function, which runs the tests.

… t.step_func() is similar, but generates a testing function, which may be used directly as an event or timeout handler.

… [Showing an example assertion from the local storage spec]

… [Example tests the onstorage event. Uses t.step_func() to generate an event handler for onstorage. Includes assertions to verify the result.]

… This includes multiple assertions in the single tests. But if one fails, the whole test fails.

… We can set more properties on the test that are useful as metadata.

… The CSS WG used <link rel="help"> to link to the part of the spec being tested.

… What we can use instead is a help property to point at the part of the spec being tested.

… This helps identify which parts of the spec have and have not been tested.

… PLH has been working on adding this for HTML.

… I propose that we structure the directories based on the section of the spec.

Lachy: I don't like the idea of using directory structure as a kind of metadata.

jgraham: There are pros and cons. THis is an issue that can be discussed tomorrow or some other time.

The step_func() method lets authors specify a timeout for an individual test.

s/The step_func()/... The step func()/

… The setup() method allows setting a global timeout for the entire testsuite.

s/step func()/async_test()/

… There are a range of asserts. e.g. assert_true, assert_false, etc. (Others shown on screen)

… assert_throws knows how to capture an exception and check that it's the right one.

… A notification API allows you to findout when certain things occur during the test, using callbacks.

… There is lots of documentation.

… darobin has written a tutorial as well.

at 16:00, we will try writing some test.

<darobin> http://darobin.github.com/test-harness-tutorial/docs/using-testharness.html -> Test Harness Tutorial

<SimonPieters> http://w3c-test.org/resources/testharness.js

XMLHttpRequest

<darobin> Julian Aubourg

julian: We have a test coverage report for XHR

… There is a CSS and Javascript file that can generate this report within the specs.

jgraham: There will be more sessions on testing tomorrow.

Web Driver

<odinho_> Simon Stewart

Simon: My name is Simon Stewart

… Over here we have Andreas from Opera, David who works on Firefox and Mozilla web driver, XXX who works on Chrome's

… Demo.

… We have support for tests written in python, java c#, etc. Basically any language.

… Facebook have contributed PHP bindings.

… There are Perl bindings as well.

… Demo, on screen.

… Obtaining a driver instance using: d = webdriver.Firefox()

… [More code on screen]

… We have a version of Firefox

… Using d.get() method to navigate to URL

… d.find_element() method to find elements in a page by an attribute value.

… e.send_keys() simulates keyboard input

… Demo of WebDriver playing the piano.

… Javascript based piano. WebDriver is sending click events to the piano keys on the page.

… Demo was using Chrome.

… We also support Opera

… Using web driver to send keyboard inputs

… Also querying using javascript and JSON to find out the position of items on the screen, in order to play a game.

… What are the kinds of thing that people are doing with these things?

… QA engineers doing end-to-end testing of their systems.

… With high fidelity user input, we can do things like drag and drop.

… On Chrome and Opera, those browsers have been modified to allow web driver to inject events directly

… For IE and Firefox, we get hold of the hwnd and pump WM messages into it.

… The second audience are browser vendors.

… They want to be able to test their browser before inflicting it upon the world.

… The third audience is spec authors wanting to write conformance tests for things that can't be expressed solely in javascript.

… Interacting with modal dialogs, for example, or other things that require user interaction.

… Web Driver can handle alert(), prompt(), etc.

<Zakim> darobin, you wanted to ask about device interaction

darobin: One of the problems we had trouble automating is platform device functions. No way to detect and verify physical actions, like phone vibrations.

simon: It's fairly easy to extend.

… We mandate that implementations should communicate in a common way, to reduce fragmentation of implementations.

… That's a high level overview. Any questions?

SimonPieters: For the W3C tests, jgraham said we have 3 formats. Can we replace manual tests with WebDriver tests?

simon: The manual tests which are a sequence of user interaction and checking the result are good candidates for web driver.

… There may be edge cases where we don't have that functionality.

… We have an advanced interaction API.

… We have a basic touch implementation.

Lachy: Is there any ability to interact with the browser chrome.

simon: Not yet. Possible to extend into this area in the future.
... web driver is an attempt to avoid getting into a place where web apps cannot be automatically tested.

ArtB: How much time before the web driver spec is at feature freeze?

simon: We're kind of doing this backwards. The implementations are fairly solid.

… Lots of major companies. Facebook, Mozilla, BBC, etc. are happy to put a lot of weight behind this.

… The actual specification is lagging behind.

… If you were able to look at the open source tree, you would be able to make a compatible implementation today.

… We are working on porting our tests to a W3C test suite alongside the specification.

ArtB: If you have comments, submit them sooner rather than later.

John: (Microsoft, Principle testee for IE). I was in the meetings for web driver spec. We are looking at and and trying to evaluate it. Cannot say whether we weil support it.

simon: Mozilla will be using WebDriver extensively

<adrianba> s/testee/test lead/

odinho_: Is it possible to take control over the browser and interact with it yourself while web driver script is running.

<JohnJansen> s/John/JohnJansen

<adrianba> s/we weil/we will/

simon: It's a bad idea. Mozilla runs it in a non-interactive way.

<adrianba> s/in the meetings/in the meetings as an observer/

… For people who run websites, it is possible to detect if web driver is being used by the client.

… I would be interested in providing a way to identify when a browser is under web driver control.

… I will hang around if people want to ask me questions later.

… Thank you

ArtB: Break.

… jgraham will continue with testing at 16:00. Web Intents will start at 16:45

… testing is at 15:30 instead

<ArtB> ScribeNick: ArtB

Testing Tutorial by James and Simon

JG: if you have any questions about writing tests, Simon and I would be glad to help

… just let us know

<hsivonen> /join #tpac

<hsivonen> doh

<jaubourg> \o/

<sgodard> Great, It's very cool with tests inside document, good job

Web Intents

<Lachy> Greg: I'm going to talk about web intents and our prototype implementation

<Lachy> … Web Intents is a draft in collaboration with device APIs.

<Lachy> … It's kind of like an RPC framework, when one app can start an activity that is satisfied by another web app.

<Lachy> … You can see some extensions and apps I have installed in Chrome. (on screen)

<tantek> is anyone there from Mozilla to bring up web activities?

<Lachy> … The page has a way to pick an image from anotehr web app. If i click on this button, it takes me to another app called Quicksnapr.

<Lachy> … Using web cam APIs to take a picture directly on the web page.

<Lachy> … [taken several pictures]

<Lachy> … Can pick one and send it back to the Imagemator app (the first one he started at)

<Lachy> … Using file system API to save the picture locally.

<Lachy> … I can now load up another local Chrome app and see the image on the local file system.

<Lachy> … The apps don't necessarily know about each other. The intents allow them to be loosely hooked up in an adhoc way.

<tantek> mounir - glad to hear it. carry-on then. thanks.

<Lachy> … The nice thing is that the first web app that launches the intent doesn't have to know about the next one.

<Lachy> … That's the loosely couple benefit that comes from this system.

<Lachy> … It does cause some problems though.

<Lachy> … The current status: We've done a tonne of work on the mechanics of the spec, resolving ambiguities, standard spec work, etc. Also developed an interchange format.

<Lachy> … e.g. the details of how an image gets transferred from point A to B

<Lachy> … More to come. e.g. When we first proposed this API, we were thinking in terms, than when picking an image, you would always get specific user interaction approaches.

<tantek> jgraham - re: <intent> - http://w3cmemes.tumblr.com/post/22399681762

<Lachy> … That was a mistake. We want to move to an event model.

<Lachy> … The problems are mostly around the UI and figuring out the responsibilities of the UA and web app.

<Lachy> … The first one is that when you have a few tabs cooperating. I have one tab that started the intent, another that satisfied the intent.

<hober> tantek jgraham: also http://w3cmemes.tumblr.com/post/29085196102

<Lachy> … How should this link be conveyed to the user.

<Lachy> … How to manage the fact that there are two tabs involved in the same activity.

<Lachy> … We thought the web app picker would be a benefit becuase they can select a new app that could satisfy the intent.

<Lachy> … The use of this picker is a lot higher than we would like.

<Lachy> … It ends up being a lot of steps.

<Lachy> … User has to check permissions when setting up a new app. Incorporating app discovery and installation into the picker doesn't work, from a user interaction perspective.

<Lachy> … If we imagine a defaulting model, where there is a system default for known intents.

<Lachy> … So users wouldn't be presented with the picker so often. They would just use their default.

<Lachy> … It's possible that these issues may need API tweaks to solve them.

<Lachy> In Chrome 24, the feature is behind an experimental flag.

<Lachy> … that's basically the demo and getting everyone up to speed. Any questions or discussion?

<Lachy> Greg. It has changed. For a while we thought we needed extra metadata in the pay load.

<Lachy> … Currently the API is very task oriented.

<Lachy> … If the model is more a persistent system or app to app connection, that may not be the best API to use.

<Lachy> XXX: You spoke a lot about interacting with 2 tabs. Could you explain?

<odinho_> s/XXX/mounir/

<Lachy> Greg: There's 1 tab that initiates the intent, one that satisfies it. What should happen if the user closes the second tab. How should that be handled by the browser or the web app? These issues are not clear.

<Lachy> … I characterise it as more of a UI problem that browser vendors need to pay attention to.

<Lachy> sicking: I haven't been following web intents, but I was under the impression that there was some mechanism to set up a communication link between two tabs. Is that there?

<Lachy> Greg: The way the experiement works in Chrome is that there's always a UI that the service presents.

<Lachy> … The tab is always opened either inline or in a new tab.

<Lachy> XXX: Chromes specification indicates that there is a pause attribute.

<odinho_> s/pause/ports/

<odinho_> s/XXX/mounir/

<hsivonen> jgraham, consider <intent> objected to

<Lachy> s/pause/port/

<Lachy> Greg: It passes a structured clone.

<shan> s/experiement/experiment/

<Lachy> YYY: I wonder about the servicing page.

<Lachy> Greg: The draft spec calls for ways to register dynamically as a extension or app with a manifest

<Lachy> Greg: For Chrome 24, we were experiementing with an icon in the URL bar tha when clicked would should things like bookmark, share, etc. with some app that you have installed. That would use the intent system to link with apps.

<Lachy> s/tha/that/

<Lachy> sicking: The impression I got around intents is that hte hard part is building a user experience that basically satisfied the people we want to implement the intents. The actual mechanics of shuffling data from one tab to another is on the hard bit.

<MagnusOlsson> s/YYY/MagnusOlsson/

<hsivonen> timeless, I object to adding new elements to <head> and I object to adding new void elements

<Lachy> Greg: It's like a two sided market. The hope is that there are lot of clients and services invoking and servicing intents. Getting that market is tough.

<Lachy> … Our initial plan is using features like that dropdown I was talking about earlier.

<Lachy> … The reason we don't have that in Chrome 24 is because of the UI problems we discoverd.

<Lachy> … Having a bunch of eco systems set up around an API that was going to change wouldn't be the best plan. So we hid it behind a flag

<Zakim> npdoty, you wanted to follow up on the distinction between user-invoked and page-invoked

<Lachy> npdoty: I mostly work on privacy in standards. To follow up, as I understand, the intents spec as it is now, the intents are done as service by a user clicking a button.

<Lachy> … But a user could also potentially share any URL from teh browser UI, even if the page doesn't explicitly support the intent.

<Lachy> Greg: The spec deals with it in a tangental way. It says that the intent may not be invoke by the API given and allows for the browser to get in the middle on one end or the other of the system.

<Lachy> … The spec can't force the browser to do it, so it's allowed but not mandated in the spec.

<Lachy> … I think we have a good sense of the interchange format to say how to transfer images or URLs as a data packet.

<Lachy> sicking: We in Firefox had the need for something similar to this, but since web intents wasn't done, we did something else.

<Lachy> … We have web activities which is similar. It has the same capabilities. Very much tied into apps. The user brings up an app, rather than a new tab.

<Lachy> … one of the UI problems we had is that if you have multiple handlers for a given intent, you need to show some sort of UI so the user can choose.

<Lachy> … what text string to you put in the title of that UI.

<Lachy> … We put application names next to each option. I don't know if you can do that in your implementation, given that there is no trusted name for a website.

<Lachy> Greg: In Chrome, the picker has a string that is related to the action that was performed by the user. There's a custom string per action and a generic one if we don't know what the action is. Something like "which service should we use?"

<Lachy> Sicking: how do you describe the options?

<Lachy> Greg: We think that using the name of the app is the most clear. The service can provide a custom string for this.

<Lachy> … I think the reason that that ends up being useful than just the name of the application is that when you see the UI, you're picking an application.

<Lachy> sicking: one problem is trust. It's possible to phish this.

<Lachy> … I could change my icon and title to Bank of America, and fool the user.

<Lachy> … It's part of the Chrome UI, so it feels more trustwothy, but in reality, it's part of the web content.

<Lachy> Greg: That's a problem with the picker that we had.

<Lachy> … That's one slice of the problem with using the picker that we discoverd. I agree there would be a phishing risk.

<Zakim> Arno, you wanted to ask status on intents semantics

<Lachy> Greg: The reason we were using a data URL is that there's a problem with web kit.

<Lachy> … It's bug we need to fix.

<npdoty> it seems like a concern that the picker also doesn't make it clear what kind of data is being passed along, in addition to it being uncertain whom you're passing the data to

<Zakim> timeless, you wanted to comment on that and to comment security concerns

<Lachy> timeless: sicking asked about security concerns.All the browsers that ship have the ability to ask other services if a website is risky.

<Lachy> … Firefox has the concept of how often you've been to a page.

<Arno> The question was about wether or not there was a work on intent semantics, as for example on the edit intent when the intent "returned" the data could either be a datablob or a data : URL

<Lachy> … Been to Facebook a lot. Have not been to a phishing site a lot. I expect that that would be taken into account by the Ui when trying to counter phishing attempts.

<Lachy> Greg: Those are good points.

<Lachy> … Some of those things are valuable to solve the problem.

<Lachy> … We also only accept the API when it's a gesture

<Lachy> ArtB: Are there other implementations?

<Lachy> Greg: I think that someof the problesm I talked about with tabs would likely show up with web activities applied to the same kind of use cases.

<Lachy> sicking: We've only done it for Firefox OS. Have not shipped yet.

<Lachy> … it's intended to solve exactly the same use cases. Picking, sharing, images, etc.

<Lachy> … We do use it internally for things like the camera app. We have a button to open your gallery using an intent.

<Lachy> … Other apps can hook into that.

<Lachy> … Likewise, when you have an input type=file, we fire a pick event that other apps can hook into.

<shan> s/problesm/problems/

<Lachy> … The goal is definitely to solve the same problem between 3rd party apps

<Lachy> mounir: We had an issue in Firefox OS. When you open an app, and an app opens another. In that case, we had to know when ???

<mounir> mounir: we had to know if the opener wanted to get a result or not

<Lachy> ArtB: Thank you very much Greg.

<Lachy> ArtB: meeting ajourned.

<mounir> mounir: in the case of a result was expected, we had to handle the case of the handler activity being left

<Lachy> RRSAgent: make minutes

<mounir> mounir: to not be in the situation where we actually don't know if the result will be sent

<Lachy> RRSAgent: make minutes

<tantek> was it not adjourned?

<timeless> trackbot, end meeting

- DRAFT -

WebApps F2F Meeting

30 Oct 2012

Attendees

Contents

Agenda Bashing

Testing

Introductions

IME

Selectors API Level 2

AppCache, Offline, Packaged WebApps, App Manifest, ...

Web Platform Docs

Testing (James Graham)

Testing the Web Backwards, Lyon

XMLHttpRequest

Web Driver

Testing Tutorial by James and Simon

Web Intents

Summary of Action Items

Scribe.perl diagnostic output