WebApps WG TPAC 2020 meeting

19 Oct 2020


Marcos_C, Darwin_H, Marijn_K, Aaron_G, Adrienne_W, Alex_R, Alex_C, Andrew_S, Austin_S, Ayu_I, Ben_K, Brady_E, Chase_P, Christian_L, Daniel_M, Emanuel_K, Emilio, Gary_K, Greg_W, Tess_O, Howard_W, Jeffrey_Y, Jan_M, Johannes_W, John_J, Joshua_B, Kagami_R, Leonardo_B, Lu_H, Leonie_W, Megan_G, Mike_W, Mike_S, mjackson, Mustaq_A, Olivier_Y, Philippe_L_H, Phillis_T, Ryosuke_N, Simon_P, Stefan_Z, Thomas_S, Tiger_O, Vitor_C, Vincent_S, Xiaoqian_W, Wenson_H, Wooglae_K
Marcos Cáceres and Léonie Watson


<scribe> scribe: Marcosc

<zcorpan> scribenick: marcosc

MC: welcome to TPAC 2020
... agenda https://github.com/w3c/webappswg/issues/40

<johanneswilm> +present

MC: really great turnout ... around 45 people

<plh> PLH, W3C

<JohnJansen> Microsoft

<jan> Jan Miksovsky, Salesforce architect working on web components

tiger, Invited expert

<tink> Léonie Watson, TetraLogical

<jsbell> Joshua Bell, Google/Chrome, Indexed DB editor

<zcorpan> Simon Pieters, Bocoup

<Mek> Marijn Kruisselbrink, Google/Chrome, File API editor

Marcos Caceres, IE

<asuth> Andrew Sutherland, Mozilla working on Storage and Service Workers related things

<emilio> Emilio Cobos, Mozilla

<xiaoqian> xiaoqian, W3C

<johanneswilm> Johannes Wilm, Invited Expert, Editing Taskforce

<msw> Mike Wasserman, Google/Chrome, Web Apps & Second Screen CG; working on Multi-Screen Window Placement proposal

<GameMaker> Megan Gardner, Apple

<christianliebel> Thinktecture

<tomayac> Thomas Steiner, Google, Developer Advocate for Web/Chrome/Fugu

<aarongu> Aaron Gustafson, Manifest Editor, PWAs & more @ Microsoft on the Edge team

<scheib> Vincent Scheib, Google Chrome, Web platform capabilities engineer such as Pointer Lock, Gamepad, 'fugu' efforts

<cmp> Chase Phillips, Google, Software Engineer on the Chrome Web Platform team

<oyiptong> Olivier Yiptong, Google, Software Engineer on the Chrome Web Platform team

<jyasskin> Jeffrey Yasskin, Google Chrome, Web Platform Team, forgot to mention web packaging out loud

<alexchristensen> Alex Christensen, Apple

<mjackson> Mike Jackson, Microsoft working on PWA

<garykac> Gary Kacmarcik (Google) Editor UIEvents, Clipboard

<slightlyoff> Alex Russell, Chrome (Google), Software Engineer on the Web Platform team, primarily focused on Fugu (capabilities) and PWAs

<leobalter> Hi, I'm Leo Balter (he/him), Standards Engineer, UI Platform @ Salesforce

<enne> Adrienne Walker (Google) (they/them)

<bradyeidson> I see zero indication of when it's whose turn to go. So I'll just type: Brady Eidson, engineer on WebKit at Apple.

<Emanuel_Krivoy> Emanuel Krivoy (Google) (he/him)

<dmurph> Daniel Murphy, Google/Chrome, working WebApps (interested in Web Manifest), used to work on IndexedDB

<krosylight> Kagami Rosylight (Mozilla) (they/them)

<xiaoqian> StefanZager, Google, Editor of the IO spec

<huangdarwin> Darwin Huang (Google) (he/him) work on Clipboard

<pwnall> Victor Costan (Google), Web Platform engineer

<pwnall> * he/him

<asully> Austin Sullivan (he/him) - Google

<szager> Stefan Zager (he/him) - Google

Agenda bashing

<JohnJansen> https://github.com/w3c/webappswg/issues/40

MC: our agenda is listed in https://github.com/w3c/webappswg/issues/40... if you'd like to make any changes, now is the time.
... Reminder to create breakout sessions for next week.
... if you'd like a chair to join, we can try to do that.
... basic rules if you do, please take minutes

Spec update - Badging API

<tomayac> Badging has shipped: https://web.dev/badging-api/

<tomayac> Latest addition was Edge folks making it work on Windows I think

MC: implemented Chrome, but it's waiting on further implementer interest. Mozilla expressed some interest but hasn't done any prototyping.

<slightlyoff> note that the API only shipped after 2 origin trials and lots of developer feedback was incorporated along the way

MC: encourage further review of the API from implementers.
... that should help us decide if we should publish a FPWD. Does anyone have any comments for the badging spec?

<tomayac> https://httparchive.org/reports/project-fugu

TS: we have a lot of web archive data on Badging API - we've seen some usage - relative a lot of growth for the badging API.
... you can see growth for the two methods the API exposes

Clipboard APIs

<tomayac> Addendum for Badging: samples sites using it: https://chromestatus.com/metrics/feature/timeline/popularity/2726 (scroll down)

<tomayac> Clipboard write stats: https://chromestatus.com/metrics/feature/timeline/popularity/2370

<tomayac> For clipboard read: https://httparchive.org/reports/project-fugu#asyncClipboardRead

GK: doesn't been many many changes in the last year. That's because we made a bunch of changes in the years before - including async API and figuring out "pickling". Pickling is a way of defining an interchange format for the clipboard API.
... I would be interested in having a breakout session around pickling.

RN: if we want to define such a pickling format, we would need it to be part of the OS.

<tomayac> Some background on pickling: https://github.com/WICG/raw-clipboard-access/blob/master/explainer.md#alternative-consistent-mime-types-without-re-encoding--pickling

GK: my understanding was the pickling would layer on top on the OS stuff and could help with some of the security issues.

RN: we (Apple) are probably probably not interested in standardizing it

DH: since last tpac HTML and image formats is now implemented in Chrome and WebKit

RN: particularly the async clipboard API
... there was some discussion on permissions. What's the update on that?

<tomayac> Is that around clipboard, vs. clipboard-read and clipboard-write?

RN: We wanted a gesture based permission, but there was permission based API (clipboard-read/clipboard-write). What's the status on that?

MC: we filed a bug for that

AR: our position is to always have integration with Permission API

<krosylight> Ah there is a PR BTW https://github.com/w3c/clipboard-apis/pull/132

MC: thanks Gary for update there

File API - https://github.com/w3c/FileAPI/issues/156

MK: not much work over the last year. Trying to update the description on blob... blob.arrayBuffer also now implemented in WebKit - so good cross browser support.

MC: what's the overall status? are there tests missing?

MK: file reader can probably use more tests, but overall in pretty good shape.

GamePad API


JH: make the spec more algorithmic. Interop issues: live objects vs static objects. We decided to make the objects live in Chrome to match Mozilla. We added SecureContext and Permissions Policy integration. The changes are likely to break some sites, so browsers are displaying warnings.


<jsbell> Status report: https://github.com/w3c/IndexedDB/issues/338


JB: not a great amount to report from last year. We had great chats last year at TPAC. See detailed summary at https://github.com/w3c/IndexedDB/issues/338#issuecomment-646749318
... IDBv3, there haven't been a substantial number fo changes go in, so doesn't quite yet justify going to CR. We are looking for any additional Editors from other implementers. We are not planning on having any further breakout sessions.

Input Events

jw: https://github.com/w3c/input-events/issues/111#issuecomment-710239251
... We split the spec into l1 and l2, based on what different browsers implement. I think it should be ready for CR. Not a lot of changes since 2019. We've had an input from Microsoft called "edit context" that may supersede Input Events. Mozilla has sent some additional functionality using WTP - but we haven't received any actual proposals. We would like for someone from Mozilla to join the calls to discuss those changes. We've had Editing T

asks Force every months so we would really like to have someone from Mozilla join those calls.

MC: there are plenty of folks here from Mozilla, so hopefully one of them will take that up.

Intersection Observer

<johanneswilm> Commits with tentative tests: https://github.com/web-platform-tests/wpt/commits/master/input-events

<johanneswilm> related issues: https://github.com/w3c/input-events/issues/114 and https://github.com/w3c/input-events/issues/115

<johanneswilm> s/"that may supersede Input Events"/"that may supersede Input Events level 2 level 2"

sz: spec has been stable. I've gone through issues. Thanks to emilio for the help with reviews. < discussion about specific issue >

<xiaoqian> issue #428 https://github.com/w3c/IntersectionObserver/issues/428

sp: the feature I was working on was lazy loading images. It seems that all browsers have a different root margin. The margin seems to change based on network speed. However, there could be other heuristics for lazy loading images - but this requires changing the root margin dynamically.

sz: if the concern is performance, there might not be any advantage to changing the root margin dynamically as opposed to making a new intersection observer.

sp: following the extensible web manifesto, it may make sense to expose some primitive.

MC: zcorpan wanted to have a breakout session.

<xiaoqian> Ability to have automatic rootMargin for all nested scroll containers https://github.com/w3c/IntersectionObserver/issues/431

sz describes how Intersection Observer works ...

See https://github.com/w3c/IntersectionObserver/issues/431

which will be relevant for the breakout session

<zcorpan> quick demo http://software.hixie.ch/utilities/js/live-dom-viewer/saved/8594

For dynamically changing rootMargin: https://github.com/w3c/IntersectionObserver/issues/428

zc: I don't see any browser taking this approach (issue 431). This could be something browsers leverage in their lazy loading implementations.

<szager> https://github.com/w3c/IntersectionObserver/blob/v2/explainer.md

sz: last year I spoke to this group about V2 ^^ explainer doc

<zcorpan> this approach being: using multiple IntersectionObserver, one for each scrollable container

<szager> https://chromestatus.com/metrics/feature/timeline/popularity/3051

sz: detects occlusion or other visual effects that intersect content. It deals with some security issues for assurances that effects are not occluding content. The issue is that different browsers measure ink overflow differently. This means having specify ink overflow - haven't done that yet. We shipped this in Chrome, and we have one web property using it quite successfully.

It's getting quite a bit of usage as per: https://chromestatus.com/metrics/feature/timeline/popularity/3051

<slightlyoff> (for reference, relatively few features breach more than 1% usage within the first few years of launch)

Pointer Lock 2.0

MA: the spec is fairly good state. Jamesh sent one feature request.

<JamesH> https://github.com/w3c/pointerlock/pull/49

jh: https://github.com/w3c/pointerlock/pull/49 to add options. we are shipping in Chrome in 88. We can now support all platforms.

MA: we would like to get feedback from other browser vendors. We can have a breakout session or we can discuss in the issue.

Push API

MC: status update https://github.com/w3c/push-api/issues/326#issuecomment-701692716
... no changes since last year. Challenge for this spec is a test suite. We are hoping to just the the IDL itself and see how much interop there is.
... Firefox was a bit behind, but it should be fairly interoperable

PLH: any reason not to move it to CR
... ?

MC: I'd like for it to first have a test suite. We usually find a ton of bugs when we write tests.

Selection API

<JohnJansen> q

RN: not much progress this year. Nothing really blocking us.

JohnJansen: based on the last conversation about push, who is writing the test suite?

MC: Marcos was going to do it. But I could use some help :)

RN: about selection, although not quite ready for CR, there are no blocking issues. We've made some progress on range associated with a selection, so we improved interop across all UAs.

Screen Orientation API

MC: not normative changes in the last year. There mostly just spec issues and not a lot of interop issues remaining. However, basically need to find time to finish that spec.

RN: about selection api, there is a challenge when the user tries to change a selection, like a word, etc... in those cases, the behavior depends on each platform. This affects interop, because it might be hard to test.

MS: it is actually defined in ICU, about word boundaries for words and browsers are already using it. It's even built into some JS engines.

<Zakim> MikeSmith, you wanted to comment

RN: the ICU depends on the dictionary data one provides - otherwise, we get into the websql-like situation.

UI Events

<garykac> Latest 'code' impl report: https://w3c.github.io/uievents-code/impl-report.html

GK: there are 3 specs... Key and Code values. Key and code are done. To get it to CR, we need an interop report. But there are a very large number of combinations so it makes it very difficult to test everything.
... for the main 90% use cases, we have good support across all UAs. However, it starts breaking down to more esoteric input devices. I still need to organize this in a way that would make people happy. Is it fine to have it broken up as shown?

MC: what matters is really that there is good interop

LW: what would be good is maybe going to REC with the stable stuff, and then putting the rest on a 2020 process

RN: the media stuff might not be super important, but for instance, the IME + keys in Japanese (for example) are super important

GK: agree, I just don't currently have access to various keyboards. Is it ok to have some optional things?

RN: I think it's ok to have exotic things as optional. But things like Japanese are critical.

PLH: you could say that some sections could be informative or move them to an appendix.
... I don't know when the last time you did a wide review, but if it's been more than 2 years, it might good to go through another round.

NW: I think the table needs to be part of the spec.

GK: the tables are part of the spec. The implementation report states if the keys are supoprted.

NW: we need to better tests locales

GK: there is no way to change keyboard locales to automate it on WTP

NW: someone should be doing some manual tests to at least verify that it works

GK: I had some tests I put together.

<garykac> https://w3c.github.io/uievents/tests/key-mtest-102fr-fr.html

GK: this only supports French and US... but so many locales and so many keyboards and takes a long time.

<garykac> https://w3c.github.io/uievents/event-algo.html

GK: UI events - is basically DOM level 3 events. This spec is unlikely to ever reach CR because it's "fast and loose" with the normative text. What I have been doing is converting it to be more algorithmic: ttps://w3c.github.io/uievents/event-algo.html
... it's an early draft. At some point, something like this should be replacing most of the spec text in UI Events. Would cover event ordering and how attributes are ordered + plus how things are fired, etc.
... there are links to pointer events, and to input events. Eventually I would like to work with johanneswilm on integration with the editing specs. This would help harmonize how events are fired across the platform. There is still a lot of work to do on this document.
... I might cut/paste it into one of the existing specs... or it could be a separate spec

jw: < specific question about where things might move >

GK: where possible, I would like definitions to be defined in their own spec. Input event specific things should live in the Input event spec. Input event is a bunch of tables, but should be algorithmic.

JW: should we wait for CR? or...

GK: I would not hold up CR on this. These changes would maybe happen a year from now.

<plh> +1 to presenting the proposal to pointer events folks

Web App Manifest + Manifest App Info


<aarongu> Extractions from the Manifest spec: ImageResource (https://w3c.github.io/image-resource/) and Manifest App Info (https://w3c.github.io/manifest-app-info)

MC: summary of the things listed on github

Web Share API

Summary at https://github.com/w3c/web-share/issues/162#issuecomment-711626840

<aarongu> Many thanks to christianliebel for the WPT work on Manifest :-)


<tink> https://github.com/w3c/html-aria/issues/233

LW: found a second implementation as a accessibility checking tool

Process 2020

lw: have a think about moving to the process 2020
... thank you for the time and effort you've put into the specs over this difficult year.

Pitch sessions



<Emanuel_Krivoy> https://docs.google.com/presentation/d/1myUKjvtGSkjEG72sxTvA31dLxv_RgBCtV_yZrPI6FQQ/edit#slide=id.p

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/10/19 23:14:50 $

Scribe.perl diagnostic output

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

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/if you/if you do/
FAILED: s/"that may supersede Input Events"/"that may supersede Input Events level 2"/
Succeeded: s/fairly/fairly good state/
Succeeded: s/that may supersede Input Events/that may supersede Input Events level 2/

WARNING: Replacing previous Present list. (Old list: plh, jan, NotWoods, Léonie, (tink), kimwooglae_, jsbell, Mek, zcorpan, marcosc, asuth, oyiptong, emilio, xiaoqian, wanderview, JamesH, GameMaker, mustaq, present, cmp, jyasskin, scheib, garykac, leobalter, bradyeidson, dmurph, enne)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ plh, jan, NotWoods, Léonie, (tink), kimwooglae_, jsbell, Mek, zcorpan, marcosc, asuth, oyiptong, emilio, xiaoqian, wanderview, JamesH, GameMaker, mustaq, present, cmp

WARNING: Replacing previous Present list. (Old list: plh, jan, NotWoods, Léonie, (tink), kimwooglae_, jsbell, Mek, zcorpan, marcosc, asuth, oyiptong, emilio, xiaoqian, wanderview, JamesH, GameMaker, mustaq, present, cmp, alexchristensen, HowardWolosky)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ plh, jan, NotWoods, Léonie, (tink), kimwooglae_, jsbell, Mek, zcorpan, marcosc, asuth, oyiptong, emilio, xiaoqian, wanderview, JamesH, GameMaker, mustaq, present, cmp

Present: plh jan NotWoods Léonie (tink) kimwooglae_ jsbell Mek zcorpan marcosc asuth oyiptong emilio xiaoqian wanderview JamesH GameMaker mustaq present cmp whsieh krosylight Emanuel_Krivoy LuHuang huangdarwin Victor Costan (Google) Ayu Ishii hober MikeSmith
Found Scribe: Marcosc
Found ScribeNick: marcosc

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]