<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
<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
<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
<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
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.
https://github.com/w3c/gamepad/issues/137
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
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.
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.
<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)
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.
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.
<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.
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.
<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
https://github.com/w3c/manifest/issues/906#issuecomment-711859121
<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
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
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.
nativeio
https://github.com/fivedots/nativeio-explainer
<Emanuel_Krivoy> https://docs.google.com/presentation/d/1myUKjvtGSkjEG72sxTvA31dLxv_RgBCtV_yZrPI6FQQ/edit#slide=id.p
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]