See also: IRC log
<ArtB> Date: 29 October 2012
<ArtB> Scribe: Josh_Soref
<ArtB> ScribeNick: timeless
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
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
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
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 ]
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
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
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
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 ]
<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
<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 ]
<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
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
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
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
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
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 ]
<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
<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
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
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[End of scribe.perl diagnostic output]