See also: IRC log
<trackbot> Date: 27 October 2014
<ArtB> ScribeNick: ArtB
<scribe> Scribe: Art
CN:
CN: everyone, please Present+
themselves as: Firstname_LastName
... before you speak, please say your name
zakime, who's here?
<tyoshino> i can hear someone speaking
<tyoshino> talking about agenda, yes
CN: Topic: agenda requests
CS: I have a proposal I'd like to talk about when IndieUI folks are here
AB: we can allocate time tomorrow Cindy
CS: ok
CN: any other topics
MS: URL spec
… want to have Larry Manister
SR: what about Dan?
AB: please tell Larry and Dan to be here at 10:00
PLH: TAG says 10:00 will not work for them today
CN: PLH, please figure out a good time for Tuesday
MS: are we having a SysApps joint meeting?
MC: Mounir will be here after lunch
… should wait for him
JS: tomorrow Wonsuk will be here
<scribe> ACTION: Marcos work with SysApps to find an agenda slot for Tuesday [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action01]
<trackbot> Error finding 'Marcos'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.
<Travis> scribe: Travis
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"
<ArtB> ScribeNick: ArtB
<darobin> Travis: for this we published an updated WD in September
TL: we published new D3E spec last month
<darobin> ... it is our intention to keep pushing this spec to the end of its day
<scribe> ScribeNick: darobin
Travis: we've tried to harmonise
with DOM4, notably for events (definition, dispatch)
... we have a number of additional significant bugs to
tackle
... notably defining the order of dispatch of events in
relation to the task queue model
... a few more clarifications and a whole lot of cleanup
... it's looking, rough estimate, 6 months to another LC
marcosc: it wasn't clear to me last I looked at HTML, if it defines task queues
Travis: you can select from the
queue you want
... if you put them in the same queue
chaa13: and this is like a legacy spec, right?
Travis: to a large extent, as we update it we are applying new spec patterns but it's arduous
marcosc: UI Events?
<ArtB> UI Events ED
Travis: it was the future of
D3Ev, but as we continue to polish this one, we realised we
needed to do some of those things now
... this is also part of the delay
marcosc: my confusion is that I keep finding the UI events and getting confused
plh: should we deprecate it?
Travis: that sounds good to me, it has very little if anything
chaa13: publish as empty Note, point to D3Ev
Travis: when D3Ev is done, where do the new events go?
marcosc: we can restart this
<ArtB> ACTION: barstow start CfC to publish UI Events as a "gutted" WG Note [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action02]
<trackbot> Created ACTION-734 - Start cfc to publish ui events as a "gutted" wg note [on Arthur Barstow - due 2014-11-03].
RESOLUTION: deprecate Topic: Pub-Status: UI Events as a deliverable and publish a gutted Note for it
ArtB: Topic: Pub-Status: DOM3 key specs
Travis: they go with D3E, should go to Rec at the same time?
ArtB: pubstatus says D3E still has tests in Mercurial, still the case?
<MikeSmith> smaug, can you hear us on the phone?
<smaug> yes
<scribe> ACTION: Travis to check that the D3E tests are in GH or Mercurial, and if needed fix [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action03]
<trackbot> Created ACTION-735 - Check that the d3e tests are in gh or mercurial, and if needed fix [on Travis Leithead - due 2014-11-03].
<smaug> MikeSmith: surprisingly well
ArtB: is Alex still available to work as a test facilitator
Travis: I don't believe he is, we should find a new facilitator
<smaug> MikeSmith: but I'm just listening in the background while doing other stuff
<MikeSmith> smaug, OK greatーthanks
<ArtB> ACTION: barstow work with Adrian to find a replacement TC for Alex and D3E [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action04]
<trackbot> Created ACTION-736 - Work with adrian to find a replacement tc for alex and d3e [on Arthur Barstow - due 2014-11-03].
Travis: Gary is interested in testing the spec further
ArtB: that was listed in potential topics, possible CR
Travis: I don't know that we have
much that's controversial
... should we have a breakout
<ArtB> DOM P&S tests
Robin: are there bugs?
Travis: status is we have a CR,
in June, contingent on TS
... the TS has yet to coalesce
chaa13: so we need tests
<ArtB> DOM P&S test open issues
Travis: Ms2ger had tests, some need porting, new ones are needed
ArtB: no test coordinator
Travis: I'm happy to be a facilitator
plh: what could help is if you
can at some point write down the list of needed test
... that helps people pick things up
cindy: I'm happy to help, but I'll need your help to step in
Travis: that would help!
rniwa: do you have any sense on how consistent browsers are?
Travis: the spec largely follows
an implementation that is pretty close to Gecko
... Chrome had serious issues serialising namespaced
attributes
... but they indicated progress
... otherwise the basics are widely implemented
... we'll see how bad that is with testing
darobin: are you going to do anything with innerText?
Travis: there was opposition because it depends on rendering, but some thought it might be doable
<Domenic> someone speccing innerText would be amaaaazing
Travis: happy to include it if
there's consensus, but otherwise would leave it alone
... maybe a new spec?
rniwa: Selection API also depends
on innerText, it would be valuable to have a spec for
that
... it's a lot of work, because it's hard, don't want to block
DOM-PS
<Domenic> for the record, previous attempts (with tests apparently) at http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Feb/0025.html; use archive.org to follow the dead links.
Travis: heard a recommendation to start a new spec as part of the editing TF, we should pursue that, it's a good idea
chaa13: any takers?
Travis: if no volunteers, I can be the default
ben: how does it relate to textContent?
Travis: they both serialise
text...
... innerText serialises "what you see on screen" text,
textContent is pure object model
... let's get a new component in the bug DB for that
<scribe> scribenick: Travis
<ArtB> ACTION: barstow create a new bugzilla component for Inner Text [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action05]
<trackbot> Created ACTION-737 - Create a new bugzilla component for inner text [on Arthur Barstow - due 2014-11-03].
chaals: Moving on to
FileAPI
... oh, on the agenda already... skipping
chaals: FullScreen
... calling tantek
<ArtB> Tantek's proposal re Fullscreen API
chaals: chaals says tantek says
let the WHATWG do it. Anyone interested in publishing in
W3C
... if no one moves it forward, it will likely be parked as a
Note.
ArtB: In our charter, we don't
make binding decisions in f2f meetings. We can take a poll
here...
... any objecting to parking fullscreen?
... (no objections noted)
<ArtB> ACTION: barstow start a CfC to publish a "gutted" WG Note of the Fullscreen API [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action06]
<trackbot> Created ACTION-738 - Start a cfc to publish a "gutted" wg note of the fullscreen api [on Arthur Barstow - due 2014-11-03].
marcosc: can we redirect the parked specs to the active specs.
plh: If the spec is going to be parked, we need to update the TR
chaals: Status information is important, the redirect will be noted in the doc.
marcosc: can we tell Google not to index it?
chaals: Gamepad.
... is anyone following? I see discussion going on...
... OK.
IndexedDB
sicking: I'm not sure what's blocking; implementation seem interoperable
<smaug> Fixing https://github.com/w3c/web-platform-tests/issues/1304 would give quite some more green in IDB tests
ArtB: looking at the implementation report...
<myakura> http://w3c.github.io/test-results/IndexedDB/less-than-2.html
<ArtB> IDB interfaces Web IDL
darobin: Note the
"interfaces.html" (WebIDL interfaces)
... Those are WebIDL related problems, not necessarily
IndexedDB...
... if you opt those out, there aren't that many failures.
plh: for WebIDL we should ignore non-basic bindings...
marcosc: strongly object. We should fix the IDL...
<smaug> IDB webidl tests are buggy
sicking: why do we keep blocking IndexedDB on WebIDL failures
<smaug> not implementations
plh: truth is no one implements WebIDL correctly yet.
<smaug> in this case
plh: implementations have been trying to get WebIDL bindings correctly.
marcosc: if it affects authors, it's bad, otherwise OK.
chaals: If these failures are 'theoretical purity' issues, then we should just move on and fix those later.
joshua: should we followup with a review of the failures just to make sure?
chaals: If it doesn't cause real-world issues for users, then that's the use case.
ArtB: Straw poll: any objections based on result.
sicking: I'm not convinced (we were looking at the 'less-than-2' results...
plh: 37 tests failing out of
595.
... if you factor out WebIDL tests it's even
better.
<ArtB> ACTION: barstow start a CfC to publish a Proposed Recommendation of IDB [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action07]
<trackbot> Created ACTION-739 - Start a cfc to publish a proposed recommendation of idb [on Arthur Barstow - due 2014-11-03].
chaals: Lots of support for moving it forward. Let's ship it!
ArtB: Anything else regarding IDB v2?
joshua: Just focusing on service worker (SW), digesting feedback around using Promises. No progress to report.
<xiaoqian> Travis: MS is considering to implement IME API @@...spec is relatively stable.
MikeSmith: Looking for another
test facilitator... please?
... any other implementation interest?
hober: Goal to support script
avoiding IME seems reasonable
... I worry assumptions are based on current IMEs
... not sure what the future holds.
... scope is reduced; think it looks better than before.
rniwa: Apple is interested in
improving editing; it important to look at how IME API fits
into the overall system.
... we don't want to be introducing lots of ways to do the same
thing.
chaals: We definitely don't want to introduce conflicts.
<ArtB> ACTION: barstow issue a Call for Test Facilitator for IME spec [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action08]
<trackbot> Created ACTION-740 - Issue a call for test facilitator for ime spec [on Arthur Barstow - due 2014-11-03].
MikeSmith: Jonas/Marcos, any help?
sicking: I know what it is; don't know any plans.
chaals: Yandex has an interest; we build IMEs; but don't have anyone to offer.
ishida: to what extent is this JP vs JP & CN?
MikeSmith: Not to go too
deep--but main use case is to avoid IME overlaps with web-based
suggestions.
... biggest problem is occlusion/overlap; that's the primary
scenario driving the spec.
ishida: main users will be JP/CN. Anyone from those communities interested in moving this forward?
chaals: Status: it's moving forward slowly
rniwa: We should try to get someone from KO/CN/JP interest groups to help (vs. folks who've never used them before)
<ArtB> ACTION: charles ask cjk interest group and others about IME (use cases, tests, etc.) [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action09]
<trackbot> Created ACTION-741 - Ask cjk interest group and others about ime (use cases, tests, etc.) [on Charles McCathie Nevile - due 2014-11-03].
cindy: tencent/baidu can help (from China)
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.
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
chaals: Server-Sent Events
ArtB: At one point, it looked
like we were close to finishing, but with new tests, we seem to
have more failures.
... rate looks like 13/124 failures.
darobin: Looks like there are
some major timeout failures.
... timeout could be a test failure, but we don't know for
sure.
... I'm also interested in taking feedback on the
implementation report--send me bugs.
<ArtB> ACTION: barstow re SSE test results, followup on the Timeouts with the 2 test facilitators [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action10]
<trackbot> Created ACTION-742 - Re sse test results, followup on the timeouts with the 2 test facilitators [on Arthur Barstow - due 2014-11-03].
chaals: Service Workers
... Streams API on the agenda already
... URL
ArtB: Yes, this is on the agenda,
combined with Push API
... is on the agenda
<sam2> quit
Yves: Had one bug to fix on integrating the test suite...
MikeSmith: Boris/Cameron not
working on this (don't have time)
... we want to move this ahead.
<ArtB> ACTION: yves, follow with Cameron re PR 271 and the Web IDL test suite [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action11]
<trackbot> Error finding 'yves,'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.
Yves: With no reply, I will probably do this myself.
marcosc: we need a better plan. Cameron is not moving it forward; who can do that.
sicking: Cameron _is_ moving it
forward, just not as fast as we want.
... features are being added from use cases in other specs.
marcosc: We need a proper plan,
we have a devision between v1 and v2.
... we keep fixing features and adding features. It's
continuing to evolve.
chaals: Are you volunteering to publish a v1?
Yves: Yes, of course.
chaals: Straw Poll: shall we try to publish a V1?
marcosc: I think we risk fragmentation.
Yves: It's documenting what's
pretty stable. We have tests, etc.
... we are mostly adding things, not modifying things
<Domenic> -1 on v1. Disagree that things are only being added.
marcosc: we've been talking about the v1/v2 thing for awhile... if Yves can't get it done, we should kill it.
<MikeSmith> 107 open WebIDL bugs
chaals: Any other concerns (from non marcosc)
MikeSmith: I think the level of
effort is high.
... there are 107 bugs... we could use some extra
help.
<ArtB> ACTION: yves, work on moving Web IDL v1 to REC [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action12]
<trackbot> Error finding 'yves,'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.
<Domenic> I am concerned that people will look at v1 and view it as authoritative, when v2 is much more up to date.
chaals: Anyone here want to help finish WebIDL v1?
<ArtB> ACTION: charles try to find someone to help Yves, Cam and Boris on Web IDL v1 [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action13]
<trackbot> Created ACTION-743 - Try to find someone to help yves, cam and boris on web idl v1 [on Charles McCathie Nevile - due 2014-11-03].
Yves: This will help with the "how do we reference WebIDL question'
chaals: Web Messaging
<MikeSmith> ACTION: Yves to work on moving Web IDL v1 to REC [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action14]
<trackbot> Created ACTION-744 - Work on moving web idl v1 to rec [on Yves Lafon - due 2014-11-03].
ArtB: KrisK from Microsoft was
going to provide some updated data.
... is Kris available to work on this?
adrianba: I will check with Kris
ArtB: Same story for Web
Sockets
... Workers
... Simon is test facilitator
... He noted a few bugs, but claims the test suite is
relatively complete
<ArtB> ACTION: adrian determine Kris' availability to work on the Web Messaging and Web Sockets implemenation reports [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action15]
<trackbot> 'adrian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., abateman2, ayanes).
<ArtB> ACTION: barstow followup with Simon re running the Web Workers tests [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action16]
<trackbot> Created ACTION-745 - Followup with simon re running the web workers tests [on Arthur Barstow - due 2014-11-03].
chaals: XHR is on the agenda...
<MikeSmith> ACTION: abateman2 to determine Kris' availability to work on the Web Messaging and Web Sockets implemenation reports [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action17]
<trackbot> Created ACTION-746 - Determine kris' availability to work on the web messaging and web sockets implemenation reports [on Adrian Bateman - due 2014-11-03].
ArtB: Now showing Dmitri's status report on custom elements...
rniwa: For custom elements, the lifecycle methods are defined pretty vague. I believe this needs to be more well-defined.
<ArtB> Custom Elements status from Dimitri 2014-Oct-24
rniwa: "transitioning from script to user-agent code" not precise enough.
ArtB: One other thing: on April meeting we talked a lot about these three specs.
<Domenic> +1
<Domenic> annevk was looking into the transition from script to user-agent code thing at one point
ArtB: dimitri has sent out requests for feedback, but it looks like no one is showing that must interest?
sicking: in our experience, the
spec is lacking and ambiguous; it's been hard to get things
defined.
... we've tried to implement, but it's been
hard/impossible.
<ArtB> HTML Imports status report from Hajime on 2014-Oct-24
sicking: I sadly have no specific examples, but it would be nice to address these issues.
<Domenic> callbacks/transition from user code bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579
rniwa: I don't have a lot of time to engage in tech conference all the time; I'm pretty busy. I prefer to stick to the mailing list to work async.
<ArtB> Shadow DOM status report from Hayato on 2014-Oct-23
chaals: Seems like folks want this and are waiting for it to be done.
sicking: Are the spec editors willing to have co-editors?
chaals: chairs may be willing to appoint co-editors.
ArtB: For resource commitments, folks can talk to us
rniwa: Given Mozilla is implementing, can we see some help from there.
(google) we're open to help (I work with dimitri)
chaals: Poll says lots of folks
enthusiastically ready to see this tech delivered. More test
cases, spec editing help appreciated.
... volunteer now!
... or when you want to :-)
<smaug> tantek: are you following the discussion?
<timeless> scribe: timeless
<scribe> scribenick: timeless
chaals: This sums up the review of pubstatus.
[ Break until 11:00 ]
<MikeSmith> I am a fish
chaals: we recently published
Streams
... Domenic, do you want to tell us where we're up to?
Domenic: yeah
... from the previous discussion, the idea was to split the
work into separate efforts
<ArtB> Streams by WHATWG
Domenic: one for low level JS
API
... and then on top of that, one for Blobs
... a lot of the work tyoshino and I have worked on
<ArtB> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm -> Streams API W3C Editor's Draft
Domenic: is going reallly
well
... the public API is extremely stable at this point
... as we make these tweaks to external behavior
... we've been maintaining a testsuite and a polyfil
... i think coverage of testsuite against polyfil should be 80%
or higher
... which i'm really happy about
... wrt the wider ecosystem
... there's been work to integrate with TCP/UDP Socket
<tyoshino> Polyfill
Domenic: Section Service
Worker
... WebAudio
... tyoshino has been working on ByteStreams
... that's been going really well
... we merged that this morning, it's at first-draft status
<tyoshino> ByteStream
Domenic: the public api is unchanged
<ArtB> WHATWG Streams Open Issues
chaals: during the publishing
discussion
... people said you have a mismatch between the spec and
MSE
<Zakim> MikeSmith, you wanted to comment
Domenic: we talked w/ the MSE
spec author
... the old direction wasn't good
... we're looking on being able to integrate MSE streams w/
other streams in the ecosystems
... kind of the point
chaals: anyone here from an MSE who wants to speak?
jdsmith: we're still trying to
evaluate the changes necessary to implement streams w/ the new
model
... it's a moderate amount of work
... we haven't made a determination of the technical merits
adrianba: i wonder if there's a
little confusion between MSE streams
... and MediaStreams in MediaCapture
... it sounded like what Domenic spoke about was more
applicable to MediaStreams
<adrianba> Media Source Extensions Status of This Document
adrianba: in MSE we have a
note
... when we went to CR
... it was early in the work that Domenic was doing on the
Stream API
... we took a dependency to a Stream Object
... a readable stream that could be read asynchronously
... i think that dependency should be to
ReadableByteStream
... i don't think MSE has a big issue for integration
Domenic: i was talking with Aaron
Colwell
... AppendStream
... could take readable stream with bytes
... we also want to expose a writeable stream
... the AppendStream pattern is a little specific to MSE
... but we also want to allow people to just write to a
WritableStream
adrianba: that makes sense
Domenic: that shouldn't block MSE from advancing
ArtB: at one point, there was
discussion, that Streams would move into TC39
... and become part of EcmaScript
... is that still the plan?
... do you have any update on it?
Domenic: as i've been working on
it, i'm not sure
... it's JS
... it takes no dependencies on Web specific stuff
... on the other hand, EcmaScript is very small
... and this would be very big
... so I want to see what the committee says
... I'm sure this could ship in multiple environments,
including Node.js
... not just theoretically, we (me) could get this shipping in
Node.js
israelh: how does the fact that
there's this portion of Stream APIs in WHAT WG
... how do we take a dependency on that?
... I understand W3 process to documents
... but this other dependency
chaals: there are 2 ways you can
do it
... one, you can publish a version of the content @ W3C
... WHATWG says "we can have specs you can fork, but we don't
want you to"
marcosc: we had a call with
tyoshino and others
... the WHAT WG version would be an ED
... and we'd work with the W3 Process
... because we understood it was important for MSE
... plh put forward the proposal to have [WHATWG] EDs in
TR
... particularly for Streams
Domenic: we had that call a while
ago
... I agreed that if that's what it takes, that's what I'll
do
... I'd like to investigate a way to reference directly
... if not, then we can just copy
plh: on ED, what we're doing for
this is to have no human involved in propagating WDs
... I wouldn't want people to lose focus
... on Wednesday, we'll have W3C 20
... we're going to use a plugin to broadcast live
... we have users today who'd love to broadcast live using
HTML5
... until we get Streams done, we can't do this without
plugins
... can you get it done by Wednesday (and Deployed)?
<plh> plh: :)
chaals: W3C needs to get a
document, or people need to figure out how to reference
... this is politics... including us
israelh: do we have an action item to do the copying?
Domenic: all commits are
reference global by unique url
... you can reference a single version
... i'm willing to work with you guys on this process
chaals: my understanding is that we have an agreement to publish a W3C version from time to time
Domenic: i will not go back on that agreement, even though I like it less and less
chaals: anything more on streams?
ArtB: thanks Domenic
[ Break until 11:30 ]
s|-> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Streams API W3C Editor's Draft |ZZZ|
<ArtB> XHR1 ED
jungkees: we already discussed
before the meeting
... speaking on behalf of the Editors
... we decided to publish a new version
... at W3C
... to have a stable version
... we will specify clearly that "this spec specifies features
as of this date"
... "but that for future versions/features, you will have to
use the WHATWG version"
<ArtB> XHR L2 ED
chaals: straw poll, do people
think that's a crazy idea?
... publish XHR1-legacy spec
... and that there is no current plan to work on future
versions of XHR in this WG
weinig: what's the value?
chaals: there's value to have a
referenceable version
... like what Spanish governments use
<MikeSmith> Comments from bz on earlier proposed options
chaals: lots of people use
this
... they use basic features of non bleeding edge
technology
... including XHR
... quite important to consumers/market
... they say, can we please have a stable version of the
spec
... W3C happens to be in a position to do that
... if you try to tell WebMasters working across Spain, they
have real problems working within their legal requirements
weinig: if we don't do it, what would Spain do?
chaals: it depends on whereabouts
you are
... some will go out and make stuff up
... a lot of places will just NOT USE XHR
... which is destructive
... because XHR is really valuable
<Zakim> MikeSmith, you wanted to ask if bz is on board with that plan
MikeSmith: it sounds like what
you're planning to do is what bz thought was a good idea
... but it's good to confirm this is in line with what bz
suggested
[ bz: If we want to publish something at all, I think this is the most ]
[ ... reasonable option, frankly. I have no strong opinions on whether this ]
[ ... is done REC-track or as a Note, I think, but I think such a document ]
[ ... would in fact be useful to have if it doesn't exist yet. ]
Yves: what's the current
status?
... having only one document with errata?
jungkees: the current ED / latest
public WD
... don't have the changes from the Fetch spec
... what we're trying to do is publish the legacy capabilities
and features that the browsers implement
... saying that this spec defines those capabilities / features
that browsers implement as of this date
Yves: do people want to add more things to XHR?
jungkees: that would be
XHR.2
... we don't have an idea of what that is
... annevk is working on Fetch
... he pointed out several features as well
... there will be more changes as time goes by
... we aren't following that point
... what we're trying to do as of now is that there's a pointer
to the future spec (outside W3)
... the editors haven't discussed a v2 plan
... forking Fetch wouldn't really work
... WHATWG is working on Fetch very actively
adrianba: XHR is a really old
technology
... we (MS) shipped it a really long time ago
... I think there's a bunch of sites on the web that use
it
... the Spanish people will use it once we get this done
... There are some issues w/ event ordering and other related
things
... I think there's particular value in having a REC with IP
commitments
... I'd like to see this done w/ minimum effort
... get the legacy thing written down
... don't worry too much about implementation differences
... I remember being here five years ago having the same
discussion about the differences
... the web hasn't collapsed
... let's get this done
jungkees: we could publish as NOTE
[ NOTE does not get IP commitment ]
ArtB: I support publishing
... at some point, we published Level 2
... we should at a minimum move this to WG NOTE, gut it, and
include a pointer to WHATWG
... if there's support for that, I'll make a CfC for it
... on L1, do you want to move it to REC?
jungkees: we thought it brings
value to the industry
... but we'll follow the decision of the group
ArtB: the plan of record is to take L1 to REC
hallvors: on the future of XHR
and Fetch
... annevk's plan is to merge XHR into Fetch
... going forward, there may not be an XHR spec at WHATWG
... just a Fetch spec
... I think we should just get rid of the level 2 draft
... and just refer to whatever annevk has developed
marcosc: i'd like to hear from
the Editors what changes they expect to make
... and in what time frame
... let's move this to PR
<ArtB> ACTION: barstow start a CfC to gut XHR L2 and publish a WG Note [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action18]
<trackbot> Created ACTION-747 - Start a cfc to gut xhr l2 and publish a wg note [on Arthur Barstow - due 2014-11-03].
jungkees: the status of the
document is WD
... we have a Test Suite
... we have ~80% test cases passing more than 2
implementations
chaals: if the Editors have a spec
<ArtB> XHR Test Results
chaals: and it's highly likely
that people can put XHR in web sites
... and have it not fall over
... then we can take that argument to the Director
... and say that
... and that is how we'd get it out the door
... i'd like to return to the straw poll
... are there people who object to the proposal that we publish
L1?
[ None ]
scribe: are there people who are in favor of the proposal that we publish L1?
[ A good number of hands ]
Yves: there are a couple of tests
with failures
... due to implementation bugs
... it doesn't mean that the specification is failing
... they're bugs in the implementations
rniwa: are there inconsistencies between the XHR1 spec and the WHATWG spec?
jungkees: Fetch spec is more interested in the underlying details
chaals: are there behavior differences?
jungkees: annevk mentioned
Service Worker
... but XHR2 doesn't cover that
rniwa: does the current XHR1 spec
have inconsistent behaviors to the WHATWG XHR spec
... if someone implemented XHR1 perfectly and that was
incompatible w/ WHATWG
... that would be bad
jungkees: WHATWG just has more
features
... there wouldn't be inconsistencies to the legacy
behavior
marcosc: i don't think anyone would implement just XHR1
chaals: people will use just XHR1
<Domenic> there are behavior differences
<Domenic> XHR1 does not go through service worker
<Domenic> WHATWG XHR goes through service worker
hallvors: it's important that we
not specify in XHR1 things that are incompatible w/
WHATWG
... most of the differences are due to refactors
... moving things from XHR to Fetch
... I think we should do some extra reviews to make sure we
don't have incompatibilities
... so that developers who implement to our spec won't have to
change and change back
plh: I was going to say what I
said to the CSS WG 8 years ago
... recommending a spec that isn't getting implemented isn't
useful
<Domenic> earlier someone said publishing would be useful for developers. that is not true. tutorials are useful for developers, but a(n outdated) spec is not.
plh: unless the implementers will
change their implementation
... we need to spec what's implemented
... no use in recommending a spec that isn't implemented
... we need tests and make sure it's implemented
... this is what we need to spec
chaals: introducing known
incompatibilities is dumb
... there's a use in having things defined that work
... there's nothing wrong with saying "doing this would be kind
of dumb"
... clarifying bits that would have trouble
... with a warning of where to look
... these are all good things
... including getting/giving IP commitments
adrianba: it may be that to follow the CSS model, we may need to add some ambiguity to the spec
[ laughter ]
adrianba: from the browser
perspective, it isn't super important
... but to allow for developers to read this
... saying you should have things in a certain order
... if someone relies on this order, then that's a
problem
... if we say "you should do it this way, but you can't rely on
it this way"
... using those test results, we might want to codify those
differences
chaals: you want us to describe the known unknowns
adrianba: but not the unknown unknowns
[ laughter ]
chaals: seems there's quite a lot
of support for the plan of record
... a spec that's useful that people can use
... and publish it
... i suggest that a provisional resolution is that's what we
do
... objections?
[ none ]
[ Lunch until 1:00 pm ]
<johnmellor-chrome> I'm one of the people on the phone
<ArtB> Push API Slides by Shijun
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
Shijun: The slides are based on
the mailing list
... We want to use Push
<inserted> Scenario analysis: RTC call with push message slides from Shijun
[ Slide 2 ]
Purpose
Make sure we understand the steps and options in the basic E2E flow
of Real-Time Communications (RTC) with push message, i.e. push an
“incoming call” notification to the user.
• Identify bottlenecks and open issues.
[ Slide 3 ]
Priorities
• Low latency
• High reliability
• High power efficiency
[ Slide 4 ]
< graphic >
Shijun: if you use
Skype.com
... the user goes there, locks in
... we want the app to be able to register something for the
user
... it isn't sensitive to realtime
... the user isn't making a call yet
... we need to set up something for the service worker
weinig: this proposal doesn't
include the security model
... for insuring that you want that push?
Shijun: the security model isn't
included in that yet
... I'm sure within the WG people here, there are people
interested in Security/UI/...
... Here, we want to focus on Low latency, High reliability,
High power efficiency
israelh: The assumption we're
making is that
... by the time you're going to deliver these messages
... the handshakes and correct permissions have happened at
this point
... handshakes with servers
... client registration has been done
weinig: doesn't that mean we
should address them before?
... since they're pre-reqs
Shijun: we recognize that it's an
issue
... but the focus for us is to understand the scenario when the
user makes a call/receives a call
... we're not trying to ignore/dismiss the other topics
[ Slide The Scenario: RTC call with push message ]
Shijun: flows from app server to
push server, push server to push client
... push client to UA
... -- that's specific to the device
... it's implementation specific
... the next step is UA to Service Worker
[ Slide -- #4. UA dispatch the message ]
• Current option
a. UA wakes up the service worker (SW) and dispatch the message to the SW
b. SW processes the message
c. SW displays a notification, and optionally renders a ringtone
d. Upon user click, SW launches the webapp
Shijun: that's our expectation -- the sound isn't defined, just an expectation
• Questions
1. Latency – How much latency between “UA receives the message” and “SW
displays a notification” to user?
2. Reliability – Can SW stay alive until user click? (issue #85)
3. Power Efficiency – Are long-living SWs a problem to the device? (issue #84)
Shijun: are we introducing
latency beyond the network overhead
... pause here for comments
rniwa: without knowing details of
the api
... keeping the SW alive doesn't seem possible
... i could have my pc at work alive for 48 hours
... and get 50 notifications
... there's no way i want 50 SWs running on my computer when i
get back
slightlyoff: thanks for the
detailed description of the process
... i think johnmellor-chrome will say the same
... SW is designed to be killable
... to get reliability back
... we'll pass a transparent structured data object to the
SW
... the application sends data w/ the notification
... when the notification is clicked, the data can be returned
to the SW
... this gives power efficiency and data availability
johnmellor-chrome: latency in
Chrome/Nexus 5 is <750ms
... you receive a message in Java
... it wakes up the browser
... it wakes up a SW
... we think it's possible to optimize this a lot
sicking: we've found
latency
... the most expensive piece is starting the relevant
process
... starting a process to show a notification
... when the user clicks the notification
... we always need to start the related process
... that's the bottleneck
... -- in FirefoxOS
... it doesn't matter if we're starting a Worker or a UI
... when it comes to Phone calls
... vs. a Chat thing
... you don't want to just display a notification
... you often want a full screen thing
... you want a picture of the caller, and a yes / no
button
... to display that, we need the full process
bryan_: i'm assuming the question
about latency will resolve itself
... based on experience w/ testing
... i'm assuming SW will minimize startup time
... I assume a WebRTC app that you use for calling
... will need a long lived SW
... but we need to optimize this so the response to the
incoming event is minimal
... the thing that receives the event could be a call app
ui
... to the extent that this is dependent on browser
technology
slightlyoff: your 8s window
target
... -> shujin
... what does that include?
[ Slide #4-a. Alternative option ]
shujin: the end to end
latency
... from server to device
... and coming back with confirmation
... 65% <1s
... for the app to launch the background process is pretty
fast
sicking: we have System Messages,
which are like SW
... we found that works really really well
... we have yet to find an instance where we need to keep an
application running in the background
... we find additional events to wake the application
... if an app wants to poll, it can use a scheduler
... for online, we can use notices
... for incoming messages when the device is off
... we can have a startup message and deliver the
messages
... we haven't found a case where we need long running
background
slightlyoff: did you have 85/95% numbers?
shujin: no
... our experience isn't browser specific
[ Slide #4-a. Alternative option ]
• Proposal
a. The push client wakes up a lightweight independent background process and pass the message to
it
• The background process can be developed by browser implementers
• This process only handles push messages
• The push client automatically wakes up this process when needed
b. The background process parses the message property to identify predefined action(s)
• The process only executes a small set of predefined actions: display notification, play ringtone
• PushRegistraiton can be registered with the predefined action(s)
c. If predefined actions are identified, the background process displays a notification, and optionally
renders a preloaded ringtone
d. Upon user click, the background process launches the UA which in turn forwards the push
message to either a webapp or a SW
<MikeSmith> Scenario analysis: RTC call with push message slides from Shijun
shujin: the background process is
an extension of the push client
... that's the solution we see, which could be more friendly
for mobile devices
slightlyoff: what is the
memory/cpu cost of the persistent background process?
... we've found we're middle of the pack for Chrome for push
messages (cpu/memory)
... vs. gmail/facebook
shujin: i don't have the numbers
handy, but i can give the numbers to the ML
... this is what is recommended to Windows apps
... for push message in Windows, >99% of the messages are
processed by the background process
... IE is considered by Windows as an application
... and it should have a separate background process
sicking: i think that's the model
that the spec is proposing
... except that, the background process is the SW
... i think what jake is proposing, is
... in what instances do you only want to display a
notification/ringtone
... if you're playing a ringtone, you also want to render an
onscreen ui
... if you're displaying something, you might want to download
data
shujin: analogy, each website as
an independent app
... from the User perspective, each website might want to
tailor the experience
... but based on the ML discussion, there's a tradeoff between
how long you can keep a SW alive
... and how much can be done in a SW
... what we're proposing
... IE has a special background SW
mt_: (Martin Thomson)
... what you're asking for is something faster than the XX
ms
... i don't think this requires more than a lightweight
process
... an SW spins up whatever is necessary to run the js in the
SW
... a very lightweight process that handles the notification,
handles it
... if that requires launching the rendering engine
... it invokes the API for that, to get that
... i don't see that's a problem
... I see an opportunity for the OS
... for the lightweight process to be able to handle the
notification w/o starting a SW
... a message comes down, immediately rendered into the
notification window
... maybe we can provide a way to say that certain messages can
become a notification directly
slightlyoff: in SW, we note where
we don't know what we don't know
... where app-cache failed
... we have this because we don't have a good track record of
doing that
... i caution us to use data
... 750ms is the full time w/ Chrome + background process
... the entire world of optimizing is several quarters
forward
... we think there's a huge ramp of opportunities
... i'd like us to prefer generality over specific cases
... if there's specific evidence for the relative weight
... if you have credible evidence
... i'd like to caution us on specifics w/o data
mounir: the push team at Google
when we designed the Push API
... we thought about a specific API for notifications
... for the reason sicking noted
... a lot of sites will have different needs
... as noted earlier, we could make that optimization
later
... offering faster
... unlike app-cache (not working)
israelh: maybe the paradigms that
we're looking at
... from our perspective, we wanted a common paradigm
... we wanted very little you could customize
... maybe the various more powerful rendering experiences we
didn't want
... we wanted a more cohesive experience
... our model is how we've been doing it since Windows 8 (3
years)
... we need to give you the specifics, i agree
... this subprocess we're describing is very specialized
... only for push
... we didn't need to enable more
... that we'll have the UA in control
... allow the SW that are instantiated to get the message
<mt_> I think that perhaps slightlyoff is casting this in the wrong light: SW *is* a lightweight process in a sense, but it just gets forced to be idle if it isn't dealing with an event
israelh: we aren't saying it
isn't a good thing
... offering an intermediary that's sort of lightweight
mounir: with your process
... if i want to update my database
... say i have a tutor client
... i get a message
... i don't click on it
... i go offline
... the app can't save that?
israelh: there are different
types of pushes
... some are raw data type
... which potentially push to the app running behind the
scenes
... that gets the registered events
shujin: in our case, the push
message is the raw format
... in comparison to the windows messages
... we're talking about letting the developers choose
simple/lightweight or not
... giving the developer more power, from a different
perspective
mounir: you're making an early
assumption
... that developers get a push message, and show a
notification
... many times the developer might get data, and show the
notification later
shujin: i agree we shouldn't
remove that from the developer
... if the message has enough information that the developer
can do without predefined actions, that's still available
... when SW is run on different devices
... whether a SW can complete is another question
... whether to enable a rich experience, somehow we might not
be able to guarantee
johnmellor-chrome: the standard
thing is notifications
... when i look at a native app
... if an app is in the foreground, it usually won't show a
notification
... some apps will only show notifications if you aren't
looking at inbox
... some apps will download content
... gmail might get data
... but only show information if you've configured labels that
match the data
... you could imagine location specific decisions
ddruta: i think it would be useful if the push could go to different UAs
shujin: the push client is an OS
component
... apps can implement their own SWs
mt_: i think we're reaching the
saturation point
... a lot of the pushback is around the optimizations MS
made
... people aren't seeing strong justification for doing
... that's what I got from slightlyoff , that's what i got from
johnmellor-chrome
... i think you should go back to the people at MS and ask why
they put in the shortcuts
... something more generic would be useful here
... we could make this optimization available
... but there are costs involved
... with the api as structured
<chaals> scribe: chaals
<timeless> ... those costs are significant
timeless: They wanted to enforce a consistent UI. (Answering MT_)
… every time the user has a similar thing, in a different client, they want it to look the same. (This is what Shujin said)
… as a user, I support that goal.
<timeless> scribe: timeless
israelh: as you get a flurry of
notifications
... the client can synthesize those
... it can buffer those notifications together
... I don't think we're saying that the model shouldn't support
SW
... that isn't what we're saying
... what we're saying, what others are calling
optimizations
... we'd like to see a mechanism where those optimizations are
allowed, enabled, encouraged
... as opposed to no, it has to be this other way
mounir: could we keep that door
open for a v2 api?
... as opposed to v1
israelh: we were under the
impression that the Push API was still early enough
... that we could make those comments
... if we think we're at LC for Push
mounir: i don't think it's an API
maturity
... i think it's a developer feedback issue
kenji: as the PM for the team
implementing SW
... if you can provide developer feedback to explain why
... that's good feedback for us as well
shujin: would it be helpful if we
could propose an API?
... put on the ML for discussion?
... and then discuss for current spec
sicking: one way to get
implementation/developer feedback right now
... is looking at existing apps
... do existing apps
... where the only thing they do is play a ringer/display a
notification
... we know twitter only displays a notification
... but when you click it, you might not see the tweet
... provide UCs
shujin: we can go back and collect the data
<Zakim> timeless, you wanted to point to BB10 apps
timeless: use case for blackberry
is normal things, you can send push notifications, we had
categories and common apps fit into these categories
... for most of these things it worked well
... some thing did drain battery, but most didn't
chaals: would people like to see an api?
[ a number of hands for yes ]
chaals: or would people like to see data?
sicking: i'd like to see data?
weinig: what data?
chaals: would people like to see UCs?
weinig: i would
israelh: a quick clarification on
UCs
... how much more detailed on UCs do you want to see?
... for example Twitter, Facebook, Email client
... the UCs are fairly common
... what granularity are you looking for?
mounir: those UCs need to come w/
numbers
... if you show Email clients only show notification w/o
fetching data
israelh: if you want only
numbers
... perhaps i can give you just numbers
... these types of apps do these types of things
... our Store app shows notifications when it finishes
updating/downloading
... shows notifications for new apps/updates available
... popular apps w/ this type of behavior
weinig: in terms of UCs, I think
we heard a lot of UCs here
... it would be good if you came with a specific list
... and then to slightlyoff, indicate which UCs go with which
patterns
israelh: we can work with that
chaals: we're done, thank you
bryan_: in the last month, there
were a number of issues raised to github
... a number have reached consensus
... a number have engendered discussion
ArtB: we have a lot of holes in
tomorrow's agenda
... if you want to use slots
bryan_: yeah
chaals: the 11-3pm overlaps with AC
<mt_> I'd like to get any decision on the agenda change promptly
<bryan_> I suggest we update the wiki with the "lightweight / low latency" use cases
weinig: is there a place where
the workflow for clients can be seen?
... i looked at the slidedeck
... "client" = "web site author"
mounir: client registers for
push, you get server+registration id
... developer sends that from client to its own server
... which then talks to the server w/ the registration id
... apple has its own push server
weinig: if a client wants to use
push notifications
... they need separate agreements w/ each vendor?
[ YES ]
mounir: there's a separate discussion in IETF to standardize that
<schuki> scribenick: schuki
<timeless> scribe: schuki
arunranga: file api can go to
LC
... whenever the publishing moratorium is lifted
... we also want to talk about file system api
ArtB: i am displaying the bugs
for file api
... we can go to LC with this
... does anyone have issues with this?
<ArtB> File API Bugs
sicking: if we mark file lists
(as at risk) and remove later
... it's a matter of doing a pull request on the spec
... so we should just mark it at risk
... and then do the rest
<ArtB> ACTION: Arun mark file list as Feature @ Risk [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action19]
<trackbot> Created ACTION-748 - Mark file list as feature @ risk [on Arun Ranganathan - due 2014-11-03].
<ArtB> ACTION: barstow start a CfC to publish File API LCWD [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action20]
<trackbot> Created ACTION-749 - Start a cfc to publish file api lcwd [on Arthur Barstow - due 2014-11-03].
sicking: it has been at LC, may be brought back before then
<anssik> http://www.w3.org/standards/history/fileapi
plh: which webapp will be break if we remove file list
sicking: hopefully none
weinig: file writing was removed at some point?
sicking: no was always in file system
weinig: so file saving is in file system?
sicking: yup
arunranga: you can trigger a file
save path
... this was probably the specs put forward by google
... file system then diverged
... this google spec has become a note
chaals: so yes, this is what file
system does
... q about file api
arunranga: requirement is file save as
<ArtB> File API UCs and Requirements
chaals: says no, as file save as can't be met
sicking: at best this statement is ambigous
chaals: so you're not meeting the requirement?
sicking: that's right
<ArtB> ACTION: Arun deleted the UC in File API that starts with "Data should be able to be stored ..." [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action21]
<trackbot> Created ACTION-750 - Deleted the uc in file api that starts with "data should be able to be stored ..." [on Arun Ranganathan - due 2014-11-03].
arunranga: so, the room agrees requirement should be removed?
chaals: yes
<arunranga> http://w3c.github.io/filesystem-api/Overview.html
arunranga: file system api link
^
... editors draft
... this file system api build on model put forth by google but
uses promises not callbacks
... there are some things we want to preserve, url
... this spec also relies on platform primitives: event stream
e.g.
... we will follow some ideas in posix, we have some ability to
write also
... there is the file handle and writable file handle
... we want feedback from implementers
<timeless> scribe: timeless
israelh: ... say i keep something
open
... allow my writes to prevail
... it doesn't seem to be as analogous as indexeddb
... because you can't necessarily add transactions
<inserted> scribe: schuki
sicking: would be good to here microsoft comments
israelh: we are thinking of the model of keeping something open
sicking: typically there's never
multiple users touching a file
... because they're sandboxed
... storage policy for filesystem is no difference between
indexeddb and sql
... you could implement file system api on top of indexeddb
with some issues, and no file system url working
... then it's a different api
... actual storage policy is same as indexeddb
israelh: i thought there was a notion that you could break out of sandbox
arunranga: i can see how that
could have come from discussion of use case
... this use case is a "nice to have"
... we want to focus on sandbox major
... if this use case is misleading we will abandon
... bigger use case of breaking out does not seem credible
sicking: i agree
israelh: why not enable with log file? People are used to this
sicking: you could easily create
dead locks
... the problem is if you open pages, one that opens file a,
then file b, then does stuff with either
... then you have another sub component that opens file b
... then dead lock - this isn't good
israelh: so if you surface dead
locks to the applications, then you can manage them
... we could provide mechanisms to handle them
... more intuitively than indexeddb
sicking: it could cause race conditions then
[ laughter ]
israelh: so then the complexity of programming increases
sicking: complexity is a
complicated thing
... you do need to open the file open, but then no need to deal
with dead locks
... is it simpler to have things like they are now, or open the
files in order always?
... seems like no good solutions
... still interested in microsoft implementation status
israelh: we're looking at it
<arunranga> israelh, great :)
chaals: arunranga you said use
case of having files is not credible
... want to build on sandboxed system of indexeddb
... is this a solution looking for a problem?
<ArtB> ACTION: Yves followup with Cameron re PR 27 and the Web IDL test suite [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action22]
<trackbot> Created ACTION-751 - Followup with cameron re pr 27 and the web idl test suite [on Yves Lafon - due 2014-11-03].
chaals: what are the barriers (if
can build security system that could work) to using the file
system api to handle access from multiple apps to same
file?
... has something been built that cannot handle multiple
access?
sicking: there is nothing
inherent with files which makes them more interesting to share
than with things such as indexeddb
... firefoxos is doing something, but for security reasons this
wouldn't work for web
chaals: there are use cases when apps would want to work on the same files
weinig: from apple perspective:
osx is file coordination system, you're only allowed to do
something in a block
... you can use filehandle to do stuff
... user has to give access to all files on ios
sicking: we have multiple solutions for firefoxos, in every case user must make decisions
chaals: question remains: is there something in file system that could break multi user problem?
sicking: no, we just need to solve the security problems
weinig: same q as before: how does using this api trigger an explicitly save somewhere else?
sicking: open write
... there's nothing to trigger save dialogue
weinig: this seems to be a major pain point
sicking: file saver api could be used, with progress saver events
arunranga: you can request the
save as and trigger the dialogue
... this file system api allows write to sandbox file
system
... is there a req to do something more to prompt user
interaction?
schuki: earlier sicking mentioned could use download attr on anchor tag
weinig: no, was just confused!
arunranga: we would like feedback from apple
adrianba: 1) save case is
independent from file system api
... we want something more than anchor tag
... we made proposal previously
... proposal was you may have a offline app, an online app, so
want to simulate a local application simulation dialogue
... therefore a number os use cases exist for saving
scenario
... need to revisit
<Zakim> timeless, you wanted to ask if anyone has actually *used* that approach (href=blob:, download=) ? or + sending a click to that
?
<anssik> FWIW, here's my demo <a download> w/ .click(): http://anssiko.github.io/html-media-capture/capture-and-download.html
timeless: do people do the flow of anchor tag with blob and download attr?
sicking: i think gmail does it but not sure
weinig: could non normatively reference in one of the api specs so other people don't get confused
<arunranga> weinig, I will take an action to do this
<weinig> thanks arunranga!
darobin: could use a json trick but could create a massive json file to pull down
<timeless> timeless: +1 to weinig's suggestion
ArtB: coffee break
... no coffee
... not here till 3
... actually 5 mins away
... let's start straight after 3
[break: return at just after 3pm]
sicking: arunranga is working on
some edits to file system
... apart from that, given microsoft is maybe interested then
we should move forward
ArtB: arunranga do some edits, let me know, and we'll go for working draft
<timeless> ACTION arun to do edits on file system spec
<trackbot> Created ACTION-752 - Do edits on file system spec [on Arun Ranganathan - due 2014-11-03].
arunranga: we can take some discussions to mailing list
jungkees: service worker cfc ok?
ArtB: yes go ahead
<timeless> s|https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm">https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm -> Streams API W3C Editor's Draft |XXXscribeERROR|
<sicking> arunranga, might be worth adding that to the File API. We could even replace the current "save to disk" use case with a informative note that says that the spec supports it in collaboration with the HTML download attribute
[break: return at just after 3pm]
<arunranga> sicking, yep, promised weinig I would do it
<benjamp> Agenda for Selection, Editing, Intentions
<benjamp> Explainer for Intentions: http://w3c.github.io/editing-explainer/commands-explainer.html
<benjamp> Explainer for Editing
benjamp: i have added links to
irc ^
... overview: started with editing (exitensible web summit in
jan)
... started to think about how to spec it
... since then had meetings on editing, and user intentions
[diagram in spec]
benjamp: diagram shows inputs,
and what the user wants to accomplish
... today the situation is not well connected between the
two
<ArtB> W3C Editing Explainer
benjamp: trying to solve both at the same time
<ArtB> User Intentions Explainer
benjamp: we are brining people
together to talk about this
... explainer doc (link above) talks about how we can make a
single shape for all these intentions
<ArtB> Selection API
benjamp: interested groups /
apis: html, webapps, indie-ui, selection api, clipboard api,
scroll,
... also interested in how this works with web components
... to look at behaviours rather than just click events
... also want to discuss how we can work on this with ARIA so
you can update properties on the fly
<cyns> https://rawgit.com/cyns/wapa/master/wapa.html
<cyns> Web Accessibility Properties and Actions (WAPA) Explainer
benjamp: task force is working on editing and user intentions
<darobin> http://lists.w3.org/Archives/Public/public-editing-tf/
benjamp: [referring to spec]
<ArtB> Editing TF list
benjamp: you can refer an action
based on intention
... we want to have a unified shape, and we need to work this
out
... clipboard is one implementation
... indie-ui is another
... dom lvl3 is working on implementing this
... based on everyone's use acses, we could come up with small
number of events
... e.g. input, scrolling
... can we create 4/5 individual events to represent?
jcraig: i see distinction between
discreet and continuous events
... most so far have been discrete
benjamp: rick, how about for scrolling?
richt: we were worried about a
lot of events
... does pressing down want to make many different
events?
... the harder problem is how these things are composed
... are dom events the right thing for this?
... scroll is a different case, a node may have a custom logic,
then i need to work with custom logic and browser logic
... we don't have a solution now, but this is a big
question
rbyers: e.g. input. If i hit letter 'a', custom node, how does the flow with custom script and browser handle work?
benjamp: would this be like other events?
jcraig: yes
... we talked about instead of having custom event types you
could have custom control
... e.g. this div represents stepper
... so it has a settable value, as well as increment and
decrement methods
Norbert: it's getting
complicated! More things: input methods [IMEs] (intercept
keyboard events)
... minimising api would mean application needs api to talk to
input method
... spelling checkers are another issue
... modifying text behind your back
... can cause issues
benjamp: editing & intentions
can be seen as different
... editing there could be some way that IMEs could be
lost
... we need to think about this, file a bug on github
rniwa: you have an action before
/ after, key input is discrete, either before or after
... these events bubble, content editing host could cancel but
not everything can do this
... could also discuss input methods
... behaviour input methods interesting: random text is
corrected by spelling mistake, which cause issues
... e.g. mac auto correction bubble
... so, intents might not identify everything, may need to
think about context
<Zakim> timeless, you wanted to say that IMEs and spellcheckers should be considered as the same
timeless: spellchecker could be
considered the same
... some devices don't have a keyboard
... mobile device e.g.
... web should not treat these differently
... latin lands are used to spell checkers - cjk to IME, -- and
not to the other one -- by merging the concepts, you ensure
that anyone who codes to handle one case doesn't break when
they encounter the other
cyns: idea is to solve use cases
[1] scenario around another state by downloading another bunch
of ARIA [2] word document, these can be long, dom has subset,
content could have list elements, numbers etc, doc isnt good
representation of a document
... idea is to allow assitive technology to trigger
events
... there may also be more actions that api could do
... this could work for testing of custom elements and web
driver accessiblity
<cyns> https://rawgit.com/cyns/wapa/master/wapa.html
benjamp: there are many scenarios
that need to be solved
... needs intention shape for intention events
... then take this and see if it works for use cases
... we need data
... input text could be one, and data would be text
... good idea?
... if we had unified shape: intention, type, data
comments?
richSchwer: if you're going to
scroll, you need range
... you need to tell app something rather than work it out
itself
... each platform has differences between each accessibility
api
... we need to get that to be seamless
... we're getting back to the design pattern
... about delivering inform to the app
rniwa: it would be useful for
interested parties to come up with use case list
... to add to explainer
... then proposal can be vetted against these use cases
<Zakim> jcraig, you wanted to mention dictation UI is similar to IME UI and to mention API for custom RTE may be the right approach for editing. and to mention intentional events
jcraig: rniwa Norbert were
talking about IMEs, an idea could be an api which custom view
could implement
... jcraig: reconciliation with physical events, first event
object could have id, and subsequent events could reference
previous events by ID, to reconcile which physical events
caused the related intention events
chaals: generic shape for events: good idea?
[5/6 hands up]
<Zakim> chaals, you wanted to ask about shapes
chaals: +1 to jcraig, need to
figure out how intentional events can interact
... need to figure out where events go when you start to pile
them
... we looked at this before
... a very simple set in 90s
... we had a set of events and they weren't used
... once you've done touch / pointer / slides etc.
... then remember you forgot mouse!
... the data payload for event, i am hearing rich and jcraig
say objects need to provide information
jcraig: yes so if view can take scroll then it should tell you how far you canview (scroll poisition, scroll range)
<Zakim> cyns, you wanted to agree that abstracting the platform apis is a goal
<Zakim> darobin, you wanted to have use cases as code as much as possible
darobin: could have shims, reuse code methods
rbyers: is i have a componet that
manages a list
... when you hit space it does certain things
... inside this list people could make widget
... now if someone hit space bar what happens?
... ideally it extensible web view should handle this
... if we say devs design for this, then checkbox will never
run, and before event will make container, container creates
beforedefault etc...
<scribe> scribe: timeless
<jcraig> partial interface UIEvent {
<jcraig> readonly attribute EventID id; // UID of current event
<jcraig> readonly attribute EventList relatedEvents; // List of related events, with ID and potentially type of each event.
<jcraig> // This "dismissrequest" event is associated with the previous "keydown" and "keyup" events.
<jcraig> }
benjamp: if the checkbox handles
the spacebar
... ---
... keydown, if handled by checkbox, you're done
weinig: my concern with the
question, and i wanted
... "should we look for generic shapes for intention
events"
... i'd understand you'd want this for keyboard actions
... first a physical key event
... the os gets a chance to get decide what it means
... the thing i don't understand is why we'd generalize this to
many different problem sets from the get go
... i'm not sure why polymorphism would be necessary
... why scroll/keyboard interactions should be handled
identically
chaals: you scroll using down /
pagedown key / gesture / assistive technology
... the issue we have is that if you don't collect each of this
different things and deal with them at the same level
... the problem isn't that a given thing will kill us all
... it's that the diversity means that web developers screw it
up
... web developers interfere with a noticable number of
people's user interface
... scroll, but for a user, it might mean something else
... twitter does this to me, every day
weinig: if it all goes well,
Twitter would just have to handle one event handler for scroll,
and get them all for free
... rubber band or scroll or bump
chaals: correct
... the complication is that there are differences in what can
be done
weinig: it seems to be hard to
fathom custom scrolling with scrolling with
... it would seem you want completely different code
running
[ We have an extra 15 minutes ]
benjamp: we can schedule more
time for editing tomorrow
... what i want to show everyone is what this looks like
... this is a demo of intention events
[ Demo ]
[ presses "a" ]
[ gets an event ]
[ presses "ctrl-b" ]
[ gets a format event ]
[ presses "ctrl-a" ]
<jrossi> Demo
[ gets before selection change ]
benjamp: on this sample, you
could do content editable with intention events
... MS Office wanted to be able to style text w/o being able to
modify text
... to give you a default style for email
... you could do that by canceling all text events except
formatting
... you could talk about how intention events could apply to a
custom component
<Zakim> jcraig, you wanted to mention potential requested code sample: and to [Example]
<jcraig> [Example]
<jcraig> partial interface UIEvent {
jcraig: someone mentioned specific examples
<jcraig> readonly attribute EventID id; // UID of current event
<jcraig> readonly attribute EventList relatedEvents; // List of related events, with ID and potentially type of each event.
<jcraig> // This "dismissrequest" event is associated with the previous "keydown" and "keyup" events.
<jcraig> }
jcraig: we had Jason Kiss
... develop a polyfill for some of these events
<Zakim> timeless, you wanted to say that FCC's complaint form interfered with me
timeless: Both the web page (FCC) and myself wanted to advance to the next field, (I pressed tab), we both won -- I lost (double advance)
rniwa: "Keyboard is easy to spec"
[ Travis kicks him ]
scribe: when you move the cursor,
it said "modify event"
... but different OSs/Browsers do different things
... right could mean right-physical, or next-logical
... cursor end could mean line end or page end
... we need to be careful what kind of extensibility we need to
be aware of
... valueChange
cyns: scrolling
... while you might want different behavior for the scroll
itself
... infinite scroll (image search results)
... you still want to load the next batch of things
... using the intention event
... and other scripts for the details
benjamp: rniwa, maybe actions can
be tied to extensions
... "shift-right-arrow"
... conjecturing, associate with "modify caret" + "to
right"
... if the site wants to do something else, they could listen
to the keys and said a different intention event
... you can modify what an intention is
[ Editing Explainer ]
benjamp: for a keyboard
event
... DeclareIntention(
... changing the intention of an action
... "shift-right-arrow" in RTL
... i want it to be non standard
... I can map this to be "modify-selection" + "left"
... )
... then you can respond to it in the intention handler
<Zakim> chaals, you wanted to say "how you move the cursor is different from browser to browser" is sort of the point
chaals: instead of you listening
to the interface action in the web app
... you get the platform event
... concept
rniwa: what if today all browsers
do selection logically
... but what if a browser wants it to be visually
... extend bidi text selection to the right
... it might be different
... to be able to extend physically
benjamp: if a browser creates
selections that are disjoint
... the browser needs to keep in mind that this may break
sites
rniwa: how do we support new intentions
chaals: we already have that
problem
... we add a new device interface
... and the web app becomes totally unusable
... i suspect that's not a really big problem
... future proofing is always difficult
... but future proofing based on what we've got is a
nightmare
... we will continue to see new intentions
jcraig: rniwa and weinig were
describing selection model changing
... that might be the case for the api to set the specific
selection
... in continuous scroll
... instead of a series of scroll events
... set some values on view
janina: sometimes we say
intention and talk about the way we achieve something
... we need to be careful about language
chaals: that gives you lots of
things to think about
... shall we put this on the agenda tomorrow?
benjamp: yes
chaals: people want to make contenteditable go away
ArtB: preference?
chaals: after 3
rniwa: likewise (but for performance conflict)
ArtB: ok, 3:30-5
jcraig: we had other topics other
than events/editing
... join had topics about selection api
... computed role on element
... user context / user settings
<chaals1> scribe: Chaals
<chaals1> FJH: The idea is to enable an annotation to something that is on the web. You have a body of an annotation annotating something.
<chaals1> … you need to point to the thing you are annotating.
<chaals1> … which might be a part of a resoource - word, sentence, video fragment...
<chaals1> … that's a target of the annottation.
<chaals1> ... the thing you annotate may change. So how do you keepthe target pointing to the right place
<chaals1> … using a word-count might be fragile, for example.
<chaals1> … We might not get perfection but we want robust linking.
<chaals1> … Doug has done some stuff, and Rob too.
<chaals1> DS: I use a Mac, so we have problems connecting to things
<chaals1> s/https://www.w3.org/wiki/Webapps/November2014Meeting//
<chaals1> DougS: This is sort of related to Selection API. Instead of based on user input it is based on something that was being selected before.
<chaals1> … problems include not having ids, having duplicate strings, or a documnt gets changed, ….
<chaals1> [slide: solutions]
<chaals1> [slide: example of context - 32 characters before and after the thing that is being selected]
<chaals1> … have a strawman, looking for help on how to achieve. One idea was using the find-in-page function...
<chaals1> … we don't expose the text locations through an API
<chaals1> TL: There's nothing in W3C platform. In the DHTML platform from MS we had something like this.
<chaals1> … IE's find on page is built on top of this, on the precursor to the DOM range API.
<chaals1> DS: That could be an interesting starting point, perhaps.
<chaals1> ACTION: travis to find an MSDN page that describes this [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action23]
<trackbot> Created ACTION-753 - Find an msdn page that describes the finding thing in IE [on Travis Leithead - due 2014-11-03].
<chaals1> DS: This is all speculative. We want to find text...
<chaals1> [slide: strawman]
<darobin> https://developer.mozilla.org/en-US/docs/Web/API/window.find -> windows.find() is also related to this
<chaals1> … simple case is a string you want to match
<fjh> the MSDN page: http://msdn.microsoft.com/en-us/library/ie/ms536422(v=vs.85).aspx
<chaals1> … have an idea how to style this too.
<chaals1> close action-753
<trackbot> Closed action-753.
<chaals1> [slide: strawman part 2]
<chaals1> [slide: styling]
<chaals1> TL: You showed some potential ways to find the annotation. And you ended up proposing stuff based on literal text and before/after. Is there a reason why that bubbled to the top?
<chaals1> DS: Not really.
<chaals1> … don't know how this would work, and what it would try.
<chaals1> … I didn't know how to do edit distance. CSS selector would be the fastest if you knew how to do it
<chaals1> FJH: Did you run this by the annotation conf?
<chaals1> Kristof: We're working on a fork of @@
<chaals1> … we implemented something related to this. You can pass in a bunch of selectors using different types, and a bunch of registered anchoring strategies. The framework is meant to run through the strategies to find solutions.
<chaals1> … they could be ranges, or in the case of images you might want to return specific part of the image which has been identified.
<chaals1> … We have one using Xpath selector, one that is character position, or using context and levenstein distance.
<chaals1> … These all should be extensible.
<chaals1> … Other side of the equation, pass in a fragment and describe it with different selectors, so you get the fragment, and it gives back different selectors.
<chaals1> … We save the selection, and try to re-anchor with several strategies for robustness.
<chaals1> DS: There are plenty of approaches we could take, this is a strawman.
<chaals1> … we want things useful for the platform in general not just annotations.
<chaals1> TL: This seems like a missing piece. You can use selectors, but this doesn't exist yet.
<chaals1> DS: Right. Seen people wanting to find text in the content but not the chrome of a webapp
<chaals1> TL: Manual text finding from the node tree is slow.
<chaals1> DS: Right
<chaals1> … a find in page dialog won't cross or block on boundaries.
<chaals1> RobS: Various ways of selecting the area, and then deciding if something matches. Levenstein distance isn't the same as Xpath.
<chaals1> … does it match vs where is it.
<chaals1> … in open annotation data model we have what we call selectors, - text quote selector and offset. Data offset for arbitrary bitstreams, SVG, fragment selector
<chaals1> … One way forward is to figure out how you transfer a set of selectors via the API.
<chaals1> DS: That's what the options object would be
<chaals1> CMN: Have you looked at the fuzzy pointers developed about 12 years ago for EARL? Like Xpointers designed for HTML, to solve this kind of problem
<chaals1> ACTION: Doug to ask chaals where fuzzy pointers stuff is [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action24]
<trackbot> Error finding 'Doug'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.
<chaals1> DS: There is a lot of prior art here...
<chaals1> Kristof: We find text in a corpus and map it back to where it is in the DOM
<ArtB> ACTION: frederick work with Doug and Chaals re fuzzy pointers stuff for Web Annotations WG [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action25]
<trackbot> Created ACTION-754 - Work with doug and chaals re fuzzy pointers stuff for web annotations wg [on Frederick Hirsch - due 2014-11-03].
<chaals1> … the browser knows where the teext it finds is, but doesn't expose that. Doing so would be good for everyone.
<chaals1> … We are using selectors defined by Open Annotation group.
<chaals1> FJH: What are our next steps?
<chaals1> [looking at http://jibbering.com/discussion/fuzzy-pointers.html is aprt of solving action 754]
<chaals1> FJH: We're looking at next steps. Are there any problems with where Doug is going?
<chaals1> Kristof: Are we doing this to work on any kind of document, or just for a few data rtypes? Because if the former we cannot just rely on DOM ranges now, and need a new type.
<chaals1> ArtB: API scope is a common question for us. One answer is always "what are the use cases"?
<chaals1> … whatis the status of use cases for this?
<chaals1> RobS: In digital publishing IG we have a long set of use cases some of which cover this.
<chaals1> … that's work in W3C and IDPF (who do ePub)
<chaals1> … there are definitely use cases around annotating images. HTML and text are the things that change most often.
<chaals1> FJH: I would argue taht we should start focusing on text in HTML.
<chaals1> … where you know someone will edit it, but you want your link not to die.
<chaals1> … this was discussed in Annotation Workshop and is in proceedings.
<chaals1> ArtB: To best engage with Webapps, should identify the use cases that are clearly in scope.
<chaals1> FJH: We have a proposal that goes beyond the use cases, but we need to figure out how to progress it. It needs to be implemented - do we do that through webapps?
<chaals1> TL: W=You could polyfill now, and it will just be slow, right?
<chaals1> DS: Right. So we should come up with solid use cases, make a spec and polyfill it and see if we get people to agree.
<chaals1> TL: Think you should continue. Please support your scenarios with some APIs you want in general. On finding text, it will probably be prohibitively expensive to find all matches at once. Finding all is an iteration on find next where you can yield back.
<chaals1> … text should be senstitive to unicode issues for characters - some things might not match all the time.
<chaals1> … to generalise it, case insensitivity, regexp, etc would be useful.
<chaals1> … Think that this really is something missing from the platform.
<chaals1> PaulC: Go look at all of the string matching stuff in Xquery/Xpath. We looked at all of those things when we did that stuff. It's in a standalone W3C spec.
<chaals1> FJH: Next steps: Bring summary of use cases to webapps. In our group do a survey of previous work, and produce a working draft and share it.
<chaals1> … want to understand how we get beyond that.
<azaroth> ACTION: azaroth to update use case document and extract robust anchoring items to provide to webapps [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action26]
<trackbot> Error finding 'azaroth'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.
<chaals1> … does webapps have any constraints about timelines?
<chaals1> TL: Is it in our charter?
<chaals1> ArtB: Yep. can be done as a joint deliverable.
<chaals1> FJH: Anything happening in webapps we should know about?
<chaals1> CMN: Look at editing - you can maybe use taht sometimes to help understand what changed, and get updates to keep your pointers able to find what happened.
<chaals1> RB: There is also a CG that worked a while ago on "CSS Xpointer scheme".
<chaals1> … it would have to be rewritten to make stuff work, but I have some notes somewhere and think this can be mapped onto an HTML DOM, and would allow you to make webpointers. It's pretty easy.
<chaals1> ACTION: Robin to solve the rest of the problems related to robust targeting of changing documents. [recorded in http://www.w3.org/2014/10/27-webapps-minutes.html#action27]
<trackbot> Created ACTION-755 - Solve the rest of the problems related to robust targeting of changing documents. [on Robin Berjon - due 2014-11-03].
<chaals1> Kristof: There are different applications and document types, and to support tehm all we should be able to register new anchor types and discovery algorithms. So we should have a framework that applications can use to communicate through, adding new algorithms rather than trying to a priori specify them all.
<darobin> *cough*
<chaals1> action-755 due wednesday
<trackbot> Set action-755 Solve the rest of the problems related to robust targeting of changing documents. due date to 2014-10-29.
<chaals1> … we should be able to inject a new strategy for finding things into the framework.
<chaals1> FJH: Right but I don't think that bears on the webapps group.
<chaals1> DS: That would have to be something that isn't the same as find-text.
<chaals1> FJH: We'll figure it out when we get a better proposal today
<chaals1> DS: Travis were you saying we make something like a regex, and then apply it repeatedly finding the next match is what we should do?
<chaals1> TL: Sure… maybe...
<chaals1> [adjourned]
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Gecoj/Gecko/ Succeeded: s/Travis/scribe/ Succeeded: s/tyoshino/DD/ Succeeded: s|TCP|TCP/UDP| Succeeded: s/DD/tyoshino/ Succeeded: s|ByteStream -> https://github.com/whatwg/streams/blob/master/BinaryExtension.md|-> https://github.com/whatwg/streams/blob/master/BinaryExtension.md ByteStream| Succeeded: s|http://www.w3.org/TR/2014/CR-media-source-20140717/#sotd|-> http://www.w3.org/TR/2014/CR-media-source-20140717/#sotd Media Source Extensions Status of This Document| Succeeded: s/Kolel/Colwell/ Succeeded: s/WriteableStream/WritableStream/ Succeeded: s/)/)?/ Succeeded: s/broadcast live/broadcast live using HTML5/ Succeeded: s|Polyfill -> https://github.com/whatwg/streams/tree/master/reference-implementation|-> https://github.com/whatwg/streams/tree/master/reference-implementation Polyfill| FAILED: s|https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm -> Streams API W3C Editor's Draft |-> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Streams API W3C Editor's Draft| Succeeded: s|https://streams.spec.whatwg.org/ -> Streams by WHATWG|-> https://streams.spec.whatwg.org/ Streams by WHATWG| Succeeded: s/spain/Spain/ Succeeded: s/[/p/ Succeeded: s/let/let's move this to PR/ Succeeded: s/(I can't hear you anymore, not sure what happened)// Succeeded: s/ofthe/of the/ Succeeded: s/spe/spec/ Succeeded: s/44 is me// Succeeded: s/audio is terrible though// Succeeded: s|https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm -> Streams API W3C Editor's Draft|-> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Streams API W3C Editor's Draft| Succeeded: s/Topic: Push API and Service Workers// Succeeded: s/QQ/Shijun/ Succeeded: s/#/Slide -- #/ Succeeded: s/avialability/availability/ Succeeded: s/50ms/750ms/ Succeeded: i/Slide 2/-> http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/att-0283/RTC_and_Push_scenario.pdf "Scenario analysis: RTC call with push message" slides from Shijun Succeeded: s/Timeless/timeless/ Succeeded: s/schuki/scribe/ Succeeded: s/schuki/scribe/ Succeeded: s/schuki/scribe/ Succeeded: s/sicking: those UCs need to come/mounir: those UCs need to come/ Succeeded: s/thank you, we're done/we're done, thank you/ Succeeded: s/sicking:// Succeeded: s/???/moratorium/ Succeeded: s/thia/this/ Succeeded: s/... we've tried to harmonise/Travis: we've tried to harmonise/ Succeeded: s/style lists/file lists/ FAILED: s/and (as at risk) and// Succeeded: s|s/and (as at risk) and/|| Succeeded: s/and/ (as at risk) and/ Succeeded: s/paulc:// Succeeded: s/+q/q+/ Succeeded: s/agenda requests/Topic: agenda requests/ Succeeded: s/Clipboard events/Topic: Pub-Status: Clipboard events/ Succeeded: s/DOM Level 3 Event/Topic: Pub-Status: DOM Level 3 Event/ Succeeded: s|https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm -> UI Events ED|-> https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm UI Events ED| Succeeded: s/UI Events/Topic: Pub-Status: UI Events/ Succeeded: s/anything about the key specs/Topic: Pub-Status: DOM3 key specs/ Succeeded: s|https://github.com/w3c/web-platform-tests/tree/master/html/syntax -> DOM P&S tests|-> https://github.com/w3c/web-platform-tests/tree/master/html/syntax DOM P&S tests| Succeeded: s|https://github.com/w3c/web-platform-tests/labels/dom-parsing -> DOM P&S test open issues|-> https://github.com/w3c/web-platform-tests/labels/dom-parsing DOM P&S test open issues| Succeeded: s/Travis: DOM-PS/Topic: Pub-Status: DOM-PS/ Succeeded: i/are you going to do anything with innerText/Topic: innerText Succeeded: i/chaals: Moving on to FileAPI/Topic: Pub-Status: FileAPI Succeeded: i/sicking: would/scribe: schuki Succeeded: i/.. FullScreen/Topic: Pub-Status: FullScreen Succeeded: i/chaals: Gamepad./Topic: Pub-Status: Gamepad Succeeded: s/it;s/it's/ Succeeded: s/differen/different/ Succeeded: i/sicking: I'm not sure what's blocking/Topic: Pub-Status: IndexedDB Succeeded: s|http://www.w3c-test.org/IndexedDB/interfaces.html -> IDB interfaces Web IDL|-> http://www.w3c-test.org/IndexedDB/interfaces.html IDB interfaces Web IDL| Succeeded: i/IDB interfaces Web IDL/Topic: IndexedDB + Web IDL Succeeded: s/logs/locks/ Succeeded: s/chaals: IME/Topic: Pub-Status: IME/ Succeeded: s/chaals: OK. Moving to PointerLock/Topic: Pub-Status: PointerLock/ Succeeded: s/timeless/scribe/ Succeeded: i/chaals: Quota Management?/Topic: Pub-Status: Quota Management Succeeded: i/... Server-Sent Events/Topic: Pub-Status: Server-Sent Events Succeeded: s/... WebIDL/Topic: Pub-Status: WebIDL/ Succeeded: s/... Web Components?/Topic: Pub-Status: Web Components/ Succeeded: s|http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0248.html -> Custom Elements status from Dimitri 2014-Oct-24|-> http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0248.html Custom Elements status from Dimitri 2014-Oct-24| Succeeded: s|http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0249.html -> HTML Imports status report frm Hajime on 2014-Oct-24|-> http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0249.html HTML Imports status report frm Hajime on 2014-Oct-24| Succeeded: s|http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0222.html -> Shadow DOM status report from Hayato on 2014-Oct-23|-> http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0222.html Shadow DOM status report from Hayato on 2014-Oct-23| Succeeded: s|http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0213.html -> Tantek's proposal re Fullscreen API|-> http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0213.html Tantek's proposal re Fullscreen API| Succeeded: s/independant/independent/ Succeeded: s/[1]/1)/ Succeeded: s/workiong/working/ FAILED: s|https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm">https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm -> Streams API W3C Editor's Draft |XXXscribeERROR| Succeeded: s|-> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Streams API W3C Editor's Draft|ZZZ| Succeeded: i/Agenda/topic: selection, editing and user interactions Succeeded: s/topic: selection, editing and user interactions// Succeeded: s|Explainer for Editing: http://w3c.github.io/editing-explainer|-> http://w3c.github.io/editing-explainer Explainer for Editing| Succeeded: s|Agenda for Selection, Editing, Intentions: http://lists.w3.org/Archives/Public/public-editing-tf/2014Oct/0021.html|-> http://lists.w3.org/Archives/Public/public-editing-tf/2014Oct/0021.html Agenda for Selection, Editing, Intentions| Succeeded: s/clip/click/ Succeeded: s/arunranga, you wanted to say I will work towards FPWD// Succeeded: s/discreet/discrete/ Succeeded: s/events/events?/ Succeeded: s/+q/q+/ Succeeded: s/input methods/input methods [IMEs]/ Succeeded: s/it has increment and decrement/so it has a settable value, as well as increment and decrement methods/ Succeeded: s/spell checkers/spell checkers - cjk to IME, -- and not to the other one -- by merging the concepts, you ensure that anyone who codes to handle one case doesn't break when they encounter the other/ Succeeded: s/it/api/ Succeeded: s/+q/q+/ Succeeded: i/This sums up the review of pubstatus/Topic: Rundown of pubstatus Succeeded: s/itseld/itself/ Succeeded: s/has accessibility apis/has differences between each accessibility api/ Succeeded: s/starting Introductin// Succeeded: s/present cynthia_shelly// Succeeded: s/definiately/definitely/ Succeeded: s/frm Hajime/from Hajime/ Succeeded: s/committments/commitments/ Succeeded: s/richt/rbyers/ Succeeded: s/requiements/requirements/ Succeeded: s/committment/commitment/ Succeeded: s/diferences/differences/ Succeeded: s/unkowns/unknowns/ Succeeded: s/intention will have id, and reconciliation can ???/first event object could have id, and subsequent events could reference previous events by ID, to reconcile which physical events caused the related intention events/ Succeeded: s/oportunities/opportunities/ Succeeded: s/userhas/user has/ Succeeded: s/thingdid/thing did/ Succeeded: s/primatives/primitives/ Succeeded: s/microsft/microsoft/ Succeeded: s/sandox/sandbox/ Succeeded: s/enbale/enable/ Succeeded: s/sandoxed/sandboxed/ Succeeded: s/explicity/explicitly/ Succeeded: s/sandox/sandbox/ Succeeded: s|demo: http://w3c.github.io/editing-explainer/demos/intentions-demo.html|-> http://w3c.github.io/editing-explainer/demos/intentions-demo.html Demo| Succeeded: s/physically/visually/ Succeeded: s/3-4/3:30-5/ Succeeded: s/The/... the/ WARNING: Bad s/// command: s/https://www.w3.org/wiki/Webapps/November2014Meeting// Succeeded: s/richt/rbyers/ Succeeded: s/describes this/describes the finding thing in IE/ Succeeded: s/@@@/anchoring/ Found ScribeNick: ArtB Found Scribe: Art Found Scribe: Travis Inferring ScribeNick: Travis Found ScribeNick: ArtB Found ScribeNick: darobin Found ScribeNick: Travis Found Scribe: timeless Inferring ScribeNick: timeless Found ScribeNick: timeless Found Scribe: chaals Inferring ScribeNick: chaals Found Scribe: timeless Inferring ScribeNick: timeless Found ScribeNick: schuki Found Scribe: schuki Inferring ScribeNick: schuki Found Scribe: timeless Inferring ScribeNick: timeless Found Scribe: schuki Inferring ScribeNick: schuki Found Scribe: timeless Inferring ScribeNick: timeless Found Scribe: Chaals WARNING: "Scribe: Chaals" command found, but no lines found matching "<Chaals> . . . " Continuing with ScribeNick: <timeless> Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname. Scribes: Art, Travis, timeless, chaals, schuki ScribeNicks: ArtB, Travis, darobin, timeless, chaals, schuki WARNING: Replacing list of attendees. Old list: [IPcaller] +1.650.318.aaaa New list: +1.650.318.aaaa Portland Portland.a Seattle Olli_Pettay Domenic anssik tyoshino lgombos? timeless +47.21.65.aacc hallvors lgombos +44.207.095.aadd mvano johnmellor-chrome +44.207.346.aaee arunranga Default Present: +1.650.318.aaaa, Portland, Portland.a, Seattle, Olli_Pettay, Domenic, anssik, tyoshino, lgombos?, timeless, +47.21.65.aacc, hallvors, lgombos, +44.207.095.aadd, mvano, johnmellor-chrome, +44.207.346.aaee, arunranga Present: Art_Barstow Yves_Lafon Charles_Neville Robin_Berjon Jungkee_Song Adrian_Bateman Ryosuke_Niwa Xiaoqian_wu Ben Peters Natasha_Rooney Marcos_Caceres Sam_Ruby Johannes Hund Wooglae_Kim Kenneth_Christiansen plh Travis_Leithead Johannes_Hund Ali_Alabbas Israel_Hilerio Sakari_Poussa Laszlo_Gombos Hiroyuki_Aizu Masataka_Yakura Michael[tm]Smith Bryan_Sullivan cynthia_shelly Dowan_Kim Claes_Nilsson David Walp Jonathan_Jeon hober Takeshi_Yoshino Anssi_Kostiainen Olli_Pettay Makoto_Morise timeless waynecarr Shijun_Sun Alan_Iida miterho jeff Joshua_Bell Brian_Raymor Alex_Russel Mounir Ben_Poulain Sam_Weining Norbert_Lindenberg Kenji Michael_van_Ouwerkerk mnot Michael_Cooper Rick_Byers Janina_Sajka Richard_Schwerdtfeger James_Craig Katie_Haritos-Shea Doug_Schepers Robert_Sanderson Frederick_Hirsch Kristof_Csillag Agenda: https://www.w3.org/wiki/Webapps/November2014Meeting Found Date: 27 Oct 2014 Guessing minutes URL: http://www.w3.org/2014/10/27-webapps-minutes.html People with action items: abateman2 adrian arun availability azaroth barstow cfc charles determine doug frederick kris marcos robin start sysapps travis try with work yves[End of scribe.perl diagnostic output]