- From: Arthur Barstow <art.barstow@gmail.com>
- Date: Tue, 28 Oct 2014 07:40:08 -0700
- To: public-webapps <public-webapps@w3.org>
The minutes from the October 27 f2f meeting are at the following and
copied below:
<http://www.w3.org/2014/10/27-webapps-minutes.html>
If anyone wants any major corrections, please speak up.
Thanks to all the Scribes: Josh, Natasha, Yves, Chaals, Travis and
anyone else who helped.
-Thanks, AB
W3C <http://www.w3.org/>
- DRAFT -
Web Applications Working Group Teleconference
27 Oct 2014
Agenda <https://www.w3.org/wiki/Webapps/November2014Meeting>
See also:IRC log <http://www.w3.org/2014/10/27-webapps-irc>
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
* Topics <http://www.w3.org/2014/10/27-webapps-minutes.html#agenda>
1. Introductions
<http://www.w3.org/2014/10/27-webapps-minutes.html#item01>
2. Spec Roll call
<http://www.w3.org/2014/10/27-webapps-minutes.html#item02>
3. Rundown of pubstatus
<http://www.w3.org/2014/10/27-webapps-minutes.html#item03>
4. Pub-Status: Clipboard events
<http://www.w3.org/2014/10/27-webapps-minutes.html#item04>
5. Pub-Status: DOM Level 3 Event
<http://www.w3.org/2014/10/27-webapps-minutes.html#item05>
6. Pub-Status: DOM-PS
<http://www.w3.org/2014/10/27-webapps-minutes.html#item06>
7. innerText <http://www.w3.org/2014/10/27-webapps-minutes.html#item07>
8. Pub-Status: FileAPI
<http://www.w3.org/2014/10/27-webapps-minutes.html#item08>
9. Pub-Status: FullScreen
<http://www.w3.org/2014/10/27-webapps-minutes.html#item09>
10. Pub-Status: Gamepad
<http://www.w3.org/2014/10/27-webapps-minutes.html#item10>
11. Pub-Status: IndexedDB
<http://www.w3.org/2014/10/27-webapps-minutes.html#item11>
12. IndexedDB + Web IDL
<http://www.w3.org/2014/10/27-webapps-minutes.html#item12>
13. Pub-Status: IME
<http://www.w3.org/2014/10/27-webapps-minutes.html#item13>
14. Pub-Status: PointerLock
<http://www.w3.org/2014/10/27-webapps-minutes.html#item14>
15. Pub-Status: Quota Management
<http://www.w3.org/2014/10/27-webapps-minutes.html#item15>
16. Pub-Status: Server-Sent Events
<http://www.w3.org/2014/10/27-webapps-minutes.html#item16>
17. Pub-Status: WebIDL
<http://www.w3.org/2014/10/27-webapps-minutes.html#item17>
18. Pub-Status: Web Components
<http://www.w3.org/2014/10/27-webapps-minutes.html#item18>
19. Rundown of pubstatus
<http://www.w3.org/2014/10/27-webapps-minutes.html#item19>
20. Streams <http://www.w3.org/2014/10/27-webapps-minutes.html#item20>
21. XHR <http://www.w3.org/2014/10/27-webapps-minutes.html#item21>
22. Introductions 2
<http://www.w3.org/2014/10/27-webapps-minutes.html#item22>
23. Push API and Service Workers
<http://www.w3.org/2014/10/27-webapps-minutes.html#item23>
24. File API <http://www.w3.org/2014/10/27-webapps-minutes.html#item24>
25. file system
<http://www.w3.org/2014/10/27-webapps-minutes.html#item25>
26. selection, editing and user interactions
<http://www.w3.org/2014/10/27-webapps-minutes.html#item26>
27. Annotations
<http://www.w3.org/2014/10/27-webapps-minutes.html#item27>
* Summary of Action Items
<http://www.w3.org/2014/10/27-webapps-minutes.html#ActionSummary>
------------------------------------------------------------------------
<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
inhttp://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>.
<http://www.w3.org/2008/webapps/track/users%3E.>
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
<https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm>
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 inhttp://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
inhttp://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
inhttp://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
<https://github.com/w3c/web-platform-tests/tree/master/html/syntax>
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
<https://github.com/w3c/web-platform-tests/labels/dom-parsing>
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)
athttp://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 inhttp://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
<http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0213.html>
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
inhttp://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> Fixinghttps://github.com/w3c/web-platform-tests/issues/1304would
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
<http://www.w3c-test.org/IndexedDB/interfaces.html>
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
inhttp://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 inhttp://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
inhttp://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
inhttp://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
inhttp://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>.
<http://www.w3.org/2008/webapps/track/users%3E.>
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
<https://www.w3.org/Bugs/Public/buglist.cgi?component=WebIDL&list_id=46230&product=WebAppsWG&resolution=--->
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
inhttp://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>.
<http://www.w3.org/2008/webapps/track/users%3E.>
<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
inhttp://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
inhttp://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
inhttp://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
inhttp://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
inhttp://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
<http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0248.html>
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
<http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0249.html>
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
<http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0222.html>
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 <https://streams.spec.whatwg.org/>
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
<https://github.com/whatwg/streams/tree/master/reference-implementation>
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
<https://github.com/whatwg/streams/blob/master/BinaryExtension.md>
Domenic:the public api is unchanged
<ArtB>WHATWG Streams Open Issues
<https://github.com/whatwg/streams/issues?q=is%3Aopen>
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
<http://www.w3.org/TR/2014/CR-media-source-20140717/#sotd>
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.htmStreams
API W3C Editor's Draft |ZZZ|
XHR
<ArtB>XHR1 ED
<https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html>
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
<https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html>
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
<http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0164.html>
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 inhttp://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 <http://jungkees.github.io/XMLHttpRequest-test/>
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
<http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/att-0283/RTC_and_Push_scenario.pdf>
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
<http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/att-0283/RTC_and_Push_scenario.pdf>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
<http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/att-0283/RTC_and_Push_scenario.pdf>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
<https://www.w3.org/Bugs/Public/buglist.cgi?component=File%20API&list_id=46243&product=WebAppsWG&resolution=--->
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
inhttp://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
inhttp://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
<http://dev.w3.org/2006/webapi/FileAPI/#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
inhttp://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
inhttp://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
<http://lists.w3.org/Archives/Public/public-editing-tf/2014Oct/0021.html>
<benjamp> Explainer for
Intentions:http://w3c.github.io/editing-explainer/commands-explainer.html
<benjamp>Explainer for Editing <http://w3c.github.io/editing-explainer>
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 <http://w3c.github.io/editing-explainer/>
benjamp:trying to solve both at the same time
<ArtB>User Intentions Explainer
<http://w3c.github.io/editing-explainer/commands-explainer.html>
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 <http://w3c.github.io/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
<http://lists.w3.org/Archives/Public/public-editing-tf/>
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
<http://w3c.github.io/editing-explainer/demos/intentions-demo.html>
[ 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 inhttp://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
<http://msdn.microsoft.com/en-us/library/ie/ms536422%28v=vs.85%29.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 inhttp://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>.
<http://www.w3.org/2008/webapps/track/users%3E.>
<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
inhttp://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
athttp://jibbering.com/discussion/fuzzy-pointers.htmlis 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
inhttp://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>.
<http://www.w3.org/2008/webapps/track/users%3E.>
<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
inhttp://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
inhttp://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
inhttp://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
inhttp://www.w3.org/2014/10/27-webapps-minutes.html#action21]
*[NEW]**ACTION:*Arun mark file list as Feature @ Risk [recorded
inhttp://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
inhttp://www.w3.org/2014/10/27-webapps-minutes.html#action26]
*[NEW]**ACTION:*barstow create a new bugzilla component for Inner Text
[recorded inhttp://www.w3.org/2014/10/27-webapps-minutes.html#action05]
*[NEW]**ACTION:*barstow followup with Simon re running the Web Workers
tests [recorded
inhttp://www.w3.org/2014/10/27-webapps-minutes.html#action16]
*[NEW]**ACTION:*barstow issue a Call for Test Facilitator for IME spec
[recorded inhttp://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
inhttp://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 inhttp://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
inhttp://www.w3.org/2014/10/27-webapps-minutes.html#action06]
*[NEW]**ACTION:*barstow start a CfC to publish a Proposed Recommendation
of IDB [recorded
inhttp://www.w3.org/2014/10/27-webapps-minutes.html#action07]
*[NEW]**ACTION:*barstow start a CfC to publish File API LCWD [recorded
inhttp://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 inhttp://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
inhttp://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
inhttp://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
inhttp://www.w3.org/2014/10/27-webapps-minutes.html#action13]
*[NEW]**ACTION:*Doug to ask chaals where fuzzy pointers stuff is
[recorded inhttp://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
inhttp://www.w3.org/2014/10/27-webapps-minutes.html#action25]
*[NEW]**ACTION:*Marcos work with SysApps to find an agenda slot for
Tuesday [recorded
inhttp://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
inhttp://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
inhttp://www.w3.org/2014/10/27-webapps-minutes.html#action03]
*[NEW]**ACTION:*travis to find an MSDN page that describes this
[recorded inhttp://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
inhttp://www.w3.org/2014/10/27-webapps-minutes.html#action22]
*[NEW]**ACTION:*Yves to work on moving Web IDL v1 to REC [recorded
inhttp://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
inhttp://www.w3.org/2014/10/27-webapps-minutes.html#action11]
*[NEW]**ACTION:*yves, work on moving Web IDL v1 to REC [recorded
inhttp://www.w3.org/2014/10/27-webapps-minutes.html#action12]
[End of minutes]
------------------------------------------------------------------------
Received on Tuesday, 28 October 2014 14:40:48 UTC