Web Platform WG F2F -- 21 Oct 2015

<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

Agenda

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

Pub Status

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 ]

Publication Status

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/

API 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.

Streams and Fetch

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

Find Text API

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 ]

Streams and fetch

<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

ARIA joint meeting

<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.

WAPA

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.

Context information

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

Directory upload

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

- DRAFT -

Web Platform WG F2F

21 Oct 2015

Attendees

Contents

Agenda

Pub Status

Publication Status

API design principles

Streams and Fetch

Find Text API

Streams and fetch

ARIA joint meeting

WAPA

Context information

Directory upload

Summary of Action Items

Scribe.perl diagnostic output