<ArtB> Date: 29 October 2012

<ArtB> Scribe: Josh_Soref

<ArtB> ScribeNick: timeless

Introductions

chaals: welcome to webapps, everybody

[ Applause ]

ArtB: we're happy to be here

chaals: in IETF, they have the hum, we get the W3C clap
... this is a big meeting
... we're going to be really strict about making you Join Queues
... and use the microphone
... I'm Charles
... the first thing i'm going to do is ask everyone to introduce themselves
... say who you are, where you work, and if you have any particular spec that interests you
... I'm Charles, I work for Yandex, i'm interested in just about everything

shepazu: I'm Doug Sheppers, I'm one of 2 w3c staff contacts

krisk: Kris, Microsoft, testing

adrianba: Adrian Bateman, Microsoft, I'm interested

BO_HU_CHINA_UNICOM: Bo Hu, China Unicom, i'm interested in Push API

Bo_Chen: Bo Chen, China Unicom, i'm interested in this WG and related groups

ArtB: Art Barstow, Co-chair with chaals, Nokia, all specs

<npdoty> timeless: Josh Soren, from RIM, not yet a member of the WG

pbakaus: Paul Bakaus, Zynga, everything that helps games

sicking: Jonas Sicking, Mozilla, all specs

<npdoty> from Zynga, everything that helps games

jaubourg: Julian Bourg, jQuery Foundation, interested in the Web

mklein: Adam Klein, Google

rafaelw: Rafael W, Google, CCC

DDD: Wayne Carr, Intel, processors

Yuan: Yuan, Nokia, everything

EEE: EEF, Google, DOM Specs

FFF: FFG

GGG: GGH

morrita: HHI, Google, Web Components

JJJ: JJK

shan: Soonbo Han from LGE

spieters: Simon Pieters, Opera

<takuya> tatakuya from Google. IME API

<bryan> Bryan Sullivan from AT&T, co-editing the Push API spec, AC rep, interested in most specs but especially storage specs and File* specs

odinho_: Odin, Opera, interest in most specs, but listens most carefully for IndexedDB atm

Lachlan Hunt, Opera, editor of Selectors API

<jgraham> jgraham: James Graham, Opera

<KenjiBX> KenjiBX ; Kenji Baheux ; Google ; general interest in WebApps spec ; particular interest in proposed IME API.

<haraken> haraken from Google. DOM specs.

bryan: bryan Sullivan, AT&T AC Rep, MM

paul: Paul Cotton, Microsoft, HTML co-chair

PPP: PPU

yoske: QQQ

RRR: RRA

Koichi Takagi: KDDI, Japan

<efullea> efullea: Eduardo Fullea, co-editing Push API spec

tomoyuki: Tomoyuki from KDDI, Japan

TTT: TTU

<efullea> efullea: Eduardo Fullea, Telefonica, co-editing Push API spec

amirabella: Anthony Mirabella, Synacor

<Oh> Jong Soo Oh, LGE

wseltzer: Wendy Seltzer, W3C

christine runnegar: Internet Society, Privacy Interest Group, Provenance WG

<amirabella> s/Amira Bella, CDE/Anthony Mirabella, Synacor/

CDH: CDJ

CDK: CDL

<a12u> Hiroyuki Aizu, TOSHIBA , interested in Web components and WebIntents

jfmoy: France Telecom

CDP: CDQ

BEF: BEJ

<krisk> www.w3.org site is down...known issue w3c staff working on this...

Travis: Travis Leithead, Microsoft

chaals: so, now you've forgotten everyone's name
... please say your name before speaking
... scribe has certainly forgotten your name

Agenda Bashing

chaals: i'm going to try to break the agenda into blocks of less than an hour
... so we can have short breaks of 5-10 minutes
... trying to talk (or scribe) for 2-3 hours is a bad idea

<hallvord> If my introduction wasn't logged, here it is: Hallvord R. M. Steen, Opera Software, XMLHttpRequest co-editor / Clipboard Events editor

<bryan> anyone else having issues with the W3C wiki server?

chaals: items: webidl
... streams
... input method
... push api

<sgodard> No access to W3C wiki server :(

chaals: indexeddb

<krisk> yes w3c.org site has issues (timesout)...staff working to resolve

chaals: web intents
... will be tomorrow afternoon just before 5
... web components (shadow dom, templates) is set for 3:45pm today
... i'm presuming we have people dialing in for that (i.e. fixed time)
... file api, 4:45pm today (again, people dialing in, fixed time slot)
... does anyone have a topic that is not on that list?
... that you'd like discussed

bryan: i'd like to take push api today (before file), or tomorrow morning
... like 3pm?

chaals: objections?

[ none ]

shepazu: webidl is a pretty long discussion
... i think we should revisit it later in the day

chaals: so split it into two sessions?
... Travis , i think you have a guy on the hook for that

ArtB: plh , you should be here for that
... do you have time constraints?

plh: don't put it tomorrow afternoon

chaals: web idl next, and then revisit after lunch

shepazu: i'd like to touch base w/ heycam, so tomorrow morning

chaals: streams, time constraints?
... streams will be merged file api discussion this afternoon
... IME... anytime
... process, web idl-1, ime, indexeddb
... as time allows

takuya: i'd like to push IME to this afternoon or tomorrow

chaals: tomorrow morning
... webidl-2, ime

mjs: Maciej, Apple
... there's been discussion on the ML about File System API
... either taking it off standards track
... or...

chaals: i expect it to be part of the file api discussion
... i'll toss in a topic
... i think we should look at AppCache, Offline Applications, ... mess
... html wg has AppCache in their spec
... everyone hates it
... either because they've implemented it
... we have a proposal from Mozilla for packaging applications using JSON instead of XML
... all of this deals w/ using applications offline

Lachy: lachlan, Opera,

<npdoty> +1 on talking about all of these offline questions at once

Lachy: when we do Selectors, can we cover Selectors api 2?

<bryan> +1 to manifest discussion and appcache

Lachy: we'll have a chance to repeat this process tomorrow
... if you've forgotten to mention something, that's bad, but we can fix tomorrow
... we have a small handful of process things
... if you want to talk about how w3c process works/how it should be changed
... this isn't the venue
... we don't care
... w3c has a CG for that
... right now we work w/ the process we get
... in walks anne
... our goal is to get docs to REC

<sgodard> ArtB, it's not just you

Lachy: there's a handful of documents we're trying to step through that
... Selectors API 1, Widget Update
... there's a set of docs where we need editors

Selectors

chaals: we have a specification for Selectors Level 1
... we have a test suite, recently revised
... there was a CfC to move to PR
... the normal process is we say does everyone agree to move along
... we prefer positive responses
... there was only one response
... did anyone want to speak?

[ No one ]

chaals: Lachy changed the test suite
... did anyone review it?

Lachy: i rewrote the test suite
... the old one was full of bugs
... and wasn't revealing bugs in implementations
... i rewrote it, it now shows bugs
... on the spec, i removed hasFeature()
... it's now irrelevant from the latest DOM spec

chaals: we think Selectors API level 1 is ready to go
... we can declare victory as soon as we've filled in the boxes/forms/done the process

Widget Updates

chaals: widget updates has sat around for a while
... in a PAG for a while
... there are a couple of implementations
... i'm curious to know if there are more implementations
... Opera has an implementation shipping

<Lachy> Selectors API Testsuite: http://dev.w3.org/2006/webapi/selectors-api-testsuite/ (Level 1 tests need review, level 2 is a work in progress.)

chaals: with a backend
... Apache has an implementation

sakari: the Tizen project has implemented it

sebastian: we use it

chaals: objections to moving it forward?

[ None ]

editor orphaned specifications

chaals: DOM4, URL Spec

<ArtB> ACTION: Charles start the process to move Widget Updates to Candidate Recommendation [recorded in http://www.w3.org/2012/10/29-webapps-minutes.html#action01]

<trackbot> Created ACTION-664 - Start the process to move Widget Updates to Candidate Recommendation [on Charles McCathie Nevile - due 2012-11-05].

chaals: we're committed atm to do them
... there's someone working on these things
... it would be interested to know what his perspective is

annevk: i'm moving them forward

chaals: but you're not doing them in w3c

annevk: that's correct
... i'm talking with w3 shortly
... about being an invited expert

chaals: our current perspective is that we'd like an editor for DOM4

Lachy: i might be able to be an editor for dom4

chaals: url?
... URL isn't a very big spec
... you can copy+paste what anne does
... put your name on it
... become famous
... it's really easy

ArtB: fame and fortune will follow

shepazu: guaranteed

ArtB: if you don't want to volunteer publicly, that's fine, talk to chaals or ArtB

chaals: Progress Spec is more or less done
... volunteer to do that spec
... shepazu will thank you

XHR

chaals: XMLHttpRequest

hallvord: we think the spec is pretty feature complete
... we're trying to get overview of test coverage

<krisk> Microsoft submitted some more tests for XHR http://dvcs.w3.org/hg/webapps/rev/be00d20f652e

hallvord: and the changes anne has done to the spec

jaubourg: that pretty much covers it

chaals: are there significant changes to the spec?

annevk: progress was ported in
... it was aligned with refersrc in html

<odinho_> https://github.com/whatwg/xhr <- XHR spec annevk

<annevk> AnonXMLHttpRequest XMLHttpRequest(anon=true)

<annevk> 308 is now mentioned

<annevk> Encoding Standard is integrated

<jgraham> https://github.com/whatwg has url and dom also

<annevk> user/password are now always okay

hallvord: i think there's some work for mapping
... and then try to ship it
... the main work is test coverage/mapping implementation
... and trying to ship the spec

annevk: there's a few more things
... canceling the send/abort algorithms
... needs to be rewritten to use a flag
... the current way doesn't work
... you always want to dispatch certain events
... it needs to be updated to use the url standard
... to reference things with spaces in them
... and we need to write tests for these conditions

chaals: should you be able to play around w/ various headers
... lots of people wanted to be able to add/change the UA header
... we ended up not making a change

hallvord: we're still trying to figure out if we'll make a decision

chaals: there are people who want to be able to change it

sicking: there's also the AnonXMLHttpRequest constructor
... i don't think it's been implemented
... we've proposed an alternate syntax
... that also allows for http headers

hallvord: that's one of the things to pick annevk 's brain

<Zakim> adrianba, you wanted to ask about Stream

adrianba: annevk did some changes recently
... for accessing Streams
... we're specifically interested in
... for the new media specs in the HTML WG
... we could talk a bit more about this under stream
... but we'd like to talk about that a bit more here

odinho_: Opera implements AnonXMLHttpRequest
... but we have no problem changing it
... we like the new proposal better
... so it won't be a problem

chaals: thanks SK telecom
... who made a commitment for RF

hallvord_: on streams
... i guess we could put that in the next version
... since we want to ship this spec
... no one's implemented that
... so i hope it's possible to defer that

adrianba: we implemented and shipped it in ie10
... with a prefix
... i'm fine with deferring it
... provided it's written somewhere that we can reference

chaals: was that you volunteering to write it?

adrianba: i didn't hear that
... but sure

chaals: he agreed
... xhr level 2
... the plan is to get the one we have finished
... and then work on the next one

<adrianba> http://www.w3.org/2008/webapps/wiki/PubStatus

Pub Status

ArtB: CORS

<sgodard> +1 w3.org is ok now

ArtB: are the webappsec folks here?

tlr: my recollection is that BradH is driving this
... trying to get it ready
... bradh is in the room here

<annevk> (latest commit to CORS is mine...)

chaals: my memory is they're LC/CR

<annevk> (W3C CORS that is)

tlr: it's LC, comment period has closed
... think we have an email for one issue

chaals: Clipboard

hallvord_: it's something i should get back to

chaals: anyone want to assist

hallvord_: i think the remaining issue is onbefore*

<npdoty> webappsec is meeting Thursday/Friday, fyi

hallvord_: for integrating copy with native browser

<tlr> on CORS: http://www.w3.org/mid/370C9BEB4DD6154FA963E2F79ADC6F2E2AB22A@DEN-EXDDA-S12.corp.ebay.com

<annevk> WHATWG CORS had a few changes: https://github.com/whatwg/fetch/commits

hallvord_: i have a request from university of geneva
... i was considering ducking it
... but chromium was interesting

<tlr> avk, do you know if Brad was tracking these?

<annevk> to account for 308, some typos, Referer control

chaals: we'll use them in yandex

<annevk> tlr: no commits have been made to the W3C copy for 4 months

ArtB: so we're one feature/issue from LC

hallvord_: sort of
... one feature is missing
... there's some text about security

<tlr> what's the nature of your changes?

hallvord_: and cleaning up of content
... which we should remove
... perhaps it isn't necessary

ArtB: if people want to see that spec move forward
... they should submit comments

hallvord_: one issue to add, one to remove

chaals: if people are worried about security, look at it, scream
... DOM4
... we're looking for an editor

<npdoty> does someone want to chat over coffee about Clipboard and security/privacy?

chaals: dom level 3 events

Travis: dom level 3 events is
... has exited its second LC
... 30 of September
... there were a short number of LC comments
... 7 or 8
... recorded in a DoC
... i think the majority of those comments have been addressed
... in comments or email

chaals: people have been asking for features
... but that should be dom4

Travis: to continue
... i'd like to transition those to dom level 4 events
... to allow the mind share to continue to progress
... while we step aside and lock down dom 3 events
... i'd like to propose that we organize those features into a separate document
... and publish that as FPWD

<hallvord_> event.key is still a problem child, authors trying to use it have been complaining both to me and on the mailing list

Travis: i can take an action
... next step for D3E
... is move to CR

<ArtB> ACTION: Travis create an ED of DOM4 Events [recorded in http://www.w3.org/2012/10/29-webapps-minutes.html#action02]

<trackbot> Created ACTION-665 - Create an ED of DOM4 Events [on Travis Leithead - due 2012-11-05].

chaals: dom parsing and serialization

Travis: also me

<ArtB> ACTION: Barstow work with Travis on a CfC for DOM3 Events Candidate [recorded in http://www.w3.org/2012/10/29-webapps-minutes.html#action03]

<trackbot> Created ACTION-666 - Work with Travis on a CfC for DOM3 Events Candidate [on Arthur Barstow - due 2012-11-05].

Travis: i'm c+p from ms2ger
... that's the status

<hallvord_> (should I ask for the mike and comment even if I've "said" something on IRC?)

chaals: file stuff we'll talk about this afternoon
... fullscreen
... we sort of have an editor
... tantek, he's in CSS, it's a joint deliverable

<npdoty> q/

chaals: i believe that if we bribe him, he'll produce drafts
... gamepad
... any editors here?
... html templates, indexeddb, ime,
... webidl
... heycam, where is java bindings for webidl?
... pointer lock, progress events

<heycam> http://dev.w3.org/2006/webapi/WebIDL/java.html

chaals: push api for later
... is the quota management editor here?
... server sent events?

ArtB: server sent events LC published last week

<heycam> I have kept the Java bindings document up to date with Web IDL, but I expect just to publish it as a note for curiosity at some point.

ArtB: two more weeks of review

<takuya> For Quota, I can follow up with its editor (Kinuko) later.

ArtB: if we have no major issues raised
... we can move forward
... we need a test facilitator
... i know there are tests from opera
... any volunteers for facilitator?
... jgraham ?

jgraham: maybe
... we moved the tests from opera's server to github

<hallvord_> welcome Jungkee :)

jgraham: anyone else w/ tests for Server-sent-events, please talk to me

<Jungkee> Hi Hallvord

chaals: testing is something we'll come back to in the agenda

<Jungkee> Hi Julian

chaals: lots of work that needs to be done
... it's great to contribute one test
... it's amazingly helpful to be the facilitator for a spec
... shadow dom is on the agenda
... screen orientation

mounir: mounir, mozilla

<ArtB> ACTION: barstow follow up with Kinuko Yasuda on status and plan for Quota Management API [recorded in http://www.w3.org/2012/10/29-webapps-minutes.html#action04]

<trackbot> Created ACTION-667 - Follow up with Kinuko Yasuda on status and plan for Quota Management API [on Arthur Barstow - due 2012-11-05].

mounir: screen orientation in Firefox for Android and B2G
... i heard from someone from google

chaals: stream api is on the agenda
... url we're looking for someone
... web app manifest is on the agenda
... web components is on the agenda
... webidl is on the agenda
... web intents is on the agenda
... web messaging

krisk: there's a good number of tests
... if we move them from web workers to web messaging
... it could be sufficient to be complete

chaals: web sockets

ArtB: CR was published last month
... question of interop for exit criteria

<jgraham> server sent events tests - https://github.com/w3c/event-source

krisk: last F2F we talked about arraybufferview and replacement character
... ie10 implements that
... we also talked about event constructors
... all 3 are issues
... i sent an email about the test server
... there's an issue w/ getting the server working for the tests

ArtB: there's a request for review of the test suite
... no comments on the test suite implies that the test suite is sufficient

<odinho_> RRSAgent: make minutes

ArtB: so we wait for implementations to catch up

chaals: who has impls?
... opera does?

SimonPieters: opera has it

sicking: i think we implement the spec
... i think we do replacement character
... and arraybufferviews
... i'm fairly sure we do event constructors now

chaals: sounds like it's being implemented

IndexedDB

chaals: just a small matter of getting it cooked
... web storage?

ArtB: it's been around for a year now
... waiting for implementations to catch up
... i need to contact Jong-Heun Lee

chaals: web workers?

ArtB: published in may
... for shared workers, i think we're lacking impls

SimonPieters: there are tests
... the opera submitted tests aren't all testharness.js
... i'm not sure about pass rate on different browsers
... test suite still needs more work

chaals: any big issues?

sicking: i'm pretty sure there are pretty big features not implemented by anyone
... we don't implement shared workers
... i don't know if anyone implements workers in workers

annevk: i think opera does workers in workers

Travis: IE10 has workers

<annevk> Opera did it first1

Travis: we don't support shared workers in any form
... we also may not support automatic GC for regular Workers

chaals: so outstanding work to be done

ArtB: is it small
... should we split the spec?

chaals: does anyone suggest we should split the spec?

Travis: i'd like to entertain the idea of splitting out shared workers
... as a separate spec
... wanting to gauge support for that idea in the group
... seems like a good idea to move workers forward since everyone has it

chaals: we entertain spec editors

SimonPieters: i think we shouldn't split the spec
... no one is not planning to implement

pbakaus: i have a question on this
... i had recent discussions on new features

<ArtB> ACTION: barstow work with Jong-Heun Lee to start a RfR Web Storage test suite [recorded in http://www.w3.org/2012/10/29-webapps-minutes.html#action05]

<trackbot> Created ACTION-668 - Work with Jong-Heun Lee to start a RfR Web Storage test suite [on Arthur Barstow - due 2012-11-05].

pbakaus: i wonder where we put them
... do we put them in a new spec?

chaals: anyone know Hixie 's view?

jgraham: Hixie will just put it in the WhatWG spec
... he won't split it out
... whether it makes sense depends on the feature
... if it ties in and affects semantics
... it might be hard to put it into a separate document
... without lots of hooks and making it fragile

sicking: one feature is sync message channels
... which ties in pretty deeply

pbakaus: we discussed canvas

chaals: i don't see this as support for splitting it out
... ArtB does the process puKinukos
... you're welcome to volunteer
... but at some point we'll be skeptical about you volunteering for more work
... if we take what we have through the process
... we expect another version in the future

<takuya> Re; WebSocket support, Chrome has also supported it for long time but arraybufferview and replacement character haven't been implemented yet.

chaals: we have widgets for tomorrow
... time for a 10 minute break

[ Break ]

Web IDL

<takuya> Correction regarding websocket support in chromium, we have already implemented both (arraybufferview and replacement character). sorry about it.

chaals: half the people asked about webidl now asked for it to be postponed

Streams

<adrianba> http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm

adrianba: we updated the streams spec last week
... it's a pretty simple spec
... we made some changes to align it with changes in the fileapi
... the stream object maps fairly closely to the Blob object in fileapi
... stream has a way to keep reading data until you get to the end of the stream
... there's a streamreader that maps fairly closely to filereader
... there's a streambuilder which is fairly close to what we used to have with blobbuilder
... it doesn't make sense to move to the constructor form
... so it's still there

sicking: can you read from a stream multiple times or just once?

adrianba: you can only read the data once
... the stream reader methods have a construct to say the maximum amount of data you want to read
... so you can avoid reading to the end
... you could read into a blob

chaals: so i could read from a stream into a blob
... and then read from the blob multiple times

adrianba: or into a string

sicking: is there a wa to get a stream that represents the content of a url?

adrianba: part of the proposal in the stream spec
... which i think i've now volunteered to write into a different spec
... in ready-state-3
... if you set the response type to stream
... then you can put it into a stream object
... and essentially read off the wire from xhr
... and at the end the xhr moves to ready-state-4

sicking: is there the concept of a stream failing?
... if the server fails instead of ending

adrianba: if you call a read method
... and the read is ending because of an io error
... then the method throws an error
... the same sort of error construct as in file reader
... we have the stream builder and the stream reader from xhr
... we have discussions in html wg for media source extension spec
... we'd like to use the stream object from xhr
... to hand off data from media to the rendering pipeline
... we the Media Group

sicking: how does that work if you can only read from a stream once
... given that a media might want to rewind

adrianba: this is for media stream
... where you can append to a buffer
... the media stream is then responsible for managing that buffer
... we want to avoid having to read all the way to the end into an array buffer
... and then copy it into the media element buffer
... this avoids copying into another buffer

<Zakim> timeless, you wanted to ask if you still get those last bytes before the exception

adrianba: you can read the data during progress events
... and then get the error later
... as with progress events/file

SimonPieters: with file we dropped blob builder
... is there a plan to do the same thing with stream?

adrianba: no, with blob you have all the data available at the time it's created
... the blob is immutable
... for stream, the stream builder lets you create an instance of a stream
... but still have a reference to the builder
... to feed in more data
... to append to the stream
... maybe sending with xhr, or consuming from some place else

SimonPieters: wouldn't it make sense to just have an append() method on the stream?

adrianba: this allows for producer-consumer in different places
... workers
... so you can transfer the object
... i'm open to discussion
... we haven't built builder yet

SimonPieters: discuss on bug/ML

sicking: if you want to stream from URL to <Media>
... you need to be able to Fast Forward
... without wanting to read all the data in the interim
... and you want to be able to rewind
... you want to be able to jump arbitrarily

adrianba: the intent is to hook it up to the media source extension
... which lets you programatically compose the buffer
... for adaptive streaming
... you'd have a manifest file
... pointing to different segments at different bitrates
... i compose an xhr for one segment
... and choose a different bitrate for another segment
... the buffer in the media element holds the segments you append/insert
... the buffer can drop parts
... the media element with the extension will tell you if you need the data

chaals: so you could rewind to a segment you've been to
... and you could choose to pull in a different quality (higher) for the segment

sicking: i think my question is more on media stream

chaals: how long will it take for you to build this? will this be in ie11/ie12?

adrianba: we built a large part of this already
... we're looking for feedback... as SimonPieters mentioned
... is this the right model
... are there more changes in the file api
... that we'd need to reflect here?
... we feel read part is more useful than builder
... which is why we did that

chaals: do you have someone doing the builder part?

adrianba: you can get a stream from xhr

chaals: is anyone doing builder side?
... break for 30 minutes

[ break ]

Web IDL

<chaals> Agenda planning for the rest of the day:

<chaals> + Web IDL

<chaals> (11.15 − 12.15)

Travis: webidl overview... and then testing
... there's a v1 spec
... which heycam forked off earlier this year
... he's currently working on v2 of webidl
... where new proposals, iterators, serializers have been placed
... in the interest of finishing v1, he did that split

s/present +/present+ /

Travis: there are a number of specs with normative references to webidl
... and they'll get stuck at CR until v1 moves to REC
... there are two approaches
... we create a test suite for the web idl specification
... that tests every normative feature in the specification
... by searching across specifications to find occurrences of those features
... to test those features specifically
... for interface object testing, we'd select a couple of those snippets
... test to see if they're present
... not testing the syntax of webidl
... testing the binding
... so if you're building a browser that supports webidl
... you'd have to implement those things
... it's a bit dicey, since the test suite builders have to pick interface sections that everyone would implement
... the second approach
... would be to create a meta test suite
... "how to test your specification test suite"
... two examples
... the selectors api spec
... the web navigation timing spec (in the web perf wg)
... both of those specifications reference webidl normatively
... and they'd like to go to REC
... if i'm building a test suite for navigation timing
... what do i test?

<Zakim> odinho_, you wanted to ask about [TreatUndefinedAs=Missing]

odinho_: we can talk about that later

Travis: i think there's a slot for that in v2

chaals: this discussion is about stabilizing/publishing v2

mjs: is there at least one spec identified for every feature of webidl
... that is likely to be widely implemented
... and a good example of that feature

Travis: good question
... there's a type called Byte
... prior to yesterday, i wasn't aware of any spec using it
... i found one yesterday, khronos's Typed Array spec
... i believe there's an instance of each feature
... but not necessarily all combinations
... clamp(...various types...)

mjs: is there a list of specifications to use for targeting

Travis: i've created a webidl test

<shepazu> there is also this page, for some references http://www.w3.org/wiki/Web_IDL

Travis: that's loading web idl assertions in iframes
... there's no summary of "these are the specs i'm taking from"
... but they're implicit

jgraham: i don't know how relevant it is to testing webidl itself
... there's IDLHarness.js
... in the resources repository
... in dvcs
... it might be helpful

http://dvcs.w3.org/hg/resources/file/tip/idlharness.js

jgraham: it will try to test the implications of webidl

plh: last i tried, it failed on the window object

SimonPieters: i think there changes to webidl
... AryehGregor wrote it

jgraham: I think AryehGregor plans to work on it

<krisk> Here is a test that consumes this idlharness.js

<krisk> http://www.w3c-test.org/html/tests/submission/AryehGregor/interfaces.html

jgraham: it uses head grabber that darobin wrote
... if things don't match that, it'll fail
... i think that's out of date and needs to be updated

Travis: assuming that worked

chaals: say we identify "this piece is used in Selectors API"
... using this tool to check whether this works

<chaals> ?

<chaals> MJS: Seems like there are 3 testing issues:

<chaals> … the combination of IDL and a particular spec, plus what IDL says, implies requirements on that spec.

<chaals> … eg notification has IDL snippets and that implies requirements for the behaviour of those interefaces.

<chaals> … Maybe every spec using IDL should include tests for the parts of WebIDL used in the given spec.

<chaals> … But also, IDL needs to be tested itself. It has requirements on other specifications, but it is hard to make a test suite that tests specs.

<chaals> … But we could do a grammar-level check, and say that satisfies spec confromance. But tehre are also requirements that cascade down to user agents, and the question is how totest those for WebIDL?

<chaals> … So let's find specs that show examples of each item, and test them. This harnes could help us do that.

<chaals> … We satisfy the larger set of test suites, and those results let us confirm that WebIDL itself works.

<chaals> … If we trust the harness we can use it to automate.

<chaals> … the process.

<chaals> CMN: +!

<chaals> Travis: We could make the test harness into the testing deliverable, and agrees that is sufficient.

<chaals> MJS: Interesting because that would let you test combinations. SUper useful but not sure it fulfils the testing requirement if the harness hasn't actually been used to do the testing yet.

<chaals> TL: How do we test the harness.

<chaals> CMN: Don't think we can get away with just the harness. Wwe need to run it, as Maciej said, but that doesn't seem to be the hard part. Agreeing on the harness seems OK.

<chaals> TL: If I edit a spec and test suite fails on WebIDL, is that a problem?

<chaals> JG: We should be allowed to say a test is failing for a reason other than the actual test itself.

chaals: our obligation is to prove that this is implementable and workable
... we can prove that
... we want to avoid the situation where we say "this is fine, it'll work some time in the future"
... it's like saying "we'll fail the selectors api because someone has a bug in target()"

<plh> --> http://w3c-test.org/webperf/tests/submission/W3C/NavigationTiming/test_interface.html

chaals: i certainly expect to do that

<Lachy> s/target()/:target pseudo-class/

<chaals> … waiting to fix all corner cases is broken, and we can be more grown-up

SimonPieters: having reference to non-REC
... it doesn't block moving to REC

<chaals> CMN: Right. We're not going to hang up on tests that fail for some non-relevant reason.

SimonPieters: you just have to inform that directory
... it doesn't necessarily block you

mjs: w3c process does require that you state your CR exit criteria
... it doesn't require "two implementations will pass in the test suite"
... a spec could state "as long as webidl issues are identified, we won't block on them"

<shepazu> +1 to mjs

mjs: CR exit criteria saying "we must have fixes for every single observed issue" isn't a good idea

plh: i did this exercise with web performance navigation timing
... I did this exercise
... And every single thing had issues

Odinho: I did testing and stopped there was too much red
... There was no prioritization
... Throwing is important
... Some things are less
... Prototype chain

Travis: hopefully when webidl is pushed to rec, people will fix their implementations to match

<chaals> TL: If there are crucial parts of WebIDL that need to pass we need to make sure they do...

Travis: so that we won't have 80% failures for indexeddb

mjs: i've heard there are things which are tested and fail
... i'd like to know what they are
... it's hard to talk in the abstract
... are these different in all browsers?
... or do the browsers all do one thing which is distinct from webidl
... in which case we could "fix" webidl
... but if the browsers each have different behaviors, then making them match webidl could be easier

jgraham: for a lot of the things
... where we see lots and lots of fails
... it's the way the testharness has been written
... it's to test the webidl stuff very carefully
... we can't say nothing about it
... but atm, we have 4 browsers doing 4 distinct things
... where should attributes be on the prototype chain?
... on the objects, on the prototype, both?
... we discussed it on the ML
... we agreed it was the right solution technically
... but everyone who isn't doing that today needs to change this, it's tedious
... but that shouldn't block specs

Lachy: priotizing tests

s/prio/priori/

scribe: i have critical tests
... and nice to have tests

<hallvord> It's important to get those prototype chain issues worked out - or we get compat problems like http://my.opera.com/hallvors/blog/2012/10/26/microsofts-skydrive-gun-meet-foot

scribe: including stuff in webidl that might fail
... changing some parts in webidl would require changing lots of things in our implementation
... and we didn't have the resources for that
... implementing TypeError / NSError from firefox
... changing that, it's in our code, it's a relatively small change
... but it can affect lots of things
... requiring a lot of test fixes in our system

sicking: there are very few controversial things

<chaals> +

sicking: there's very few cases where we should remove something from the spec
... it's just tedious to fix
... and doesn't add value for implementers
... so it gets less priority

mjs: it'd be useful to make a list of known common things
... where there aren't 2 implementations matching webidl's spec
... if the harness could group things
... based on which type of interop issue
... that'd be useful
... thus the remaining ones would be more easily identified
... for the n different behaviors of attribute behaviors
... i'd like to know what they are

sicking: three behaviors i know of
... webkit puts stuff on object itself
... i think opera puts things on the relevant prototype object
... for dom node nodeName, on the Node interface object
... gecko puts it on the Node interface object and the leaf interface object
... e.g. Node and Div interface

Travis: IE since 9 puts it on the Node prototype

jgraham: opera is different for Methods and Attributes

<SimonPieters> in Opera methods are on the prototype, attributes are on the object.

Travis: i'll take an action as we build the test
... to understand the impl report
... there's 2/3 here
... it sounds like that'd be helpful for further discussion on issues

chaals: if you build stuff on webidl
... and you change the spec underneath them
... that makes a mess for really hard to change things
... things outside web browsers
... we need to think about pragmatic
... a way of testing downstream specs
... and finding out what the issues are
... having a WG lets us discuss how to break each of everyone's systems to reach interop
... seems we have a path forward

<smaug> plh: to nav timing? I recall one change + webidl-fying the implementation

ArtB: plh , do you know what to tell the web performance group?

timeless: Nightly has 45 pass (2 fail)
... ie9 has 42 pass (5 fail)

plh: i can take that to the director

chaals: an answer to how long does it take to get done
... there's a priority problem
... "until web idl is finished, you have more work to do"
... to be sure that webidl isn't going to change under you

<krisk> IE10 has the same result as IE9 (42 pass, 5 fail)

chaals: go back to groups "you should push web idl to be sure it's finished sooner"

plh: those groups don't know how to test webidl

chaals: i see darobin 's boss looking at darobin

darobin: i'm coding it right now

Travis: i'd propose we send out a general announcement
... "if your spec depends on webidl. please contact Travis "
... "we'll see if we can prioritize your pieces of webidl"

plh: we have a few specs in PR waiting on WebIDL

<ArtB> ACTION: barstow work with PLH on an announcement seeking IRC fragments [recorded in http://www.w3.org/2012/10/29-webapps-minutes.html#action06]

<trackbot> Created ACTION-669 - Work with PLH on an announcement seeking IRC fragments [on Arthur Barstow - due 2012-11-05].

plh: including GeoLoc

<ArtB> s/IRC fragments/Web IDL fragments/

chaals: on getting WebIDL stable, anything else we need to add?
... we have a plan
... find out what we don't agree on, work on making them work

Travis: please review the assertions in webidl http://dev.w3.org/2006/webapi/WebIDL/WebIDLTest.htm

ArtB: i can send out a call for review to public-script-coord

chaals: time check

<ArtB> ACTION: barstow start a Call for Review for Web IDL test plan on public-script-coord [recorded in http://www.w3.org/2012/10/29-webapps-minutes.html#action07]

<trackbot> Created ACTION-670 - Start a Call for Review for Web IDL test plan on public-script-coord [on Arthur Barstow - due 2012-11-05].

ArtB: the guys working on Quota API could give a quick update

Quota API

UNKNOWN_SPEAKER: she received two pieces of feedback
... temporary/permanent
... the other was to change the interface name
... to get the object instead of integer
... Kinuko mentioned changing temporary/permanent
... as far as she knows, chromium is the only browser supporting this api
... to move forward,
... she's eager to look at how to get others to associate things with

[ .... ]

tobie: vaguely, i made those comments

timeless: he isn't an implementer, he's a consumer

Lunch

chaals: 75 minutes for lunch
... be back here, 1:30 Central European Standard Time

MikeSmith: will the room be locked?

chaals: MikeSmith will find out

MikeSmith: if people want to leave stuff, we can lock the room

<ArtB> ACTION: barstow work with Opera Websocket tester(s) on a Request for Review of their web socket tests [recorded in http://www.w3.org/2012/10/29-webapps-minutes.html#action08]

<trackbot> Created ACTION-671 - Work with Opera Websocket tester(s) on a Request for Review of their web socket tests [on Arthur Barstow - due 2012-11-05].

<kotakagi> s/Koichi Takagi/kotakagi/

<aizu> Present Hiroyuki_Aizu

chaals: it's getting on towards the 1:30pm start time

<sicking> supercalifragelisticexpialidocious

s/supercalifragelisticexpialidocious//

<smaug> shadows

s/shadows/

<ArtB> s/Present Hiroyuki_Aizu/Present+ Hiroyuki_Aizu/

<slightlyoff> OH HAI

chaals: anything else people want to talk about?

lmastiner: will you talk about URLs?

chaals: we're looking for an editor to rebrand annevk's work

s/mastiner/masinter/

lmasinter: i'm interested making sure the IETF specs are useful

chaals: good thing to do

IETF specs

chaals: where's the other mic?

lmasinter: there are 4 specs
... trying to describe what an IRI is
... there was a document for comparing IRIs
... a document for bidirectional IRIs
... combining LTR w/ RTL text
... and a document to update the URI scheme registration
... because people were confused about URI/IRI registration
... the IRI WG has been meeting for several years
... there'll be a meeting in Atlanta next week
... i'll be there
... i'm hoping if we'll get more test cases into the test suite
... we need to make sure the reality matches the right reality
... the specs are open
... there's a tracker with issues
... there's been about 60 issues
... there hasn't been much overlap between the people here and there
... i haven't seen substantive work taking place here
... we did commit to doing work
... i've been doing work with SDQ

<hsivonen> I have been lead to believe only Opera implements IDNA 2008. others implement 2003

lmasinter: on rfc 3987

<odinho_> WHATWG URL spec

lmasinter: http://tools.ietf.org/wg/iri/trac/report/1

alex_russell: Alex Russell, Google
... who's signed up to implementing this?

lmasinter: the people who are there are those who have sent email

chaals: while we have a URI spec in our WG
... i haven't seen anyone doing work on it

lmasinter: we put in 8 test cases, and all the browsers are different about how they behave

timeless: just filing the bugs is a first step

lmasinter: http://www.w3.org/wiki/UriTesting
... http://lists.w3.org/Archives/Public/uri/2012Oct/0007.html
... i've been trying to get Chris Weber to put his testcases into a form where people can run them

Introductions continued

tobie: Tobie Langel, Facebook, everything

amirabella: XXX

alex_russell: Alex Russell, Google

dgrogan_cloud: David Grogan, Google, IndexedDB

mjs: Maciej, Apple, most things

<slightlyoff> timeless: I'm Alex Russell for the record

bradee-oh: Bradee, Google, ibid

<bradee-oh> s/Bradee/Brady/

<bradee-oh> s/Google/Apple/

spoussa: Sakario Poussa

Jungkee: Jungkee Song, Samsung

IndexedDB

sicking: we've gotten a bunch of feedback
... we've got a lot of feedback
... we need to integrate the feedback
... and then update the spec to use WebIDL
... we have good scripts from darobin to do that
... i've been slacking
... either i need help, or i need to make it happen

chaals: who's doing impl?

sicking: chrome and firefox are more or less fully spec conformant
... ie10 is mostly there
... i don't know about opera

odinho_: pretty done

sicking: including blobs and array keypath?

odinho_: array keypath, yes
... blobs, some blobs

[ laughter ]

odinho_: it's being reviewed
... we need to figure out ordering
... exceptions
... we want to get it in pretty soonish
... blocked error

sicking: blocked vs. error

odinho_: having a blocked error vs. an onblocked event
... we wanted a simpler thing
... where the developer ...

sicking: we disagree

dgrogan_cloud: internally we talked about it
... we liked opera's proposal
... but since we already implemented
... we're ambivalent

sicking: there's the question of what microsoft wants
... there's also the question of exposing GC behavior
... the spec exposes some
... but if we do more, we may expose more GC
... the root cause is that there are GC effects
... i'm concerned about changing the spec given how implemented it is

dgrogan_cloud: i don't know if we want to discuss this further

adrianba: we don't want to change the behavior we've implemented
... we've shipped this
... we're building applications that depend on this
... the new version of exchange supports offline email using indexeddb

chaals: so we have legacy implementation
... such is life
... is opera's request just make work?

sicking: so far, no one has opposed adding opera's requested behavior in a new function
... i don't have a strong opinion
... but people will use the short named one with the bad behavior

odinho_: if it has a longer name it will be less frequently used
... i hope your exchange app doesn't need this
... if the browser asks the page to close the connection, it should probably close the connection
... it's a corner case

we tried arguing this for a while before

scribe: it's quite late for us as well
... we implemented the other thing, it was extremely quick to do
... the consensus is to keep the spec as is
... it's a corner case
... hopefully it won't hurt too much
... if it starts hurting, we'd fix it in bug fixing
... v2 features
... get database names

sicking: i think firefox is the only one w/o it

odinho_: we implemented it as we saw in the email
... since everyone is implementing this
... it'll be on the web platform in some form

sicking: we need to be able to figure out how to elevate new features
... if someone wants to work on extended functions in a v2
... for get database names
... i'd request it's a safe thing
... if you try to open it right away
... you're guaranteed to have it there with the version number you were told

odinho_: we did it super fast, so it probably doesn't do that

sicking: that was my requirement when we discussed it earlier
... ms came back and said it makes sense but didn't they could do it in time
... it's implementable, but non-trivial to implement

adrianba: the other thing is that we've been close to a long time
... but we should get this first spec finalized

sicking: i'm not interested in adding features for v1

odinho_: for some internal stuff, we need this
... since we need it, we're going to implement it

chaals: can we put it in an FPWD

sicking: i'm happy to put it in a draft if people are

chaals: sicking to write a v2 draft

odinho_: by next week

chaals: i heard by tomorrow

ArtB: v1 is in LC
... what's eliott's status?

adrianba: he's been pretty busy, but he's available

sicking: there's also exception ordering
... which could be a big chunk of work

ArtB: can i assume sicking and israel can help?

dgrogan_cloud: i don't think anyone from google has touched editing

ArtB: we can editors

dgrogan_cloud: those editors have moved on to other projects

odinho_: the bug about undefined handling sounds uncontroversiall

s/all/al/

scribe: treat undefined as missing

sicking: i think the behavior has been decided on
... webidl spec doesn't define the desired behavior
... treat-undefined-as-missing will be the default behavior

dgrogan_cloud: sounds like these are editorial things

chaals: there's issues
... but not complex/controversial

sicking: i think the only one is open()
... the exception issue is technical
... but it just needs to be defined

ArtB: can anyone from Apple/Safari comment?

bradee-oh: we have no comment

chaals: does anyone care about websql?

timeless: can you please bury it further than it's already buried?

chaals: i don't know where's it's buried
... so good.

[ Break until 2:45pm ]

Push APIs

<npdoty> if you're trying to call in, please let us know if you are hearing anything, and if not, ping me

bryan: we reached fpwd

<bryan> http://dvcs.w3.org/hg/push/raw-file/default/index.html

bryan: i'd suggest we do a quick run through
... hopefully many people have taken a look at this
... we originally presented this in 2009
... last year we proposed doing this in the web-apps recharter
... in the interim we worked on this outside w3c
... this puts together things that are possible today using different methods
... the focus of this api is on what happens between the application and its runtime
... practical implementations take into account the platform in which the application runs
... that includes browser/native os platforms
... or platforms from OMA/SMS/SIP
... whichever API is available/supported by the UA is supported through the API
... when we put out our CfC
... we only got a question from sicking
... we can take comments, or walk through the spec...

chaals: can we skip through rapidly?
... who implements?

sicking: for mozilla
... unfortunately, it isn't an easy answer
... there are patches to do the proposed api for gecko
... for Firefox OS
... (B2G)
... it was very recently decided that it wouldn't ship in the initial release of Firefox OS
... the api is implementable
... there's also an implementation of the server side infrastructure
... the reason we aren't putting in v1 is the set of reasons from my email
... we're not convinced it's the right solution
... we are going to start working on experimenting to see what we think is the right solution

chaals: you're interested in Push
... you want to make something work
... if we had the same spec w/ different content?

sicking: we're very interested in push
... but we want a good design

/me sicking "implementation" -> "design" ?

s| /me sicking "implementation" -> "design" ?||

ed: we're working w/ mozilla
... and are very interested

BO_HU_CHINA_UNICOM: we're interested
... we won't be precisely implementing it
... but we're supportive of this unified api
... there's a question of whether there's a broker
... in /above the browser
... and accessible by web apps

chaals: you don't implement your own browser

BO_HU_CHINA_UNICOM: no, we don't

chaals: some operators say to certain browsers "you will do this"
... and some produce enough content that browsers will do this

BO_HU_CHINA_UNICOM: we may have significant influence over Chinese browsers
... if every web application builds on their own channel
... that's something to avoid
... it will have negative impact on devices and networks

pbakaus: we're interested in this
... we want to push messages to the client
... in our games

bryan: we believe there is a lot of interest in the concept
... it isn't possible today to do this outside an app by app connection, or a shared worker
... how things are done is less of a concern than that they are done

sicking: this draft is a lot closer to the right api
... than anything else that's been discussed in this space
... i'd love to hear from apple and google
... i'll note that a lot of companies have experience
... is apple interested in push for the web?

mjs: i think we'll need to wait for our legal department's review of this FPWD
... from a technical review, i haven't read/considered this spec
... your review has the concerns i'd want to express
... scalability and authentication are what i'd worry about

sicking: can we get the people w/ experience to comment?

mjs: probably not possible to get them to comment directly
... they aren't involved in standards
... but i can probably get them to look at it and forward comments
... the way apple addressed this
... is that apple devices only trust apple servers

and apple forces app authors to create certificates which we trust

scribe: i don't know of a way to avoid spam

sicking: i think this spec requires the device to trust the push server
... but not the push server to trust the device

rafaelw: i think we're interested

<Zakim> timeless, you wanted to note that MS announced it had for Skype in wp8

<ArtB> ACTION: rafael provide feedback on Push API [recorded in http://www.w3.org/2012/10/29-webapps-minutes.html#action09]

<trackbot> Created ACTION-672 - Provide feedback on Push API [on Rafael Weinstein - due 2012-11-05].

adrianba_: so
... right now, Microsoft's experience / position is similar to mjs's outline of Apple's
... notifications are built on top of windows live notifications
... that messenger has provided
... we have a generic notification system
... operated by microsoft for WP
... it's tied in to the services provided by microsoft

chaals: does Opera have any position?

jgraham: i know nothing

ArtB: quick question, probably to bryan and ed
... in section 9

<efullea> it is efullea, not ed

ArtB: are there issues w/ w3 having normative references to OMA / similar specs?

bryan: i'm not aware of any
... establishing an api to connect to something supported by the device
... shouldn't be an issue

chaals: tizen?

Wonsuk: Wonsuk, Samsung
... for Tizen
... i think it's a core feature for a lot of mobile apps including Games/apps
... Samsung has its own service for this

chaals: so, everyone has a push system
... everyone who has one doesn't need a standard
... everyone who doesn't have a system want a standard

bryan: in 80% of phones worldwide, push is supported

<chaals> scribe: chaals

<npdoty> 30 minutes for coffee starting now, unless you want to talk about Push API details, in which case stick around

timeless: "this" example is requesting permission. How does the server side discover where it wants to talk to?

… does the platform get called to the URI?

… eg, zynga has an app on a phone, apple runs the network. I open the phone, how does the zynga app register to the cloud, so the zynga server knows where to send the push notification?

Bryan: There is a URL that the push service provides for the app to register and invoke the operation.

… It's the service URL in the activate variable (we are in example 1)

… it is passed up to the application, to kbow where to invoke messages and what protocols are supported.

… There are a variety of ways it could be done - people have worked on this for a dozen years or more.

Bryan. It is intended to describe the context of how push can work

… show use cases like RTC, activity getting woken, multiple instances of apps, etc.

… THings that folow from the use cases we proposed early on.

… Security/Privacy section was filled in on request - this is fairly boilerplate text copied from DAP.

<timeless> timeless: fwiw, "&serverProtocols="+mypush.serverProtocols; should probably have an encode method, otherwise it's asking for pain :)

… referenced Jonas' comments

… So those are noted open questions for further discussion.

… Framework section gives a general explanation, but main bit is between the app and the user agent. There are some artifacts coming from the way permission is arranged.

… for registration. Challenge we have seen in current push systems is developers lacking a way to globally implement a push-based app.

… We're not presuming to establish one protocol for everyone, but to enable the app to discover what services are available in a given context.

… We have pretty much taken the suggestions from Jonas on attributes for the interface. They facilitate some of the questions about keys, etc. We need to get into detail about how this addresses security, etc. Otherwise it is similar to server sent events in design - type of events, ready state, etc.

… There is a section on service bindings. Based on work done outside W3C and what might work well in W3C context. We left stuff out to simplify, eg headers (compared to OMA)

… Same for SMS - no headers...

<ArtB> Scribe+ ArtB

Shadow DOM

<timeless> scribe: timeless

<ArtB> DG: [provides some history of the spec ...]

dglazkov: custom dom elements
... i started writing as a response to
... the needs from the mozilla folks
... who started implementing some of these things
... i felt i needed to start capturing requirements
... this spec is in the very early stages at this point
... for when people ask "how does this work"
... the shadow dom spec is in really good shape
... someone said "no plan survives contact with the enemy"
... in this case, the enemy is the users
... we discover that we haven't thought about this/we haven't thought about that
... the other thing that can happen
... we tried to work w/ CSS WG a bit more
... there's a lot of concepts that bleed over from shadow dom into css
... currently some things are hard coded in shadow dom
... but i want to redefine it in terms of displayed content
... which will enable the text to disappear
... i'm going to let rafaelw cover html templates

rafaelw: html templates is a collaboration between google and microsoft
... tross
... the <template> element is from the web components effort

<morrita> s/displayed content/display: content/

rafaelw: web applications need a way to declare a fragment of dom that isn't in use when the fragment loads
... but is used later
... this is important for declarative declaration of components

<adrianba> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html

rafaelw: for declaring shadow dom
... we're pretty close to FPWD
... a majority of the work is going into validating the parser changes
... there was a discussion about contextless parsing, or implied parsing
... there was a consensus about implied parsing
... the parser wouldn't have an explict context element
... it would choose it
... there seemed to be no dissent to doing this
... but there was an objection to an explicit api (document.parse)
... the parser changes encapsulated changes are managed by the <template> element
... changing the parser itself may be controversial
... i'm not sure if people have questions about the <template> element
... there are two ideas
... one is accommodating this type of content
... the other is the concept of the content being inert
... the parser takes the content and makes it a document fragment
... hsivonen here?

hsivonen: yes

rafaelw: i know you had concerns

hsivonen: this is such a radical thing to do
... it's radically unusual to do this sort of thing
... where the markup and data structure no longer have the correspondence the DOM was designed to have
... DOM was designed to have an AST
... for XHTML
... we're breaking that
... not that i care about XHTML per se

mjs: how important is it to the goals of the <template> element
... is it to retain inline markup
... it seems like the template could have a src= attribute, or a srcdoc= attribute

rafaelw: it's our opinion that it's worth doing
... we could imagine a future src= attribute
... srcdoc= is the more relevant proposal
... that was brought up on the mailing list including CDATA
... none of those proposals offer a good combination of developer ergonomics
... recursively defined components
... a component that uses a templating mechanism

<hsivonen> I want the above-parser impl to be the same for HTML and XHTML

rafaelw: it's my feeling that it's worth doing

Travis: standing in for tross
... i think our position is we don't care either way

<adrianba> s/tross/tross/

mjs: src[doc] solves the inert document question
... it's much easier to make a compatible polyfill model using js with src[doc]
... you're creating a huge hazard for developers
... it's much easier to backfill this with js if you use src[doc]

<annevk> s/src[doc]/srcdoc=""/

slightlyoff: it's possible to use display:none
... and have rules about not having side-effect code
... there's a thing TemplateXZ which does this
... we don't need to preclude one by agreeing that the other is a good idea

s/+ alex_russell/+ alex_russell_(slightlyoff)/

hsivonen: for 2d / webgl, for perf reasons, people move to webgl
... for polyfill it isn't clear that the benefits outweigh the hacky thing
... people would rather use some new thing
... rather than something that works w/ ie10 w/in its support peroid

s/oid/iod/

chaals: i get nervous about "new-that-breaks-backwards-compat"

slightlyoff: i'm not slightly sympathetic to that view
... it's microsoft's job to get their users off the old browsers
... we have library authors who are adamant that this is what they want
... document fragments don't do it
... EmberJS

s/EmberJS/Ember.js/

pbakaus: i tend to agree
... perf characteristics should also be considered
... if not making it backwards compat gives a big win
... it's worth it

chaals: yandex has no sympathy with your view that people should force users to upgrade
... we ship content to most of russia
... and those users don't upgrade
... it costs us a boat-load when people change things
... if there's a way to avoid that
... and from a development perspective, it provides the functionality
... then there's no question about which is right, and which is insane
... we all want every browser user to upgrade
... but they don't
... it costs us boatloads to assume they do

mjs: developer ergonomics has been cited as an important reason for this
... for components, it's assumed that components will be reusable
... is it really assumed that they'll be included inline
... instead of at a shared place
... rafaelw said we will have to break compatibility
... we might as do it now
... what's that

dglazkov: i'll answer

<hsivonen> why aren't templates loaded via XHR?

dglazkov: the compat concern
... is really serious and valuable
... the whole issue comes down to
... compatibility
... and making sure you can provide this content to old browsers as well
... and polyfill it
... you can develop a feature
... but this template feature
... srcdoc has bad regonomics
... how do we balance this
... mjs asked about reusable components
... but if for every definition of components, i need to fetch some other file that defines this component, that's terrible
... sure you should be able to split them up
... but that shouldn't be the only way
... compatibility seems to be a bug-a-bear
... what is actually going to break
... and what can we say "this is ok"
... as someone who wrote a polyfill for templates in web components

rafaelw: i didn't mean to imply that we need to break compat

dglazkov: i'm sorry i can't see your faces
... chaals you asked a philosophical question

[ scribe didn't minute it ]

<npdoty> rafaelw: I didn't have some specific criterion/condition for why we would should break compatibility at this point in time

dglazkov: if we're breaking something, how badly are we breaking it

rafaelw: aside from static documents
... most apps hide templates with some hack
... comments, text fields, ...
... we're not going to make life any better

<hallvord> ... script tags ...

rafaelw: i don't think srcdoc is better than existing hacks
... using <script> is better than that
... pages keep content hidden, squirreled away somehow
... composing documents w/ innerHTML/script
... i don't think it should be controversial that there's an established need for something better than we have now
... it's my opinion that we've settled on something
... it does need something
... parser changes

chaals: there's no disagreement that we need the functionality
... the question is how we get it
... is there anyone who says "we don't need <template>ing"

[ no one ]

hallvord: re: breaking back-compat
... what's the oldest computer in your circle of family/friends
... when we should develop the web
... we should accommodate them

slightlyoff: there are semantics we need to put into the platform
... are there semantics we need to put into the browser
... we can auto update those browsers

morrita: why can't we extend

chaals: we all accept we need <template>ing

hsivonen: srcdoc= erognomics are bad
... and pages use <script>template-inline-here</script>
... we have XHR
... which works in all browsers
... why don't we specify templates be external resources loaded via xhr
... considering we want script/css in external files
... for paving a cowpath, it seems people want to put this inline
... why don't we want to use XHR for this?

rafaelw: that has a terrible perf profile
... production web sites go to great lengths not to break up pages

<pbakaus> I agree with rafaelw

rafaelw: it's important to use inline declared content
... it's a non starter to say all content is remotely sourced

chaals: i buy the perf argument
... the dev ergonomics argument is harder
... the yandex BEM library
... (used by our biggest competitor as well)
... sources things externally
... if we started out by bringing templates in w/ srcdoc
... and we then said "it'd be really cool if we could drop this in line"
... could we get consensus sooner

<Zakim> mjs, you wanted to ask, if you can polyfill fine now, why do we need a new feature for inert dom?

mjs: that needs to be a huge win given the acknowledged high cost
... what are the downsides of <Script type=non-standard>
... we could make <script type=standard>

<Zakim> timeless, you wanted to ask about HTTP2

<chaals> timeless: Developers void splitting content to save load time. If we had HTTP2 that solved that issue, would it be better.

pbakaus: we can't live with a solution that requires XHR
... the games we're building require complete inlining
... to the extent of a single request
... on mobile

sicking: it seems provable that people can use external
... but they use inline hacks

<darobin> +1 to jonas

sicking: we might as well not do anything at all if that's the solution we're advocating

jaubourg: it seems like a tooling issue
... consider <script>
... you have tools to handle dependencies
... in development you can external resources
... in production you inline scripts to a single file
... if you had a tool that could do the concatentation
... if you had a script to fetch external/do inline

rafaelw: if we had HTTP2, would that address the external resource latency issue
... i'm not sure the status of HTTP2
... if external latency wasn't a problem, then would it not be a problem

mjs: what's the problem w/ <script type=random-mime-type>

rafaelw: script tokenization stops when it sees </script>
... which means you can't have recursive templates
... to embed a <script> in your template
... they break the script into two tokens
... hitting </script> in the script token ends the script token

mjs: with some small amount of escaping, you could address that

timeless: we have today <\/script>

rafaelw: you're asking if we can stick with what we have
... slightlyoff mentioned it's painful

mjs: is the pain-point lack of built in

<slightlyoff> ...and the frameworks vendors agree

mjs: or is it the escaping
... i believe that having to roll their own templating
... reguardless of the syntax

<chaals> ?

mjs: but if we had a defined script type
... would just the need to escape </script> be such a pain point?
... i'm skeptical

rafaelw: my sense is it's pretty painful
... i'd let yehuda katz and mishko (angular) speak for themselves

<Zakim> timeless, you wanted to ask about <script> v. <script src>

<slightlyoff> Lachy: wait, what?

<slightlyoff> are you actually kidding?

<slightlyoff> I think you're trolling

timeless: <script> was inline first

<Lachy> slightlyoff, no. It's one little extra character that authors would have to type. How is it hard? It's already needed when doing things like document.write("<script …><\/script>");

timeless: and <script src> was added later
... but i think that 80-95% is now <script src>

<MikeSmith> s/mishko/Miško Hevery/

dglazkov: pending a polyfill for feature

<mjs> SimonPieters: you could probably design it so only a single level of escaping is needed regardless of nesting

<annevk> <\/script> is shorter than </template> :p

dglazkov: angular/Ember.js
... they have a specific UC

<slightlyoff> timeless: I think you're also wrong about this. Most script tags are ads, and they tend to marry inline/out-of-band <script> elements = )

dglazkov: it's hard to do one that's universal

<ericu> artb I'm about to call in.

dglazkov: polyfills are never 100% faithful

<mjs> SimonPieters: the escaping is only needed to be compatible with legacy <script> parsing, not fundamentally for a hypothetical <script type=template>

dglazkov: we have views of breaking compat as the general
... i know rafaelw studied this and there's very little that actually changes
... most still works

<ericu> artb, I can hear you now.

<annevk> mjs: change end tag parsing based on an attribute value? o_O

dglazkov: throw someone if they suggest XHR agian

s/agian/again/

scribe: we could solve everything with escaping

<mjs> annevk: not sure how that follows?

scribe: but people don't always remember to escape

<pbakaus> +1

<aklein> mjs: I think annevk is asking how the parser finds the end-tag in <script type=template> parsing

<mjs> annevk: <script type=template><script type=template><script type=template><\/script><\/script></script>

chaals: calling you on this, it's a sales pitch

<annevk> mjs: right that uses the escaping

<mjs> annevk: nothing about that needs to change existing parsing based on an attribute

hsivonen: people who write libraries

<mjs> annevk: yeah but you don't need to double-escape the innermost one

<mjs> annevk: that

hsivonen: if this feature was available

<annevk> mjs: oh

<mjs> that is all I meant

hsivonen: would they stop using <script>?

<annevk> k

hsivonen: i have the bad feeling that balancing the new feature / availability
... the compat tends to win over inconvenience
... do we believe that yehuda/ Miško would break compat

sicking: re: HTTP2, it only solves additional overhead
... for requests

<mjs> sicking, it can solve extra round trip latency b/c it lets the server push resources it thinks are needed

<slightlyoff> hsivonen: this is absolutely the wrong question. Holding a feature that can help the future out to the idea that some vendor will adopt it *immediately* is standards judo of the worst sort.

pbakaus: almost everything can be solved in terms of tooling

<morrita> maybe <template> could be just an alias of <script> to avoid escaping?

pbakaus: building tools is extremely hard
... we did it

<slightlyoff> making the world safe for new features need not be held up by current practice

pbakaus: but not everyone can
... we want standards everyone can use

chaals: spend some time tonight w/ beer to talk about this w/ someone who doesn't agree
... the market will determine what's used

<jaubourg> pbakaus: I was talking about tooling to transform tags that link to external resources into a tag with content inline. I know <template> is needed. I was just telling that people are inlining right now because tooling is hard, liike you said

<sicking> mjs: the server needs to know about it to solve the roundtrip issue. I think it's also the case that the way it works is that the server can "pre recommend" that the client downloads a resource, but the client stil has to request it. But I'm not sure that that works

timeless: i'm pretty sure that the server can actually send the resource too instead of just recommending it

File * APIs

ericu: about the file system api

<mjs> sicking, I suppose it could change but I don't believe that's how it works in the current SPDY protocol http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3#TOC-3.3-Server-Push-Transactions

ericu: there's been discussion about note tracking it
... two questions
... is there a quorum of browser vendors likely to implement at all
... if not, then note track
... if so, we should keep talking
... if there's interest

<hallvord> slightlyoff: more features = more complexity, more features = less back-compat - this is always a tradeoff. So we need to look carefully at how much value new features provide.

ericu: should we move forward, throw away + start over w/ sicking / mjs's proposals
... or try to evolve current work to something near proposal

<slightlyoff> hallvord: I think that's just absolutely the wrong perspective: folks are building this stuff the hard, slow, expensive way

adrianba: we'll never say never
... but right now we don't see the file system api as a high priority
... we focused on indexeddb
... making sure you can store blob data there

<hsivonen> sicking: I believe SPDY allows a response before request, so the server could send *everything* over when the initial request has been made

adrianba: right now, making sure that's an adequate solution

timeless: what hsivonen said

ericu: could a file system api provide photos directory access?

adrianba: not from the browser

chaals: anyone want to speak in favor of it?

bryan: this is the file system directory apis?

<sicking> hsivonen: mjs: timeless: Ok, appears I was wrong and "full" server push is supported.

ericu: right, directory api + writer

bryan: writer w/o reading is useless
... browsers will need to be able to store hundreds of files and gb's of data

<hallvord> slightlyoff: you're saying we should never be asking "how hard now? / how much easier tomorrow?" for a new feature? You see no trade-offs to be made at all? ;-)

sicking: simple answer is indexeddb supports any amount/number of files

<adrianba> s/not from the browser/not from the browser, at least in the short term/

sicking: any file stored in indexeddb in firefox today
... is stored as an actual file

<slightlyoff> hallvord: trying to engagine you in PM but you're not responding there. Are you auth'd?

sicking: we haven't optimized for all cases yet, but that's something we'll work on
... i don't believe it's possible to evolve the current file system proposal from google into something like mjs/my proposal
... i like mjs's proposal
... it's possible to evolve that proposal
... mozilla's proposal supports doing small writes to files
... mjs asked if there's UCs for that
... we should provide use cases for that, i believe they exist
... there were other proposals which allowed incremental writing
... mozilla's proposal has atomic writing
... unix's doesn't have this
... ms got this right
... we don't have good locking mechanisms on the web
... i'd like something with the same capabilities as mozilla's
... but not tied to that api

mjs: my proposal supports incremental writing
... but it could be simplified if it wasn't needed
... interest in file system apis in general
... my own opinion
... not necessarily apple's
... we've added too damn many storage apis to the web platform
... i'd much prefer to see
... if there's a short list of features not available to indexeddb
... let's add them there
... if there's a reason that's impossible
... let's try to create something minimal

s/../.../

scribe: it's much easier to take something too simple and add
... than to subtract

<SimonPieters> I agree with mjs, FTR

pbakaus: we're fine w/ either approach

<chaals> ak pb

pbakaus: i can't w/ indexedb
... is local file protocol handlers
... to be able to use a file in <script src>/<style src>

ericu: i think most of what i had in mind is covered
... you can store large files in indexeddb
... chrome doesn't have blobs yet, but we will
... large mutable data in indexeddb isn't appropriate
... transactions on gb's of data is painful
... sicking has a proposal
... i don't see an efficient way to deal w/ large mutable blobs in indexeddb
... a file system api is the only proposal that addresses that

sicking: indexeddb doesn't support large mutable files
... i have a proposal for that -- not super clean, but it definitely works
... the other is file system protocol handler
... i haven't thought of a clean way to do it
... but it's technically possible
... something we can explore
... if we add this to indexeddb, it won't be super clean
... but it's something we can explore

mjs: externally referenceable blobs as a feature
... then we should put it into indexeddb

<bryan> If we have the ability to layer a virtual filesystem capability on IndexedDB via JavaScript, at least for non-mutable large blobs, at least that provides a means to develop implementations for the media gallery and offline content storage use cases, and would be a step in the right direction.

mjs: and large mutable blobs
... likewise

chaals: how many file system hands in webapps?
... darobin, pbakaus, jaubourg, spoussa
... maybe half a dozen people here
... eric, if you're prepared to keep editing, i'm not prepared to throw you on note

<slightlyoff> OH HAI arunranga

chaals: who's interested in the current file spec?
... ericu, do you want to vote?

<odinho_> s/OH HAI arunranga//

chaals: i'd like to work on sicking 's suggestions (locking), and possibly strip it down

<bryan> I would still prefer the File* APIs remain REC track until the IndexedDB alternative is proven feasible through testing of available implementations.

s/chaals/ericu/

pbakaus: i'd like to say...
... indexeddb or filesystem
... the abstract concept of working with files
... is good
... if we can do that in indexeddb as well, then i'm totally happy

<ericu> timeless, I talked about stripping down the current API towards the Mozilla proposal, not strip down Mozilla's.

chaals: it sounds like we should suggest that you make a file system spec
... should we drop the work item, and just do something on top of indexeddb

timeless: it seems like the simplest thing is a spec for making indexeddb referencable objects from uri's for use in script-src/style-src

sicking: it seems like the support can't be lower
... i'm not sure about the official cut off is

chaals: i'm not reading any support for the spec as is
... i'm not seeing any support for the spec as is

pbakaus: many people agree on the feature spec
... is it one spec that covers everything
... that covers db and stuff
... or multiple specs

chaals: i don't see the consensus to just stop work on that
... that'd be a thing via a CfC

mjs: one option is to tombstone the current draft
... and then give people the opportunity to offer a counter proposal
... which would probably be a delete and replace
... i'm not sure if ericu is willing to do that

ericu: obviously there's no support for the current draft
... i'm interested in iterating the current draft to what sicking is suggesting
... sounds like sicking isn't expecting me to iterate far enough close to his draft

sicking: it seems implausible that it can be iterated
... it seems better with a replace than a modify

bryan: with indexeddb as i could with filesystem
... would apps with different origins have access to the same indexeddb?

chaals: file systems can be shared
... maybe we should keep the idea alive?

jgraham: my view is similar to mjs's view
... we've invented a lot of storage apis
... so far they've been really bad
... let's work on the one we have that we haven't proven to be really bad
... before we spec a new one
... let's let authors build on top of indexeddb
... and let them build interfaces
... and see if we can steal their api/concepts

chaals: you're too late
... we have started specing file system apis
... we even specified them in the 70s

paulc: some of us are older than...

[ laughter ]

chaals: adding 47 apis just because we can

timeless: that's what sysapps is for

jgraham: it's about creating another legacy which is bad
... we've had 3 different proposals
... which have had varying levels of support
... unless there's something really compelling that we had to do yesterday
... i don't think there is

chaals: js libraries don't have access to the file system

jgraham: but they will make apis on top of indexeddb to pretend to be a file

timeless: i suspect we could see apps written using DnD support + indexeddb to emulate the file system

<bryan> does someone have links to any javascript-based indexedDB filesystems that anyone is currently playing with? If it's a good and feasible idea, then surely someone is trying to do it.

pbakaus: let's keep the feature set of the current file system

slightlyoff: we should stop iterating
... because we got it wrong last time

<bryan> i can't find anything on the web of a similar nature using indexeddb.

slightlyoff: seems like a bad argument

jgraham: that's not the argument i was making
... once we do something, it's fixed in stone
... it's very hard to change
... when a js library makes something
... it can make it look like a file
... and design things

<slightlyoff> timeless: that's not what I said

<slightlyoff> I said that we *shouldn't* stop iterating

<slightlyoff> also, I object that there is equivalence between what JS libraries will do with an API vs. exposing a new fundamental capability

chaals: how many people think we should keep working on the current file system api?

<slightlyoff> they're different orders or magnitude in change

[ 12 ]

chaals: how many people think we should ask ericu to stop working, and then wait for a new editor?

[ around 12 ]

chaals: ericu, you're welcome to keep working on this
... if we get someone to edit another proposal
... put the two up
... and ask the group to choose
... is that an outcome people would be happy with?

[ 15 ]

chaals: the number of people in the room change faster than the number of questions

shepazu: seems clear we want some sort of file system api

timeless: you could create a competing one for yourself

ArtB: arunranga is on the call

File Reader API

chaals: darobin was going to ship this in 2006

arunranga: fileapi is done
... but there's a question of auto-revoke
... auto-revoke of Blob URIs is a question
... there's a question where to put auto-revoke of Blob URIs with the HTML5 spec
... microtask checkpoints
... i think we're around the corner from it
... i think discussing it on the list makes sense

chaals: so there's one outstanding issue

arunranga: ms2ger wrote a nice test suite

ArtB: anyone want to add something to the test suite?

chaals: please?
... krisk just volunteered to add to the test suite

adrianba: i wanted to mention one other issue
... events that fire for file reader
... file reader is designed to be reusable
... you can call read() on an instance
... and then call again() on that instance
... assuming one isn't pending
... there's discussion on the list about which events to fire

<jgraham> We might have more tests

adrianba: if you call read() during load/XXZ
... there's a question of what to do
... our proposal is to not fire load-end for the first() read if there's a second read() outstanding

arunranga: the last i remember of that discussion
... we set it up so you couldn't call read() multiple times
... it would throw an exception
... if that isn't resolved adequately...

adrianba: i thought that resolution was for if you tried to call read() while there's a second read()

timeless: is this read() triggers load... loadend, and there's a chance of calling read() after the last load fired but before loadend ?

pbakaus: maybe we could discuss archive reader tomorrow?

chaals: toss it on the agenda wiki
... thank you very much
... thanks to timeless for scribing

[ applause ]

<ericu> pbakaus I won't be on tomorrow, but any reason you can't do that in javascript?

chaals: we resume tomorrow @ 9 am

<pbakaus> uh – I think it's simply not fast

[ adjourned ]

<ericu> pbakaus try it and see if it's too slow, use that as a proof of utility?

trackbot end meeting

<pbakaus> ericu: to elaborate, a JS based solution is probably too slow for general purpose

s/trackbot end meeting//

trackbot, end meeting

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/present+ timeless/present+ Josh_Soref/
Succeeded: s/Scribe: Josh/Scribe: Josh_Soref/
Succeeded: s/XXX/Zynga/
Succeeded: s/YYY/everything that helps games/
Succeeded: s/AAA/jQuery Foundation, interested in the Web/
Succeeded: s/DDE/Wayne Carr/
Succeeded: s/HHH/morrita/
Succeeded: s/KKK/spieters/
Succeeded: s/Soon bo/Soonbo/
Succeeded: s/BBB/Adam Klein/
Succeeded: s/LLL: LLM, Opera/Lachlan Hunt, Opera, editor of Selectors API/
Succeeded: s/OOO/interest in most specs, but listens most carefully for IndexedDB atm/
Succeeded: s/Soonbo/Soonbo from LGE/
Succeeded: s/Amira Bella, CDE/Anthony Mirabella, Synacor/
FAILED: s/Amira Bella, CDE/Anthony Mirabella, Synacor/
Succeeded: s/SSU/Tomoyuki from KDDI, Japan/
Succeeded: s/Seltzter/Seltzer/
Succeeded: s/CDF/christine runnegar/
Succeeded: s/CDM/France Telecom/
Succeeded: s/CDG/Internet Society, Privacy Interest Group, Provenance WG/
Succeeded: s/SSS/Koichi Takagi/
Succeeded: s/SST/KDDI, Japan/
Succeeded: s/indexdb/indexeddb/
Succeeded: s/done/none/
Succeeded: s/Macie/Maciej/
Succeeded: s/ces/sed/
Succeeded: s/APIs/Spec/
Succeeded: i/XML/Topic: XHR
Succeeded: s/anne:/annevk:/g
Succeeded: s/https/-> https/
Succeeded: s/->//
Succeeded: s/urla nd/url and/
Succeeded: s/chance/change/
Succeeded: s/Soonbo from LGE han/Soonbo Han from LGE/
Succeeded: s/KKL/Simon Pieters/
Succeeded: s/talked about constructors/talked about event constructors/
Succeeded: s/Hi Jungkee, where are you in the room ?//
Succeeded: s/screen orientation in Firefox for B2G/screen orientation in Firefox for Android and B2G/
Succeeded: s/ime/im/
Succeeded: s/toppic/topic/
Succeeded: s/q//
FAILED: s/present +/present+ /
Succeeded: s/!/1/
FAILED: s/target()/:target pseudo-class/
Succeeded: s/y//
FAILED: s/prio/priori/
FAILED: s/IRC fragments/Web IDL fragments/
Succeeded: s/she/Kinuko/
FAILED: s/Koichi Takagi/kotakagi/
Succeeded: i/getting/Topic: IndexedDB
FAILED: s/supercalifragelisticexpialidocious//
FAILED: s/shadows//
FAILED: s/Present Hiroyuki_Aizu/Present+ Hiroyuki_Aizu/
FAILED: s/mastiner/masinter/
FAILED: s/Bradee/Brady/
FAILED: s/Google/Apple/
FAILED: s/all/al/
FAILED: s| /me sicking "implementation" -> "design" ?||
FAILED: s/displayed content/display: content/
FAILED: s/trossi/tross/
Succeeded: s/trossi/tross/g
FAILED: s/src[doc]/srcdoc=""/
FAILED: s/+ alex_russell/+ alex_russell_(slightlyoff)/
FAILED: s/oid/iod/
FAILED: s/EmberJS/Ember.js/
Succeeded: s/+q/q+/G
FAILED: s/mishko/Miško Hevery/
FAILED: s/agian/again/
FAILED: s/not from the browser/not from the browser, at least in the short term/
FAILED: s/../.../
FAILED: s/OH HAI arunranga//
FAILED: s/chaals/ericu/
FAILED: s/trackbot end meeting//
Found Scribe: Josh_Soref
Found ScribeNick: timeless
Found Scribe: chaals
Inferring ScribeNick: chaals
Found Scribe: timeless
Inferring ScribeNick: timeless
Scribes: Josh_Soref, chaals, timeless
ScribeNicks: timeless, chaals
Default Present: Rhone_3, Yves, +1.650.214.aaaa, +1.415.865.aabb, EricU, +1.415.294.aacc, arunranga
Present: Art_Barstow Josh_Soref Bryan_Sullivan Odin_Hoerthe_Omdal chaals Julian_Aubourg Adam_Klein jgraham zcorpan adrianba Soonbo_Han Wonsuk_Lee Jungkee_Song Charles_McCathie_Nevile Travis_Leithead Jonas_Sicking Olli_Pettay Simon_Pieters Maciej_Stachowiak Lachlan_Hunt Hallvord_Steen Kenji_Baheux Bo_Hu Bo_Chen Arnaud_Braud Doug_Schepers Eduardo_Fullea Kris_Krueger Lars_Erik_Bolstad Magnus_Olsson Mike_Smith Mounir_Lamouri Paul_Bakaus Philippe_Le_Hégaret Rafael_Weinstein Sakari_Poussa Virginie_GALINDO Wayne_Carr Yuan_Ji Erika_Doyle_Navara Christine_Runnegar Thomas_Roessler Paul_Cotton Steve_Holbrook Anne_van_Kesteren Norbert_Lindenberg Robin_Berjon Tobie_Langel David_Grogan Alex_Russell Brady_Eidson kris_krueger Larry_Masinter Ryan_Sleevi Koichi_Takagi
Agenda: http://www.w3.org/wiki/Webapps/TPAC2012Meeting
Found Date: 29 Oct 2012
Guessing minutes URL: http://www.w3.org/2012/10/29-webapps-minutes.html
People with action items: barstow charles jong-heun lee rafael travis with work