W3C

- DRAFT -

Web Applications Working Group Teleconference

27 Oct 2014

Agenda

See also: IRC log

Attendees

Present
Art_Barstow, Yves_Lafon, Charles_Neville, Robin_Berjon, Jungkee_Song, Adrian_Bateman, Ryosuke_Niwa, Xiaoqian_wu, Ben, Peters, Natasha_Rooney, Marcos_Caceres, Sam_Ruby, Johannes, Hund, Wooglae_Kim, Kenneth_Christiansen, plh, Travis_Leithead, Johannes_Hund, Ali_Alabbas, Israel_Hilerio, Sakari_Poussa, Laszlo_Gombos, Hiroyuki_Aizu, Masataka_Yakura, Michael[tm]Smith, Bryan_Sullivan, cynthia_shelly, Dowan_Kim, Claes_Nilsson, David, Walp, Jonathan_Jeon, hober, Takeshi_Yoshino, Anssi_Kostiainen, Olli_Pettay, Makoto_Morise, timeless, waynecarr, Shijun_Sun, Alan_Iida, miterho, jeff, Joshua_Bell, Brian_Raymor, Alex_Russel, Mounir, Ben_Poulain, Sam_Weining, Norbert_Lindenberg, Kenji, Michael_van_Ouwerkerk, mnot, Michael_Cooper, Rick_Byers, Janina_Sajka, Richard_Schwerdtfeger, James_Craig, Katie_Haritos-Shea, Doug_Schepers, Robert_Sanderson, Frederick_Hirsch, Kristof_Csillag
Regrets
Chair
Art, Charles
Scribe
Art, Travis, timeless, chaals, schuki

Contents


<trackbot> Date: 27 October 2014

<ArtB> ScribeNick: ArtB

<scribe> Scribe: Art

CN:

Introductions

CN: everyone, please Present+ themselves as: Firstname_LastName
... before you speak, please say your name

zakime, who's here?

<tyoshino> i can hear someone speaking

<tyoshino> talking about agenda, yes

CN: Topic: agenda requests

CS: I have a proposal I'd like to talk about when IndieUI folks are here

AB: we can allocate time tomorrow Cindy

CS: ok

CN: any other topics

MS: URL spec

… want to have Larry Manister

SR: what about Dan?

AB: please tell Larry and Dan to be here at 10:00

PLH: TAG says 10:00 will not work for them today

CN: PLH, please figure out a good time for Tuesday

MS: are we having a SysApps joint meeting?

MC: Mounir will be here after lunch

… should wait for him

JS: tomorrow Wonsuk will be here

<scribe> ACTION: Marcos work with SysApps to find an agenda slot for Tuesday [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action01]

<trackbot> Error finding 'Marcos'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.

Spec Roll call

<Travis> scribe: Travis

Rundown of pubstatus

Pub-Status: Clipboard events

UNKNOWN_SPEAKER: hallvord has a few issues he wanted to deal with
... "strip dangerous content for paste"
... would be useful for email (to have a standard way to do this)
... allow beforepaste event; are there privacy concerns?
... chaals thinks 'no'
... This spec goes back a while... is this converging to an LC?
... anyone interested in committing to this?

rniwa: clarify the question?

(no volunteers to help in the room)

marcosc_: Not sure on mozilla stance... wondering if others are planning to implement?
... is Apple?

benjamp: Microsoft is.

rniwa: Apple is paying "close attention"

Pub-Status: DOM Level 3 Event

<ArtB> ScribeNick: ArtB

<darobin> Travis: for this we published an updated WD in September

TL: we published new D3E spec last month

<darobin> ... it is our intention to keep pushing this spec to the end of its day

<scribe> ScribeNick: darobin

Travis: we've tried to harmonise with DOM4, notably for events (definition, dispatch)
... we have a number of additional significant bugs to tackle
... notably defining the order of dispatch of events in relation to the task queue model
... a few more clarifications and a whole lot of cleanup
... it's looking, rough estimate, 6 months to another LC

marcosc: it wasn't clear to me last I looked at HTML, if it defines task queues

Travis: you can select from the queue you want
... if you put them in the same queue

chaa13: and this is like a legacy spec, right?

Travis: to a large extent, as we update it we are applying new spec patterns but it's arduous

marcosc: UI Events?

<ArtB> UI Events ED

Travis: it was the future of D3Ev, but as we continue to polish this one, we realised we needed to do some of those things now
... this is also part of the delay

marcosc: my confusion is that I keep finding the UI events and getting confused

plh: should we deprecate it?

Travis: that sounds good to me, it has very little if anything

chaa13: publish as empty Note, point to D3Ev

Travis: when D3Ev is done, where do the new events go?

marcosc: we can restart this

<ArtB> ACTION: barstow start CfC to publish UI Events as a "gutted" WG Note [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action02]

<trackbot> Created ACTION-734 - Start cfc to publish ui events as a "gutted" wg note [on Arthur Barstow - due 2014-11-03].

RESOLUTION: deprecate Topic: Pub-Status: UI Events as a deliverable and publish a gutted Note for it

ArtB: Topic: Pub-Status: DOM3 key specs

Travis: they go with D3E, should go to Rec at the same time?

ArtB: pubstatus says D3E still has tests in Mercurial, still the case?

<MikeSmith> smaug, can you hear us on the phone?

<smaug> yes

<scribe> ACTION: Travis to check that the D3E tests are in GH or Mercurial, and if needed fix [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action03]

<trackbot> Created ACTION-735 - Check that the d3e tests are in gh or mercurial, and if needed fix [on Travis Leithead - due 2014-11-03].

<smaug> MikeSmith: surprisingly well

ArtB: is Alex still available to work as a test facilitator

Travis: I don't believe he is, we should find a new facilitator

<smaug> MikeSmith: but I'm just listening in the background while doing other stuff

<MikeSmith> smaug, OK greatーthanks

<ArtB> ACTION: barstow work with Adrian to find a replacement TC for Alex and D3E [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action04]

<trackbot> Created ACTION-736 - Work with adrian to find a replacement tc for alex and d3e [on Arthur Barstow - due 2014-11-03].

Travis: Gary is interested in testing the spec further

Pub-Status: DOM-PS

ArtB: that was listed in potential topics, possible CR

Travis: I don't know that we have much that's controversial
... should we have a breakout

<ArtB> DOM P&S tests

Robin: are there bugs?

Travis: status is we have a CR, in June, contingent on TS
... the TS has yet to coalesce

chaa13: so we need tests

<ArtB> DOM P&S test open issues

Travis: Ms2ger had tests, some need porting, new ones are needed

ArtB: no test coordinator

Travis: I'm happy to be a facilitator

plh: what could help is if you can at some point write down the list of needed test
... that helps people pick things up

cindy: I'm happy to help, but I'll need your help to step in

Travis: that would help!

rniwa: do you have any sense on how consistent browsers are?

Travis: the spec largely follows an implementation that is pretty close to Gecko
... Chrome had serious issues serialising namespaced attributes
... but they indicated progress
... otherwise the basics are widely implemented
... we'll see how bad that is with testing

innerText

darobin: are you going to do anything with innerText?

Travis: there was opposition because it depends on rendering, but some thought it might be doable

<Domenic> someone speccing innerText would be amaaaazing

Travis: happy to include it if there's consensus, but otherwise would leave it alone
... maybe a new spec?

rniwa: Selection API also depends on innerText, it would be valuable to have a spec for that
... it's a lot of work, because it's hard, don't want to block DOM-PS

<Domenic> for the record, previous attempts (with tests apparently) at http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Feb/0025.html; use archive.org to follow the dead links.

Travis: heard a recommendation to start a new spec as part of the editing TF, we should pursue that, it's a good idea

chaa13: any takers?

Travis: if no volunteers, I can be the default

ben: how does it relate to textContent?

Travis: they both serialise text...
... innerText serialises "what you see on screen" text, textContent is pure object model
... let's get a new component in the bug DB for that

<scribe> scribenick: Travis

<ArtB> ACTION: barstow create a new bugzilla component for Inner Text [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action05]

<trackbot> Created ACTION-737 - Create a new bugzilla component for inner text [on Arthur Barstow - due 2014-11-03].

Pub-Status: FileAPI

chaals: Moving on to FileAPI
... oh, on the agenda already... skipping

Pub-Status: FullScreen

chaals: FullScreen
... calling tantek

<ArtB> Tantek's proposal re Fullscreen API

chaals: chaals says tantek says let the WHATWG do it. Anyone interested in publishing in W3C
... if no one moves it forward, it will likely be parked as a Note.

ArtB: In our charter, we don't make binding decisions in f2f meetings. We can take a poll here...
... any objecting to parking fullscreen?
... (no objections noted)

<ArtB> ACTION: barstow start a CfC to publish a "gutted" WG Note of the Fullscreen API [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action06]

<trackbot> Created ACTION-738 - Start a cfc to publish a "gutted" wg note of the fullscreen api [on Arthur Barstow - due 2014-11-03].

marcosc: can we redirect the parked specs to the active specs.

plh: If the spec is going to be parked, we need to update the TR

chaals: Status information is important, the redirect will be noted in the doc.

marcosc: can we tell Google not to index it?

Pub-Status: Gamepad

chaals: Gamepad.
... is anyone following? I see discussion going on...
... OK.

IndexedDB

Pub-Status: IndexedDB

sicking: I'm not sure what's blocking; implementation seem interoperable

<smaug> Fixing https://github.com/w3c/web-platform-tests/issues/1304 would give quite some more green in IDB tests

ArtB: looking at the implementation report...

<myakura> http://w3c.github.io/test-results/IndexedDB/less-than-2.html

IndexedDB + Web IDL

<ArtB> IDB interfaces Web IDL

darobin: Note the "interfaces.html" (WebIDL interfaces)
... Those are WebIDL related problems, not necessarily IndexedDB...
... if you opt those out, there aren't that many failures.

plh: for WebIDL we should ignore non-basic bindings...

marcosc: strongly object. We should fix the IDL...

<smaug> IDB webidl tests are buggy

sicking: why do we keep blocking IndexedDB on WebIDL failures

<smaug> not implementations

plh: truth is no one implements WebIDL correctly yet.

<smaug> in this case

plh: implementations have been trying to get WebIDL bindings correctly.

marcosc: if it affects authors, it's bad, otherwise OK.

chaals: If these failures are 'theoretical purity' issues, then we should just move on and fix those later.

joshua: should we followup with a review of the failures just to make sure?

chaals: If it doesn't cause real-world issues for users, then that's the use case.

ArtB: Straw poll: any objections based on result.

sicking: I'm not convinced (we were looking at the 'less-than-2' results...

plh: 37 tests failing out of 595.
... if you factor out WebIDL tests it's even better.

<ArtB> ACTION: barstow start a CfC to publish a Proposed Recommendation of IDB [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action07]

<trackbot> Created ACTION-739 - Start a cfc to publish a proposed recommendation of idb [on Arthur Barstow - due 2014-11-03].

chaals: Lots of support for moving it forward. Let's ship it!

ArtB: Anything else regarding IDB v2?

joshua: Just focusing on service worker (SW), digesting feedback around using Promises. No progress to report.

Pub-Status: IME

<xiaoqian> Travis: MS is considering to implement IME API @@...spec is relatively stable.

MikeSmith: Looking for another test facilitator... please?
... any other implementation interest?

hober: Goal to support script avoiding IME seems reasonable
... I worry assumptions are based on current IMEs
... not sure what the future holds.
... scope is reduced; think it looks better than before.

rniwa: Apple is interested in improving editing; it important to look at how IME API fits into the overall system.
... we don't want to be introducing lots of ways to do the same thing.

chaals: We definitely don't want to introduce conflicts.

<ArtB> ACTION: barstow issue a Call for Test Facilitator for IME spec [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action08]

<trackbot> Created ACTION-740 - Issue a call for test facilitator for ime spec [on Arthur Barstow - due 2014-11-03].

MikeSmith: Jonas/Marcos, any help?

sicking: I know what it is; don't know any plans.

chaals: Yandex has an interest; we build IMEs; but don't have anyone to offer.

ishida: to what extent is this JP vs JP & CN?

MikeSmith: Not to go too deep--but main use case is to avoid IME overlaps with web-based suggestions.
... biggest problem is occlusion/overlap; that's the primary scenario driving the spec.

ishida: main users will be JP/CN. Anyone from those communities interested in moving this forward?

chaals: Status: it's moving forward slowly

rniwa: We should try to get someone from KO/CN/JP interest groups to help (vs. folks who've never used them before)

<ArtB> ACTION: charles ask cjk interest group and others about IME (use cases, tests, etc.) [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action09]

<trackbot> Created ACTION-741 - Ask cjk interest group and others about ime (use cases, tests, etc.) [on Charles McCathie Nevile - due 2014-11-03].

cindy: tencent/baidu can help (from China)

Pub-Status: PointerLock

ArtB: No status report from Vincent Scheib
... there is a link to test suite, but only has WebIDL templates...

chaals: Anyone know anything more on status.

Pub-Status: Quota Management

chaals: Quota Management?

ArtB: Kinuko sent mail
... status is "not very active". Anyone interested in helping push this forward?
... not hearing anything.

chaals: Screen Orientation - on the agenda for tomorrow.
... so is Selection API

Pub-Status: Server-Sent Events

chaals: Server-Sent Events

ArtB: At one point, it looked like we were close to finishing, but with new tests, we seem to have more failures.
... rate looks like 13/124 failures.

darobin: Looks like there are some major timeout failures.
... timeout could be a test failure, but we don't know for sure.
... I'm also interested in taking feedback on the implementation report--send me bugs.

<ArtB> ACTION: barstow re SSE test results, followup on the Timeouts with the 2 test facilitators [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action10]

<trackbot> Created ACTION-742 - Re sse test results, followup on the timeouts with the 2 test facilitators [on Arthur Barstow - due 2014-11-03].

chaals: Service Workers
... Streams API on the agenda already
... URL

ArtB: Yes, this is on the agenda, combined with Push API
... is on the agenda

Pub-Status: WebIDL

<sam2> quit

Yves: Had one bug to fix on integrating the test suite...

MikeSmith: Boris/Cameron not working on this (don't have time)
... we want to move this ahead.

<ArtB> ACTION: yves, follow with Cameron re PR 271 and the Web IDL test suite [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action11]

<trackbot> Error finding 'yves,'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.

Yves: With no reply, I will probably do this myself.

marcosc: we need a better plan. Cameron is not moving it forward; who can do that.

sicking: Cameron _is_ moving it forward, just not as fast as we want.
... features are being added from use cases in other specs.

marcosc: We need a proper plan, we have a devision between v1 and v2.
... we keep fixing features and adding features. It's continuing to evolve.

chaals: Are you volunteering to publish a v1?

Yves: Yes, of course.

chaals: Straw Poll: shall we try to publish a V1?

marcosc: I think we risk fragmentation.

Yves: It's documenting what's pretty stable. We have tests, etc.
... we are mostly adding things, not modifying things

<Domenic> -1 on v1. Disagree that things are only being added.

marcosc: we've been talking about the v1/v2 thing for awhile... if Yves can't get it done, we should kill it.

<MikeSmith> 107 open WebIDL bugs

chaals: Any other concerns (from non marcosc)

MikeSmith: I think the level of effort is high.
... there are 107 bugs... we could use some extra help.

<ArtB> ACTION: yves, work on moving Web IDL v1 to REC [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action12]

<trackbot> Error finding 'yves,'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.

<Domenic> I am concerned that people will look at v1 and view it as authoritative, when v2 is much more up to date.

chaals: Anyone here want to help finish WebIDL v1?

<ArtB> ACTION: charles try to find someone to help Yves, Cam and Boris on Web IDL v1 [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action13]

<trackbot> Created ACTION-743 - Try to find someone to help yves, cam and boris on web idl v1 [on Charles McCathie Nevile - due 2014-11-03].

Yves: This will help with the "how do we reference WebIDL question'

chaals: Web Messaging

<MikeSmith> ACTION: Yves to work on moving Web IDL v1 to REC [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action14]

<trackbot> Created ACTION-744 - Work on moving web idl v1 to rec [on Yves Lafon - due 2014-11-03].

ArtB: KrisK from Microsoft was going to provide some updated data.
... is Kris available to work on this?

adrianba: I will check with Kris

ArtB: Same story for Web Sockets
... Workers
... Simon is test facilitator
... He noted a few bugs, but claims the test suite is relatively complete

<ArtB> ACTION: adrian determine Kris' availability to work on the Web Messaging and Web Sockets implemenation reports [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action15]

<trackbot> 'adrian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., abateman2, ayanes).

<ArtB> ACTION: barstow followup with Simon re running the Web Workers tests [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action16]

<trackbot> Created ACTION-745 - Followup with simon re running the web workers tests [on Arthur Barstow - due 2014-11-03].

chaals: XHR is on the agenda...

Pub-Status: Web Components

<MikeSmith> ACTION: abateman2 to determine Kris' availability to work on the Web Messaging and Web Sockets implemenation reports [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action17]

<trackbot> Created ACTION-746 - Determine kris' availability to work on the web messaging and web sockets implemenation reports [on Adrian Bateman - due 2014-11-03].

ArtB: Now showing Dmitri's status report on custom elements...

rniwa: For custom elements, the lifecycle methods are defined pretty vague. I believe this needs to be more well-defined.

<ArtB> Custom Elements status from Dimitri 2014-Oct-24

rniwa: "transitioning from script to user-agent code" not precise enough.

ArtB: One other thing: on April meeting we talked a lot about these three specs.

<Domenic> +1

<Domenic> annevk was looking into the transition from script to user-agent code thing at one point

ArtB: dimitri has sent out requests for feedback, but it looks like no one is showing that must interest?

sicking: in our experience, the spec is lacking and ambiguous; it's been hard to get things defined.
... we've tried to implement, but it's been hard/impossible.

<ArtB> HTML Imports status report from Hajime on 2014-Oct-24

sicking: I sadly have no specific examples, but it would be nice to address these issues.

<Domenic> callbacks/transition from user code bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579

rniwa: I don't have a lot of time to engage in tech conference all the time; I'm pretty busy. I prefer to stick to the mailing list to work async.

<ArtB> Shadow DOM status report from Hayato on 2014-Oct-23

chaals: Seems like folks want this and are waiting for it to be done.

sicking: Are the spec editors willing to have co-editors?

chaals: chairs may be willing to appoint co-editors.

ArtB: For resource commitments, folks can talk to us

rniwa: Given Mozilla is implementing, can we see some help from there.

(google) we're open to help (I work with dimitri)

chaals: Poll says lots of folks enthusiastically ready to see this tech delivered. More test cases, spec editing help appreciated.
... volunteer now!
... or when you want to :-)

<smaug> tantek: are you following the discussion?

<timeless> scribe: timeless

<scribe> scribenick: timeless

Rundown of pubstatus

chaals: This sums up the review of pubstatus.

[ Break until 11:00 ]

<MikeSmith> I am a fish

Streams

chaals: we recently published Streams
... Domenic, do you want to tell us where we're up to?

Domenic: yeah
... from the previous discussion, the idea was to split the work into separate efforts

<ArtB> Streams by WHATWG

Domenic: one for low level JS API
... and then on top of that, one for Blobs
... a lot of the work tyoshino and I have worked on

<ArtB> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm -> Streams API W3C Editor's Draft

Domenic: is going reallly well
... the public API is extremely stable at this point
... as we make these tweaks to external behavior
... we've been maintaining a testsuite and a polyfil
... i think coverage of testsuite against polyfil should be 80% or higher
... which i'm really happy about
... wrt the wider ecosystem
... there's been work to integrate with TCP/UDP Socket

<tyoshino> Polyfill

Domenic: Section Service Worker
... WebAudio
... tyoshino has been working on ByteStreams
... that's been going really well
... we merged that this morning, it's at first-draft status

<tyoshino> ByteStream

Domenic: the public api is unchanged

<ArtB> WHATWG Streams Open Issues

chaals: during the publishing discussion
... people said you have a mismatch between the spec and MSE

<Zakim> MikeSmith, you wanted to comment

Domenic: we talked w/ the MSE spec author
... the old direction wasn't good
... we're looking on being able to integrate MSE streams w/ other streams in the ecosystems
... kind of the point

chaals: anyone here from an MSE who wants to speak?

jdsmith: we're still trying to evaluate the changes necessary to implement streams w/ the new model
... it's a moderate amount of work
... we haven't made a determination of the technical merits

adrianba: i wonder if there's a little confusion between MSE streams
... and MediaStreams in MediaCapture
... it sounded like what Domenic spoke about was more applicable to MediaStreams

<adrianba> Media Source Extensions Status of This Document

adrianba: in MSE we have a note
... when we went to CR
... it was early in the work that Domenic was doing on the Stream API
... we took a dependency to a Stream Object
... a readable stream that could be read asynchronously
... i think that dependency should be to ReadableByteStream
... i don't think MSE has a big issue for integration

Domenic: i was talking with Aaron Colwell
... AppendStream
... could take readable stream with bytes
... we also want to expose a writeable stream
... the AppendStream pattern is a little specific to MSE
... but we also want to allow people to just write to a WritableStream

adrianba: that makes sense

Domenic: that shouldn't block MSE from advancing

ArtB: at one point, there was discussion, that Streams would move into TC39
... and become part of EcmaScript
... is that still the plan?
... do you have any update on it?

Domenic: as i've been working on it, i'm not sure
... it's JS
... it takes no dependencies on Web specific stuff
... on the other hand, EcmaScript is very small
... and this would be very big
... so I want to see what the committee says
... I'm sure this could ship in multiple environments, including Node.js
... not just theoretically, we (me) could get this shipping in Node.js

israelh: how does the fact that there's this portion of Stream APIs in WHAT WG
... how do we take a dependency on that?
... I understand W3 process to documents
... but this other dependency

chaals: there are 2 ways you can do it
... one, you can publish a version of the content @ W3C
... WHATWG says "we can have specs you can fork, but we don't want you to"

marcosc: we had a call with tyoshino and others
... the WHAT WG version would be an ED
... and we'd work with the W3 Process
... because we understood it was important for MSE
... plh put forward the proposal to have [WHATWG] EDs in TR
... particularly for Streams

Domenic: we had that call a while ago
... I agreed that if that's what it takes, that's what I'll do
... I'd like to investigate a way to reference directly
... if not, then we can just copy

plh: on ED, what we're doing for this is to have no human involved in propagating WDs
... I wouldn't want people to lose focus
... on Wednesday, we'll have W3C 20
... we're going to use a plugin to broadcast live
... we have users today who'd love to broadcast live using HTML5
... until we get Streams done, we can't do this without plugins
... can you get it done by Wednesday (and Deployed)?

<plh> plh: :)

chaals: W3C needs to get a document, or people need to figure out how to reference
... this is politics... including us

israelh: do we have an action item to do the copying?

Domenic: all commits are reference global by unique url
... you can reference a single version
... i'm willing to work with you guys on this process

chaals: my understanding is that we have an agreement to publish a W3C version from time to time

Domenic: i will not go back on that agreement, even though I like it less and less

chaals: anything more on streams?

ArtB: thanks Domenic

[ Break until 11:30 ]

s|-> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Streams API W3C Editor's Draft |ZZZ|

XHR

<ArtB> XHR1 ED

jungkees: we already discussed before the meeting
... speaking on behalf of the Editors
... we decided to publish a new version
... at W3C
... to have a stable version
... we will specify clearly that "this spec specifies features as of this date"
... "but that for future versions/features, you will have to use the WHATWG version"

<ArtB> XHR L2 ED

chaals: straw poll, do people think that's a crazy idea?
... publish XHR1-legacy spec
... and that there is no current plan to work on future versions of XHR in this WG

weinig: what's the value?

chaals: there's value to have a referenceable version
... like what Spanish governments use

<MikeSmith> Comments from bz on earlier proposed options

chaals: lots of people use this
... they use basic features of non bleeding edge technology
... including XHR
... quite important to consumers/market
... they say, can we please have a stable version of the spec
... W3C happens to be in a position to do that
... if you try to tell WebMasters working across Spain, they have real problems working within their legal requirements

weinig: if we don't do it, what would Spain do?

chaals: it depends on whereabouts you are
... some will go out and make stuff up
... a lot of places will just NOT USE XHR
... which is destructive
... because XHR is really valuable

<Zakim> MikeSmith, you wanted to ask if bz is on board with that plan

MikeSmith: it sounds like what you're planning to do is what bz thought was a good idea
... but it's good to confirm this is in line with what bz suggested

[ bz: If we want to publish something at all, I think this is the most ]

[ ... reasonable option, frankly. I have no strong opinions on whether this ]

[ ... is done REC-track or as a Note, I think, but I think such a document ]

[ ... would in fact be useful to have if it doesn't exist yet. ]

Yves: what's the current status?
... having only one document with errata?

jungkees: the current ED / latest public WD
... don't have the changes from the Fetch spec
... what we're trying to do is publish the legacy capabilities and features that the browsers implement
... saying that this spec defines those capabilities / features that browsers implement as of this date

Yves: do people want to add more things to XHR?

jungkees: that would be XHR.2
... we don't have an idea of what that is
... annevk is working on Fetch
... he pointed out several features as well
... there will be more changes as time goes by
... we aren't following that point
... what we're trying to do as of now is that there's a pointer to the future spec (outside W3)
... the editors haven't discussed a v2 plan
... forking Fetch wouldn't really work
... WHATWG is working on Fetch very actively

adrianba: XHR is a really old technology
... we (MS) shipped it a really long time ago
... I think there's a bunch of sites on the web that use it
... the Spanish people will use it once we get this done
... There are some issues w/ event ordering and other related things
... I think there's particular value in having a REC with IP commitments
... I'd like to see this done w/ minimum effort
... get the legacy thing written down
... don't worry too much about implementation differences
... I remember being here five years ago having the same discussion about the differences
... the web hasn't collapsed
... let's get this done

jungkees: we could publish as NOTE

[ NOTE does not get IP commitment ]

ArtB: I support publishing
... at some point, we published Level 2
... we should at a minimum move this to WG NOTE, gut it, and include a pointer to WHATWG
... if there's support for that, I'll make a CfC for it
... on L1, do you want to move it to REC?

jungkees: we thought it brings value to the industry
... but we'll follow the decision of the group

ArtB: the plan of record is to take L1 to REC

hallvors: on the future of XHR and Fetch
... annevk's plan is to merge XHR into Fetch
... going forward, there may not be an XHR spec at WHATWG
... just a Fetch spec
... I think we should just get rid of the level 2 draft
... and just refer to whatever annevk has developed

marcosc: i'd like to hear from the Editors what changes they expect to make
... and in what time frame
... let's move this to PR

<ArtB> ACTION: barstow start a CfC to gut XHR L2 and publish a WG Note [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action18]

<trackbot> Created ACTION-747 - Start a cfc to gut xhr l2 and publish a wg note [on Arthur Barstow - due 2014-11-03].

jungkees: the status of the document is WD
... we have a Test Suite
... we have ~80% test cases passing more than 2 implementations

chaals: if the Editors have a spec

<ArtB> XHR Test Results

chaals: and it's highly likely that people can put XHR in web sites
... and have it not fall over
... then we can take that argument to the Director
... and say that
... and that is how we'd get it out the door
... i'd like to return to the straw poll
... are there people who object to the proposal that we publish L1?

[ None ]

scribe: are there people who are in favor of the proposal that we publish L1?

[ A good number of hands ]

Yves: there are a couple of tests with failures
... due to implementation bugs
... it doesn't mean that the specification is failing
... they're bugs in the implementations

rniwa: are there inconsistencies between the XHR1 spec and the WHATWG spec?

jungkees: Fetch spec is more interested in the underlying details

chaals: are there behavior differences?

jungkees: annevk mentioned Service Worker
... but XHR2 doesn't cover that

rniwa: does the current XHR1 spec have inconsistent behaviors to the WHATWG XHR spec
... if someone implemented XHR1 perfectly and that was incompatible w/ WHATWG
... that would be bad

jungkees: WHATWG just has more features
... there wouldn't be inconsistencies to the legacy behavior

marcosc: i don't think anyone would implement just XHR1

chaals: people will use just XHR1

<Domenic> there are behavior differences

<Domenic> XHR1 does not go through service worker

<Domenic> WHATWG XHR goes through service worker

hallvors: it's important that we not specify in XHR1 things that are incompatible w/ WHATWG
... most of the differences are due to refactors
... moving things from XHR to Fetch
... I think we should do some extra reviews to make sure we don't have incompatibilities
... so that developers who implement to our spec won't have to change and change back

plh: I was going to say what I said to the CSS WG 8 years ago
... recommending a spec that isn't getting implemented isn't useful

<Domenic> earlier someone said publishing would be useful for developers. that is not true. tutorials are useful for developers, but a(n outdated) spec is not.

plh: unless the implementers will change their implementation
... we need to spec what's implemented
... no use in recommending a spec that isn't implemented
... we need tests and make sure it's implemented
... this is what we need to spec

chaals: introducing known incompatibilities is dumb
... there's a use in having things defined that work
... there's nothing wrong with saying "doing this would be kind of dumb"
... clarifying bits that would have trouble
... with a warning of where to look
... these are all good things
... including getting/giving IP commitments

adrianba: it may be that to follow the CSS model, we may need to add some ambiguity to the spec

[ laughter ]

adrianba: from the browser perspective, it isn't super important
... but to allow for developers to read this
... saying you should have things in a certain order
... if someone relies on this order, then that's a problem
... if we say "you should do it this way, but you can't rely on it this way"
... using those test results, we might want to codify those differences

chaals: you want us to describe the known unknowns

adrianba: but not the unknown unknowns

[ laughter ]

chaals: seems there's quite a lot of support for the plan of record
... a spec that's useful that people can use
... and publish it
... i suggest that a provisional resolution is that's what we do
... objections?

[ none ]

[ Lunch until 1:00 pm ]

<johnmellor-chrome> I'm one of the people on the phone

<ArtB> Push API Slides by Shijun

Introductions 2

alex: Alex Russel, Google

mounir: Mounir, Google

notbenjamin: Benjamin, Apple

weinig: Sam Weinig, Apple

norbert: Norbert Lindenberg, Invited Expert

kenji: Kenji, Google

Joshua_Bell: Joshua Bell, Google

lgombos: Lazlo Gombos, Samsung

johnmellor-chrome: John Mellor, Google

anssik: Anssi Kostiainen, Intel

<mounir> +Michael_van_Ouwerkerk

Michael_van_Ouwerkerk: Michael van Ouwerkerk, Google

Push API and Service Workers

Shijun: The slides are based on the mailing list
... We want to use Push

<inserted> Scenario analysis: RTC call with push message slides from Shijun

[ Slide 2 ]

Purpose

Make sure we understand the steps and options in the basic E2E flow

of Real-Time Communications (RTC) with push message, i.e. push an

“incoming call” notification to the user.

• Identify bottlenecks and open issues.

[ Slide 3 ]

Priorities

• Low latency

• High reliability

• High power efficiency

[ Slide 4 ]

< graphic >

Shijun: if you use Skype.com
... the user goes there, locks in
... we want the app to be able to register something for the user
... it isn't sensitive to realtime
... the user isn't making a call yet
... we need to set up something for the service worker

weinig: this proposal doesn't include the security model
... for insuring that you want that push?

Shijun: the security model isn't included in that yet
... I'm sure within the WG people here, there are people interested in Security/UI/...
... Here, we want to focus on Low latency, High reliability, High power efficiency

israelh: The assumption we're making is that
... by the time you're going to deliver these messages
... the handshakes and correct permissions have happened at this point
... handshakes with servers
... client registration has been done

weinig: doesn't that mean we should address them before?
... since they're pre-reqs

Shijun: we recognize that it's an issue
... but the focus for us is to understand the scenario when the user makes a call/receives a call
... we're not trying to ignore/dismiss the other topics

[ Slide The Scenario: RTC call with push message ]

Shijun: flows from app server to push server, push server to push client
... push client to UA
... -- that's specific to the device
... it's implementation specific
... the next step is UA to Service Worker

[ Slide -- #4. UA dispatch the message ]

• Current option

a. UA wakes up the service worker (SW) and dispatch the message to the SW

b. SW processes the message

c. SW displays a notification, and optionally renders a ringtone

d. Upon user click, SW launches the webapp

Shijun: that's our expectation -- the sound isn't defined, just an expectation

• Questions

1. Latency – How much latency between “UA receives the message” and “SW

displays a notification” to user?

2. Reliability – Can SW stay alive until user click? (issue #85)

3. Power Efficiency – Are long-living SWs a problem to the device? (issue #84)

Shijun: are we introducing latency beyond the network overhead
... pause here for comments

rniwa: without knowing details of the api
... keeping the SW alive doesn't seem possible
... i could have my pc at work alive for 48 hours
... and get 50 notifications
... there's no way i want 50 SWs running on my computer when i get back

slightlyoff: thanks for the detailed description of the process
... i think johnmellor-chrome will say the same
... SW is designed to be killable
... to get reliability back
... we'll pass a transparent structured data object to the SW
... the application sends data w/ the notification
... when the notification is clicked, the data can be returned to the SW
... this gives power efficiency and data availability

johnmellor-chrome: latency in Chrome/Nexus 5 is <750ms
... you receive a message in Java
... it wakes up the browser
... it wakes up a SW
... we think it's possible to optimize this a lot

sicking: we've found latency
... the most expensive piece is starting the relevant process
... starting a process to show a notification
... when the user clicks the notification
... we always need to start the related process
... that's the bottleneck
... -- in FirefoxOS
... it doesn't matter if we're starting a Worker or a UI
... when it comes to Phone calls
... vs. a Chat thing
... you don't want to just display a notification
... you often want a full screen thing
... you want a picture of the caller, and a yes / no button
... to display that, we need the full process

bryan_: i'm assuming the question about latency will resolve itself
... based on experience w/ testing
... i'm assuming SW will minimize startup time
... I assume a WebRTC app that you use for calling
... will need a long lived SW
... but we need to optimize this so the response to the incoming event is minimal
... the thing that receives the event could be a call app ui
... to the extent that this is dependent on browser technology

slightlyoff: your 8s window target
... -> shujin
... what does that include?

[ Slide #4-a. Alternative option ]

shujin: the end to end latency
... from server to device
... and coming back with confirmation
... 65% <1s
... for the app to launch the background process is pretty fast

sicking: we have System Messages, which are like SW
... we found that works really really well
... we have yet to find an instance where we need to keep an application running in the background
... we find additional events to wake the application
... if an app wants to poll, it can use a scheduler
... for online, we can use notices
... for incoming messages when the device is off
... we can have a startup message and deliver the messages
... we haven't found a case where we need long running background

slightlyoff: did you have 85/95% numbers?

shujin: no
... our experience isn't browser specific

[ Slide #4-a. Alternative option ]

• Proposal

a. The push client wakes up a lightweight independent background process and pass the message to

it

• The background process can be developed by browser implementers

• This process only handles push messages

• The push client automatically wakes up this process when needed

b. The background process parses the message property to identify predefined action(s)

• The process only executes a small set of predefined actions: display notification, play ringtone

• PushRegistraiton can be registered with the predefined action(s)

c. If predefined actions are identified, the background process displays a notification, and optionally

renders a preloaded ringtone

d. Upon user click, the background process launches the UA which in turn forwards the push

message to either a webapp or a SW

<MikeSmith> Scenario analysis: RTC call with push message slides from Shijun

shujin: the background process is an extension of the push client
... that's the solution we see, which could be more friendly for mobile devices

slightlyoff: what is the memory/cpu cost of the persistent background process?
... we've found we're middle of the pack for Chrome for push messages (cpu/memory)
... vs. gmail/facebook

shujin: i don't have the numbers handy, but i can give the numbers to the ML
... this is what is recommended to Windows apps
... for push message in Windows, >99% of the messages are processed by the background process
... IE is considered by Windows as an application
... and it should have a separate background process

sicking: i think that's the model that the spec is proposing
... except that, the background process is the SW
... i think what jake is proposing, is
... in what instances do you only want to display a notification/ringtone
... if you're playing a ringtone, you also want to render an onscreen ui
... if you're displaying something, you might want to download data

shujin: analogy, each website as an independent app
... from the User perspective, each website might want to tailor the experience
... but based on the ML discussion, there's a tradeoff between how long you can keep a SW alive
... and how much can be done in a SW
... what we're proposing
... IE has a special background SW

mt_: (Martin Thomson)
... what you're asking for is something faster than the XX ms
... i don't think this requires more than a lightweight process
... an SW spins up whatever is necessary to run the js in the SW
... a very lightweight process that handles the notification, handles it
... if that requires launching the rendering engine
... it invokes the API for that, to get that
... i don't see that's a problem
... I see an opportunity for the OS
... for the lightweight process to be able to handle the notification w/o starting a SW
... a message comes down, immediately rendered into the notification window
... maybe we can provide a way to say that certain messages can become a notification directly

slightlyoff: in SW, we note where we don't know what we don't know
... where app-cache failed
... we have this because we don't have a good track record of doing that
... i caution us to use data
... 750ms is the full time w/ Chrome + background process
... the entire world of optimizing is several quarters forward
... we think there's a huge ramp of opportunities
... i'd like us to prefer generality over specific cases
... if there's specific evidence for the relative weight
... if you have credible evidence
... i'd like to caution us on specifics w/o data

mounir: the push team at Google when we designed the Push API
... we thought about a specific API for notifications
... for the reason sicking noted
... a lot of sites will have different needs
... as noted earlier, we could make that optimization later
... offering faster
... unlike app-cache (not working)

israelh: maybe the paradigms that we're looking at
... from our perspective, we wanted a common paradigm
... we wanted very little you could customize
... maybe the various more powerful rendering experiences we didn't want
... we wanted a more cohesive experience
... our model is how we've been doing it since Windows 8 (3 years)
... we need to give you the specifics, i agree
... this subprocess we're describing is very specialized
... only for push
... we didn't need to enable more
... that we'll have the UA in control
... allow the SW that are instantiated to get the message

<mt_> I think that perhaps slightlyoff is casting this in the wrong light: SW *is* a lightweight process in a sense, but it just gets forced to be idle if it isn't dealing with an event

israelh: we aren't saying it isn't a good thing
... offering an intermediary that's sort of lightweight

mounir: with your process
... if i want to update my database
... say i have a tutor client
... i get a message
... i don't click on it
... i go offline
... the app can't save that?

israelh: there are different types of pushes
... some are raw data type
... which potentially push to the app running behind the scenes
... that gets the registered events

shujin: in our case, the push message is the raw format
... in comparison to the windows messages
... we're talking about letting the developers choose simple/lightweight or not
... giving the developer more power, from a different perspective

mounir: you're making an early assumption
... that developers get a push message, and show a notification
... many times the developer might get data, and show the notification later

shujin: i agree we shouldn't remove that from the developer
... if the message has enough information that the developer can do without predefined actions, that's still available
... when SW is run on different devices
... whether a SW can complete is another question
... whether to enable a rich experience, somehow we might not be able to guarantee

johnmellor-chrome: the standard thing is notifications
... when i look at a native app
... if an app is in the foreground, it usually won't show a notification
... some apps will only show notifications if you aren't looking at inbox
... some apps will download content
... gmail might get data
... but only show information if you've configured labels that match the data
... you could imagine location specific decisions

ddruta: i think it would be useful if the push could go to different UAs

shujin: the push client is an OS component
... apps can implement their own SWs

mt_: i think we're reaching the saturation point
... a lot of the pushback is around the optimizations MS made
... people aren't seeing strong justification for doing
... that's what I got from slightlyoff , that's what i got from johnmellor-chrome
... i think you should go back to the people at MS and ask why they put in the shortcuts
... something more generic would be useful here
... we could make this optimization available
... but there are costs involved
... with the api as structured

<chaals> scribe: chaals

<timeless> ... those costs are significant

timeless: They wanted to enforce a consistent UI. (Answering MT_)

… every time the user has a similar thing, in a different client, they want it to look the same. (This is what Shujin said)

… as a user, I support that goal.

<timeless> scribe: timeless

israelh: as you get a flurry of notifications
... the client can synthesize those
... it can buffer those notifications together
... I don't think we're saying that the model shouldn't support SW
... that isn't what we're saying
... what we're saying, what others are calling optimizations
... we'd like to see a mechanism where those optimizations are allowed, enabled, encouraged
... as opposed to no, it has to be this other way

mounir: could we keep that door open for a v2 api?
... as opposed to v1

israelh: we were under the impression that the Push API was still early enough
... that we could make those comments
... if we think we're at LC for Push

mounir: i don't think it's an API maturity
... i think it's a developer feedback issue

kenji: as the PM for the team implementing SW
... if you can provide developer feedback to explain why
... that's good feedback for us as well

shujin: would it be helpful if we could propose an API?
... put on the ML for discussion?
... and then discuss for current spec

sicking: one way to get implementation/developer feedback right now
... is looking at existing apps
... do existing apps
... where the only thing they do is play a ringer/display a notification
... we know twitter only displays a notification
... but when you click it, you might not see the tweet
... provide UCs

shujin: we can go back and collect the data

<Zakim> timeless, you wanted to point to BB10 apps

timeless: use case for blackberry is normal things, you can send push notifications, we had categories and common apps fit into these categories
... for most of these things it worked well
... some thing did drain battery, but most didn't

chaals: would people like to see an api?

[ a number of hands for yes ]

chaals: or would people like to see data?

sicking: i'd like to see data?

weinig: what data?

chaals: would people like to see UCs?

weinig: i would

israelh: a quick clarification on UCs
... how much more detailed on UCs do you want to see?
... for example Twitter, Facebook, Email client
... the UCs are fairly common
... what granularity are you looking for?

mounir: those UCs need to come w/ numbers
... if you show Email clients only show notification w/o fetching data

israelh: if you want only numbers
... perhaps i can give you just numbers
... these types of apps do these types of things
... our Store app shows notifications when it finishes updating/downloading
... shows notifications for new apps/updates available
... popular apps w/ this type of behavior

weinig: in terms of UCs, I think we heard a lot of UCs here
... it would be good if you came with a specific list
... and then to slightlyoff, indicate which UCs go with which patterns

israelh: we can work with that

chaals: we're done, thank you

bryan_: in the last month, there were a number of issues raised to github
... a number have reached consensus
... a number have engendered discussion

ArtB: we have a lot of holes in tomorrow's agenda
... if you want to use slots

bryan_: yeah

chaals: the 11-3pm overlaps with AC

<mt_> I'd like to get any decision on the agenda change promptly

<bryan_> I suggest we update the wiki with the "lightweight / low latency" use cases

weinig: is there a place where the workflow for clients can be seen?
... i looked at the slidedeck
... "client" = "web site author"

mounir: client registers for push, you get server+registration id
... developer sends that from client to its own server
... which then talks to the server w/ the registration id
... apple has its own push server

weinig: if a client wants to use push notifications
... they need separate agreements w/ each vendor?

[ YES ]

mounir: there's a separate discussion in IETF to standardize that

File API

<schuki> scribenick: schuki

<timeless> scribe: schuki

arunranga: file api can go to LC
... whenever the publishing moratorium is lifted
... we also want to talk about file system api

ArtB: i am displaying the bugs for file api
... we can go to LC with this
... does anyone have issues with this?

<ArtB> File API Bugs

sicking: if we mark file lists (as at risk) and remove later
... it's a matter of doing a pull request on the spec
... so we should just mark it at risk
... and then do the rest

<ArtB> ACTION: Arun mark file list as Feature @ Risk [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action19]

<trackbot> Created ACTION-748 - Mark file list as feature @ risk [on Arun Ranganathan - due 2014-11-03].

<ArtB> ACTION: barstow start a CfC to publish File API LCWD [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action20]

<trackbot> Created ACTION-749 - Start a cfc to publish file api lcwd [on Arthur Barstow - due 2014-11-03].

sicking: it has been at LC, may be brought back before then

<anssik> http://www.w3.org/standards/history/fileapi

plh: which webapp will be break if we remove file list

sicking: hopefully none

weinig: file writing was removed at some point?

sicking: no was always in file system

weinig: so file saving is in file system?

sicking: yup

arunranga: you can trigger a file save path
... this was probably the specs put forward by google
... file system then diverged
... this google spec has become a note

chaals: so yes, this is what file system does
... q about file api

arunranga: requirement is file save as

<ArtB> File API UCs and Requirements

chaals: says no, as file save as can't be met

sicking: at best this statement is ambigous

chaals: so you're not meeting the requirement?

sicking: that's right

file system

<ArtB> ACTION: Arun deleted the UC in File API that starts with "Data should be able to be stored ..." [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action21]

<trackbot> Created ACTION-750 - Deleted the uc in file api that starts with "data should be able to be stored ..." [on Arun Ranganathan - due 2014-11-03].

arunranga: so, the room agrees requirement should be removed?

chaals: yes

<arunranga> http://w3c.github.io/filesystem-api/Overview.html

arunranga: file system api link ^
... editors draft
... this file system api build on model put forth by google but uses promises not callbacks
... there are some things we want to preserve, url
... this spec also relies on platform primitives: event stream e.g.
... we will follow some ideas in posix, we have some ability to write also
... there is the file handle and writable file handle
... we want feedback from implementers

<timeless> scribe: timeless

israelh: ... say i keep something open
... allow my writes to prevail
... it doesn't seem to be as analogous as indexeddb
... because you can't necessarily add transactions

<inserted> scribe: schuki

sicking: would be good to here microsoft comments

israelh: we are thinking of the model of keeping something open

sicking: typically there's never multiple users touching a file
... because they're sandboxed
... storage policy for filesystem is no difference between indexeddb and sql
... you could implement file system api on top of indexeddb with some issues, and no file system url working
... then it's a different api
... actual storage policy is same as indexeddb

israelh: i thought there was a notion that you could break out of sandbox

arunranga: i can see how that could have come from discussion of use case
... this use case is a "nice to have"
... we want to focus on sandbox major
... if this use case is misleading we will abandon
... bigger use case of breaking out does not seem credible

sicking: i agree

israelh: why not enable with log file? People are used to this

sicking: you could easily create dead locks
... the problem is if you open pages, one that opens file a, then file b, then does stuff with either
... then you have another sub component that opens file b
... then dead lock - this isn't good

israelh: so if you surface dead locks to the applications, then you can manage them
... we could provide mechanisms to handle them
... more intuitively than indexeddb

sicking: it could cause race conditions then

[ laughter ]

israelh: so then the complexity of programming increases

sicking: complexity is a complicated thing
... you do need to open the file open, but then no need to deal with dead locks
... is it simpler to have things like they are now, or open the files in order always?
... seems like no good solutions
... still interested in microsoft implementation status

israelh: we're looking at it

<arunranga> israelh, great :)

chaals: arunranga you said use case of having files is not credible
... want to build on sandboxed system of indexeddb
... is this a solution looking for a problem?

<ArtB> ACTION: Yves followup with Cameron re PR 27 and the Web IDL test suite [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action22]

<trackbot> Created ACTION-751 - Followup with cameron re pr 27 and the web idl test suite [on Yves Lafon - due 2014-11-03].

chaals: what are the barriers (if can build security system that could work) to using the file system api to handle access from multiple apps to same file?
... has something been built that cannot handle multiple access?

sicking: there is nothing inherent with files which makes them more interesting to share than with things such as indexeddb
... firefoxos is doing something, but for security reasons this wouldn't work for web

chaals: there are use cases when apps would want to work on the same files

weinig: from apple perspective: osx is file coordination system, you're only allowed to do something in a block
... you can use filehandle to do stuff
... user has to give access to all files on ios

sicking: we have multiple solutions for firefoxos, in every case user must make decisions

chaals: question remains: is there something in file system that could break multi user problem?

sicking: no, we just need to solve the security problems

weinig: same q as before: how does using this api trigger an explicitly save somewhere else?

sicking: open write
... there's nothing to trigger save dialogue

weinig: this seems to be a major pain point

sicking: file saver api could be used, with progress saver events

arunranga: you can request the save as and trigger the dialogue
... this file system api allows write to sandbox file system
... is there a req to do something more to prompt user interaction?

schuki: earlier sicking mentioned could use download attr on anchor tag

weinig: no, was just confused!

arunranga: we would like feedback from apple

adrianba: 1) save case is independent from file system api
... we want something more than anchor tag
... we made proposal previously
... proposal was you may have a offline app, an online app, so want to simulate a local application simulation dialogue
... therefore a number os use cases exist for saving scenario
... need to revisit

<Zakim> timeless, you wanted to ask if anyone has actually *used* that approach (href=blob:, download=) ? or + sending a click to that

?

<anssik> FWIW, here's my demo <a download> w/ .click(): http://anssiko.github.io/html-media-capture/capture-and-download.html

timeless: do people do the flow of anchor tag with blob and download attr?

sicking: i think gmail does it but not sure

weinig: could non normatively reference in one of the api specs so other people don't get confused

<arunranga> weinig, I will take an action to do this

<weinig> thanks arunranga!

darobin: could use a json trick but could create a massive json file to pull down

<timeless> timeless: +1 to weinig's suggestion

ArtB: coffee break
... no coffee
... not here till 3
... actually 5 mins away
... let's start straight after 3

[break: return at just after 3pm]

sicking: arunranga is working on some edits to file system
... apart from that, given microsoft is maybe interested then we should move forward

ArtB: arunranga do some edits, let me know, and we'll go for working draft

<timeless> ACTION arun to do edits on file system spec

<trackbot> Created ACTION-752 - Do edits on file system spec [on Arun Ranganathan - due 2014-11-03].

arunranga: we can take some discussions to mailing list

jungkees: service worker cfc ok?

ArtB: yes go ahead

<timeless> s|https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm">https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm -> Streams API W3C Editor's Draft |XXXscribeERROR|

<sicking> arunranga, might be worth adding that to the File API. We could even replace the current "save to disk" use case with a informative note that says that the spec supports it in collaboration with the HTML download attribute

[break: return at just after 3pm]

<arunranga> sicking, yep, promised weinig I would do it

selection, editing and user interactions

<benjamp> Agenda for Selection, Editing, Intentions

<benjamp> Explainer for Intentions: http://w3c.github.io/editing-explainer/commands-explainer.html

<benjamp> Explainer for Editing

benjamp: i have added links to irc ^
... overview: started with editing (exitensible web summit in jan)
... started to think about how to spec it
... since then had meetings on editing, and user intentions

[diagram in spec]

benjamp: diagram shows inputs, and what the user wants to accomplish
... today the situation is not well connected between the two

<ArtB> W3C Editing Explainer

benjamp: trying to solve both at the same time

<ArtB> User Intentions Explainer

benjamp: we are brining people together to talk about this
... explainer doc (link above) talks about how we can make a single shape for all these intentions

<ArtB> Selection API

benjamp: interested groups / apis: html, webapps, indie-ui, selection api, clipboard api, scroll,
... also interested in how this works with web components
... to look at behaviours rather than just click events
... also want to discuss how we can work on this with ARIA so you can update properties on the fly

<cyns> https://rawgit.com/cyns/wapa/master/wapa.html

<cyns> Web Accessibility Properties and Actions (WAPA) Explainer

benjamp: task force is working on editing and user intentions

<darobin> http://lists.w3.org/Archives/Public/public-editing-tf/

benjamp: [referring to spec]

<ArtB> Editing TF list

benjamp: you can refer an action based on intention
... we want to have a unified shape, and we need to work this out
... clipboard is one implementation
... indie-ui is another
... dom lvl3 is working on implementing this
... based on everyone's use acses, we could come up with small number of events
... e.g. input, scrolling
... can we create 4/5 individual events to represent?

jcraig: i see distinction between discreet and continuous events
... most so far have been discrete

benjamp: rick, how about for scrolling?

richt: we were worried about a lot of events
... does pressing down want to make many different events?
... the harder problem is how these things are composed
... are dom events the right thing for this?
... scroll is a different case, a node may have a custom logic, then i need to work with custom logic and browser logic
... we don't have a solution now, but this is a big question

rbyers: e.g. input. If i hit letter 'a', custom node, how does the flow with custom script and browser handle work?

benjamp: would this be like other events?

jcraig: yes
... we talked about instead of having custom event types you could have custom control
... e.g. this div represents stepper
... so it has a settable value, as well as increment and decrement methods

Norbert: it's getting complicated! More things: input methods [IMEs] (intercept keyboard events)
... minimising api would mean application needs api to talk to input method
... spelling checkers are another issue
... modifying text behind your back
... can cause issues

benjamp: editing & intentions can be seen as different
... editing there could be some way that IMEs could be lost
... we need to think about this, file a bug on github

rniwa: you have an action before / after, key input is discrete, either before or after
... these events bubble, content editing host could cancel but not everything can do this
... could also discuss input methods
... behaviour input methods interesting: random text is corrected by spelling mistake, which cause issues
... e.g. mac auto correction bubble
... so, intents might not identify everything, may need to think about context

<Zakim> timeless, you wanted to say that IMEs and spellcheckers should be considered as the same

timeless: spellchecker could be considered the same
... some devices don't have a keyboard
... mobile device e.g.
... web should not treat these differently
... latin lands are used to spell checkers - cjk to IME, -- and not to the other one -- by merging the concepts, you ensure that anyone who codes to handle one case doesn't break when they encounter the other

cyns: idea is to solve use cases [1] scenario around another state by downloading another bunch of ARIA [2] word document, these can be long, dom has subset, content could have list elements, numbers etc, doc isnt good representation of a document
... idea is to allow assitive technology to trigger events
... there may also be more actions that api could do
... this could work for testing of custom elements and web driver accessiblity

<cyns> https://rawgit.com/cyns/wapa/master/wapa.html

benjamp: there are many scenarios that need to be solved
... needs intention shape for intention events
... then take this and see if it works for use cases
... we need data
... input text could be one, and data would be text
... good idea?
... if we had unified shape: intention, type, data

comments?

richSchwer: if you're going to scroll, you need range
... you need to tell app something rather than work it out itself
... each platform has differences between each accessibility api
... we need to get that to be seamless
... we're getting back to the design pattern
... about delivering inform to the app

rniwa: it would be useful for interested parties to come up with use case list
... to add to explainer
... then proposal can be vetted against these use cases

<Zakim> jcraig, you wanted to mention dictation UI is similar to IME UI and to mention API for custom RTE may be the right approach for editing. and to mention intentional events

jcraig: rniwa Norbert were talking about IMEs, an idea could be an api which custom view could implement
... jcraig: reconciliation with physical events, first event object could have id, and subsequent events could reference previous events by ID, to reconcile which physical events caused the related intention events

chaals: generic shape for events: good idea?

[5/6 hands up]

<Zakim> chaals, you wanted to ask about shapes

chaals: +1 to jcraig, need to figure out how intentional events can interact
... need to figure out where events go when you start to pile them
... we looked at this before
... a very simple set in 90s
... we had a set of events and they weren't used
... once you've done touch / pointer / slides etc.
... then remember you forgot mouse!
... the data payload for event, i am hearing rich and jcraig say objects need to provide information

jcraig: yes so if view can take scroll then it should tell you how far you canview (scroll poisition, scroll range)

<Zakim> cyns, you wanted to agree that abstracting the platform apis is a goal

<Zakim> darobin, you wanted to have use cases as code as much as possible

darobin: could have shims, reuse code methods

rbyers: is i have a componet that manages a list
... when you hit space it does certain things
... inside this list people could make widget
... now if someone hit space bar what happens?
... ideally it extensible web view should handle this
... if we say devs design for this, then checkbox will never run, and before event will make container, container creates beforedefault etc...

<scribe> scribe: timeless

<jcraig> partial interface UIEvent {

<jcraig> readonly attribute EventID id; // UID of current event

<jcraig> readonly attribute EventList relatedEvents; // List of related events, with ID and potentially type of each event.

<jcraig> // This "dismissrequest" event is associated with the previous "keydown" and "keyup" events.

<jcraig> }

benjamp: if the checkbox handles the spacebar
... ---
... keydown, if handled by checkbox, you're done

weinig: my concern with the question, and i wanted
... "should we look for generic shapes for intention events"
... i'd understand you'd want this for keyboard actions
... first a physical key event
... the os gets a chance to get decide what it means
... the thing i don't understand is why we'd generalize this to many different problem sets from the get go
... i'm not sure why polymorphism would be necessary
... why scroll/keyboard interactions should be handled identically

chaals: you scroll using down / pagedown key / gesture / assistive technology
... the issue we have is that if you don't collect each of this different things and deal with them at the same level
... the problem isn't that a given thing will kill us all
... it's that the diversity means that web developers screw it up
... web developers interfere with a noticable number of people's user interface
... scroll, but for a user, it might mean something else
... twitter does this to me, every day

weinig: if it all goes well, Twitter would just have to handle one event handler for scroll, and get them all for free
... rubber band or scroll or bump

chaals: correct
... the complication is that there are differences in what can be done

weinig: it seems to be hard to fathom custom scrolling with scrolling with
... it would seem you want completely different code running

[ We have an extra 15 minutes ]

benjamp: we can schedule more time for editing tomorrow
... what i want to show everyone is what this looks like
... this is a demo of intention events

[ Demo ]

[ presses "a" ]

[ gets an event ]

[ presses "ctrl-b" ]

[ gets a format event ]

[ presses "ctrl-a" ]

<jrossi> Demo

[ gets before selection change ]

benjamp: on this sample, you could do content editable with intention events
... MS Office wanted to be able to style text w/o being able to modify text
... to give you a default style for email
... you could do that by canceling all text events except formatting
... you could talk about how intention events could apply to a custom component

<Zakim> jcraig, you wanted to mention potential requested code sample: and to [Example]

<jcraig> [Example]

<jcraig> partial interface UIEvent {

jcraig: someone mentioned specific examples

<jcraig> readonly attribute EventID id; // UID of current event

<jcraig> readonly attribute EventList relatedEvents; // List of related events, with ID and potentially type of each event.

<jcraig> // This "dismissrequest" event is associated with the previous "keydown" and "keyup" events.

<jcraig> }

jcraig: we had Jason Kiss
... develop a polyfill for some of these events

<Zakim> timeless, you wanted to say that FCC's complaint form interfered with me

timeless: Both the web page (FCC) and myself wanted to advance to the next field, (I pressed tab), we both won -- I lost (double advance)

rniwa: "Keyboard is easy to spec"

[ Travis kicks him ]

scribe: when you move the cursor, it said "modify event"
... but different OSs/Browsers do different things
... right could mean right-physical, or next-logical
... cursor end could mean line end or page end
... we need to be careful what kind of extensibility we need to be aware of
... valueChange

cyns: scrolling
... while you might want different behavior for the scroll itself
... infinite scroll (image search results)
... you still want to load the next batch of things
... using the intention event
... and other scripts for the details

benjamp: rniwa, maybe actions can be tied to extensions
... "shift-right-arrow"
... conjecturing, associate with "modify caret" + "to right"
... if the site wants to do something else, they could listen to the keys and said a different intention event
... you can modify what an intention is

[ Editing Explainer ]

benjamp: for a keyboard event
... DeclareIntention(
... changing the intention of an action
... "shift-right-arrow" in RTL
... i want it to be non standard
... I can map this to be "modify-selection" + "left"
... )
... then you can respond to it in the intention handler

<Zakim> chaals, you wanted to say "how you move the cursor is different from browser to browser" is sort of the point

chaals: instead of you listening to the interface action in the web app
... you get the platform event
... concept

rniwa: what if today all browsers do selection logically
... but what if a browser wants it to be visually
... extend bidi text selection to the right
... it might be different
... to be able to extend physically

benjamp: if a browser creates selections that are disjoint
... the browser needs to keep in mind that this may break sites

rniwa: how do we support new intentions

chaals: we already have that problem
... we add a new device interface
... and the web app becomes totally unusable
... i suspect that's not a really big problem
... future proofing is always difficult
... but future proofing based on what we've got is a nightmare
... we will continue to see new intentions

jcraig: rniwa and weinig were describing selection model changing
... that might be the case for the api to set the specific selection
... in continuous scroll
... instead of a series of scroll events
... set some values on view

janina: sometimes we say intention and talk about the way we achieve something
... we need to be careful about language

chaals: that gives you lots of things to think about
... shall we put this on the agenda tomorrow?

benjamp: yes

chaals: people want to make contenteditable go away

ArtB: preference?

chaals: after 3

rniwa: likewise (but for performance conflict)

ArtB: ok, 3:30-5

jcraig: we had other topics other than events/editing
... join had topics about selection api
... computed role on element
... user context / user settings

<chaals1> scribe: Chaals

Annotations

<chaals1> FJH: The idea is to enable an annotation to something that is on the web. You have a body of an annotation annotating something.

<chaals1> … you need to point to the thing you are annotating.

<chaals1> … which might be a part of a resoource - word, sentence, video fragment...

<chaals1> … that's a target of the annottation.

<chaals1> ... the thing you annotate may change. So how do you keepthe target pointing to the right place

<chaals1> … using a word-count might be fragile, for example.

<chaals1> … We might not get perfection but we want robust linking.

<chaals1> … Doug has done some stuff, and Rob too.

<chaals1> DS: I use a Mac, so we have problems connecting to things

<chaals1> s/https://www.w3.org/wiki/Webapps/November2014Meeting//

<chaals1> DougS: This is sort of related to Selection API. Instead of based on user input it is based on something that was being selected before.

<chaals1> … problems include not having ids, having duplicate strings, or a documnt gets changed, ….

<chaals1> [slide: solutions]

<chaals1> [slide: example of context - 32 characters before and after the thing that is being selected]

<chaals1> … have a strawman, looking for help on how to achieve. One idea was using the find-in-page function...

<chaals1> … we don't expose the text locations through an API

<chaals1> TL: There's nothing in W3C platform. In the DHTML platform from MS we had something like this.

<chaals1> … IE's find on page is built on top of this, on the precursor to the DOM range API.

<chaals1> DS: That could be an interesting starting point, perhaps.

<chaals1> ACTION: travis to find an MSDN page that describes this [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action23]

<trackbot> Created ACTION-753 - Find an msdn page that describes the finding thing in IE [on Travis Leithead - due 2014-11-03].

<chaals1> DS: This is all speculative. We want to find text...

<chaals1> [slide: strawman]

<darobin> https://developer.mozilla.org/en-US/docs/Web/API/window.find -> windows.find() is also related to this

<chaals1> … simple case is a string you want to match

<fjh> the MSDN page: http://msdn.microsoft.com/en-us/library/ie/ms536422(v=vs.85).aspx

<chaals1> … have an idea how to style this too.

<chaals1> close action-753

<trackbot> Closed action-753.

<chaals1> [slide: strawman part 2]

<chaals1> [slide: styling]

<chaals1> TL: You showed some potential ways to find the annotation. And you ended up proposing stuff based on literal text and before/after. Is there a reason why that bubbled to the top?

<chaals1> DS: Not really.

<chaals1> … don't know how this would work, and what it would try.

<chaals1> … I didn't know how to do edit distance. CSS selector would be the fastest if you knew how to do it

<chaals1> FJH: Did you run this by the annotation conf?

<chaals1> Kristof: We're working on a fork of @@

<chaals1> … we implemented something related to this. You can pass in a bunch of selectors using different types, and a bunch of registered anchoring strategies. The framework is meant to run through the strategies to find solutions.

<chaals1> … they could be ranges, or in the case of images you might want to return specific part of the image which has been identified.

<chaals1> … We have one using Xpath selector, one that is character position, or using context and levenstein distance.

<chaals1> … These all should be extensible.

<chaals1> … Other side of the equation, pass in a fragment and describe it with different selectors, so you get the fragment, and it gives back different selectors.

<chaals1> … We save the selection, and try to re-anchor with several strategies for robustness.

<chaals1> DS: There are plenty of approaches we could take, this is a strawman.

<chaals1> … we want things useful for the platform in general not just annotations.

<chaals1> TL: This seems like a missing piece. You can use selectors, but this doesn't exist yet.

<chaals1> DS: Right. Seen people wanting to find text in the content but not the chrome of a webapp

<chaals1> TL: Manual text finding from the node tree is slow.

<chaals1> DS: Right

<chaals1> … a find in page dialog won't cross or block on boundaries.

<chaals1> RobS: Various ways of selecting the area, and then deciding if something matches. Levenstein distance isn't the same as Xpath.

<chaals1> … does it match vs where is it.

<chaals1> … in open annotation data model we have what we call selectors, - text quote selector and offset. Data offset for arbitrary bitstreams, SVG, fragment selector

<chaals1> … One way forward is to figure out how you transfer a set of selectors via the API.

<chaals1> DS: That's what the options object would be

<chaals1> CMN: Have you looked at the fuzzy pointers developed about 12 years ago for EARL? Like Xpointers designed for HTML, to solve this kind of problem

<chaals1> ACTION: Doug to ask chaals where fuzzy pointers stuff is [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action24]

<trackbot> Error finding 'Doug'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.

<chaals1> DS: There is a lot of prior art here...

<chaals1> Kristof: We find text in a corpus and map it back to where it is in the DOM

<ArtB> ACTION: frederick work with Doug and Chaals re fuzzy pointers stuff for Web Annotations WG [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action25]

<trackbot> Created ACTION-754 - Work with doug and chaals re fuzzy pointers stuff for web annotations wg [on Frederick Hirsch - due 2014-11-03].

<chaals1> … the browser knows where the teext it finds is, but doesn't expose that. Doing so would be good for everyone.

<chaals1> … We are using selectors defined by Open Annotation group.

<chaals1> FJH: What are our next steps?

<chaals1> [looking at http://jibbering.com/discussion/fuzzy-pointers.html is aprt of solving action 754]

<chaals1> FJH: We're looking at next steps. Are there any problems with where Doug is going?

<chaals1> Kristof: Are we doing this to work on any kind of document, or just for a few data rtypes? Because if the former we cannot just rely on DOM ranges now, and need a new type.

<chaals1> ArtB: API scope is a common question for us. One answer is always "what are the use cases"?

<chaals1> … whatis the status of use cases for this?

<chaals1> RobS: In digital publishing IG we have a long set of use cases some of which cover this.

<chaals1> … that's work in W3C and IDPF (who do ePub)

<chaals1> … there are definitely use cases around annotating images. HTML and text are the things that change most often.

<chaals1> FJH: I would argue taht we should start focusing on text in HTML.

<chaals1> … where you know someone will edit it, but you want your link not to die.

<chaals1> … this was discussed in Annotation Workshop and is in proceedings.

<chaals1> ArtB: To best engage with Webapps, should identify the use cases that are clearly in scope.

<chaals1> FJH: We have a proposal that goes beyond the use cases, but we need to figure out how to progress it. It needs to be implemented - do we do that through webapps?

<chaals1> TL: W=You could polyfill now, and it will just be slow, right?

<chaals1> DS: Right. So we should come up with solid use cases, make a spec and polyfill it and see if we get people to agree.

<chaals1> TL: Think you should continue. Please support your scenarios with some APIs you want in general. On finding text, it will probably be prohibitively expensive to find all matches at once. Finding all is an iteration on find next where you can yield back.

<chaals1> … text should be senstitive to unicode issues for characters - some things might not match all the time.

<chaals1> … to generalise it, case insensitivity, regexp, etc would be useful.

<chaals1> … Think that this really is something missing from the platform.

<chaals1> PaulC: Go look at all of the string matching stuff in Xquery/Xpath. We looked at all of those things when we did that stuff. It's in a standalone W3C spec.

<chaals1> FJH: Next steps: Bring summary of use cases to webapps. In our group do a survey of previous work, and produce a working draft and share it.

<chaals1> … want to understand how we get beyond that.

<azaroth> ACTION: azaroth to update use case document and extract robust anchoring items to provide to webapps [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action26]

<trackbot> Error finding 'azaroth'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.

<chaals1> … does webapps have any constraints about timelines?

<chaals1> TL: Is it in our charter?

<chaals1> ArtB: Yep. can be done as a joint deliverable.

<chaals1> FJH: Anything happening in webapps we should know about?

<chaals1> CMN: Look at editing - you can maybe use taht sometimes to help understand what changed, and get updates to keep your pointers able to find what happened.

<chaals1> RB: There is also a CG that worked a while ago on "CSS Xpointer scheme".

<chaals1> … it would have to be rewritten to make stuff work, but I have some notes somewhere and think this can be mapped onto an HTML DOM, and would allow you to make webpointers. It's pretty easy.

<chaals1> ACTION: Robin to solve the rest of the problems related to robust targeting of changing documents. [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action27]

<trackbot> Created ACTION-755 - Solve the rest of the problems related to robust targeting of changing documents. [on Robin Berjon - due 2014-11-03].

<chaals1> Kristof: There are different applications and document types, and to support tehm all we should be able to register new anchor types and discovery algorithms. So we should have a framework that applications can use to communicate through, adding new algorithms rather than trying to a priori specify them all.

<darobin> *cough*

<chaals1> action-755 due wednesday

<trackbot> Set action-755 Solve the rest of the problems related to robust targeting of changing documents. due date to 2014-10-29.

<chaals1> … we should be able to inject a new strategy for finding things into the framework.

<chaals1> FJH: Right but I don't think that bears on the webapps group.

<chaals1> DS: That would have to be something that isn't the same as find-text.

<chaals1> FJH: We'll figure it out when we get a better proposal today

<chaals1> DS: Travis were you saying we make something like a regex, and then apply it repeatedly finding the next match is what we should do?

<chaals1> TL: Sure… maybe...

<chaals1> [adjourned]

Summary of Action Items

[NEW] ACTION: abateman2 to determine Kris' availability to work on the Web Messaging and Web Sockets implemenation reports [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action17]
[NEW] ACTION: adrian determine Kris' availability to work on the Web Messaging and Web Sockets implemenation reports [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action15]
[NEW] ACTION: Arun deleted the UC in File API that starts with "Data should be able to be stored ..." [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action21]
[NEW] ACTION: Arun mark file list as Feature @ Risk [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action19]
[NEW] ACTION: azaroth to update use case document and extract robust anchoring items to provide to webapps [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action26]
[NEW] ACTION: barstow create a new bugzilla component for Inner Text [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action05]
[NEW] ACTION: barstow followup with Simon re running the Web Workers tests [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action16]
[NEW] ACTION: barstow issue a Call for Test Facilitator for IME spec [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action08]
[NEW] ACTION: barstow re SSE test results, followup on the Timeouts with the 2 test facilitators [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action10]
[NEW] ACTION: barstow start a CfC to gut XHR L2 and publish a WG Note [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action18]
[NEW] ACTION: barstow start a CfC to publish a "gutted" WG Note of the Fullscreen API [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action06]
[NEW] ACTION: barstow start a CfC to publish a Proposed Recommendation of IDB [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action07]
[NEW] ACTION: barstow start a CfC to publish File API LCWD [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action20]
[NEW] ACTION: barstow start CfC to publish UI Events as a "gutted" WG Note [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action02]
[NEW] ACTION: barstow work with Adrian to find a replacement TC for Alex and D3E [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action04]
[NEW] ACTION: charles ask cjk interest group and others about IME (use cases, tests, etc.) [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action09]
[NEW] ACTION: charles try to find someone to help Yves, Cam and Boris on Web IDL v1 [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action13]
[NEW] ACTION: Doug to ask chaals where fuzzy pointers stuff is [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action24]
[NEW] ACTION: frederick work with Doug and Chaals re fuzzy pointers stuff for Web Annotations WG [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action25]
[NEW] ACTION: Marcos work with SysApps to find an agenda slot for Tuesday [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action01]
[NEW] ACTION: Robin to solve the rest of the problems related to robust targeting of changing documents. [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action27]
[NEW] ACTION: Travis to check that the D3E tests are in GH or Mercurial, and if needed fix [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action03]
[NEW] ACTION: travis to find an MSDN page that describes this [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action23]
[NEW] ACTION: Yves followup with Cameron re PR 27 and the Web IDL test suite [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action22]
[NEW] ACTION: Yves to work on moving Web IDL v1 to REC [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action14]
[NEW] ACTION: yves, follow with Cameron re PR 271 and the Web IDL test suite [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action11]
[NEW] ACTION: yves, work on moving Web IDL v1 to REC [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action12]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-10-27 23:58:18 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Gecoj/Gecko/
Succeeded: s/Travis/scribe/
Succeeded: s/tyoshino/DD/
Succeeded: s|TCP|TCP/UDP|
Succeeded: s/DD/tyoshino/
Succeeded: s|ByteStream -> https://github.com/whatwg/streams/blob/master/BinaryExtension.md|-> https://github.com/whatwg/streams/blob/master/BinaryExtension.md ByteStream|
Succeeded: s|http://www.w3.org/TR/2014/CR-media-source-20140717/#sotd|-> http://www.w3.org/TR/2014/CR-media-source-20140717/#sotd Media Source Extensions Status of This Document|
Succeeded: s/Kolel/Colwell/
Succeeded: s/WriteableStream/WritableStream/
Succeeded: s/)/)?/
Succeeded: s/broadcast live/broadcast live using HTML5/
Succeeded: s|Polyfill -> https://github.com/whatwg/streams/tree/master/reference-implementation|-> https://github.com/whatwg/streams/tree/master/reference-implementation Polyfill|
FAILED: s|https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm -> Streams API W3C Editor's Draft |-> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Streams API W3C Editor's Draft|
Succeeded: s|https://streams.spec.whatwg.org/ -> Streams by WHATWG|-> https://streams.spec.whatwg.org/ Streams by WHATWG|
Succeeded: s/spain/Spain/
Succeeded: s/[/p/
Succeeded: s/let/let's move this to PR/
Succeeded: s/(I can't hear you anymore, not sure what happened)//
Succeeded: s/ofthe/of the/
Succeeded: s/spe/spec/
Succeeded: s/44 is me//
Succeeded: s/audio is terrible though//
Succeeded: s|https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm -> Streams API W3C Editor's Draft|-> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Streams API W3C Editor's Draft|
Succeeded: s/Topic: Push API and Service Workers//
Succeeded: s/QQ/Shijun/
Succeeded: s/#/Slide -- #/
Succeeded: s/avialability/availability/
Succeeded: s/50ms/750ms/
Succeeded: i/Slide 2/-> http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/att-0283/RTC_and_Push_scenario.pdf "Scenario analysis: RTC call with push message" slides from Shijun
Succeeded: s/Timeless/timeless/
Succeeded: s/schuki/scribe/
Succeeded: s/schuki/scribe/
Succeeded: s/schuki/scribe/
Succeeded: s/sicking: those UCs need to come/mounir: those UCs need to come/
Succeeded: s/thank you, we're done/we're done, thank you/
Succeeded: s/sicking://
Succeeded: s/???/moratorium/
Succeeded: s/thia/this/
Succeeded: s/... we've tried to harmonise/Travis: we've tried to harmonise/
Succeeded: s/style lists/file lists/
FAILED: s/and (as at risk) and//
Succeeded: s|s/and (as at risk) and/||
Succeeded: s/and/ (as at risk) and/
Succeeded: s/paulc://
Succeeded: s/+q/q+/
Succeeded: s/agenda requests/Topic: agenda requests/
Succeeded: s/Clipboard events/Topic: Pub-Status: Clipboard events/
Succeeded: s/DOM Level 3 Event/Topic: Pub-Status: DOM Level 3 Event/
Succeeded: s|https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm -> UI Events ED|-> https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm UI Events ED|
Succeeded: s/UI Events/Topic: Pub-Status: UI Events/
Succeeded: s/anything about the key specs/Topic: Pub-Status: DOM3 key specs/
Succeeded: s|https://github.com/w3c/web-platform-tests/tree/master/html/syntax -> DOM P&S tests|-> https://github.com/w3c/web-platform-tests/tree/master/html/syntax DOM P&S tests|
Succeeded: s|https://github.com/w3c/web-platform-tests/labels/dom-parsing -> DOM P&S test open issues|-> https://github.com/w3c/web-platform-tests/labels/dom-parsing DOM P&S test open issues|
Succeeded: s/Travis: DOM-PS/Topic: Pub-Status: DOM-PS/
Succeeded: i/are you going to do anything with innerText/Topic: innerText
Succeeded: i/chaals: Moving on to FileAPI/Topic: Pub-Status: FileAPI
Succeeded: i/sicking: would/scribe: schuki
Succeeded: i/.. FullScreen/Topic: Pub-Status: FullScreen
Succeeded: i/chaals: Gamepad./Topic: Pub-Status: Gamepad
Succeeded: s/it;s/it's/
Succeeded: s/differen/different/
Succeeded: i/sicking: I'm not sure what's blocking/Topic: Pub-Status: IndexedDB
Succeeded: s|http://www.w3c-test.org/IndexedDB/interfaces.html -> IDB interfaces Web IDL|-> http://www.w3c-test.org/IndexedDB/interfaces.html IDB interfaces Web IDL|
Succeeded: i/IDB interfaces Web IDL/Topic: IndexedDB + Web IDL
Succeeded: s/logs/locks/
Succeeded: s/chaals: IME/Topic: Pub-Status: IME/
Succeeded: s/chaals: OK. Moving to PointerLock/Topic: Pub-Status: PointerLock/
Succeeded: s/timeless/scribe/
Succeeded: i/chaals: Quota Management?/Topic: Pub-Status: Quota Management
Succeeded: i/... Server-Sent Events/Topic: Pub-Status: Server-Sent Events
Succeeded: s/... WebIDL/Topic: Pub-Status: WebIDL/
Succeeded: s/... Web Components?/Topic: Pub-Status: Web Components/
Succeeded: s|http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0248.html -> Custom Elements status from Dimitri 2014-Oct-24|-> http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0248.html Custom Elements status from Dimitri 2014-Oct-24|
Succeeded: s|http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0249.html -> HTML Imports status report frm Hajime on 2014-Oct-24|-> http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0249.html HTML Imports status report frm Hajime on 2014-Oct-24|
Succeeded: s|http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0222.html -> Shadow DOM status report from Hayato on 2014-Oct-23|-> http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0222.html Shadow DOM status report from Hayato on 2014-Oct-23|
Succeeded: s|http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0213.html -> Tantek's proposal re Fullscreen API|-> http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0213.html Tantek's proposal re Fullscreen API|
Succeeded: s/independant/independent/
Succeeded: s/[1]/1)/
Succeeded: s/workiong/working/
FAILED: s|https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm">https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm -> Streams API W3C Editor's Draft |XXXscribeERROR|
Succeeded: s|-> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Streams API W3C Editor's Draft|ZZZ|
Succeeded: i/Agenda/topic: selection, editing and user interactions
Succeeded: s/topic: selection, editing and user interactions//
Succeeded: s|Explainer for Editing: http://w3c.github.io/editing-explainer|-> http://w3c.github.io/editing-explainer Explainer for Editing|
Succeeded: s|Agenda for Selection, Editing, Intentions: http://lists.w3.org/Archives/Public/public-editing-tf/2014Oct/0021.html|-> http://lists.w3.org/Archives/Public/public-editing-tf/2014Oct/0021.html Agenda for Selection, Editing, Intentions|
Succeeded: s/clip/click/
Succeeded: s/arunranga, you wanted to say I will work towards FPWD//
Succeeded: s/discreet/discrete/
Succeeded: s/events/events?/
Succeeded: s/+q/q+/
Succeeded: s/input methods/input methods [IMEs]/
Succeeded: s/it has increment and decrement/so it has a settable value, as well as increment and decrement methods/
Succeeded: s/spell checkers/spell checkers - cjk to IME, -- and not to the other one -- by merging the concepts, you ensure that anyone who codes to handle one case doesn't break when they encounter the other/
Succeeded: s/it/api/
Succeeded: s/+q/q+/
Succeeded: i/This sums up the review of pubstatus/Topic: Rundown of pubstatus
Succeeded: s/itseld/itself/
Succeeded: s/has accessibility apis/has differences between each accessibility api/
Succeeded: s/starting Introductin//
Succeeded: s/present cynthia_shelly//
Succeeded: s/definiately/definitely/
Succeeded: s/frm Hajime/from Hajime/
Succeeded: s/committments/commitments/
Succeeded: s/richt/rbyers/
Succeeded: s/requiements/requirements/
Succeeded: s/committment/commitment/
Succeeded: s/diferences/differences/
Succeeded: s/unkowns/unknowns/
Succeeded: s/intention will have id, and reconciliation can ???/first event object could have id, and subsequent events could reference previous events by ID, to reconcile which physical events caused the related intention events/
Succeeded: s/oportunities/opportunities/
Succeeded: s/userhas/user has/
Succeeded: s/thingdid/thing did/
Succeeded: s/primatives/primitives/
Succeeded: s/microsft/microsoft/
Succeeded: s/sandox/sandbox/
Succeeded: s/enbale/enable/
Succeeded: s/sandoxed/sandboxed/
Succeeded: s/explicity/explicitly/
Succeeded: s/sandox/sandbox/
Succeeded: s|demo: http://w3c.github.io/editing-explainer/demos/intentions-demo.html|-> http://w3c.github.io/editing-explainer/demos/intentions-demo.html Demo|
Succeeded: s/physically/visually/
Succeeded: s/3-4/3:30-5/
Succeeded: s/The/... the/
WARNING: Bad s/// command: s/https://www.w3.org/wiki/Webapps/November2014Meeting//
Succeeded: s/richt/rbyers/
Succeeded: s/describes this/describes the finding thing in IE/
Succeeded: s/@@@/anchoring/
Found ScribeNick: ArtB
Found Scribe: Art
Found Scribe: Travis
Inferring ScribeNick: Travis
Found ScribeNick: ArtB
Found ScribeNick: darobin
Found ScribeNick: Travis
Found Scribe: timeless
Inferring ScribeNick: timeless
Found ScribeNick: timeless
Found Scribe: chaals
Inferring ScribeNick: chaals
Found Scribe: timeless
Inferring ScribeNick: timeless
Found ScribeNick: schuki
Found Scribe: schuki
Inferring ScribeNick: schuki
Found Scribe: timeless
Inferring ScribeNick: timeless
Found Scribe: schuki
Inferring ScribeNick: schuki
Found Scribe: timeless
Inferring ScribeNick: timeless
Found Scribe: Chaals

WARNING: "Scribe: Chaals" command found, 
but no lines found matching "<Chaals> . . . "
Continuing with ScribeNick: <timeless>
Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname.

Scribes: Art, Travis, timeless, chaals, schuki
ScribeNicks: ArtB, Travis, darobin, timeless, chaals, schuki

WARNING: Replacing list of attendees.
Old list: [IPcaller] +1.650.318.aaaa
New list: +1.650.318.aaaa Portland Portland.a Seattle Olli_Pettay Domenic anssik tyoshino lgombos? timeless +47.21.65.aacc hallvors lgombos +44.207.095.aadd mvano johnmellor-chrome +44.207.346.aaee arunranga

Default Present: +1.650.318.aaaa, Portland, Portland.a, Seattle, Olli_Pettay, Domenic, anssik, tyoshino, lgombos?, timeless, +47.21.65.aacc, hallvors, lgombos, +44.207.095.aadd, mvano, johnmellor-chrome, +44.207.346.aaee, arunranga
Present: Art_Barstow Yves_Lafon Charles_Neville Robin_Berjon Jungkee_Song Adrian_Bateman Ryosuke_Niwa Xiaoqian_wu Ben Peters Natasha_Rooney Marcos_Caceres Sam_Ruby Johannes Hund Wooglae_Kim Kenneth_Christiansen plh Travis_Leithead Johannes_Hund Ali_Alabbas Israel_Hilerio Sakari_Poussa Laszlo_Gombos Hiroyuki_Aizu Masataka_Yakura Michael[tm]Smith Bryan_Sullivan cynthia_shelly Dowan_Kim Claes_Nilsson David Walp Jonathan_Jeon hober Takeshi_Yoshino Anssi_Kostiainen Olli_Pettay Makoto_Morise timeless waynecarr Shijun_Sun Alan_Iida miterho jeff Joshua_Bell Brian_Raymor Alex_Russel Mounir Ben_Poulain Sam_Weining Norbert_Lindenberg Kenji Michael_van_Ouwerkerk mnot Michael_Cooper Rick_Byers Janina_Sajka Richard_Schwerdtfeger James_Craig Katie_Haritos-Shea Doug_Schepers Robert_Sanderson Frederick_Hirsch Kristof_Csillag
Agenda: https://www.w3.org/wiki/Webapps/November2014Meeting
Found Date: 27 Oct 2014
Guessing minutes URL: http://www.w3.org/2014/10/27-webapps-minutes.html
People with action items: abateman2 adrian arun availability azaroth barstow cfc charles determine doug frederick kris marcos robin start sysapps travis try with work yves

[End of scribe.perl diagnostic output]