See also: IRC log
<inserted> scribe: Travis
Welcome everyone!
<garykac> Status update: I moved the bugs from bugzilla over to github
<garykac> So we have nothing left in the old W3C bugzilla
garykac: Didn't have time to
clear out the easy bugs.
... I'll spend some time on Sunday looking at those.
... we can then spend face-to-face time on the difficult
ones.
... We can do the testing-specific stuff later (after Masayuki
leaves).
... cross-browser compat stuff is more important to focus
on.
... (while Masayuki is with us)
Travis: I labelled the bugs that
Masayuki felt were most important:
https://github.com/w3c/uievents/issues?q=is%3Aopen+is%3Aissue+label%3A%21important
... We also have two repositories for key and code
... https://github.com/w3c/DOM-Level-3-Events-code
this is the code one.
<garykac> There are some bugs that are 'code' and 'key' specific, we need to move these issues out of UIEvents and into the appropriate github project.
<garykac> I'm looking up how to move an issue to a new repro...
garykac: Success!
<garykac> I'm using https://github-issue-mover.appspot.com/ to move the 'key' and 'code' issues into the appropriate repo.
Travis: I'm starting to revise the pre-existing labels and will do a pass on the existing issues labelling them for easy-identification.
<garykac> I just moved the key and code issues
<garykac> There are now 4 'code' issues and 7 'key' issues
<garykac> And 40 UIEvent issues
<masayuki> Great, I'll be careful when I report key/code issues.
<garykac> It's actually fairly easy to move them using the tool. But it's nice to have them sorted.
<garykac> Masayuki: If you have any suggestions for Labels to group bugs, feel free to add them.
<masayuki> garykac: I see.
<garykac> I'm pretty sure that we're going to want to talk about CompositionEvents at TPAC
Travis: yes, with the editing TF.
<garykac> We should all gather in a locked room and fight it out.
<garykac> At TPAC: we need to clarify where beforeinput (and friends) are specified
<garykac> We tagged the CompositionEvent related bugs. We appear have 6 of them.
<masayuki> Sigh... I should read and comment https://github.com/w3c/uievents/issues/5
<garykac> Masayuki: yes, I think that's the one that prompted me to think that we need to sit down and resolve that with them while we're at TPAC.
<garykac> I added a tag to group the "Device" related bugs.
<garykac> OK. Looks like times up. We got some triaging done.
<garykac> I suppose the next time we'll talk to each other will be in Sapporo over ramen.
OK, I will be arriving in the afternoon on Sunday. I'll try and connect with you, Gary, when I land.
<garykac> らめん!
<masayuki> I'll be in late Sunday.
<garykac> See you all then!
<masayuki> See you!
<timeless> scribe: timeless
chaals: good morning web platform
WG
... and guests
... we're looking for someone who can project the information
on the screen
... someone prepared to offer to run a screen up here [front of
room]
... not a big ask
... second request. People likely to speak about things, please
come to the inner ring of seats
... that's easier if you're on the inner tables, and not the
outer tables
... We have a laptop
... Here's a demonstration of why siting in the inside is
helpful
[ chaals leans across inner tables to retrieve a laptop ]
chaals: first thing we want up on
the screen is the agenda
... does anyone have a laptop adapter cable?
... all you people w/ Macintosh devices
... anyone have HDMI to VGA adapter?
... we're using IRC for tracking this meeting
... everything you say is public, will be written down, and
used against you in the future
<xiaoqian> scribe: xiaoqian
chaals: the way we'll do this,
it's a big group, it has just begun
... it has a lot of work that it covers
... first, introductions
... in one minute or less, your name, what you're interested
in
... we don't need the details
... just which specs you'll want to talk about
... chaals, I work for Yandex
... a cochair of this WG
... mostly interested in making sure it gets stuff
published
LJWatson: Leonie Watson, TPG, YYY
adrianba: Adrian Bateman, Microsoft, a cochair
jsoref: Josh Soref, scribe, invited expert
xiaoqian: xiaoqianX, team contact
alia: Ali Alabbas, Microsoft, IndexedDB
jungkees: Jung Kee, Samsung, Service Workers, XHR Level 1
hober: Ted O Connor, Apple, lots of things
gsnedders: Geoffrey Sneddon, IE, testing everything
jyasskin: Jeffrey Yasskin, Google, Web Bluetooth
kenneth_: Kenneth Christiansen, Intel, manifests, webnfc
anssik: Anssi Kostiainen, Intel, specs: editing web app manifest
annevk: Anne van Kesteren, Mozilla, Observer
<jsbell> (do we have audio? called in, it's awfully quiet)
JakeA: Jake Archibald, Google, Observer
mjs: Maciej, Apple, most things
<gsnedders> jsbell: going round room giving introductions
wenyudong_CM: Wenyu Dong, China Mobile, SSA
yuwei: Yu Wei, China Mobile, UUQ
hellojintae: JinTae Yu, WePlanet
<JeffH> sodden thought -- have everyone type their own intro into here rather than burdening the scribe. . . .
<mt_____> mt_____: Martin Thomson, Mozilla, Push &c
Travis: Microsoft, Shadow DOM ...
garykac: Google
<JeffH> JeffH: Jeff Hodges, PayPal, Observer
Masayuki: Masayuki Nakano, IME, Moz
<yhirano_> Yutaka Hirano, Google, interested in fetch & streams
@@: IE
<tyoshino> Takeshi Yoshino, Google, Fetch/Streams/XHR
<Hyunijn> Hyunjin, mtreecare
tyoshino: Google
<kochi> Takayoshi Kochi, "kochi" on IRC, from Google, working on Shadow DOM
<falken> I'm Matt Falkenhagen, Google, service workers
Kochi: Google, Shadow DOM
<Kasar> Kasar Masood, VIACOM, General interest in web technologies (observer)
<dom> Dominique Hazael-Massieux, W3C Staff, observer
<Arnaud_> Arnaud_ : Arnaud Braud , Orange, Push and any Api interacting with the network
annbass: Free agent, observing
LiuXin: Alibaba
<wenyudong_CM> @xiaoqian Wei YU, China Mobile. Wenyu DONG, China Mobile, APIs relevant telecommunication
@Zhang: Alibaba
<kimwooglae> KIM WOOGLAE, Inswave
Zhiqiang: Intel
<karl> karl: Karl Dubost, Mozilla, everything about Web Compatibility (observer)
ken@: Moz
<aizu> Hiroyuki Aizu, TOSHIBA, interested in Shadow DOM and Service workers etc.
Jing: Huawei
<mathieucitrix> Mathieu Hofman, Citrix, Observer
<Mek> Mek: Marijn Kruisselbrink, Google, Service Workers etc
<katsu> Katsuyoshi Naka, Panasonic, interested in WoT
paulc: Co chair of HTMLWG
<vivien> Vivien Lacourba, W3C Staff, observer
guillaume: W3C staff
<annevk> jsbell: still there?
<nsakai2> Narumichi Sakai, Toshiba, interested in Shadow DOM and Service Worker
<jyasskin> jsbell: Are you still trying to listen?
<jsbell> yes
<annevk> jsbell: can you hear something?
<jsbell> nope
<jsbell> (yes, listening; nope on audio)
<annevk> jsbell: someone is looking into it
<jsbell> thanks
chaals: (to IT support) we need to investigate webex audio problem
<jsbell> (calling in, not there in person) Joshua Bell, Google, Indexed DB
chaals: plan is to not spend more
than 1 hour at a time in the meeting room
... we have a range of topics, some we can postpone
... how many people are members of web platform. please raise
your hand
... please raise your hand
... how many people were in web apps?
... please raise your hands
... same people ish
... if you're an invited expert and want to know how to get
reinvited
... it isn't automatic
... web platforms has responsibility for most of HTML
... and whatever W3C decides to develop in HTML
... it's unclear what we will with HTML
... I'll run a session on Wednesday talking about that
... if people are desperate to talk about it, we could add an
agenda item
... HTML Editing
<wenyudong_CM> zakim
chaals: an area of work, about fixing .contentEditable
[ WebEx breaks into room ]
chaals: they're not here yet, so
not on agenda for today
... tomorrow, a breakout group will work on Service Workers
jgraham: we'll work through the
issues in Service Worker, and improvements to core, Fetch,
lifecycle, cache api
... unlikely to discuss background sync or push
chaals: potential topics: CSS,
Shadow DOM
... ES modules in HTML
... I believe there are other topics people are interested
in
... we'll try to put that on the agenda
<jsbell> (audio appears to be fixed, thx)
chaals: if you have a topic you'd like to add, please put your hand up
hober: constraints, rniwa would
like to be here for Web Components (tomorrow) -- he's at
WebPerf today,
... we'd like someone to call in for ES Modules from Cupertino,
so tomorrow morning
chaals: if someone could get npdoty
<kochi> or "Ryosuke Niwa"
chaals: we'd like PING at some
point (npdoty?)
... other topics/specs?
Travis: 10 mins to talk about Design Guidelines draft
alia: IndexedDB v2 and
status
... directory upload proposal (currently in incubatory)
annevk: slot on
Fetch+Streams
... if group is small, ~2 hours, it's a combined topic, not
separate
... we asked ArtB if we could do between 10-12
chaals: spec update, break,
fetch+streams
... if you take two hours, you get two sessions
adrianba: Joint meeting w/ Web Annotation
chaals: oh, and joint meeting w/
Aria
... CSS/Shadow DOM, tomorrow afternoon
... ES module imports for tomorrow morning
... HTML modularisation for the rest
[ no responses for baiting ]
chaals: how many people are interested in both Web Components and Service Workers v1?
hober: I clash, but that's fine
chaals: ok, tomorrow for both
(concurrently?)
... how long for ES Modules?
hober: less than an hour
... do Web Components unrelated to CSS right before CSS
agenda
chaals: CSS+Shadow DOM ~1
hour
... how many people going to AC meeting tomorrow?
... ~3
... ok,
... doesn't affect group, good, but it affects me, but adrianba
can chair
... today: web components after lunch
... we'll retweak timing
... current assumes 90 mins in a row, which is too long
chaals: we'll look at what it is web platform is going to work on
<timeless> scribe: timeless
chaals: can i put api design
first
... fetch and streams
... web annotation has asked for a joint meeting/time
... we'll wrap around that
... we may renegotiate w/ aria
... and then directory upload when we get to it
... anyone who had a request that I ignored or forgot?
[ none ]
chaals: HTML postponed
... clipboard API + events
... we have an editor
... we have someone working on a test suite
<jsbell> https://www.w3.org/WebPlatform/WG/PubStatus
chaals: every spec we make needs
more tests, even if it has a lot, we almost certainly need
more
... we're always looking for someone to write/review
tests
... for each spec I mention, i'd hope someone would volunteer
to work on tests for it
... we don't have a status report, halvard works on it
on/off
... DOM Level 3 Keyboard Events
Travis: exciting things are
happening here
... Mozilla is implementing, Google is implementing, MS will
hopefully catch up
... small spec, mostly scan codes/key codes for
characters/virtual keys
chaals: no test facilitator
... anyone want to write/collect/review tests
Travis: we have masayuki who documented on MDN page the various mappings
chaals: if we could link that, it'd be good
Travis: DOM Parsing and
Serialization
... in CR, we have several bugs, I'm writing tests
... next, write implementation report once they get through the
web platform process
<yuwei> who
Travis: at least one implementations pass each test
chaals: impls, but not
clean
... File API, arun has been working on this for longer than Web
Apps has existed
... test implementer, need help, more than a decade in the
making, fairly small, looking for volunteers
Travis: not voluteering
... has this spec seen a lot of churn recently?
... why just WD?
chaals: churn recently, slow
progress because stuff only happens once a year
... lack of progress is lack of people working on it
... File System API, long standing item, we don't know
<jsbell> (lost audio again)
chaals: if anyone would like to
work on an item, you could work on it
... you could be famous
... Find Text api, we'll talk w/ Web Annotation later
... Gamepad, we have a spec, it's moving along
... IndexedDB
alia: is jsbell on the call?
<jsbell> I can't hear any more :( Take it away, alia
alia: there's quite a bit of work
for v2
... incorporating, documenting features,
... working to contiguous IDL
... changing algorithms so they're more imperative
... looking for people to review, ensure nothing is
broken,
... looking for people to look into Promise version
chaals: Impl Status?
alia: some parts of v2 are already in Firefox and now Chrome, otherwise, no change
chaals: anyone know implementers, who might be convinced to upgrade?
[ Silence ]
chaals: absence of evidence is
not evidence of absence, some people don't work in public
... IME
Travis: Editing TF is looking
once again at this area
... in ML, they've even talked about specifying IME
behaviors
chaals: IME causes big problems
for Editors
... but it's a system/platform level thing that might interfere
w/ browsers
... people also write Browser-based IMEs
... our audience uses Russian+English together
... Manifests for Web Apps
MMM: basically stable
... implemented in Firefox, MS
chaals: how to standardize
Browser Extensions?
... we could use Manifests for this
... Jeni Tenisson proposed ....
... anyone know what happened, did it die? people proposed
HTTP2?
... Digital Pub?
... Pointer Lock
... blocked on implementation?
... no one mentioned it
... we won't talk about it
... Push API
AAX: pretty active
<Yves> re: packaging - the "performance" aspect of it is not the right angle anymore (there are better ways), but interest from digital publishing and secutiry use cases, so spec is not dead yet
<gsnedders> That wasn't me. I don't know who it was.
chaals: Quota Management
... TAG?
... Screen Orientation
... chugging away?
... Selection API
... part of stuff that goes into Editing
... editors select things
... it's pretty horrible and messy
... they'll meet on Wednesday
... Service Workers
JakeA: heading to v1, shipping in Chrome, Firefox is getting close
chaals: people are using it on the web
JakeA: there's a Crossword
jungkees: Service Workers - we'll
push candidate Rec after TPAC
... there was a CfC
... confident to publish a CR soon
<karl> slightly related to screenorientation, window.orientation for Web Compat issues https://groups.google.com/forum/#!topic/mozilla.dev.platform/N3i7Yc2UpR0
jungkees: Samsung will also ship Service Workers soon
chaals: if you have issues w/
Service Workers, tell them NOW
... UI Events
Travis: new name, hoping to start
a revival
... lots of bugs
... primarily focused on testing of the spec
... cleaning out the old testsuite test
... focusing on interop/questions
... novelty is in keyboard events
... focus/mouse is pretty stable
CXX: input events
... a few things were moved out
... one we're hoping to address is "beforeInput" and
"input"
chaals: that goes to Editing,
we'll talk on Wednesday
... URL, annevk: that's in WHAT WG?
... Web IDL ... mjs?
Travis: I've been working w/
yeves.. getting an old pr from heycam
... hoping to get that wrapped up and checked in this
week
... that will unblock the tests to get the level 1 of WebIDL,
and get that published to REC
chaals: Web Sockets
xiaoqian: for features
implemented, we'll publish at the end of this year or beginning
of next year
... current Implementation Report, we have some small
things
... Web Workers, same ...
... I know people are still adding some new features, but we
may publish a REC for the stable features
... still CfC, and evolving
chaals: XHR Level 1
jungkees: we're not actively
working on it, the gap is pretty huge spec wise
... I didn't here anything from VVV
... probably publish a NOTE
... like to hear opinions
chaals: a NOTE, not a REC?
jungkees: I don't think moving to
REC makes real sense here
... annevk is working on XHR Living Standard, it's now using
Fetch
... we could try to make it compatible in some level, because
it's APIs
... but the behavior/implementation is pretty different, I
don't know how much value it makes
chaals: this is documentation on what is interoperable and widely implemented
jungkees: a lot of work to make it happen, no one is working on it
chaals: we're unlikely to bother
making this a complete REC
... as a content producer, is this the spec you'd rely on if
you wanted broad interop
... what do people who need to ship to the wide web implement
against?
jungkees: I haven't checked the latest changes, but there should be quite a few changes...
chaals: annevk: what's the impl
status of the new/incompatible/different
... is the whatwg stuff speculative, or would it work
today?
annevk: 50/50
chaals: enough of an answer
... two questions: is there value to creating a REC
... how far is the spec from publishable, some work required?
need someone to work on it to make it publishable
... to everyone here who isn't a browser producer
... if you're publishing to the web, you need specs, need specs
that tell you what you can do
... browser vendors in this WG tend to say what they want, have
well thought ideas
... content producers don't do that, and should be
... if there's a failure in the group, it's that we don't have
enough input from people who want to produce content
... Web Component specs?
... they're being worked on
... whose on WebEx? just jsbell ?
Travis: Custom Elements has
proposals for locking down when parsing happens
... synchronicity, core to spec, talking about those
later
... Shadow DOM, active implementation happening
... in Safari and Chrome
... Microsoft has stated we want to get started
... not a lot of big blocking issues
chaals: HTML Imports
... Mozilla says they're not interested
Travis: I think we need a
conversation about that
... maybe talk about that in ES Modules
chaals: push resolution to
tomorrow
... Recs in maintenance mode
... sometimes they go out of date
... that's our specs
... next agenda item is API Design
... we'll talk about that after a short break
... welcome yves, staff contact
... come back in the next 20 minutes
[ Break ]
<jsbell> (dropping off now, thanks for kicking the audio a few times, folks)
<npdoty_> I'd love to come chat with Web Platform WG. per earlier conversation, I hope you're not inviting me to talk about patents
<Travis> http://w3ctag.github.io/design-principles/
<Travis> http://w3ctag.github.io/design-principles/
<inserted> scribe: LJWatson
Travis: Spec contains information
that hasn't previously been documented before.
... Want to share it here and solicit feedback.
<jyasskin> (It's *so bad* that Travis had to join the TAG to learn about these documents.)
<Travis> https://github.com/w3ctag/design-principles/issues
Travis: It provides guidance on what to do and what not to do when designing an API.
<JakeA> Travis: should this link to or even incorporate https://www.w3.org/2001/tag/doc/promises-guide
Chaals: Who is editing an
API?
... About 12. How many have read this spec?
... About none.
... Is the TAG reviewing APIs against this doc?
Travis: Implicitly, yes.
CMN: Would like to request the TAG does use this doc when reviewing APIs.
Travis: We'll take it under consideration.
Anne: Whoever is interested in Fetch and Streams, is welcome to join our breakout.
<scribe> scribenick: LJWatson
<JeffH> sudden thot: someone in AnneVK's fetch huddle ought to scribe
<paulc> test
Anne: Fetch now has support for streaming of response bodies
YHI: We think it's useful to have user contructed responses.
<webapp-projects> scribeNick: webapp-projects
Jake: what is the alternative?
<LJWatson> Jake: What's the alternative?
AvK: we have request object,
response object, both have a body that in theort is a
stream.\
... lifecycle is you pass a request to a fetch that returns a
promise for a response object, and that has access to the body
stream in some way.
... with service workers the lifecycle gets bigger - it gets
the requests and you can manipulate the response that can be
used by whatever gets the response.
... except websocket doesn't integrate
TL: is the response object finite?\
AvK: No, it is an HTTP response - if the connection satays iopen, possible in theory, it could be infinite.\
TL: you get an object and notice when ythere is more info?
AvK: Fetch returns a response
object when the headers have been received, and has an accessor
to get the body. Currently very simplistic.
... they require finite streams because otherwise the promises
will never resolbe and you run out of memory.
... but we assiume ingfinite memory in specs...
... question is: we have body exposed as a stream for
response.
... what do we do next. should we expose request.body as
well?
... I think XXX was suggesting we extend response constructors
to enable passing in a n object.
Jake: in fetch spec, request the body.
AvK: Body is the entire thing, and there is a separate body on entire stream.
YY: We have body but only response has the body property
AvK: Until we figure out the design.
TL: in media capture they are looking at recording a media stream. A potentially infinite stream you want to capture in pieces over time. They have a model that seems to work for that.
Matthew: media not using streams, they should consider that. It is very different. Streams can be used for other cases in media.
TL: I know media are not
considered a specigic data format so you can't just suck bytes
off and use them.
... JS: seems there are 2 questions - how do we stream a
request, how do we create a response object with a
JS-controlled stream as its body
AvK: Yes.
... you want to create a request and access its body as a
stream.
JS: Stream has a readable constructor, obvious thing would be to let body be one of those.
AvK: there is also a writable stream - which one?
MJS: How do you create a request
- are they inputs to the API created by the user?
... looks like the constructor takes another request, or a
string that I assume is the URL.
... how do I make a request with my own stuff?
AvK: There is a second argument.
MJS: OK, I see. If one of the options was a readable stream, it seems like that would so it.,
AvK: There are some outstanding things in the strerams spec about writeable vs readable.
MJS: from th request, the point is reading it - the interface is a readable stream beacuse they have to read it to issue the request.
AvK: Not sure if we want to get
into the request discussion now. one thing is you pass a
request to fetch and it clones the request.
... then you need to do something special with the stream
... we ideally want the stream you get to be the low-level
socket. To get a handle on that you want to expose it the
moment you use the fetch method, or you have an abstraction
stream that pipes into it.
MJS: For request? seems that
stream doesn't directly represent an undertlying socket, just a
custom way of provifding data. Are you taking the request from
the network?
... seems like for the common use case producing a complicated
long request being assembled, it isn't common that there is an
underlying single socket.
Avk: If you request from a server the OS opens a connection. then you write bytes to it.
<jyasskin> Zakim: JS is me
MJS: The implementation is reading from the stream and writing to the socket.
AvK: you might want to expose that socket to directly access what is going in
MJS: Suspect strongly that is a
premature optimisaiton. In webkit we pass abstract stream
objects as part of a request, e.g. posting a form with files -
we don't want to pre-compose the body in memory.
... never seemed to be a bottleneck that we are doing this
instead of reading then writing.
... think for the common case the person making teh request
porovides the stream leaves you with th cloning problem,...
AVK: The cloning problem isn't a
big thing.
... thin domenic wanted to expose the lowest level to JS
MJS: real level network APIs for
URLS don't expose that. Ones for servers might, because you're
bound by your ability to get from disk to IO.
... ther are many things that are lower level than you would
expose from JS, like pull in this file afterwards.
jyasskin: We have that operation
in the streams spec.
... you can dump a readable to a writeable stream.
MJS: so in theory that could optimise if we knew the pieces?
JS: Stream has a blocking system so if data is waiting and not observed by others, think the browser can optimise the stream reading.
MJS: API is designed to copy from
readable to writeable streams. so seems like provising a
readable stream makes sense.
... don't think it makes sense to provide a writeable stream,
you give a callback that creates something and that seems like
weird.
... you have to have dataprovidesr giving a readable stream not
being given a writeable stream. Otherwise thye are a callback
that gives a writeable stream.
matt: design would create a pair - a writeable stream that writes to a readable stream.
Jake: In the streams spec as a transform stream - a writeable and a readable stream.
tyoshino: This is the identity transform stream
<jyasskin> https://streams.spec.whatwg.org/#ts
Martin: THink maciej is right on
readable stream.
... this is how you plumb the thing - readable stream comes
from a request, you pipe that to the request. Having identity
transform solves the problem.
... returning to clone, consider the clone happening and that
produces a stream from the clone and that is the primitive
fetch uses, so explain fetch in terms of the streams it has,
makes it easy to model.
... the JSON consumes the stream and produces a JSON
body.
... seems simple, has anyone written it up?
MJS: " Cloning is tricky because
if you want to issue the request more than once, if you clone a
request with transient information and it disappears, you have
a problem.
... all other request bodies don't have that issue.
... maybe 3 ways round.
<jyasskin> We need a "tee" operation.
MJS: 1, make it invalid to replay
a stream request - sucks.
... 2 instead of a stream you provvide a cllback to make the
stream on demand, and you can produce the stream more than once
if required.
... another is to fork a stream and catch the data in the
middle but I think that defeats the purpose of having a stream,
e.g. not having to hold the whole thing in memory
AvK: We already neuter requests after first use. But there is a clone operation, and we would have to throw an exception if the request depended on a readable stream or we could tee - maybe that is somewhat reasonable.
Jake: Clone request so it can replay the post for a redirect?
AvK: No, it is sort of to reset a set of potentially problematic features for service workerrs. that we don't want fetch to use
Jake: No case of post body being sent?
AVK: Yes there is but it isn't
the reason we did this.
... need to add different headers in a later stage, you need to
replay in redirect or auth dialogs. So we would also need to
change and tee for thiose cases.
... that makes request harder - need to decide what to do in
network layer
MJS: No way to tee an arbitrary stream?
Martin: you can always ...
MJS: I assume we can't afford to assume infinite memory in reality. You may be able to tee with participation of the stream, that can be used to build another vrion, but if you are reading live from the network there is no way to tee because you don't know if you will get that back
jyasskin: don't think we should
tee automatically. You might run out of memory teeing on
request, but at least you asked for that.
... think the request issue is latency - start sedning
something fast, not to avoid memory use.
MJS: If that isn't the primary design goal, you should still include "don't catch everything in memory"
AVK: Request body is a stream today ignoring JS stream, unless redirects are disabled and no dialogs, the request will need to be teed for compat. We could have a special case that if you pass a readable stream you can't auth or redirect, but
MJS: that would be a fail
AVK: and then you would have to tee.
MJS: Even if you expose body as a atream, the inputs are all data objects, only JS streams raise a concept of teeing because other stuff you can clone without cloning the stream.
AVK: you can implement in various ways. In spec defined as a te operation.
MJS: If it was a tee as jeffrey described, start from where you are, it isn't that it resets at the start
AVK: Yeah tee happens at the start.
MJS: So if you tee, read all
through nd read other stuff....
... want to suggest alternative. instead of providing custom
implementor-readable stream you provide a function that can
produce one on demand when you send. that can have state to
enable reproduction of the stream and might be more useful than
geenric tee, or giuve a way to tee using a custom tee on
request.
AVK: redirects are not exposed, they might bring a security risk of sorts.
MJS: you expose that request is played more than once. might mean a redirect or multipple issuing the requst, doesn't seem like a big deal.
AVK: You can tell the redirect happened, not how often but you can get the info of how many times it redirected...
Jake: What does progress do with
redirect?
... in XHR
AvK: You can tell from completion.
Jake: We say streams instead of progress events. so with a request the cloning at the start means we lose the ability to use those for progess events? Does the stream get read to completion before sending?
AVK: Don't know...
jake: It would be good to use stream to indicate progress of an upload. tricky if you redirect and replay
AVK: like MJS design of callback design
ake: ditto..
AVK: That opens option for writeable streams, you get the right notification when you need it
TL: with writeable you an write any time. with readable stream you want to ensure the same content gets reread but that isn't guaranteed.
MJS: callback version with
readable stream, if impl. is well optimised you have produced
an identity stream, and can be just as efficient as writing to
an underlying writeable to which readable is being
copied.\
... in theory writing to an identity pair should be as
effiencnt as wwriting directly to a writeable,
martin: Travis' point could be a
security issue if you send different info to each point along
the redirrect chain you could use that to expliore
... don't like that. You post something that will get
redirected, and post something different each time it gets
bounced to track its path ...
... haven't come up with an attack through that, but if we are
trying to make redirect uninspectable, this breaks that.
AVK: security teams would need to consider if that is acceptable. If not we are back to teeing or only first request works...
TL: if it is a readable stream the impl could ensure that the stream has to be identical and block extra state.
yhirano: If we we create streams, and if redirect happens on request, and that is called inservice worker and that chain should be caught in service worker?
AVK: Service worker doesn't ge
access to redirects. ONly if request was made with redirect
mode manual, then worker doesn't get the destination, and
subsequent requests don't go to the service worker.
... can generate a redirect, but can't trap one out of the
network.
... has to be same origin. opaque redirect design for browser
navigation.
... click on a and service worker moves it to b, and passes
that to the page and the browser can poke inside and make the
requst that it wanted. Only in same origin case though.
... seems based on this, for requests using a readable stream
as input where we keep teeing would be fine, a callback
approach would be interesting to investigate but might collapse
in security review. with overloading you can find the callback
- we can make that work.
... maybe special parameter for the callback...
... what is the problem with making request.body work - I
forget.
JS: One, redirect issue, and it
is not well-aligned with current fetch spec.
... need to modify fetch algorithm, and didn't want to do
that.
AVK: how does it relate to
redirect, reading request.body ?
... think you only get that if you pass in custom stream to a
request
JS: maybe, but if we use the bosy.request and we use JS treams generally, we cannot assume that body is replyaable
<falken> "JS" above is Yutaka Hirano (yhirano)
MT: so if we can read request
body from service worker we need a way to recreata a stream or
tee it. Think safest think is to automaticeally tee at starting
point.
... return the automatic tee. Wy own't that work?
AR: Why instead of clone?
MT": discussin what a clone is in implementation - it would be a tee.
scribe: or mjs suggested a stream
factory insterad of the stream.
... same machinery
MJS: seems weird that a request is a body instead of having a boy. Why is that?
AVK: Body mixin is a set of utilities on a request
MJS: Body isn't being a body it is methods you have if you have a body?
MJA. hmmmm
AVK: yeah
... mixins are useful, call it waht you want - hasbody?
MJS: looking at methods, it seems like it would make sense to have a body rather than be a body. request.JSON doesn't seem to express "getting the body as JSON" request.body.JSON seems to make more sense
AVK: we havd longer names and
people don't like them so we went for shorter.
... considered a tier of object but that brings lifecycle
issues.
... wanted to use body object for an actual stream, rather than
being a pie of helper methods
MJS: Seems weird for
readability.
... response.text - what wil that give, status and body, or
what? Seems a bit unintuitive.
... think brevity will imit this to experts and others will
find it hard
JS: We will have arbitrary
consumers, so consuming and generating stream will have a
shorthand for consuming streams and generating data. So keeping
nmaes short is important
... like stream consumers rather than heading and response.
MJS: if you come back with body stream and consume that makes sense but these are not on the stream they are on teh requst or response and seems weirtd
Jake: XHR does this - there is precendent
EOC: is that a good precedent?
MJS: No.
MT: Think basic idea could be a readable stream has all the body mixin attrivbutes
MJS: That would be amuch more
readable API...
... .body produces that stream
AVK: We went there to start and decided not to go there
MJS: if there is a way to get a readable stream doesn't it make sense to have the helper methods on that stream?
Jake: we didn't know if it would
be possible to have it taht way when we strated.
... either we have requst.JSON or requst.body, or
requst.body.JSON and request.body.stream
MJS: Does that reasonaing still apply?
AR: We have multiple shipping implementations of fetch., Don't think there is opposition to figuring out whether streams should have those methods. removing existing mthods on response seem sorthogonals
Avk: think domenic was opposed to having helper methods on teh stream stuff.
<dcooney> *domenic
Avk: so we decided to put themon
requst response. should be clear from cnotext what these are
for.
... you see around teh code what is going on when you use the
methods...
... thgink it should be clear.
<adrianba> s/domonic/domenic/
MJS: nnot convinced names are good, convinced they are shipping.
TL: any future reason to be able
to get the rest of the text?
... that would be a problem.
Jake: you might want a serialisation to put ito a dB
MJS: you could make thhe names go the other way, mint response.headerText.
AVK: would not be prmoisey things.
<timeless> scribe: timeless
shepazu: Doug Sheppers, W3C, Spec
Editor
... this is the Find Text API
[ Projected, URL? ]
<rhiaro_> w3.org/TR/findtext
shepazu: we take a JSON object
<azaroth> URL: http://www.w3.org/TR/findtext/
shepazu: create a findText
object, set parameters of what you want to find
... and execute the search
... we have search() -- incremental, and searchAll() -- find
all at once
... you can search for Text (string), prefix+suffix (arbitrary
number of characters before/after text)
... e.g. if you're searching in a poem/song that has
repetition, you might ask for a prefix to disambiguate
... i'll show an example
... here we have a poem
... "Rage, rage against the dying of the light"
... repeated several times
<azaroth> Discussing example 1: http://w3c.github.io/findtext/#example-1
shepazu: I want to find the
second time
... If I want to find ... a prefix might be "Their frail deeds
might have danced in a green bay,"
... or "Blind eyes could blaze like meteors and be gay,"
... these disambiguate
... they're not part of the selection
... then, there's a .scope, it sets the scope to be within that
element
... this could limit the search to an editing interface,
excluding the chrome of your app
... then you have the traditional options that you'd have in a
find text dialog
... case folding, whole word, wrap
... if I search for "godel" it could find "Gödel"
... then there's fuzzy matching
... to handle a document that has changed
chaals: does this find rendered
text?
... does it collapse dom node boundaries?
shepazu: yes
... first, it collapses the .scope down
... then it does unicode normalization/case folding
chaals: so you can't find markup?
shepazu: correct, it doesn't find
markup,
... and it returns a DOMRange of the selection
... matching the search
chaals: if you have SVG where
things are randomly in the document
... where you have 1, 2, 3, 4, 5, 6
shepazu: if you use CSS to
reorder how things are, then your document won't be as
searchable
... it doesn't matter how it's ordered
... presumably you select some text (to select the text to
seek)
... and search for that
chaals: the other case is HTML Tables
shepazu: yes, that's an
interesting case, and we should have an issue for it
... if you want to select a column, and how you serialize that
is an open issue
chaals: it comes up where you
have multirange selection
... how many people have multirange selection
... JS Editors use multirange selection
shepazu: the point of my bringing
this to this WG
... it was originally in Web Apps
... we talked about it at TPAC last year
... it was just published recently under Web Annotation and Web
Platform
... every browser has Find in Page
... we're looking for Browser vendors to talk to us about how
we can improve this
... and how we can get this implemented
... and do it in a performant way
Travis: I see you have a search algorithm
shepazu: which is terrible by the way
Travis: do you describe how to
transform the DOM Tree into searchable text?
... or is that left up to the implementations?
shepazu: in the spec, I say you
serialize it according to .innerHTML from DOM4
... but I got feedback that there are other ways to serialize
that might be better for search
... I can't remember what they suggested
... the question of serialization might be another spec
Travis: in the Incubator WG, they
started work on a spec for .innerText
... "serialize text how it shows up on the screen"
shepazu: which might include css text
Travis: and as a precond, we
might need a Spec for how to go from a Tree into a linear
set
... people might need that
... I think there's room to layer on top of that
shepazu: I'm happy to help other
specs
... I'd like to layer on some other set of specs
Travis: just bringing that
up
... if you don't have that, you'll have trouble w/ interop
mjs: looking at this
quickly
... some possibly overly basic questions
... what is expected to implement the findText interface?
... is this on Window, or Document?
shepazu: I expect Document, but I don't know where it best lives
mjs: I see findText() is an
EventTarget
... is that because it dispatches events?
shepazu: that's probably my bad
specing, it evolved
... it should be Promise() based
mjs: for available params, I
think
... I've never seen something so complicated
... does anyone actually want to use all of these options?
shepazu: this isn't exclusively
for the Find Text dialog
... it's also for Annotation (Robust Anchoring)
... where you want to select something, pass the url to a
friend so that the friend can find it again
mjs: that sort of makes
sense
... although to sort of handle that UC, I think you need a way
to serialize that
shepazu: that's a different spec
mjs: edit distance is tricky, I
don't think browsers have that concept
... generally, I think RegExp might be enough, expressing some
of these might be tricky with RegExp
... case insensitivity, prefix, suffix, might be
shepazu: I'd love to do this with
RegExp
... but there's a matter of User Friendliness
chaals: for Robust Anchoring, You
need a serialization you can pass around
... these seem to be a set of helper methods, you pick the ones
you like, and leave out the others
... most of these could map down to RegExp, but most people
can't do that
... this sits on tap, implementation might drop down to
RegExp
<azaroth> Re Robust Anchoring, it's #6 in our charter: http://www.w3.org/annotation/charter/
mjs: seems like this API is great
and optimized for Robust Anchoring
... but crappy for Find In Page
shepazu: number of params isn't interesting, you include or don't include
mjs: having a struct w/ dozens of
params makes an API hard to understand
... find RegExp or find WildCard
... exists in Find in Page
<paulc> There are LOTS of other search features for full-text search. For a language example see in a W3C spec see http://www.w3.org/TR/2011/REC-xpath-full-text-10-20110317/
mjs: from the narrow
perspective
... it has a bunch of things I haven't seen, and is missing
some I expect
... I see overlap
shepazu: I'd love to consider
it
... but couple of comments aren't enough
... could you give suggestions
mjs: unsigned cursor, flat
numeric isn't the best way to do it
... Node + offset would be better
... if the document has changed in any way, then you have to
rewalk the document
<paulc> For more wildcard options see http://www.w3.org/TR/2011/REC-xpath-full-text-10-20110317/#ftwildcardoption
mjs: If you have a Node + offset,
you can do it efficiently
... is this position in the document?
... it's in the logically serialized document
... the way a browser would implement this is probably to
implement the algorithm through the document
... instead of serializing
... an index into that would be more complicated
shepazu: one problem w/ how
browsers do search is that you can't find text across
boundaries
... because of that optimization
mjs: I don't think the
thing
... representing your current search start position doesn't
affect the algorithm used for matching
<Josh_Soref> MS Find dialog (some app)
mjs: there's no way that browsers
will implement find text that requires fully serializing a
document
... you don't need to serialize the whole text
... you just need your algorithm to not stop when it hits
boundaries
shepazu: I'm happy to do
this
... I'm doing this because people are using JS APIs to do
searches
... they needed a cursor to do some operations
mjs: having a representation
makes sense
... doing Range + offset is better
... instead of worrying about Mutations w/ flat number
shepazu: if that's what you suggest, that's fine
<fsasaki> +1 to paulc for mentioning the xpath full text wildcard options, this is something one may want to look at for background infos
<Zakim> timeless, you wanted to discuss MS Word
<inserted> Josh_Soref: The word dialog (url above) has the serialization (sounds like), word forms (not even offered), regular expressions and captures are under "special"
<xiaoqian> Doug: look forward to more feedback
[ Lunch ]
<webapps-projects> [note for cleaning minutes. JS as quoted on this topic was really YT]
<webapps-projects> scribeNick: webapps-projects
<falken> Scribe: falken
AvK: Before the break, we
discussed streams and requests. We didn't get to the topic from
Yukata about passing the stream to the response
... Takeshi wanted to discuss general issues about
streams
... let's do streams and response first. If we make the body
the first argument, if that becomes a readable stream it seems
straightfoward
yhirano: adding the readablestream to the body... does anyone have concerns
AvK: only one way to clone a response at the moment, response.clone() that already does a tee
MJS: do custom implementable streams have a way to do tee. what does generic operation tee do?
AvK: if the stream has been tampered with clone will fail
MJS: So you can't replay a
body?
... seems like design flaw
Jake: but we want these responses to be like a 3 GB video
MJS: oh you're talking about responses
AvK: but for requests I don't understand either what you mean
MJS: sorry I thought we're
talking about requests
... for requests, whatever mechanism there is to custom
implement your own read stream.... a common case is using the
identiy stream thing to have a writable and reasable
stream
... so you tee it before anyone has read from it
... might have buffered already from write... you read from the
copy does this mean that stream has to indefinitely buffer that
idenitify stream now needs infinite buffering?
... because no one is ever reading from the readable stream,
they're always reading from the clone?
... the only generic way to make tee is work is to buffer
everything forever
JY: security question of streamfactory
AvK: maybe we can have both for requests?
MJS: if you don't use identity stream... does custom stream have a hook for implementing tee?
JY: No
AvK: Not clear yet
JY: spec has start, pull, and cancel
<jyasskin> JY: https://streams.spec.whatwg.org/#rs-constructor
MJS: if someone teed your stream someone does buferring for you?
Jake: Yes
JY: Looks like a hole in ReadableStream
Jake: WHy
MJS: IF you're producing a readablestream with 10 files, when someone tees you...
AvK: input stream creates out 1 and out 2, input is locked
JY: how does that interact with underlying source
YH: each pulls data from underlying source and dupes data and pushes them to branches
AvK: looking at spec... tee is
already in there
... it's a concept implemented in readablestream
Jake: the spec gives you that the objects coming out are the same objects
Martin: if you tee, the tee
operation says you kill the stream that you teed... create two
new streams and lock the original
... so same object doesn't work
YH: we're talking about Each chunk in stream
MJS: pretty harsh because it
requires buffering from everywhere
... list of 10 file names I will read from series and produce
the data
... have to buffer forever if someone is producing from one
side of the tee
... since you're preemptively teeing before you know there's a
redirect
AvK: itd be useful to have that
too, to preserve memory
... second instance for the stream, it'd be great if UA doesn't
create a third instance because it might get a redirect
... having to dupe only once is better for memory
... the simplest thing to add is the simple request accepts a
radable stream
... later have a new feature with body factory that calls that
thing
MJS: you can solve this in
streams spec but need an optional hook to produce the two
streams when it's teed
... assuming those spec changes are acceptable
Jake: how about allow users to
override the tee method?
... if the developer says my stream.tee = whatever
... as long as there are two streams there you've got a tee
operation
<jyasskin> Maybe https://streams.spec.whatwg.org/#teereadablestream-pull-function
MJS: can someone drop a URL for relevant spec
<mt_____> https://streams.spec.whatwg.org/#rs-tee
AvK: generally we avoid that pattern... but seems ok
<tyoshino> and the details https://streams.spec.whatwg.org/#tee-readable-stream
Jake: it could be in the constructor...
AvK: you'd invoke it for each new
redirect presumably
... queue some task, then do some dance, either method
invocation or callback
JY: we need tee operation on
readablestream. if the security issue really is a problem maybe
the platform has to do it rather than JS
... convenience vs efficiency tradeoff is normal for developers
so we can give them both options
YH: can we avoid infinite buffering?
JY: if you create a redablestream using undlerying source ctor argument, nothing has to buffer stuff. but if you use identity transofmration then it has to buffer data. it'll be less efficient
hober: If there's an explainer document it would be good
Jake: How does underlying source help?
JY: dev can specifiy a tee operation
MJS: yes they can tee in whatever way is most efficient
hober: sounds like everyone likes this
JY: domenic?
Martin: make sure that's written down
<scribe> ... new primitive operation for tee
AvK: so basically make tee implementable?
<mt_____> Yes
<jyasskin> JY: ReadableStream's underlyingSource argument should grow a new "tee" method.
AvK: if we want that in fetch we must figure out if we actually can.
Jake: fetch might throw?
Martin: fetch has a choice. can
do infinite buffering as necessary
... i don't see an inherent problem with infinite
bufferring
AvK: instead of teeing fetch can
pipe and tee on the output of that
... because that would not be exposed
... to avoid having to call into javascript
... So we need to solve this before we add readablestream to
response
<mt_____> And, if there are security concerns with accessing jsimplemented tee(), then the browser would clone itself and avoid the js-tee()
AvK: because it affects how
response with clone would behave
... response.clone calls back to js which it currently does
not
... doesn't sem problematic
YH: we discussed whether we allow infinite buffering when reading from buffer 1 is much faster than reding from buffer 2. so introduced some kind of different buffer managment such as stop reading from the ?? one. so that seems like a streams problem. do you plan to revisit the rpoblem?
Martin: i think the conclusion was in absence of something that the JS had implemented for tee especially we would accept that if someone is forced to tee a stream the default impl would be to infinntely buffer
YH: if stream provider wants, we should allow provider to provide another kind of policy?
Martin: Yes
YH: if that is provided in stream
spec, it doesn't break fetch integration?
... maybe we can provide such an option
Martin: the concern I see
potentially is if you have a JS implemented tee is the stream
might be originated from a worker
... so having a sync clone might be a problem
... but streams are inherently async
AvK: once you cross that boundary objects also need to cross the boundary
Jake: on response cloning thing I
already see workers calling .clone() on each use which leaves
the original unconsumed
... so the infintte buffer thing works well there
... because it gets locked until gc
AvK: we do need to change streams
spec first
... to include this tee method
... otherwise if you pass a redablestream to a response and
invoke clone, we'd need to define what happens if there's no
tee operation defined
Jake: we know the default tee. it's buffer
Martin: yes that's fine
AvK: another concern passing to
response... we need to to figure out if we'll have
readablebytestream or not
... because IDL does type checks
... it'lll change from readablestream to readablebytestream
YH: problem is that when calling response.clone it will allow an infintie buffering right?
AvK: No
... I was just thinking about potential show stoppers for when
you do new response and pass in a readablestream
... we can add custom teeing later
... but later if we want readablebyte instances... that's a
separate API
YH: domenic talked about merging readablestream and readbablebytestream once
TY: it's ongoing
... trying to refactor each class and find out how much overlap
there is
... it might take some more work to figure out
Martin: this seems to fit well
with json.text
... can explain everything in terms of streams
AvK: they are explained. but they
don't tee. they consume the stream and make the object
useless
... if you invoke .text it consumed the stream. but if you
clone you only get the clone. cloning happens if you invoke
.clone() or during the request in fetching
Martin: sounds good
AvK: Move on to new topic about streams
TY: want feedback on
readablebytestream design
... not yet finished
... no spec text
... but streams repository has reference impl
<tyoshino> https://github.com/whatwg/streams/blob/master/reference-implementation/lib/readable-byte-stream.js
TY: will paste url to irc
... currently just have code
... take a look at method names
... readablebytestream... controller...
MJS: difference between readablestream and readablebytestream?
TY: BYOB
... bring your own buffer
AvK: streams themselves are generic. they hold any value.
TY: original goal of streams was hold anything. before we had the byte specific one. readablestream as currently implemented as stream of arraybuffer
YH: readablestream has minimal interface. we can add properties to readablebytestream
TY: extended version of readablestream for bytes is readablebytestream
MJS: is readablebytestream a subclass?
YH: parallel object
MJS: kind of lame to have two
abstractions of streams
... bytes are the common case
... does non-byte readablestream even have a use case
Jake: agreed, but disagree common case is bytes. in node you see a lot of objects as streams. text stream
AvK: they do implement the same interface though.
<jyasskin> https://streams.spec.whatwg.org/#rbs-class has both getByobReader() and getReader()
MJS: does readablebytestream have a convenience if you know you don't want bytes
JY: it has both getreader and getbyobreader
TY: we originally had sync
version of read interface last year
... now read returns a promise
MJS: limiting readablebytestream
to bytes may be too limiting, for example if you know there's
floats it'd be more efficient to use float buffer
... useful for each type to have a type of stream
AvK: readabletypedarraystream
TY: this implementation is
designed to handle typed arrays correctly
... it already works
AvK: so it just needs a different name
MJS: maybe more productive to
discuss this with a spec
... instead of reading the code
... almost every question I have is answered by the code but
not enough time to read in 15 minutes
break time
chaals: what's the next step for this
hober: So, mayking the tee changes is one AI. and another AI is making the spec about typed streams
Martin: i'm filing an issue now
chaals: two minute wrapup?
AvK: as far as streams
integration into fetch, we have a good iddea of accepting
readablestream everywhere for requwest and response
... maybe not all at once, mostly up to YH who is writing the
spec text
... look into making teeing pluggable
... that's optional but needs to implemented in JS and we need
to figure out if it's secure if invoked from the fetch
layer
... for example redirects
... and......
... then lastly there's some work to do in straems spec to
around readablebyte stream
... does it need to exist? and if so it needs to be renamed so
it's clear it's generic and applies to typed arrays
... typedarray or arraybuffer...? more generic than it is
now
MJS: and if it can be a subclass
hober: question about
summary
... do we have agreement that it is possible to do
subclass?
AvK: I think so
... I don't know why it is not now
chaals: ok we have a summary now
end of session
<LJWatson> scribenick: LJWatson
RS: Want to talk about
accessibility in Web Components, and what you need us to
address.
... Also a proposal for a new accessibility API.
CMN: Most Web Comps people will
be here tomorrow.
... If you construct new things in Web Comps, in the way we've
done with HTML + JS in the past, we need to be able to add
accessibility.
... We created ARIA to do this in HTML.
... How do we do that in Web Comps? Think it's unsolved.
MS: Think there are three aspects
to this.
... ARIA has historically focused on representing the state of
controls so an Assistive Technology (AT) can convey to a
user.
... This should work in Web Comps.
... But there are two limitations.
... People may make controls that don't match existing
HTML/ARIA semantics.
... Second is how do we interact and manipulate it?
... On touch screen - the fact something is keyboard accessible
is no help.
... ARIA has no way to know what operations are available, or
how to effect those operations.
RS: We're looking at ARIA
2.0.
... We need a device independent interaction layer/API. May not
be part of ARIA.
... We want to know what requirements you have for this.
Hober: Use cases from IndieUI will fall out of this.
Cyns: One thing we're looking at is scripted accessibility - WAPA.
CMN: There is a related piece of work from the HTML A11y TF. How do you do this with basic markup?
<kurosawa> APIs which cyns mentioned are https://github.com/cyns/wapa/blob/master/ScriptAccessibility.md and https://wicg.github.io/a11yapi/, aren't they
CMN: WAPA is like the React.js
way of device independence and not putting everything in the
markup.
... There are different threads that tie into the point Maciej
made - there will be new components.
... How do we map things that are useful to one group of 800k
users?
<cyns> https://github.com/WICG/a11yapi
CMN: There is work in the Editing
TF and other places.
... we need to tie things together and find a solution, and
that's the job of this WG.
cyns: Web Accessibility
Properties and Actions (WAPA). sometimes known as dynamic
ARIA.
... It makes the accessibility layer accessible through
scripting.
<richardschwerdtfeger> http://wicg.github.io/a11yapi/
cyns: We heard from internalteams
at MS that when making applications accessible, most of the app
lived in JS, but to do accessibility they had to write HTML -
which is expensive.
... There is a prototype for Edge.
... Mozilla is working on a JavaScript API that's
similar.
... One problem is that there are three acc APIs on Windows,
another on Linux, another on OSX etc.
... We want developers to be able to build things accessibility
the same way they build everything else.
RS: The most expensive effort for
accessibility is adding keyboard support.
... We want to make things as device independent as
possible.
... This will also make code more portable.
<cyns> https://github.com/cyns/wapa/blob/master/ScriptAccessibility.md
RS: So we want an interface... It is costly to have to write to multiple acc APIs in different browsers and platforms.
ss/So we want an interfac... It is costly /It is costly/
yns: There have been failed attempts to create a single AP before. This is more about getting the different APIs to align.
<webapps-projects> making a standard accessibility API
Ted: Agree keyboard is one of the big areas.
<cyns> that xkcd cartoon is exactly what we're trying to avoid. Rather than make a whole new one, we want to fill the gaps in overlap.
CMN: The Editing TF is looking at
standardising the way browsers handle editable/rich text
content.
... Making it easier for JS developers to provide a quality
UI.
... How do you ask for text to be bold? How do you indicate
something should be a link?
Ted: If you have a low level API to insert/replace text, you can talk about different operations.
RS: There is a broad spectrum of APIs that are cross-platform.
Ted: Think what we want is not
making the platform acc APIs common, but where we can extend
the Web API tat interacts with them.
... We want some kind of accessibility delegation.
... Think it's a good idea for someone to work on a
proposal.
Cyns: We're trying to avoid
standards proliferation. we already have ARIA, and we're
mapping it to different platforms.
... We're spinning up an incubation project in WICG and would
really like to have people from Web Platform involved to help
us solve things.
CMN: Editing is a specific
area.
... What we have with Web Comps is the ability to create
anything.
... What we don't have is a way to make the interaction with a
web Comp device independent.
JW: Agree with Chaals.
... The IndieUI WG had IndieUI Events 1.0.
... The goal was to define device independent events, sometimes
called intention events.
... Would be interested to know what concrete steps and
relationships can be established within the new WGs to carry
this work forward?
CMN: The WP WG has an enormous
scope and a short charter, but if we find something we should
be working on we can recharter.
... We may think of other areas, as well as Editing, and look
for the events.
... Or we can work on a new framework to describe what a
component is and how someone might interact with it.
... That's harder and we're likely to get it wrong the first
dozen times we try.
... We can do either thing, or both. What are the use cases we
want to solve, and who's going to put in the effort to work on
either one?
cyns: If we choose to create a framework there are examples we can follow.
RS: The work in WICG will be
focusing on these issues.
... Two things have happened on the web that will break
accessiility testing.
... CSS content injection is one problem, many ATs and test
tools don't get to CSS generated content.
... Web Components.
LW: We have the High Level User Interaction spec unde our charter,and this is the thing that will start in WICG.
Jeff: Would it make sense for someone, perhaps a chair of WP, to continually review whethere there is a need for participation from members of WP?
CMN: suggest the other way around. If the ARIA WG wants help and doesn't have it, ping the WP co-chairs and ask.
cyns: What we're looking for is people who understand editing, web Comps and whatever your other use cases are, plus browser vendors.
RS: Can do this trough JS
APIs.
... Getting environmental context informationfrom the browser,
and Media Queries, two things tackling the same problem.
... We don't want two/three vehicles to do this.
... We want contextual information for people with
disabilities.
... What's the best vehicle to do this?
... We jdon't want to restrict how the information is
generated, only to be able to access it.
... We'd like to talk to you about a consistent way of doing
this.
CMN: I work for a search engine
company and we have lots of information about context.
... We work hard not to expose this information, otherwise
privacy people get edgy.
... It's not clear that this work would be in WP.
... Nothing in our scope that says we can work on it at the
moment.
... I understand the use cases and the privacy concerns. Not
sure this is something we should work on.
Ted: Agree with Chaals.
... There is a difference between consistency of processing and
the API.
... Suppose we had a simple API that could take some string of
user context data.
... it might be an awful idea for some pieces of
information.
... Would rather we considered each one carefully.
Anne: Things will depend on what information you want to query. There are also privacy issues here.
RS: One thing that hasn't made it
into Media queries today is Hich Contrast Mode (HCM).
... Need alternte text for video, is there an AT accessing
theebrowser?
Ted: These are things for Device APIs WG.
RS: Why is whether captions are turned on a device API?
Ted: The Media TF could talk to you about captions.
CMN: Talk to PaulC about the
Media TF.
... There is only a small amount of things that are relevant to
this WG.
cyns: APIs for describing
widgets, controls and events are in scope for this WG.
... Testing is outside of this WG, but people might be
interested to know we're meeting with Web Drivers tomorrow.
CMN: How we provide information
about components is definitely in scope for us. We should
continue the conversation.
... encourage members of WP to look at the work done on how to
make a component accessible.
... ADo you have any sense of particular problems with Web
Comps.
JN: Referencing the Shadow DOM from outside is one problem.
Mark: we're building Web Comps prototypes.
<MichaelC> clarification on JN, think issue was referencing outside the Shadow DOM from inside it
RS: Are there any semantics that we don't have in ARIA today that you need for web Comps?
Anne: There might be room for
someong else apart from the shadow tree.
... If you have a button and you want to expose its role and
state, there needs to be something in between where you could
set the default ARIA - wich could be overridden.
... Similar to the way HTML elements have default roles and
states.
... There are similar APIs needed around things like
focus.
... We've maybe figured out accessibility in Custom
Elements.
... Trying to understand how we would implement native HTML as
Web Components today reveals lots of problems.
RS: We should look at mappings for the HTML elements themselves and see where we have gaps.
Anne: Also what kind of API the
HTML elements thmselves would use to talk to the acc or browser
layers.
... It's a ard problem.
cyns: So if we built the <select> as a web Coponent, what would we need?
<annevk> https://github.com/domenic/html-as-custom-elements
<annevk> hober: ^^
Ted: Domenic D started a project to document this.
CMN: Of course there are emantics missing in ARIA.
<hober> https://github.com/domenic/html-as-custom-elements
CMN: every controls in my
starship controller UI I'm building.
... But there are some semantics we probably don't need in
ARIA.
... Can we provide a list of semantics for allthe things people
might make? No, that's why we have Web Comps in the first
place.
... we need to go beyond compiling a giant list of
semantics.
<mt_____> https://docs.google.com/presentation/d/1soMBhvsd0wuk8PO5UjtrMd116Z95jJiZLxlUFomyBFs/edit#slide=id.p.
mt: showing slides in deck.
mt: traditionally, when you close the page the web app stops.
... having an indicator for location, etc. let's you know something is happening so you can revoke it if it was a mistake.
... for new features we need to figure out how to manage things that happen in the background outside the users control.
chaals: do you give a notification to the site when the quota runs out.
mt: thinking about how to notify the site
... can change the quota based on interactions with site
... looking at how to assign reputation to sites for users
JakeA: if notification is shown it doesn't dock quota - why is this way around?
mt: want to make sure it is a notification that the user sees.
... no accountability if the user doesn't actually see the notice
JakeA: any defence against one notification showing and then hiding
mt: yes, the 3s time is to still be showing a notice
JakeA: what about setTimeout?
mt: didn't think we had setTimeout - why do we have that?
JakeA: useful and no reason not to have it
JakeA: the idea that when a tab is closed the site can't run any more
... on android I have tabs open I wouldn't expect to run code
mt: I removed points about background tabs to keep the slides simple
mt: I don't have any good answers - I think the features are worth having -
npdoty: really glad we could have a little time to discuss this
... privacy ig hearing about this more often
... coming up in more APIs
... want to share knowledge about this
... also useful to figure out what to put into specs to deal with this
mt: shipping some code that implements this experiment
... actively looking for new ways to solve the problem
annevk: do we still require user opt in for all these?
mt: we do for push
... don't believe there is for background sync
JakeA: periodic background sync will require a permission but not for one off
chaals: in the same way a user can revoke permission, being able to send a note to the server asking to forget some information might be useful
... won't deal with bad actors
... seems some value in enabling that
mt: periodic background sync will require a permission but not for one off
... so next time they try to send they will find out
annevk: when?
mt: after the final message?
JakeA: sendBeacon might have the same problem with being cached after laptop sleep
kbx, Chrome PM: working on background sync
... focused on one shot first
... in most cases will fire right away
... for an API where you can specify a delay then we might show a notification
chaals: I wasn't talking about unsubscribe - I meant having sent data over the wire being able to ask the server to please forget what I sent
... which is why it only works for good actors
mt: need to think about how you might identify that information
JakeA: another case where me might leak data is if you type into address bar, you get autocomplete that can send data for preconnect
mt: yes, but this might be a different issue
... we do DNS look-up when you hover a link for example
... somewhat orthogonal though
npdoty: one thing for the task manager option or for SW in general
... when I install something on my phone it has an icon and a name
... but with SW even if I go to look it might be hard for me to figure out which maps to what
... using origin is great, might be memorable, but also have a danger where task manager list content is meaningless
JakeA: task manager works well for storage
... might have adding to home screen puts it into storage settings
... for privacy settings is having a separate manager the right thing?
kbx: might be biased but do like the way chrome is doing for site settings - if there is concern for geofencing - if you know something happened you can go and disable it
mt: we don't see a lot of people using site settings
... new permissions API to see some of these things
... maybe look at how often things are used
... but don't see many users go to this
kbx: when you get push notification you get a link to site settings
mt: I didn't show firefox UX - origin is shown and menu allows blocking push from the site there
... we don't go via site settings
npdoty: if you want to continue this conversation - privacy IG is meeting friday
... if you think there is some documentation we need to write then turn into work items is helpful
chaals: break for 20 mins
alia: want to do something like the old FileSystem API but new
... don't think FileSystem API should be dependency for this
... file upload first and then file system later
annevk: that's fine with us too - we're not implementing FS API yet
... but we do want to do this
alia: okay, not hearing any objections
... also heard about security/privacy concerns
... when you select folder, you give the site explicit permission to go through the folder
... we heard from Mozilla concerns about this
... there might be hidden files, files user didn't know were there, etc.
... conversation with martin to look at this again
... about whether we need some restrictions in place
mt: don't know what the world looks like if we decide the security is terrible
... we'd say we don't want to ship the API
... but I've been convinced we can ship the API
... so I need to persuade the folks
... not clear we need the API but that's a different topic
chaals: seems entirely clear we do need this
... uploading one file at a time is painful
annevk: we have upload multiple
chaals: yes, but when you have a folder structure it is easier to do in one go
... hidden files, I know there are data files that get created
... is that acceptable or are some of those files necessary?
... e.g. in unix file system lots of hidden files that make things work
annevk: hidden files created by OS probably okay not to upload
... but created by the user probably necessary
... for example .htaccess or .git
alia: think one viewpoint was there should be allow list based on name
chaals: sounds dreadful, problem is knowing how they were created
alia: going to need a policy to do all or none
... another things I heard was restricting to just https
... not sure that is the right idea - legacy API doesn't have this restriction
annevk: any new thing that involves user data should not go over http
alia: already do file uploads over http
annevk: but not a good reason to keep doing bad ideas
alia: primary concern is that this is new API to do the same use case as old chrome API
... advantage is promises and asynchrony
... other than that if they are not getting the functionality because of https then they will use the old one
chaals: might get "it works in other browsers"
... perhaps chrome will add restriction to current API
... web is moving to https - might get away with doing restriction for this API
annevk: one thing that would be interesting is how much usage on non https sites
mjs: also worth asking is what the threat model we're defending against
... doing on general principle for new features is silly
... can imagine you think you are uploading a file somewhere
... not ssl site
... but hijacker is uploading elsewhere than you think
... is this ever a bad thing since they weren't using ssl anyway
annevk: might make a mistake about folder you pick and send files you didn't want in the clear
... bigger risk because of folders
chaals: don't think there is some particular threat - this is part of pushing people to https
... if lots of people using chrome API are already on https then the others may diminish
... would be concerned if we upload hidden files
alia: how about making it https only and see if we get pushback
... easier to remove the restriction later than add it on later
mt: perfectly reasonable
... need people from chrome team to be part of the conversation
... premature to make decision to support non-https yet
mt: my position is that file upload that we have had in the web since forever in clear text was a mistake but everything was at that time
alia: agreed
alia: for new API directory property called path
... question about if this is useful
... never had this in old File System API
... maybe this isn't needed - it is a convenience thnig
annevk: when you serialise it to send there is just the filename with the path
alia: I think this is a different issue
annevk: thinking about an analogy to serialization
alia: questioning the utility of the attribute
annevk: should have a single thing with path and file name
adrianba: don't think you should merge path and filename - always will want filename and don't want to keep splitting
annevk: maybe a path attribute - not sure
[discussion about how you might use folder name or not]
[discussion about use of directory names vs. paths]
chaals: leave out path and see if anyone complains
alia: right now there is a description of the UI in the spec
... not clear that this is a good idea
... we have an API in the spec because we have this UI
... in the spec there is a control when you add folder attribute to input element
... you get two buttons, one for files and one for folders
... not all OS allow file and folders to be picked together today
... but might not in future
hober: don't think the spec should have to work around system bugs in Windows and Linux
alia: if we make it platform agnostic then it won't readily support APIs that Apple has
annevk: problem was that the spec is very prescriptive
... about how UX should look
alia: https://wicg.github.io/directory-upload/proposal.html
mjs: for rendering of the control, if you specify both files and folders the UA must allow this capability
... but it's optional how
... perhaps we should have something better than calling click
slightlyoff: we can't support UX in this kind of spec
alia: okay, will follow mjs suggestion
mt: don't have a flag, just have three functions, and files, folders, and both and then both might not be available
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Travis: Hi!// Succeeded: s/Hi!// Succeeded: s/I'm gearing up for a trip to Japan this weekend!// Succeeded: s/Hey Gary. I just texted you, but you made it!// Succeeded: s/Wow, maybe, it's rainy Sunday - Thursday of Sapporo according to weather forceast.// Succeeded: s/Mmm. Not great for walking. Are umbrellas a good choice?// Succeeded: s/Not sure. 50%. Japanese weather forecaster uses "50%" when they're not sure if it will be actually rainy.// Succeeded: s/I'll be at Keio Plaza Sapporo.// Succeeded: s/XXX/Leonie Watson/ Succeeded: s/QQQ/Ali Alabbas/ Succeeded: s/TTT/Geoffrey Sneddon/ Succeeded: s/OOO/Web Bluetooth/ Succeeded: s/Jeffry/Jeffrey/ Succeeded: s/Arch/Archibald/ Succeeded: s/Koistanen/Kostiainen/ Succeeded: s/VK/van Kesteren/ Succeeded: s/Macie/Maciej/ Succeeded: s/Christianson/Christiansen/ Succeeded: s/rsuniwa/rniwa/ Succeeded: s/PSIG/PING/ Succeeded: s/timinig/timing/ Succeeded: s/Jenny/Jeni/ Succeeded: s/ZZZ/JakeA/ Succeeded: s/ZZZ/JakeA/ Succeeded: s/we'll/Service Workers - we'll/ Succeeded: s/Travis: And I'm at the Renessance hotel.// Succeeded: s/gsnedders: pretty active/AAX: pretty active/ Succeeded: s/!/1/ Succeeded: s/Let's have a status update!// Succeeded: s/I'm arriving in Sapporo late Saturday.// Succeeded: s/I moved the bugs over to github// Succeeded: s/Status update:/Status update: I moved the bugs over to github/ Succeeded: s/garykac: ...from bugzilla.// Succeeded: s/over to github/from bugzilla over to github/ Succeeded: s/garykac: I will be staying at Keio hotel.// Succeeded: s/responsive ???/response bodies/ Succeeded: s/apss/pass/ Succeeded: s/teh/the/ Succeeded: s/nad/and/ Succeeded: s/??/jyasskin/ Succeeded: s/cllbakc/callback/ Succeeded: s/sctream/stream/ Succeeded: s/retunring/returning/ Succeeded: s/prodeuces/produces/ Succeeded: s/XXX/tyoshino/ Succeeded: i/Welcome everyone!/scribe: Travis Succeeded: s/We also have two repros for key and code/... We also have two repros for key and code/ Succeeded: s|https://github.com/w3c/DOM-Level-3-Events-code this is the code one.|... https://github.com/w3c/DOM-Level-3-Events-code this is the code one.| Succeeded: s/scribeNick: webapps-projects/scribeNick: webapp-projects/ Succeeded: s/never sseemed/... never seemed/ Succeeded: s/Jake; In the streams/Jake: In the streams/ Succeeded: s/matt/jyasskin/ Succeeded: s/ This is the i/: This is the i/ Succeeded: s/the JSON consumes the stream and produces a JSON body./... the JSON consumes the stream and produces a JSON body./ Succeeded: s/looks like the constructor/... looks like the constructor/ Succeeded: s/gd/jeffrey/ Succeeded: i/Travis: Spec contains/scribe: LJWatson Succeeded: s/scribe: LJWatson/scribe: _LJWatson/ Succeeded: s/scribe: _LJWatson// Succeeded: s/with service workers the lifecycle/... with service workers the lifecycle/ FAILED: s/writeabel/writeable/ Succeeded: s|s/writeabel/writeable/|| Succeeded: s/writeabl/writeable/ Succeeded: s/th reight/the right/ Succeeded: s/Jake/martin/ Succeeded: s/syugesting/suggesting/ Succeeded: s/bofy property/body property/ Succeeded: s/medai capture/media capture/ Succeeded: s/THey/They/ Succeeded: s/JS/yhirano/ Succeeded: s/..JS/... JS/ Succeeded: s/seems tehre/seems there/ Succeeded: s/ahving/having/ Succeeded: s/memry/memory/ Succeeded: s/there si a/there is a/ Succeeded: s/th primary/the primary/ Succeeded: s/ignoting/ignoring/ Succeeded: s/redicrects/redirects/ Succeeded: s/goret/forget/ Succeeded: s/reditrects/redirects/ Succeeded: s/teh/the/ Succeeded: s/callbaclk/callback/ Succeeded: s/reditrect or ultipple/redirect or multipple/ Succeeded: s/howmany/how many/ Succeeded: s/It oulwd/It would/ Succeeded: s/Jake/AR/ Succeeded: s/writeabel/writeable/ Succeeded: s/writng/writing/ Succeeded: s/iffue/issue/ Succeeded: s/somethign/something/ Succeeded: s/requst/request/ Succeeded: s/requst/request/ Succeeded: s/requst/request/ Succeeded: s/wher we/where we/ Succeeded: s/investigae/investigate/ Succeeded: s/ti would/it would/ Succeeded: s/repros/repositories/ Succeeded: s/Presetnt/Present/ Succeeded: s/WePlanning/JinTae Yu, WePlanet/ Succeeded: s/weplanet// Succeeded: s/mon/men/ Succeeded: s/UUU/yuwei/ Succeeded: s/USQ/Yu Wei/ FAILED: s/domonic/domenic/ Succeeded: s/sodden/sudden/ Succeeded: s/ont/not/ Succeeded: s/ot/not/ Succeeded: s/ot/not/ Succeeded: s/Masayuki: IME/Masayuki: Masayuki Nakano, IME/ Succeeded: s/Mbile/Mobile/ Succeeded: s/rage rage/Rage, rage/ Succeeded: s/shepazu/chaals/ Succeeded: s/Annotation/Annotation (Robust Anchoring)/ Succeeded: i/forward/Josh_Soref: The word dialog (url above) has the serialization (sounds like), word forms (not even offered), regular expressions and captures are under "special" Succeeded: s/xiaoqian/timeless/ Succeeded: s/csribeNick: webapps-projects// Succeeded: s/rather than platform/rather than JS/ Succeeded: s/hober: /MJS: / Succeeded: s/Jake/JY/ Succeeded: s/aria joint meeting/ARIA joint meeting/ Succeeded: s/Also a proposal for a new accessibility API./... Also a proposal for a new accessibility API./ Succeeded: s/of hits/of this/ Succeeded: s/Widows/Windows/ Succeeded: s/interfac/interface/ Found Scribe: Travis Inferring ScribeNick: Travis Found Scribe: timeless Inferring ScribeNick: timeless Found Scribe: xiaoqian Inferring ScribeNick: xiaoqian Found Scribe: timeless Inferring ScribeNick: timeless Found Scribe: LJWatson Inferring ScribeNick: LJWatson Found ScribeNick: LJWatson Found ScribeNick: webapp-projects Found Scribe: timeless Inferring ScribeNick: timeless Found ScribeNick: webapps-projects Found Scribe: falken Inferring ScribeNick: falken WARNING: No scribe lines found matching previous ScribeNick pattern: <webapps\-projects> ... Found ScribeNick: LJWatson Scribes: Travis, timeless, xiaoqian, LJWatson, falken ScribeNicks: Travis, timeless, xiaoqian, LJWatson, webapp-projects, webapps-projects, falken Present: Joshua_Bell hober Travis_Leithead Jungkee_Song jyasskin LJWatson gsnedders Martin_Thomson Marijn_Kruisselbrink Karl_Dubost Arnaud_Braud Rob_Sanderson Yves_Lafon fsasaki Benjamin_Young Ivan_Herman Charles_LaPierre Takeshi_Kanai rhiaro David_clarke Got date from IRC log name: 21 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/21-webapps-minutes.html People with action items:[End of scribe.perl diagnostic output]