15:23:58 <RRSAgent> RRSAgent has joined #webapps
15:23:58 <RRSAgent> logging to https://www.w3.org/2022/09/12-webapps-irc
15:24:04 <Zakim> Zakim has joined #webapps
15:51:00 <hyojin> hyojin has joined #webapps
15:54:25 <kenneth> kenneth has joined #webapps
15:57:33 <bkardell_> bkardell_ has joined #webapps
15:58:33 <tink> xiaoqian>
15:58:40 <anssik> anssik has joined #webapps
15:59:57 <xiaoqian> xiaoqian has changed the topic to: WebApps TPAC Agenda -> https://github.com/w3c/webappswg/wiki/TPAC-2022
16:02:52 <AramZS> AramZS has joined #webapps
16:03:31 <marcosc> marcosc has joined #webapps
16:06:18 <jsbell> jsbell has joined #webapps
16:07:58 <dmurph> dmurph has joined #webapps
16:08:24 <christianliebel> christianliebel has joined #webapps
16:08:33 <tink> Xiaoqian do you know how we're supposed to connect the room to the Zoom?
16:08:59 <xiaoqian> is there a machine in the room? let me ping the Systeam
16:09:18 <jsbell> tink: there's a touchscreen with a Join button over on my side of the room. Want me to press it?
16:09:59 <dmurph> present+
16:10:35 <tantek> tantek has joined #webapps
16:10:52 <tantek> present+
16:11:04 <jsbell> present+
16:11:13 <reillyg> present+
16:11:22 <jsbell> Zoom should be active. Muted right now, I will unmute when someone gives me the signal
16:11:24 <xiaoqian> present+
16:11:53 <Mek> present+
16:11:55 <ayu> ayu has joined #webapps
16:12:46 <msw> present+
16:12:51 <xiaoqian> present+
16:13:04 <ayu> present+
16:13:15 <marcosc> present+
16:13:26 <kenneth> present+
16:13:27 <christianliebel> present+
16:14:25 <dmurph> dmurph has joined #webapps
16:15:28 <mjackson> mjackson has joined #webapps
16:15:50 <xiaoqian> meeting: TPAC 2022 WebApps WG meeting
16:15:54 <asully> asully has joined #webapps
16:15:54 <Lu_Huang> Lu_Huang has joined #webapps
16:15:57 <xiaoqian> chair: marcosc, tink
16:16:16 <diekus> diekus has joined #webapps
16:16:40 <tomayac> present+
16:16:44 <tink> Zoom URL: https://mit.zoom.us/j/98918462714?pwd=MmcrMWxuUnJBSVdwZ2ZTNHVEdHBFdz09
16:16:57 <mattreynolds> mattreynolds has joined #webapps
16:17:12 <Jack_Hsieh> Jack_Hsieh has joined #webapps
16:17:16 <motokim__> motokim__ has joined #webapps
16:17:48 <LuHuang> LuHuang has joined #webapps
16:19:00 <scheib> present+
16:19:19 <Andrew_Sutherland> Andrew_Sutherland has joined #webapps
16:20:45 <christianliebel> christianliebel has left #webapps
16:21:20 <louise> louise has joined #webapps
16:21:57 <emilio> present+
16:22:13 <louise> present+
16:22:45 <HakanI> HakanI has joined #webapps
16:22:59 <mattreynolds> present+
16:23:06 <christianleibel> christianleibel has joined #webapps
16:25:17 <smaug> present+
16:25:26 <gregwhitworth> present+
16:25:45 <dmurph> present+
16:27:32 <Andrew_Sutherland> present+
16:28:58 <kzms2> present+
16:29:11 <asully> asully has joined #webapps
16:29:12 <hjrchung> hjrchung has joined #webapps
16:29:13 <dandclark> dandclark has joined #webapps
16:29:23 <mustaq> present+
16:29:24 <hjrchung> present+
16:29:26 <asully> present+
16:29:27 <diekus> present+
16:29:29 <ericwilligers> ericwilligers has joined #webapps
16:29:36 <tink> present+ Léonie (tink)
16:29:44 <dandclark> present+
16:29:45 <ericwilligers> + Eric Willigers
16:29:46 <heycam> heycam has joined #webapps
16:30:48 <mjackson> present+
16:31:13 <JakeArchibald> JakeArchibald has joined #webapps
16:31:20 <JakeArchibald> present+
16:31:30 <garykac> present+
16:31:33 <christianliebel> christianliebel has joined #webapps
16:32:14 <lgombos_> lgombos_ has joined #webapps
16:32:31 <Joonhyung> Joonhyung has joined #webapps
16:32:35 <evanstade> evanstade has joined #webapps
16:32:42 <evanstade> present+
16:32:46 <lgombos_> Present+ Laszlo_Gombos
16:33:04 <dmurph> scribe+
16:33:40 <dmurph> macrosc: We're going to start by doing an update
16:33:42 <joonhyung_> joonhyung_ has joined #webapps
16:34:08 <dmurph> Agenda: https://github.com/w3c/webappswg/issues/88
16:34:32 <dmurph> if you are on zoom, you can try to raise your hand. Or, you can type "q+" on IRC
16:34:43 <dmurph> (and then "q-" when you are done)
16:34:49 <dmurph> topic: Status update
16:35:12 <dmurph> topic: Status update - ARIA HTML
16:35:42 <dmurph> ARIA went to rec last year
16:36:01 <dmurph> in the meantime a bunch of corrections & additions have been made, and it is stabilizing now.
16:36:14 <dmurph> We are moving to a new process to allow the spec to update quicker
16:36:34 <dmurph> In a couple months we will send out something for folks in this area to review
16:36:42 <dmurph> topic: Status update - Badging
16:37:00 <dmurph> Currently held up looking for second implementer
16:37:13 <dmurph> (this effectively lets you put a badge on an app icon)
16:37:43 <dmurph> We got a lot of input from various folks on this spec - seems like a good spec. However, haven't been able to get a second implementer yet
16:38:13 <dmurph> Thomas Steiner: There is a proposal for installed app badge, but also a proposal for a badge on the tab (in the browser)
16:38:18 <dmurph> any status on that?
16:38:27 <Guest85> Guest85 has joined #webapps
16:38:40 <dmurph> marcosc: Yes, that proposal is there, but again we haven't had enough implementer interest
16:38:50 <miriam> miriam has joined #webapps
16:38:53 <MikeWasserman> MikeWasserman has joined #webapps
16:40:38 <karlcow> karlcow has joined #webapps
16:40:54 <dmurph> topic: Status update - Contacts API
16:41:35 <HI> HI has joined #webapps
16:41:39 <dmurph> raya: Not a lot of changes in the spec, pretty happy. Moved from WICG to W3C. AFAIK nothing blocking moving it to rec
16:41:50 <dmurph> marcosc: There is a test suite as well. Second implementation is webkit?
16:41:53 <dmurph> raya: Yes
16:42:36 <reillyg> q+
16:43:17 <dmurph> marcosc: We need to publish as first working draft. Haven't had a chance to see how it works in Safari yet.
16:43:42 <dmurph> raya: It mostly works on mobile phones, but the spec is generic enough for desktop as well. but there isn't usually a contacts provider on desktop
16:43:45 <reillyg> q-
16:44:37 <dmurph> reillyg: There was an open question about whether or not the implementation on Safari was shipped or not. It would be nice if we could get a comment from Apple about whether they are shipping it or not. If there is clear multi-vendor, we can move forward with more official publication, and Marcos & I can sync up
16:45:19 <PeterConn> PeterConn has joined #webapps
16:45:24 <dmurph> action: marcosc & reillyg to figure out first public working draft for this. Hopefully within 6 weeks we can move towards CR.
16:45:24 <trackbot> Sorry, but no Tracker is associated with this channel.
16:45:41 <EllaGe> EllaGe has joined #webapps
16:45:57 <dmurph> topic: Status update - File API
16:46:07 <dmurph> mek: Not a lot has happened in last 2 years.
16:46:24 <dmurph> mek: We can use better tests.
16:46:39 <dmurph> Partitioning & partitioning blobs are active things that are being discussed
16:46:54 <dmurph> Something will need to be changed in the spec & we will be making changes in Chrome
16:47:11 <dmurph> https://github.com/w3c/FileAPI/
16:48:15 <dmurph> For partitioning we will need to figure out agent cluster vs desktop-side partitioning (please correct this - I think I misheard)
16:48:33 <dmurph> marcosc: Heard similar things - model is not quite right here with partitioning, will need to do additional spec work here
16:48:46 <dmurph> files are pretty useable right now even though the spec is not perfect
16:48:54 <dmurph> topic: Status update - Gamepad API
16:49:15 <dmurph> Matt Reynolds: Have been adding support for more recent gamepads
16:49:21 <Mek> s/desktop-side/top-leve-site/
16:49:21 <dmurph> touchpad support
16:49:32 <Mek> s/top-leve-site/top-level-site/
16:49:36 <dmurph> there are some issues around haptics that we want to discuss
16:49:51 <dmurph> Moving to CR: we have several issues blocked CR-blocking - want to go through this later
16:50:07 <dmurph> most - want to figure out how to handle gamepad inputs when page is not active or visible
16:50:25 <dmurph> marcosc: there is a PR open about events
16:50:36 <dmurph> Matt Reynolds: Not sure how quickly we will be able to get that done for CR
16:51:21 <dmurph> (current API is a polling API - events would be a push API, big change, so probably not for this CR now)
16:52:01 <dmurph> topic: Status update - Image Resource
16:52:01 <dmurph> https://github.com/w3c/image-resource/
16:52:37 <dmurph> marcosc: Image resource may or may not survive, because payment handler does something different that might take over
16:53:02 <dmurph> secure payment confirmation, specifically, which may supercede payment handler
16:53:10 <dmurph> topic: IndexedDB
16:53:20 <dmurph> https://www.w3.org/TR/IndexedDB/
16:53:32 <dmurph> jsbell: Did start to integrate things into spec describing storage partitioning
16:53:41 <dmurph> jsbell: some minor editorial things as well
16:53:58 <RayanKanso> RayanKanso has joined #webapps
16:53:59 <RayanKanso> tantek (IRC): here's the position issue for the contacts API https://github.com/mozilla/standards-positions/issues/153
16:54:19 <dmurph> implementation-side there were thoughts around API additions for mass population. On the Chromium side, did some experimenting that didn't pan out. Most of our effort has been on non-indexedDB specific implementation
16:54:42 <dmurph> Safari on WebKit did implement most of the additions in v3 indexeddb, all 3 engines have all of the additions, hooray!
16:55:14 <dmurph> Not very dramatic additions, so we could say we should move towards v4, but there are a lot of small infra things we could do
16:55:31 <dmurph> There are small things like -0 handling, terminology changes
16:55:53 <dmurph> biggest things coming up - storage buckets, which was talked about a past few tpacs ago. Moving forward w/ prototyping on Chromium side
16:56:21 <dmurph> similarly, as people are looking to refining back-forward cache spec, we may need to tweak things for how indexeddb is specified
16:56:37 <dmurph> there are a number of these integration-with-other-spec improvements that we could do
16:56:57 <dmurph> it would be great if we could have another active editor on IndexedDB, someone to jump in, bounce ideas off of, etc
16:57:27 <dmurph> marcosc: Good opportunity to help out for folks, mature spec, and important for the web
16:57:40 <dmurph> topic: Status update - Intersection Observer
16:57:49 <dmurph> https://github.com/w3c/IntersectionObserver/
16:58:25 <dmurph> emilio: Mike Taylor triaged a bunch of spec issues that were obsolete, and removed polyfill in spec repo
16:58:39 <dmurph> some minor things fixed, and some improvements around zero-ing margins
16:59:25 <dmurph> there is one particular issue w/ interop issue between blink, webkit, and gecko. otherwise v1 is pretty stable
16:59:53 <dmurph> marcosc: For v2, mozilla had a bunch of concerns that seemed obvious around pixel perfect rendering etc
17:00:09 <dmurph> how feasible is the v2? Can we get something from the v2 part that is in agreement?
17:00:29 <dmurph> emilio: I don't know enough to answer that question, unfortunately
17:00:42 <dmurph> marcosc: v1 seems fairly interop-able, so we are happy with this?
17:01:03 <emilio> interop issue worth fixing: https://github.com/w3c/IntersectionObserver/issues/432
17:02:13 <dmurph> marcosc: Learning is that it's fantastic to do a polyfill, but do it in a different repo, as people file issues on the polyfill in the same repo as the spec and it gets confusing. Put the polyfill in a different repo (still hosted in w3c is fine though)
17:02:44 <dmurph> topic: Status update - Pointer Lock
17:02:54 <dmurph> https://github.com/w3c/pointerlock/
17:03:41 <dmurph> mustaq: There is one big change since last TPAC
17:03:45 <dmurph> it is synced with HTML-side
17:04:00 <dmurph> Status update: https://github.com/w3c/pointerlock/issues/80
17:04:30 <dmurph> Standing issues - the working draft and the editor draft shows the same timestamp, so they are the same thing?
17:04:42 <dmurph> marcosc: I can figure that one out for you
17:05:27 <dmurph> mustaq: Issue #74 - need to update pointer lock spec to add details about where information should be
17:05:28 <Github> https://github.com/w3c/webappswg/issues/74 : Update WG homepage
17:05:57 <dmurph> https://github.com/w3c/pointerlock/issues/36
17:06:11 <dmurph> unaccelerated movement for better gamepad experience
17:06:23 <dmurph> This need browser / implementer opinions, please reach out
17:06:24 <xiaoqian> action: xiaoqian to work with Marcos on pointer lock issue#25
17:06:24 <trackbot> Sorry, but no Tracker is associated with this channel.
17:06:59 <dmurph> Mac & Windows we seem to have a solution for that issue
17:07:18 <dmurph> marcosc: There has been no feedback from WebKit side, right?
17:07:29 <dmurph> mustaq: Right, nothing from Mozilla or WebKit
17:08:22 <mustaq> https://lists.webkit.org/pipermail/webkit-dev/2020-October/031473.html
17:08:33 <dmurph> action: marcosc - track down the WebKit position on this spec https://lists.webkit.org/pipermail/webkit-dev/2020-October/031473.html.
17:08:33 <trackbot> Sorry, but no Tracker is associated with this channel.
17:08:34 <mustaq> https://github.com/mozilla/standards-positions/issues/448
17:10:16 <dmurph> topic: Status update - Push API https://github.com/w3c/push-api/issues/354
17:10:21 <marcosc> marcosc has joined #webapps
17:10:29 <dmurph> marcosc: The spec is in really good shape. 3 shipping implementations
17:10:41 <dmurph> Push API coming to MacOS and hopefully soon to iOS as well
17:11:08 <dmurph> issues - not many open, lacking testing, but it's a difficult spec to test, as you need a push infra to do it
17:11:20 <dmurph> so either create a webdriver API, or actually put up a push server somewhere and use that for testing
17:11:41 <dmurph> still unsure - but all browser vendors have worked hard to make this as interop as possible, but probably will find issues in the coming year
17:12:11 <dmurph> now looking at the future for folks who interested in leading working group about potential efficiencies we could do here with push looking forward
17:12:21 <dmurph> like, what if you could skip the service worker?
17:12:55 <dmurph> we are in a good state to move to CR, just needs a once-over. Marcos found a bunch of bugs last time he did a once-over.
17:13:30 <dmurph> topic: Status update - Screen orientation API https://github.com/w3c/screen-orientation/issues/208
17:13:45 <dmurph> marcosc: This allows you to lock the screen orientation to landscape or portrait
17:13:54 <dmurph> Mobile-centric, but does have utility on desktop as well
17:14:12 <dmurph> (also events when orientation changes)
17:14:24 <dmurph> We have determined that this could be abusable, as there is no user-gesture guards
17:14:41 <dmurph> if you can't use it w/o fullscreen, and you need fullscreen to trigger it, why not just integrate w/ fullscreen spec?
17:14:54 <dmurph> (for example, fullscreen gives you the gesture to enter it)
17:15:43 <dmurph> kenneth: Manifest spec has standalone & fullscreen in the spec too - why not there?
17:15:52 <dmurph> marcosc: Yes - we should figure that out
17:16:22 <dmurph> topic: Status update - UI Events https://github.com/w3c/uievents/issues/333
17:16:37 <dmurph> Gary: UI events were originally big tables
17:16:49 <dmurph> There was a request to break it out so there was required & optional values
17:17:18 <dmurph> There are only a few minor interop issues. e.g. mozilla still uses OS left and right instead of meta left and right
17:17:55 <dmurph> Doesn't seem like there is a reason to not move to to CR
17:18:25 <dmurph> Above was about key & code spec
17:18:33 <marcosc> https://www.w3.org/TR/uievents/
17:18:34 <dmurph> Now, about UI Events:
17:19:06 <dmurph> There are implementation differences between browsers because the spec is written in old style. Working on rewrite that is algorithmic to fix this
17:19:25 <dmurph> There is also pointer events which are related.
17:19:42 <dmurph> There is also related things with gamepad API and those events
17:20:01 <dmurph> Additionally - how to manage this spec change from spec writing point of view? not changing anything, but rewriting
17:20:20 <dmurph> marcosc: There is a long legacy with this spec, and it overlaps a lot with the dom spec itself.
17:20:45 <dmurph> This is really important spec with long legacy, but not in a good way right now
17:21:06 <dmurph> Gary: The way to make it algorithmic, is to identify differences, and document them (or convince browsers to agree
17:21:08 <dmurph> )
17:21:22 <dmurph> marcosc: Is this a useful spec at all to look up behavior, or is this fiction?
17:21:38 <dmurph> Gary: Not everything has been brought into DOM, there are things relied on here still
17:22:01 <dmurph> DOM spec would have same problem defining this. Event ordering is underspecified everywhere (focus, etc)
17:22:33 <dmurph> We do have some areas that we want to improve - scroll wheel. Developers are not following spec and looking at delta mode, for example
17:23:16 <dmurph> Mozilla does delta mode differently. There was a proposal for additional fields, and scroll wheel events. There is a request to put this into UI Event spec. Another request to put raw key data into the event too.
17:23:46 <dmurph> UI Events is the only place where they can talk about these requests at the moment
17:23:53 <dmurph> marcosc: Is there overlap with HTML as well?
17:24:16 <dmurph> Gary: Not once you get on top of the core event spec
17:24:52 <dmurph> We need those algorithms somewhere. Question is where & is the HTML or DOM spec better.
17:25:31 <dmurph> topic: Web App Manifest - https://github.com/w3c/manifest/issues/1046
17:26:03 <dmurph> marcosc: Two major interop issues are with internationalization (have model) and overriding things based on environmental conditions (like dark mode)
17:26:18 <dmurph> These seem like separate, but they could be seen as inter-related. Still trying to figure out
17:26:48 <dmurph> Also, some topics: scope extensions, launch handler, etc. We are having a session later to discuss these
17:27:11 <dmurph> Generally speaker, spec is in good place, although a bit slow. Becoming more and more inter-operable.
17:27:39 <dmurph> marcosc: Call out to mozilla - would be great to find a way of getting Mozilla more engaged
17:27:45 <diekus> A2HS ftw
17:29:45 <dmurph> dmurph: One issue spec-related is "where display modes are defined" - currently CSS
17:30:04 <dmurph> dmurph: One issue spec-related is "where display modes are defined" - currently CSS. Makes more sense in manifest?
17:30:37 <dmurph> ericwilligers: Yes - we would like to move these. Would be good to being up in css spec
17:30:48 <garykac> To clarify the UIEvents comment above about deltaMode: Mozilla correctly uses the various deltaMode values, but other browsers always use DOM_DELTA_PIXEL. Because most browsers use PIXEL, many websites simply assume PIXEL without checking and then (erroneously) blame Firefox instead of the website. Hence the proposal to modify the scrollwheel event.
17:31:07 <dmurph> topic: Status update - Web Share https://github.com/w3c/web-share/
17:31:20 <LuHuang> LuHuang has joined #webapps
17:31:36 <dmurph> marcos: in excellent state
17:31:58 <diekus> Edge <3 WebShare on macv
17:32:12 <dmurph> marcosc: Microsoft folks have added this to desktop, would be great for this to come to Mac on Chrome
17:32:24 <dmurph> s/have added/are adding/
17:32:43 <ericwilligers> s/Would be good to being up in css spec/Would be good to have these move back to the Manifest spec./
17:33:44 <dmurph> marcosc: There were differences with permissions policies with agents. Would be nice to resolve
17:33:56 <dmurph> topic: Web Locks https://github.com/w3c/web-locks/issues/111
17:34:09 <dmurph> jsbell: moved from WICG to webapps!
17:34:29 <dmurph> shout out to Mozilla for help and now also actively editing, thanks!
17:34:48 <dmurph> Spec has small surface area, mostly edge cases being discovered. Spec is in good shape. Implemented in all 3 engines!
17:34:57 <dmurph> on Chrome-side, looking at integration with storage buckets
17:35:18 <dmurph> Like IndexedDB - the integration with other concepts on the web - buckets & bf-cache - are things we need to work through
17:35:35 <dmurph> because implementation is on all 3 browsers, no reasons to not proceed with first working draft
17:35:38 <dmurph> questions?
17:35:57 <tink> zakim, make minutes
17:35:57 <Zakim> I don't understand 'make minutes', tink
17:36:27 <dmurph> marcosc: Agenda: https://github.com/w3c/webappswg/wiki/TPAC-2022
17:36:41 <tink> zakim,draft minutes
17:36:42 <Zakim> I don't understand 'draft minutes', tink
17:36:55 <xiaoqian> zakim, make minutes
17:36:55 <Zakim> I don't understand 'make minutes', xiaoqian
17:36:59 <xiaoqian> RRSAgent, make minutes
17:36:59 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/12-webapps-minutes.html xiaoqian
17:37:04 <xiaoqian> RRSAgent, make log public
17:50:23 <AramZS> AramZS has joined #webapps
17:57:05 <dgrogan> dgrogan has joined #webapps
18:00:01 <GlennHartmann> GlennHartmann has joined #webapps
18:06:12 <hartmanng> hartmanng has joined #webapps
18:10:36 <joonhyung> joonhyung has joined #webapps
18:24:20 <wonsuk> wonsuk has joined #webapps
18:33:46 <bradley> bradley has joined #webapps
18:43:28 <Guest85> Guest85 has joined #webapps
18:45:53 <AramZS> AramZS has joined #webapps
18:47:09 <Marcosc> Marcosc has joined #webapps
18:47:20 <Marcosc> Zakim: draft minutes
18:49:52 <msw> https://mit.zoom.us/j/98918462714?pwd=MmcrMWxuUnJBSVdwZ2ZTNHVEdHBFdz09
18:49:59 <msw> https://www.w3.org/2022/09/12-webapps-minutes.html
18:50:51 <msw> Topic: Screen Orientation Lock
18:51:23 <msw> https://github.com/whatwg/fullscreen/issues/186
18:52:14 <reillyg> scribe+
18:52:39 <reillyg> Marcosc: This is a very old specification that goes back to Firefox OS.
18:53:29 <reillyg> ... Requires full-screen.
18:53:49 <reillyg> kenneth: On Android you can request this without fullscreen in an installed PWA.
18:54:35 <reillyg> Marcosc: https://www.w3.org/TR/screen-orientation/
18:54:51 <reillyg> ... It would be good to address this inconsistency for web compatibilty.
18:55:40 <reillyg> ... Should we update orientation lock to require a user gesture?
18:55:51 <reillyg> JakeArchibald: You've already gone through a user gesture to get full screen.
18:56:04 <reillyg> Marcosc: Should you be able to keep rotating the screen without a gesture?
18:56:31 <reillyg> JakeArchibald: You could do the same with a CSS transform. It would be horrible and hacky so we should give developers a better option.
18:56:48 <reillyg> Marcosc: It's a bit of a maybe.
18:57:16 <reillyg> EllaGe: Apps like games on Android are only useful in landscape mode.
18:57:27 <mattreynolds> mattreynolds has joined #webapps
18:57:29 <reillyg> Marcosc: The manifest allows specifying this "base orientation".
18:57:59 <reillyg> ... Is there a use case to rotate and is there enough of a risk of user annoyance to require a user gesture?
18:58:24 <reillyg> ... We don't see people doing hacky things.
18:58:56 <reillyg> JakeArchibald: I see a use case for being in portrait mode for the initial setup (e.g. entering a name) and then going into landscape for the game.
18:59:44 <reillyg> Marcosc: When you are entering full screen, could we add an option to set orientation. This could avoid jank.
19:00:40 <reillyg> JakeArchibald: If you wanted to change the orientation you could call requestFullscreen() again with a different option and it wouldn't exit full screen.
19:01:08 <reillyg> MikeWasserman: I think the ergonomics of this are really nice, and could be polyfilled.
19:01:38 <ayui> ayui has joined #webapps
19:01:50 <reillyg> ... Should there be a bit controlling whether the device can flip 180 degrees when locked to portrait or landscape?
19:02:08 <reillyg> ... There are separate "primary" and "secondary" landscape and portrait modes.
19:02:30 <reillyg> ... The use case is being able to flip your phone and have the content remain upright.
19:02:48 <reillyg> ... Useful for video. Gaming might want the content locked to one particular direction.
19:03:01 <rego1> rego1 has joined #webapps
19:03:05 <reillyg> Marcosc: There's a game I know which does this as you move your phone.
19:03:44 <reillyg> ... This is allowed with "landscape", "landscape-primary" and "landscape-secondary".
19:03:45 <rego> rego has joined #webapps
19:04:18 <reillyg> ... "landscape" means it can flip 180 degrees.
19:05:03 <reillyg> JakeArchibald: Could you requestFullscreen() with both "landscape-primary" and "portrait-primary"?
19:05:50 <reillyg> reillyg: Why specify multiple in requestFullscreen()?
19:06:29 <reillyg> JakeArchibald: The array would allow you to specify the list of orientations that can be entered into while in full screen.
19:06:47 <reillyg> ... Instead of having special enum values which mean multiple allowed orientations.
19:08:18 <reillyg> kenneth: In an installed app which already uses the manifest to set full screen it would be weird to still have to call requestFullscreen().
19:09:32 <reillyg> JakeArchibald: If you have a standalone PWA then you could call requestFullscreen() without a user gesture.
19:09:47 <reillyg> kenneth: It wouldn't be good if the browser showed the full screen notification to the user when that happened.
19:09:58 <reillyg> JakeArchibald: The browser could choose not to do that.
19:10:35 <reillyg> Marcosc: This proposal looks good to me. It takes power away from the developer to flip exactly when they want to but gives the user control and the developer can react with CSS media queries.
19:10:43 <jsbell> jsbell has joined #webapps
19:10:59 <reillyg> MikeWasserman: How would a site know it had been granted the orientation lock if the request was made with requestFullsceen()?
19:11:18 <reillyg> Marcosc: This call is a suggestion. The site could detect using CSS.
19:11:31 <reillyg> JakeArchibald: How would you get into a situation where full screen was granted but lock was not?
19:12:02 <PennyMcLachlan> PennyMcLachlan has joined #webapps
19:12:35 <reillyg> ... You could detect by checking if the browser reads from the `orientation` property.
19:13:43 <reillyg> ... If you give a dictionary property that the browser doesn't know it will ignore it.
19:14:02 <reillyg> Marcosc: This is a suggestion of how it will be.
19:14:42 <reillyg> smaug: This feels very different from the existing orientation lock.
19:15:05 <reillyg> JakeArchibald: It either needs to be considered a hint or you need to know in advance what values will be accepted.
19:15:18 <reillyg> Marcosc: When orientation changes it will fire an event, so you could observe that.
19:15:46 <reillyg> MikeWasserman: Are you referring to screen.orientation.type?
19:15:56 <reillyg> Marcosc: Yes, the event will fire after the properties change.
19:16:09 <reillyg> JakeArchibald: That will tell you the current rotation state but not the states that are possible.
19:16:19 <reillyg> Marcosc: We could add screen.supportedOrientations.
19:17:12 <reillyg> JakeArchibald: A hint is compatible with user agents that support it. But requestFullscreen() is not a hint. If it isn't supported then it fails.
19:17:19 <reillyg> Marcosc: That was the intent with this API as well.
19:17:37 <reillyg> ... We're not likely to solve this now.
19:18:21 <reillyg> ... I'm going to ask friends from Microsoft: On WebKit we've received bug reports from O365 about this API.
19:18:45 <reillyg> diekus: I don't know.
19:19:10 <reillyg> JakeArchibald: Orientations that are allowed could change. E.g. a laptop that turns into a tablet.
19:19:13 <diekus> diekus has joined #webapps
19:19:37 <reillyg> Marcosc: diekus is the editor of the Device Postures API.
19:19:58 <reillyg> present+: diekus
19:20:35 <reillyg> ... What happens when you are in portrait  in tablet mode but then go into laptop mode. What happens?
19:20:47 <reillyg> kenneth: Android is similar. You can disable rotations at a system level.
19:21:05 <reillyg> JakeArchibald: That suggests that the hinting model is beter.
19:21:36 <reillyg> ... There should be an event for "the supported subset of requested modes has changed"
19:22:29 <reillyg> Marcosc: There's a privacy angle.
19:22:39 <reillyg> reillyg: There aren't that many possible combinations.
19:23:32 <reillyg> MikeWasserman: It would be an passive fingerprinting surface if we fired an event but other mitigations are possible such as only firing for foreground tabs.
19:24:00 <reillyg> Marcosc: MikeWasserman has volunteered to work on this spec. We have web compat requests coming in from the WebKit side.
19:24:46 <reillyg> MikeWasserman: Existing usage for orientation type and angle is pretty substantial but locks are not.
19:25:11 <reillyg> ... It's nice ergonomics to declare requested orientation when requesting full screen.
19:25:20 <reillyg> Marcosc: No objections heard here.
19:26:03 <reillyg> RRSAgent, please generate the minutes
19:26:03 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/12-webapps-minutes.html reillyg
19:26:41 <reillyg> scribe-
19:26:52 <reillyg> scribe+
19:27:10 <reillyg> Marcosc: We should find annevk who edits full screen and put these ideas in his head
19:27:14 <reillyg> scribe-
19:27:19 <reillyg> RRSAgent, please generate the minutes
19:27:19 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/12-webapps-minutes.html reillyg
20:13:48 <etienne> etienne has joined #webapps
20:24:11 <cabanier> cabanier has joined #webapps
20:24:15 <joonhyung> joonhyung has joined #webapps
20:31:09 <mattreynolds> mattreynolds has joined #webapps
20:31:36 <LuHuang> LuHuang has joined #webapps
20:31:51 <jsbell> jsbell has joined #webapps
20:31:55 <Guest85> Guest85 has joined #webapps
20:34:23 <marcosc> marcosc has joined #webapps
20:34:32 <marcosc> TOPIC: Gamepad
20:35:02 <scheib> present+
20:35:06 <mattreynolds> present+
20:35:06 <jsbell> present+
20:35:10 <cabanier> present+
20:35:22 <ericc> ericc has joined #webapps
20:35:45 <Jack_Hsieh> Jack_Hsieh has joined #webapps
20:35:57 <scheib> scribe+
20:36:23 <youenn> youenn has joined #webapps
20:36:32 <estade> estade has joined #webapps
20:37:42 <emilio> present+
20:38:01 <smaug> present+
20:39:01 <scheib> bradley: Here from Sony, been working on multi-touch for gamepad
20:39:43 <scheib> mattreynolds: There are regular spec maintainer meetings, check in to join if interested.
20:39:55 <jsbell> Can someone on zoom drop the links matt shared into IRC?
20:40:07 <scheib> subtopic: Back Forward cache interaction
20:40:18 <marcosc> https://github.com/w3c/gamepad/issues/149
20:40:26 <AramZS> AramZS has joined #webapps
20:41:55 <scheib> Relevant page lifecycle events, e.g. load, navigate away for pagehide, visibility change, freeze, and later resume, visibilitychange ...
20:42:03 <smaug> I could note that freeze/resume aren't part of the bfcache, but Lifecycle API
20:42:39 <scheib> GamepadAPI has only gamepadconnected, gamepaddisconnected.  No events when hidden
20:43:50 <scheib> Proposing events: rawgamepadchange sent immediately, gamepadchange has same data but may be queued
20:46:06 <scheib> Re: Page visibility integration
20:46:41 <scheib> When becoming visible after being non visible need to compute a difference between states, and only fire event if needed
20:47:49 <scheib> BFCache design principles sldie:
20:48:13 <scheib> Gate actions on fully active state
20:49:38 <scheib> Notes on integration:
20:49:53 <scheib> . Inputs can be shared, so it is OK to disconnect and reconnect devices
20:50:02 <scheib> . Vibration can not be shared
20:51:51 <scheib> Exclusive access modes in other APIs may be related, e..g USB, HID
20:52:55 <scheib> [end of slides]
20:54:15 <scheib> smaug: lifecycle events are still only WICG, page hide and show are in HTML spec
20:54:47 <igarashi> igarashi has joined #webapps
20:55:24 <scheib> JakeArchibald: Like that this proposal resolves issues as the page returns to visibility
20:55:49 <jsbell> jsbell has joined #webapps
20:56:16 <mattreynolds> https://docs.google.com/presentation/d/1zAcqgIut9WcJTh6Ikfh4CmKecD5LgG6_NKG6mmP0Lcg/edit?resourcekey=0-bAagoqjkLyQXymVtnPgKkQ#slide=id.g1537c9e7700_0_240
20:57:22 <marcosc> Rakina from Google BF Cache team
20:57:38 <diekus> diekus has joined #webapps
20:57:59 <ericc> ericc has joined #webapps
20:58:29 <scheib> Rakina: We could adjust event timings before freeze
20:58:40 <rakina> rakina has joined #webapps
20:59:00 <scheib> JakeArchibald: What happens in USB when leaving a page?
20:59:14 <reillyg> q+
21:00:00 <reillyg> q-
21:00:34 <scheib> JakeArchibald: Only do things on hiding if necessary
21:01:00 <scheib> mattreynolds: in proposal, would not fire disconnect on loss of visibility
21:01:12 <scheib> Rakina: is it OK to never fire?
21:01:45 <scheib> reillyg: Yes, same as e.g. closing a tab
21:03:28 <scheib> mattreynolds: Changing topics:
21:03:29 <scheib> subtopic: Xbox One impulse trigger effects
21:03:55 <mattreynolds> https://docs.google.com/presentation/d/1yWlVHJeIYaikxHnFj0VXrAYTv_n9rXG0CzpTVRsFNQ8/edit#slide=id.g15642ef02ee_0_59
21:05:01 <scheib> previously only intensity and duration
21:06:11 <scheib> 2017 TPAC proposal included.  This was implemented in chromium
21:06:32 <scheib> 2022 trigger-rumble effect being proposed by Microsoft
21:07:42 <scheib> WebKit currently opposed regarding integrations
21:08:57 <scheib> [end of slides]
21:09:12 <Marcosc_> Marcosc_ has joined #webapps
21:09:22 <scheib> JakeArchibald: Compatibility with haptics that aren't just rumble? e.g. PS5 trigger?
21:09:47 <scheib> mattreynolds: Earlier proposal is extensible with new effect types
21:10:23 <scheib> believe effects beyond rumble are possible.
21:10:56 <scheib> e.g. buffered haptics (a waveform) might be possible.  But we don't have a specification for how to handle / buffer these yet
21:12:05 <scheib> marcosc: Would like to hear from device manufacturers regarding what types of waveforms , how much data, number of waveworks
21:12:13 <scheib> s/waveworks/waveforms/
21:13:35 <scheib> marcosc: Also do not want to limit for what hardware is coming with more capabilities
21:14:50 <scheib> mattreynolds: agree with goals for extensibility
21:16:10 <scheib> Ricky(?) at Meta on oculus.  Have implemented gamepad API with several features, can share more off meeting
21:17:07 <Marcosc_> s/Ricky/Rik Cabanier/
21:17:12 <scheib> bradley: Perhaps device introspection would permit addressing the wider range of devices for now
21:17:24 <plh> plh has joined #webapps
21:18:03 <scheib> scribe-
21:18:14 <Marcosc_> TOPIC: ARIA in HTML
21:19:22 <plh> marcos: ARIA in HTML is now a REC. for corrections/additions, you need to label each change in the new draft to get IPR commitments.etc.
21:20:17 <mattreynolds_> mattreynolds_ has joined #webapps
21:21:07 <plh> marcos: the process promised us to automatically update things on /TR and it didn't happen
21:21:20 <plh> ... [showing proposed corrections]
21:23:32 <AramZS> AramZS has joined #webapps
21:24:52 <Marcosc_> plh: to update steps we can me up with Candidate Corrections/Additions  -> Proposed Correction. For Proposed Corrections it requires an AC review. This requires feedback from your lawyers and your AC Reps. If everything goes well, then it goes to the Director for approval.
21:25:13 <Marcosc_> plh: for the first two steps you don't need Director approval
21:25:38 <Marcosc_> plh: ideally it should be done like 2 times a year
21:26:18 <plh>  https://github.com/w3c/webrtc-pc/pull/2713
21:26:19 <Marcosc_> plh: so the question is how do you do this painlessly. We haven't managed to figure out how to do this as an Editor. There has been one proposal from the WebRTC working group.
21:26:53 <ericwilligers> ericwilligers has joined #webapps
21:26:58 <Marcosc_> plh: their intent is to make lives easier for Editors, while considering what lawyers need (they need to see the changes)
21:27:04 <bradley> bradley has left #webapps
21:27:09 <Marcosc_> plh: I told the WebRTC that their approach is ok
21:28:03 <Marcosc_> plh: is you want to propose your own, that's ok... but if this is too painful, we need to change the Process once again. I'm open to alternatives. This is where we are.
21:28:22 <Marcosc_> MC: thanks for that overview.
21:29:20 <Marcosc_> MC: this potentially affects all of us if we care about moving stuff to Rec. Of course this doesn't apply to perpetual CR state.
21:29:56 <Marcosc_> MC: specific for ARIA in HTML and auto publishing, where did we land on that?
21:30:26 <Marcosc_> plh: Danis has already enabled it
21:30:30 <plh> https://github.com/w3c/echidna/issues/1048
21:30:50 <Marcosc_> MC: fantastic...
21:31:24 <Marcosc_> plh: the system doesn't know about the substantive vs non-substantive changes.
21:32:10 <Marcosc_> MC: so, how do we add new features?
21:32:32 <Marcosc_> plh: you can add "candidate additions"
21:35:10 <mattreynolds> mattreynolds has joined #webapps
21:37:23 <joonhyung_> joonhyung_ has joined #webapps
21:48:44 <joonhyung_> joonhyung_ has joined #webapps
21:50:17 <hakan> hakan has joined #webapps
21:51:00 <hakan> hakan has joined #webapps
21:55:54 <joonhyung_> joonhyung_ has joined #webapps
22:17:40 <joonhyung> joonhyung has joined #webapps
22:21:20 <joonhyung> joonhyung has joined #webapps
22:37:04 <reillyg> scribe+
22:37:15 <reillyg> Topic: UI Events Specification
22:37:39 <garykac> TOPIC: Scrollwheel deltaMode
22:37:46 <garykac> TOPIC: Scrollwheel deltaMode
22:37:56 <garykac> Some background:
22:37:58 <reillyg> scribe+: garykac
22:38:00 <garykac> Many developers don't bother checking |deltaMode| before using the |deltaX| value. They just assume that it's DOM_DELTA_PIXEL (the default).
22:38:19 <garykac> Not an issue for Chrome,Edge,Safari because they *always* return PIXEL values.
22:38:28 <garykac> But Firefox can return _LINE or _PAGE (as appropriate).
22:38:36 <garykac> This is good because there are scenarios where _LINE or _PAGE can be Quite Useful.
22:38:38 <Marcosc> Marcosc has joined #webapps
22:38:42 <garykac> Websites that don't check |deltaMode| (and assume _PIXEL) may have problems. Users will complain about a bug in Firefox, when it's really a bug on the website.
22:38:58 <garykac> Proposal to have |deltaMode| to always be _PIXEL and add a new attribute (or attributes) for _LINE and _PAGE values.
22:39:24 <garykac> https://github.com/w3c/uievents/issues/181
22:39:30 <garykac> See followup: Firefox updated to always use _PIXEL unless it detects that |deltaMode| has been queried.
22:39:52 <garykac> https://groups.google.com/g/mozilla.dev.platform/c/fUXLgaSoeLI/m/ubt__u7MAQAJ?pli=1
22:39:56 <garykac> Is this proposal for new attributes no longer necessary?
22:40:18 <reillyg> smaug: This is what we're doing now and I cannot recall and regressions.
22:41:35 <garykac> How can we spec that algorithmically?
22:41:47 <garykac> Add an internal slot "deltaModeChecked" that tracks whether or not |deltaMode| was recently read in the current script context
22:42:06 <reillyg> s/and regressions/any regressions/
22:42:20 <garykac> if (deltaModeChecked) {
22:42:24 <garykac>    UA can return _PIXEL _LINE or _PAGE values as appropriate
22:42:28 <garykac> } else {
22:42:31 <garykac>    UA must return _PIXEL
22:42:35 <garykac> }
22:43:10 <garykac> Issue: When does deltaModeChecked get reset?
22:43:10 <trackbot> Sorry, but no Tracker is associated with this channel.
22:43:27 <garykac> TOPIC: Scrollwheel ticks
22:43:34 <garykac> https://github.com/w3c/uievents/issues/17
22:43:41 <garykac> Examples of where ticks can be useful: a digit-selector, a menu or a drop-down list, a photo carousel.
22:43:55 <garykac> In each of these cases, a single tick should select the next element regardless of how many "pixels" are reported.
22:44:07 <garykac> Ticks are hard for web devs to calculate since pixels-per-tick differs for each platform (and hardware).
22:44:26 <garykac> Issues:
22:44:30 <garykac> But what about mouse with smooth scrolling?
22:44:34 <garykac> Or input devices that fake scrollwheel events (like a touchpad)?
22:44:42 <garykac> Browsers currently generate fake high-level scroll events for these devices for compatibility.
22:44:49 <garykac> What should these fake events have for ticks?
22:44:55 <garykac> Options:
22:44:59 <garykac> * Always use 0 for devices that don't have natural ticks
22:45:03 <garykac> * Use a heuristic to generate fake ticks
22:45:10 <garykac> Tentative Proposal:
22:45:13 <garykac> * Add ticks attribute
22:45:17 <garykac> * Default value = 0 for devices that don't have natural ticks
22:45:27 <garykac> Looking for high-level feedback before writing a more formal proposal.
22:45:56 <Marcosc> q+
22:46:19 <reillyg> Marcosc: What is supported hardware-wise on various platforms?
22:46:43 <reillyg> garykac: Chrome used to have an API for ticks as part of Pepper (for plugins) that worked across platforms.
22:46:49 <reillyg> ... I know Apple has an API for ticks.
22:46:50 <tantek> tantek has joined #webapps
22:47:07 <reillyg> ... Linux and Windows differ in how they report ticks.
22:47:33 <reillyg> ... I believe Pepper tried to fake ticks when they weren't supported rather than returning 0.
22:47:34 <Marcosc> q-
22:47:45 <reillyg> smaug: I worry that some sites would be broken on a laptop without a mouse.
22:48:02 <reillyg> ... Some sites could depend on the presence of the ticks attribute.
22:48:06 <reillyg> q+
22:48:16 <reillyg> garykac: You would prefer a heuristic?
22:48:21 <reillyg> smaug: Yes.
22:48:37 <reillyg> garykac: I will work on a heuristic as part of the proposal.
22:50:13 <garykac> A Nullable default would be better for feature support discovery.
22:50:20 <reillyg> q-
22:51:07 <ericwilligers> ericwilligers has joined #webapps
22:51:10 <reillyg> smaug: That could be difficult for developers if there are multiple devices.
22:52:17 <reillyg> garykac: I will follow up with proposals for deltaMode and ticks.
23:02:37 <AramZS> AramZS has joined #webapps
23:04:33 <plh> plh has left #webapps
23:10:20 <Guest85> Guest85 has joined #webapps
23:16:34 <diekus> diekus has joined #webapps
23:17:04 <reillyg> scribe+
23:17:12 <reillyg> Topic: Web Application Manifest
23:17:15 <dmurph> present+
23:17:28 <marcosc> marcosc has joined #webapps
23:17:35 <scheib> present+
23:18:41 <reillyg> Sub-topic: Manifest overrides
23:18:52 <reillyg> Subtopic: Manifest overrides
23:18:57 <marcosc> https://github.com/w3c/manifest/issues/1045
23:19:14 <diekus> present+
23:19:17 <reillyg> marcosc: Editors have gotten together to discuss this issue.
23:19:33 <jsbell> jsbell has joined #webapps
23:20:06 <reillyg> ... When you launch an application for a user who prefers dark mode you don't want a flash of unstyled content.
23:20:30 <reillyg> ... This is a solved problem for CSS but operating systems don't know CSS and so can't apply this solution in real time.
23:20:43 <reillyg> ... How do we structure this data in JSON?
23:20:56 <reillyg> ... Similar problem for translations: It is an environment setting.
23:21:31 <reillyg> ... I may install an application in English but be a French speaker and change the language.
23:21:58 <reillyg> ... Having translations inside the manifest file is tremendously helpful because you don't need to maintain multiple files but it does introduce some redundancy.
23:22:24 <reillyg> RRSAgent, please generate minutes
23:22:24 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/12-webapps-minutes.html reillyg
23:23:05 <reillyg> marcosc: On the WebKit side we feel that we should use a media query everywhere we can.
23:23:17 <reillyg> ... Limitation is that there is no "prefers language" media query.
23:23:26 <reillyg> ... We could take this to the CSS WG.
23:23:38 <reillyg> dmurph: This requires specifying a parser for CSS.
23:23:57 <reillyg> marcosc: The infrastructure for this is already there.
23:24:11 <tantek> tantek has joined #webapps
23:24:15 <reillyg> louise: We have some concerns with using the media query parser.
23:24:22 <reillyg> ... (we = Chromium)
23:24:26 <tantek> present+
23:25:07 <reillyg> ... How do we parse queries like "width" from inside the manifest parser.
23:25:22 <reillyg> marcosc: Yes, some media queries might not make sense.
23:25:33 <dcrousso> dcrousso has joined #webapps
23:25:51 <reillyg> ... The user agent might throw these away.
23:26:31 <reillyg> dmurph: If CSS media queries have all these capabilities that come from all over the system. That's fine in the renderer but in the manifest that data is needed at all times.
23:26:38 <reillyg> ... Is the cost worth it vs. string matching.
23:27:21 <reillyg> marcosc: Devin and I went through the potential queries and it felt like these media queries could make sense in the future.
23:27:44 <reillyg> dcrousso: These queries have demonstrated their usefulness on the web.
23:28:13 <reillyg> ... It's odd to make a decision about what is useful when they exist on the web already.
23:28:34 <reillyg> dmurph: It would be helpful to see the results of that investigation that you did.
23:29:10 <reillyg> dcrousso: It's okay if not all of these media queries exist for manifest.
23:29:25 <reillyg> ... Developers get progressive enhancement as engines support them in the future.
23:29:30 <tantek> +1 progressive enhancement and such "forward compat" design of dropping things you don't understand
23:29:38 <reillyg> ... Don't outright reject them when we don't have a use case today.
23:29:49 <tantek> +1 dcrousso
23:29:53 <reillyg> dmurph: I'm not the person to convince here.
23:30:06 <reillyg> ... Even imaginary use cases seem helpful.
23:30:15 <reillyg> dcrousso: We'll write down some of our examples.
23:30:40 <reillyg> marcosc: We could have a very limited set of supported things.
23:31:15 <reillyg> ... We should start with CSS media queries syntax instead of starting our own thing.
23:31:51 <reillyg> ... We don't know how insane it could get.
23:32:15 <reillyg> ... It would be nice to specify this and do a reference implementation to see how it goes.
23:32:23 <reillyg> louise: I'm going to do a prototype with the CSS parser.
23:32:39 <reillyg> ... It will support dark and light mode to start with.
23:32:39 <tantek> q?
23:34:04 <reillyg> marcosc: We'll work out a time to meet tomorrow to go through queries that could be useful.
23:34:22 <ericwilligers> present+
23:34:34 <reillyg> Subtopic: Updating security-sensitive manifest members
23:35:05 <reillyg> dmurph: We see fields like "name" as a security boundary.
23:35:11 <rmcelrath> rmcelrath has joined #webapps
23:35:18 <reillyg> ... It would be bad if sites changed these out from under the user.
23:35:27 <reillyg> ... It's easy to detect when a string changed.
23:35:57 <reillyg> dmurph: Images are much harder.
23:36:22 <reillyg> ... We noticed that some CDNs are encoding images differently under different scenarios.
23:36:35 <igarashi> igarashi has joined #webapps
23:36:36 <reillyg> ... This broke things.
23:36:49 <reillyg> ... We considered building a custom image diffing algorithm.
23:37:11 <reillyg> ... We're considering having the manifest declare a token, e.g. "brand_token".
23:37:28 <reillyg> ... When this changes then we prompt the user for changes to fields like images.
23:37:32 <marcosc> q+
23:37:37 <reillyg> ... Otherwise we don't touch changes to these fields.
23:37:43 <marcosc> q-
23:37:57 <reillyg> scheib: New installs would always get the new images.
23:38:02 <marcosc> q+
23:38:07 <reillyg> ... Old installs wouldn't get any changes until you change the key.
23:38:23 <reillyg> dmurph: Our position is that none of these changes can occur without a prompt to the user.
23:38:49 <reillyg> ... We originally thought this could be versioned but parsing a number introduces risk and we didn't want to make it look to much like a version number.
23:38:54 <reillyg> ... So we only care if the token value changes.
23:39:23 <dmurph> Current proposal for image updating: https://docs.google.com/document/d/11qoRuZRU2W7eKCimhcu2TmJS4jvJ65-Nz8_n9Fidrlg/edit
23:40:50 <reillyg> marcosc: This proposal is digging really deep into specifically changing images. I'm looking at this more generally. If you change the identity then it is a new app.
23:41:00 <reillyg> dmurph: Developers need to change the name and icon if there is a brand change.
23:41:15 <reillyg> ... Images seem to be the thing which require this token.
23:41:28 <jsbell> present+
23:41:44 <reillyg> marcosc: If something's changed then you should go through the install flow again.
23:42:33 <reillyg> dmurph: We could imagine having a version for the whole manifest and wouldn't consider any changes to the manifest unless this changes.
23:42:56 <reillyg> ... There's a concern that if we used numbers then developers would think that it can't go down.
23:43:15 <tantek> q?
23:43:29 <marcosc> q-
23:43:32 <reillyg> marcosc: We could run into the same issue with shortcuts.
23:43:57 <reillyg> dmurph: Our Trust and Safety team didn't think shortcuts were a problem because they are shown in the context of the main app icon. File handling however is a problem.
23:44:21 <reillyg> marcosc: We could leave this up to the implementer and say that all icons could be considered security sensitive.
23:46:09 <reillyg> tomayac: Another alternative: require a URL change in order to have the icon redownloaded.
23:47:04 <reillyg> dmurph: I think that option is in the document but we thought that it would be less obvious for developers.
23:48:40 <tantek> q?
23:49:13 <reillyg> marcosc: We could assume that if the manifest has changed then that is a signal to do a re-install.
23:49:17 <scheib> q+
23:49:55 <tantek> q+ to ask if there is a documentation of good faith / developer desired use-cases for updating the icon? possible to add friction to bad faith changes without actual use-cases?
23:50:18 <tomayac> q+
23:50:23 <reillyg> scheib: There's a risk of over-triggering if you use changes to the manifest to repeat the install.
23:50:27 <marcosc> q-
23:50:36 <marcosc> q- scheib
23:50:44 <tantek> +1 scheib alert/notification fatigue is real
23:50:50 <reillyg> ... This was our experience when we tried to detect changes.
23:50:54 <scheib> q-
23:50:58 <reillyg> ... It caused a lot of user fatiguq.
23:51:11 <reillyg> s/fatiguq/fatigue/
23:51:12 <PenelopeMcLachlan> q+
23:51:25 <marcosc> q- tantek
23:51:29 <reillyg> tantek: Do we have documentation of what the good-faith changes are.
23:51:44 <reillyg> dmurph: Brand changes, e.g. Google Drive changing their icon.
23:52:10 <reillyg> tantek: Have you seen temporary icons updates, like for the holiday season?
23:52:21 <reillyg> dmurph: No, but developers might have noticed that it doesn't work.
23:52:36 <reillyg> marcosc: When the Ukraine war started lots of apps changed their icon.
23:52:54 <reillyg> tantek: Can we add friction to bad-faith changes without blocking good-faith changes?
23:53:12 <reillyg> dmurph: It's hard to tell the difference.
23:53:37 <marcosc> q- tomayac
23:53:38 <reillyg> ... We feel the user has to approve the icon before it can be shown.
23:53:56 <reillyg> tomayac: Developers are used to changing hashed URLs when the file contents change.
23:54:19 <reillyg> ... I've seen some apps which allow the user to change icons after they are installed.
23:54:35 <reillyg> ... With app stores reviewers can notice bad-faith icon changes.
23:54:48 <reillyg> ... Users are used to these changes happening without their interaction.
23:54:56 <reillyg> ... On the web we don't have this review step.
23:55:31 <reillyg> ... Users have muscle memory of where their apps are and so might notice when something changes maliciously.
23:56:05 <tantek> q?
23:56:06 <reillyg> q?
23:56:28 <reillyg> dmurph: Alan at Google is working on this right now. Reach out to him or me.
23:56:30 <reillyg> q- PenelopeMcLachlan
23:57:32 <reillyg> PenelopeMcLachlan: Developer might not expect changes to the URL or bytes to trigger UI but an explicit token would make it clear that that is what is going to happen.
23:57:58 <reillyg> Subtopic: Getting display modes out of CSS and back to the manifest spec
23:58:14 <reillyg> dmurph: I think we've been a bit blocked on CSS.
23:58:24 <reillyg> marcosc: We just need to find Florian and get this merged.
23:58:44 <reillyg> ericwilligers: Does this group want this back?
23:58:46 <reillyg> marcosc: Yes.
23:59:18 <scheib> do work on issue, not discussed here. https://github.com/w3c/csswg-drafts/issues/7306
23:59:47 <reillyg> RRSAgent, please generate minutes
23:59:47 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/12-webapps-minutes.html reillyg