– DRAFT –
TPAC 2022 WebApps WG meeting

Meeting Agenda: https://github.com/w3c/webappswg/wiki/TPAC-2022

Status update

macrosc: We're going to start by doing an update

if you are on zoom, you can try to raise your hand. Or, you can type "q+" on IRC

(and then "q-" when you are done)

Status update - ARIA HTML

ARIA went to rec last year

in the meantime a bunch of corrections & additions have been made, and it is stabilizing now.

We are moving to a new process to allow the spec to update quicker

In a couple months we will send out something for folks in this area to review

Status update - Badging

Currently held up looking for second implementer

(this effectively lets you put a badge on an app icon)

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

Thomas Steiner: There is a proposal for installed app badge, but also a proposal for a badge on the tab (in the browser)

any status on that?

marcosc: Yes, that proposal is there, but again we haven't had enough implementer interest

Status update - Contacts API

raya: Not a lot of changes in the spec, pretty happy. Moved from WICG to W3C. AFAIK nothing blocking moving it to rec

marcosc: There is a test suite as well. Second implementation is webkit?

raya: Yes

marcosc: We need to publish as first working draft. Haven't had a chance to see how it works in Safari yet.

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

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

ACTION: marcosc & reillyg to figure out first public working draft for this. Hopefully within 6 weeks we can move towards CR.

<trackbot> Sorry, but no Tracker is associated with this channel.

Status update - File API

mek: Not a lot has happened in last 2 years.

mek: We can use better tests.

Partitioning & partitioning blobs are active things that are being discussed

Something will need to be changed in the spec & we will be making changes in Chrome

https://github.com/w3c/FileAPI/

For partitioning we will need to figure out agent cluster vs top-level-site partitioning (please correct this - I think I misheard)

marcosc: Heard similar things - model is not quite right here with partitioning, will need to do additional spec work here

files are pretty useable right now even though the spec is not perfect

Status update - Gamepad API

Matt Reynolds: Have been adding support for more recent gamepads

touchpad support

there are some issues around haptics that we want to discuss

Moving to CR: we have several issues blocked CR-blocking - want to go through this later

most - want to figure out how to handle gamepad inputs when page is not active or visible

marcosc: there is a PR open about events

Matt Reynolds: Not sure how quickly we will be able to get that done for CR

(current API is a polling API - events would be a push API, big change, so probably not for this CR now)

Status update - Image Resource

https://github.com/w3c/image-resource/

marcosc: Image resource may or may not survive, because payment handler does something different that might take over

secure payment confirmation, specifically, which may supercede payment handler

Status update - IndexedDB

https://www.w3.org/TR/IndexedDB/

jsbell: Did start to integrate things into spec describing storage partitioning

jsbell: some minor editorial things as well

<RayanKanso> tantek (IRC): here's the position issue for the contacts API https://github.com/mozilla/standards-positions/issues/153

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

Safari on WebKit did implement most of the additions in v3 indexeddb, all 3 engines have all of the additions, hooray!

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

There are small things like -0 handling, terminology changes

biggest things coming up - storage buckets, which was talked about a past few tpacs ago. Moving forward w/ prototyping on Chromium side

similarly, as people are looking to refining back-forward cache spec, we may need to tweak things for how indexeddb is specified

there are a number of these integration-with-other-spec improvements that we could do

it would be great if we could have another active editor on IndexedDB, someone to jump in, bounce ideas off of, etc

marcosc: Good opportunity to help out for folks, mature spec, and important for the web

Status update - Intersection Observer

https://github.com/w3c/IntersectionObserver/

emilio: Mike Taylor triaged a bunch of spec issues that were obsolete, and removed polyfill in spec repo

some minor things fixed, and some improvements around zero-ing margins

there is one particular issue w/ interop issue between blink, webkit, and gecko. otherwise v1 is pretty stable

marcosc: For v2, mozilla had a bunch of concerns that seemed obvious around pixel perfect rendering etc

how feasible is the v2? Can we get something from the v2 part that is in agreement?

emilio: I don't know enough to answer that question, unfortunately

marcosc: v1 seems fairly interop-able, so we are happy with this?

<emilio> interop issue worth fixing: https://github.com/w3c/IntersectionObserver/issues/432

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)

Status update - Pointer Lock

https://github.com/w3c/pointerlock/

mustaq: There is one big change since last TPAC

it is synced with HTML-side

Status update: https://github.com/w3c/pointerlock/issues/80

Standing issues - the working draft and the editor draft shows the same timestamp, so they are the same thing?

marcosc: I can figure that one out for you

mustaq: Issue #74 - need to update pointer lock spec to add details about where information should be

<Github> https://github.com/w3c/webappswg/issues/74 : Update WG homepage

https://github.com/w3c/pointerlock/issues/36

unaccelerated movement for better gamepad experience

This need browser / implementer opinions, please reach out

ACTION: xiaoqian to work with Marcos on pointer lock issue#25

<trackbot> Sorry, but no Tracker is associated with this channel.

Mac & Windows we seem to have a solution for that issue

marcosc: There has been no feedback from WebKit side, right?

mustaq: Right, nothing from Mozilla or WebKit

<mustaq> https://lists.webkit.org/pipermail/webkit-dev/2020-October/031473.html

ACTION: marcosc - track down the WebKit position on this spec https://lists.webkit.org/pipermail/webkit-dev/2020-October/031473.html.

<trackbot> Sorry, but no Tracker is associated with this channel.

<mustaq> https://github.com/mozilla/standards-positions/issues/448

Status update - Push API https://github.com/w3c/push-api/issues/354

marcosc: The spec is in really good shape. 3 shipping implementations

Push API coming to MacOS and hopefully soon to iOS as well

issues - not many open, lacking testing, but it's a difficult spec to test, as you need a push infra to do it

so either create a webdriver API, or actually put up a push server somewhere and use that for testing

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

now looking at the future for folks who interested in leading working group about potential efficiencies we could do here with push looking forward

like, what if you could skip the service worker?

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.

Status update - Screen orientation API https://github.com/w3c/screen-orientation/issues/208

marcosc: This allows you to lock the screen orientation to landscape or portrait

Mobile-centric, but does have utility on desktop as well

(also events when orientation changes)

We have determined that this could be abusable, as there is no user-gesture guards

if you can't use it w/o fullscreen, and you need fullscreen to trigger it, why not just integrate w/ fullscreen spec?

(for example, fullscreen gives you the gesture to enter it)

kenneth: Manifest spec has standalone & fullscreen in the spec too - why not there?

marcosc: Yes - we should figure that out

Status update - UI Events https://github.com/w3c/uievents/issues/333

Gary: UI events were originally big tables

There was a request to break it out so there was required & optional values

There are only a few minor interop issues. e.g. mozilla still uses OS left and right instead of meta left and right

Doesn't seem like there is a reason to not move to to CR

Above was about key & code spec

<marcosc> https://www.w3.org/TR/uievents/

Now, about UI Events:

There are implementation differences between browsers because the spec is written in old style. Working on rewrite that is algorithmic to fix this

There is also pointer events which are related.

There is also related things with gamepad API and those events

Additionally - how to manage this spec change from spec writing point of view? not changing anything, but rewriting

marcosc: There is a long legacy with this spec, and it overlaps a lot with the dom spec itself.

This is really important spec with long legacy, but not in a good way right now

Gary: The way to make it algorithmic, is to identify differences, and document them (or convince browsers to agree

)

marcosc: Is this a useful spec at all to look up behavior, or is this fiction?

Gary: Not everything has been brought into DOM, there are things relied on here still

DOM spec would have same problem defining this. Event ordering is underspecified everywhere (focus, etc)

We do have some areas that we want to improve - scroll wheel. Developers are not following spec and looking at delta mode, for example

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.

UI Events is the only place where they can talk about these requests at the moment

marcosc: Is there overlap with HTML as well?

Gary: Not once you get on top of the core event spec

We need those algorithms somewhere. Question is where & is the HTML or DOM spec better.

Web App Manifest - https://github.com/w3c/manifest/issues/1046

marcosc: Two major interop issues are with internationalization (have model) and overriding things based on environmental conditions (like dark mode)

These seem like separate, but they could be seen as inter-related. Still trying to figure out

Also, some topics: scope extensions, launch handler, etc. We are having a session later to discuss these

Generally speaker, spec is in good place, although a bit slow. Becoming more and more inter-operable.

marcosc: Call out to mozilla - would be great to find a way of getting Mozilla more engaged

<diekus> A2HS ftw

dmurph: One issue spec-related is "where display modes are defined" - currently CSS

dmurph: One issue spec-related is "where display modes are defined" - currently CSS. Makes more sense in manifest?

ericwilligers: Yes - we would like to move these. Would be good to have these move back to the Manifest spec.

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.

Status update - Web Share https://github.com/w3c/web-share/

marcos: in excellent state

<diekus> Edge <3 WebShare on macv

marcosc: Microsoft folks are adding this to desktop, would be great for this to come to Mac on Chrome

marcosc: There were differences with permissions policies with agents. Would be nice to resolve

Web Locks https://github.com/w3c/web-locks/issues/111

jsbell: moved from WICG to webapps!

shout out to Mozilla for help and now also actively editing, thanks!

Spec has small surface area, mostly edge cases being discovered. Spec is in good shape. Implemented in all 3 engines!

on Chrome-side, looking at integration with storage buckets

Like IndexedDB - the integration with other concepts on the web - buckets & bf-cache - are things we need to work through

because implementation is on all 3 browsers, no reasons to not proceed with first working draft

marcosc: Agenda: https://github.com/w3c/webappswg/wiki/TPAC-2022

Screen Orientation Lock

<msw> https://github.com/whatwg/fullscreen/issues/186

Marcosc: This is a very old specification that goes back to Firefox OS.
… Requires full-screen.

kenneth: On Android you can request this without fullscreen in an installed PWA.

Marcosc: https://www.w3.org/TR/screen-orientation/
… It would be good to address this inconsistency for web compatibilty.
… Should we update orientation lock to require a user gesture?

JakeArchibald: You've already gone through a user gesture to get full screen.

Marcosc: Should you be able to keep rotating the screen without a gesture?

JakeArchibald: You could do the same with a CSS transform. It would be horrible and hacky so we should give developers a better option.

Marcosc: It's a bit of a maybe.

EllaGe: Apps like games on Android are only useful in landscape mode.

Marcosc: The manifest allows specifying this "base orientation".
… Is there a use case to rotate and is there enough of a risk of user annoyance to require a user gesture?
… We don't see people doing hacky things.

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.

Marcosc: When you are entering full screen, could we add an option to set orientation. This could avoid jank.

JakeArchibald: If you wanted to change the orientation you could call requestFullscreen() again with a different option and it wouldn't exit full screen.

MikeWasserman: I think the ergonomics of this are really nice, and could be polyfilled.
… Should there be a bit controlling whether the device can flip 180 degrees when locked to portrait or landscape?
… There are separate "primary" and "secondary" landscape and portrait modes.
… The use case is being able to flip your phone and have the content remain upright.
… Useful for video. Gaming might want the content locked to one particular direction.

Marcosc: There's a game I know which does this as you move your phone.
… This is allowed with "landscape", "landscape-primary" and "landscape-secondary".
… "landscape" means it can flip 180 degrees.

JakeArchibald: Could you requestFullscreen() with both "landscape-primary" and "portrait-primary"?

reillyg: Why specify multiple in requestFullscreen()?

JakeArchibald: The array would allow you to specify the list of orientations that can be entered into while in full screen.
… Instead of having special enum values which mean multiple allowed orientations.

kenneth: In an installed app which already uses the manifest to set full screen it would be weird to still have to call requestFullscreen().

JakeArchibald: If you have a standalone PWA then you could call requestFullscreen() without a user gesture.

kenneth: It wouldn't be good if the browser showed the full screen notification to the user when that happened.

JakeArchibald: The browser could choose not to do that.

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.

MikeWasserman: How would a site know it had been granted the orientation lock if the request was made with requestFullsceen()?

Marcosc: This call is a suggestion. The site could detect using CSS.

JakeArchibald: How would you get into a situation where full screen was granted but lock was not?
… You could detect by checking if the browser reads from the `orientation` property.
… If you give a dictionary property that the browser doesn't know it will ignore it.

Marcosc: This is a suggestion of how it will be.

smaug: This feels very different from the existing orientation lock.

JakeArchibald: It either needs to be considered a hint or you need to know in advance what values will be accepted.

Marcosc: When orientation changes it will fire an event, so you could observe that.

MikeWasserman: Are you referring to screen.orientation.type?

Marcosc: Yes, the event will fire after the properties change.

JakeArchibald: That will tell you the current rotation state but not the states that are possible.

Marcosc: We could add screen.supportedOrientations.

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.

Marcosc: That was the intent with this API as well.
… We're not likely to solve this now.
… I'm going to ask friends from Microsoft: On WebKit we've received bug reports from O365 about this API.

diekus: I don't know.

JakeArchibald: Orientations that are allowed could change. E.g. a laptop that turns into a tablet.

Marcosc: diekus is the editor of the Device Postures API.
… What happens when you are in portrait in tablet mode but then go into laptop mode. What happens?

kenneth: Android is similar. You can disable rotations at a system level.

JakeArchibald: That suggests that the hinting model is beter.
… There should be an event for "the supported subset of requested modes has changed"

Marcosc: There's a privacy angle.

reillyg: There aren't that many possible combinations.

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.

Marcosc: MikeWasserman has volunteered to work on this spec. We have web compat requests coming in from the WebKit side.

MikeWasserman: Existing usage for orientation type and angle is pretty substantial but locks are not.
… It's nice ergonomics to declare requested orientation when requesting full screen.

Marcosc: No objections heard here.

Marcosc: We should find annevk who edits full screen and put these ideas in his head

Gamepad

bradley: Here from Sony, been working on multi-touch for gamepad

mattreynolds: There are regular spec maintainer meetings, check in to join if interested.

<jsbell> Can someone on zoom drop the links matt shared into IRC?

Back Forward cache interaction

<marcosc> https://github.com/w3c/gamepad/issues/149

Relevant page lifecycle events, e.g. load, navigate away for pagehide, visibility change, freeze, and later resume, visibilitychange ...

<smaug> I could note that freeze/resume aren't part of the bfcache, but Lifecycle API

GamepadAPI has only gamepadconnected, gamepaddisconnected. No events when hidden

Proposing events: rawgamepadchange sent immediately, gamepadchange has same data but may be queued

Re: Page visibility integration

When becoming visible after being non visible need to compute a difference between states, and only fire event if needed

BFCache design principles sldie:

Gate actions on fully active state

Notes on integration:

. Inputs can be shared, so it is OK to disconnect and reconnect devices

. Vibration can not be shared

Exclusive access modes in other APIs may be related, e..g USB, HID

[end of slides]

smaug: lifecycle events are still only WICG, page hide and show are in HTML spec

JakeArchibald: Like that this proposal resolves issues as the page returns to visibility

<mattreynolds> https://docs.google.com/presentation/d/1zAcqgIut9WcJTh6Ikfh4CmKecD5LgG6_NKG6mmP0Lcg/edit?resourcekey=0-bAagoqjkLyQXymVtnPgKkQ#slide=id.g1537c9e7700_0_240

<marcosc> Rakina from Google BF Cache team

Rakina: We could adjust event timings before freeze

JakeArchibald: What happens in USB when leaving a page?

JakeArchibald: Only do things on hiding if necessary

mattreynolds: in proposal, would not fire disconnect on loss of visibility

Rakina: is it OK to never fire?

reillyg: Yes, same as e.g. closing a tab

mattreynolds: Changing topics:

Xbox One impulse trigger effects

<mattreynolds> https://docs.google.com/presentation/d/1yWlVHJeIYaikxHnFj0VXrAYTv_n9rXG0CzpTVRsFNQ8/edit#slide=id.g15642ef02ee_0_59

previously only intensity and duration

2017 TPAC proposal included. This was implemented in chromium

2022 trigger-rumble effect being proposed by Microsoft

WebKit currently opposed regarding integrations

[end of slides]

JakeArchibald: Compatibility with haptics that aren't just rumble? e.g. PS5 trigger?

mattreynolds: Earlier proposal is extensible with new effect types

believe effects beyond rumble are possible.

e.g. buffered haptics (a waveform) might be possible. But we don't have a specification for how to handle / buffer these yet

marcosc: Would like to hear from device manufacturers regarding what types of waveforms , how much data, number of waveforms

marcosc: Also do not want to limit for what hardware is coming with more capabilities

mattreynolds: agree with goals for extensibility

Rik Cabanier(?) at Meta on oculus. Have implemented gamepad API with several features, can share more off meeting

bradley: Perhaps device introspection would permit addressing the wider range of devices for now

ARIA in HTML

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

<plh> marcos: the process promised us to automatically update things on /TR and it didn't happen

<plh> ... [showing proposed corrections]

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

<Marcosc_> plh: for the first two steps you don't need Director approval

<Marcosc_> plh: ideally it should be done like 2 times a year

<plh> https://github.com/w3c/webrtc-pc/pull/2713

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

<Marcosc_> plh: their intent is to make lives easier for Editors, while considering what lawyers need (they need to see the changes)

<Marcosc_> plh: I told the WebRTC that their approach is ok

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

<Marcosc_> MC: thanks for that overview.

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

<Marcosc_> MC: specific for ARIA in HTML and auto publishing, where did we land on that?

<Marcosc_> plh: Danis has already enabled it

<plh> https://github.com/w3c/echidna/issues/1048

<Marcosc_> MC: fantastic...

<Marcosc_> plh: the system doesn't know about the substantive vs non-substantive changes.

<Marcosc_> MC: so, how do we add new features?

<Marcosc_> plh: you can add "candidate additions"

Scrollwheel deltaMode

Some background:

Many developers don't bother checking |deltaMode| before using the |deltaX| value. They just assume that it's DOM_DELTA_PIXEL (the default).

Not an issue for Chrome,Edge,Safari because they *always* return PIXEL values.

But Firefox can return _LINE or _PAGE (as appropriate).

This is good because there are scenarios where _LINE or _PAGE can be Quite Useful.

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.

Proposal to have |deltaMode| to always be _PIXEL and add a new attribute (or attributes) for _LINE and _PAGE values.

https://github.com/w3c/uievents/issues/181

See followup: Firefox updated to always use _PIXEL unless it detects that |deltaMode| has been queried.

https://groups.google.com/g/mozilla.dev.platform/c/fUXLgaSoeLI/m/ubt__u7MAQAJ?pli=1

Is this proposal for new attributes no longer necessary?

smaug: This is what we're doing now and I cannot recall any regressions.

How can we spec that algorithmically?

Add an internal slot "deltaModeChecked" that tracks whether or not |deltaMode| was recently read in the current script context

if (deltaModeChecked) {

UA can return _PIXEL _LINE or _PAGE values as appropriate

} else {

UA must return _PIXEL

}

ISSUE: When does deltaModeChecked get reset?

<trackbot> Sorry, but no Tracker is associated with this channel.

Scrollwheel ticks

https://github.com/w3c/uievents/issues/17

Examples of where ticks can be useful: a digit-selector, a menu or a drop-down list, a photo carousel.

In each of these cases, a single tick should select the next element regardless of how many "pixels" are reported.

Ticks are hard for web devs to calculate since pixels-per-tick differs for each platform (and hardware).

Issues:

But what about mouse with smooth scrolling?

Or input devices that fake scrollwheel events (like a touchpad)?

Browsers currently generate fake high-level scroll events for these devices for compatibility.

What should these fake events have for ticks?

Options:

* Always use 0 for devices that don't have natural ticks

* Use a heuristic to generate fake ticks

Tentative Proposal:

* Add ticks attribute

* Default value = 0 for devices that don't have natural ticks

Looking for high-level feedback before writing a more formal proposal.

Marcosc: What is supported hardware-wise on various platforms?

garykac: Chrome used to have an API for ticks as part of Pepper (for plugins) that worked across platforms.
… I know Apple has an API for ticks.
… Linux and Windows differ in how they report ticks.
… I believe Pepper tried to fake ticks when they weren't supported rather than returning 0.

smaug: I worry that some sites would be broken on a laptop without a mouse.
… Some sites could depend on the presence of the ticks attribute.

garykac: You would prefer a heuristic?

smaug: Yes.

garykac: I will work on a heuristic as part of the proposal.

A Nullable default would be better for feature support discovery.

smaug: That could be difficult for developers if there are multiple devices.

garykac: I will follow up with proposals for deltaMode and ticks.

Web Application Manifest

Manifest overrides

Manifest overrides

<marcosc> https://github.com/w3c/manifest/issues/1045

marcosc: Editors have gotten together to discuss this issue.
… When you launch an application for a user who prefers dark mode you don't want a flash of unstyled content.
… This is a solved problem for CSS but operating systems don't know CSS and so can't apply this solution in real time.
… How do we structure this data in JSON?
… Similar problem for translations: It is an environment setting.
… I may install an application in English but be a French speaker and change the language.
… Having translations inside the manifest file is tremendously helpful because you don't need to maintain multiple files but it does introduce some redundancy.

marcosc: On the WebKit side we feel that we should use a media query everywhere we can.
… Limitation is that there is no "prefers language" media query.
… We could take this to the CSS WG.

dmurph: This requires specifying a parser for CSS.

marcosc: The infrastructure for this is already there.

louise: We have some concerns with using the media query parser.
… (we = Chromium)
… How do we parse queries like "width" from inside the manifest parser.

marcosc: Yes, some media queries might not make sense.
… The user agent might throw these away.

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.
… Is the cost worth it vs. string matching.

marcosc: Devin and I went through the potential queries and it felt like these media queries could make sense in the future.

dcrousso: These queries have demonstrated their usefulness on the web.
… It's odd to make a decision about what is useful when they exist on the web already.

dmurph: It would be helpful to see the results of that investigation that you did.

dcrousso: It's okay if not all of these media queries exist for manifest.
… Developers get progressive enhancement as engines support them in the future.

<tantek> +1 progressive enhancement and such "forward compat" design of dropping things you don't understand

dcrousso: Don't outright reject them when we don't have a use case today.

<tantek> +1 dcrousso

dmurph: I'm not the person to convince here.
… Even imaginary use cases seem helpful.

dcrousso: We'll write down some of our examples.

marcosc: We could have a very limited set of supported things.
… We should start with CSS media queries syntax instead of starting our own thing.
… We don't know how insane it could get.
… It would be nice to specify this and do a reference implementation to see how it goes.

louise: I'm going to do a prototype with the CSS parser.
… It will support dark and light mode to start with.

marcosc: We'll work out a time to meet tomorrow to go through queries that could be useful.

Updating security-sensitive manifest members

dmurph: We see fields like "name" as a security boundary.
… It would be bad if sites changed these out from under the user.
… It's easy to detect when a string changed.

dmurph: Images are much harder.
… We noticed that some CDNs are encoding images differently under different scenarios.
… This broke things.
… We considered building a custom image diffing algorithm.
… We're considering having the manifest declare a token, e.g. "brand_token".
… When this changes then we prompt the user for changes to fields like images.
… Otherwise we don't touch changes to these fields.

scheib: New installs would always get the new images.
… Old installs wouldn't get any changes until you change the key.

dmurph: Our position is that none of these changes can occur without a prompt to the user.
… 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.
… So we only care if the token value changes.

Current proposal for image updating: https://docs.google.com/document/d/11qoRuZRU2W7eKCimhcu2TmJS4jvJ65-Nz8_n9Fidrlg/edit

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.

dmurph: Developers need to change the name and icon if there is a brand change.
… Images seem to be the thing which require this token.

marcosc: If something's changed then you should go through the install flow again.

dmurph: We could imagine having a version for the whole manifest and wouldn't consider any changes to the manifest unless this changes.
… There's a concern that if we used numbers then developers would think that it can't go down.

marcosc: We could run into the same issue with shortcuts.

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.

marcosc: We could leave this up to the implementer and say that all icons could be considered security sensitive.

tomayac: Another alternative: require a URL change in order to have the icon redownloaded.

dmurph: I think that option is in the document but we thought that it would be less obvious for developers.

marcosc: We could assume that if the manifest has changed then that is a signal to do a re-install.

scheib: There's a risk of over-triggering if you use changes to the manifest to repeat the install.

<tantek> +1 scheib alert/notification fatigue is real

scheib: This was our experience when we tried to detect changes.
… It caused a lot of user fatigue.

tantek: Do we have documentation of what the good-faith changes are.

dmurph: Brand changes, e.g. Google Drive changing their icon.

tantek: Have you seen temporary icons updates, like for the holiday season?

dmurph: No, but developers might have noticed that it doesn't work.

marcosc: When the Ukraine war started lots of apps changed their icon.

tantek: Can we add friction to bad-faith changes without blocking good-faith changes?

dmurph: It's hard to tell the difference.
… We feel the user has to approve the icon before it can be shown.

tomayac: Developers are used to changing hashed URLs when the file contents change.
… I've seen some apps which allow the user to change icons after they are installed.
… With app stores reviewers can notice bad-faith icon changes.
… Users are used to these changes happening without their interaction.
… On the web we don't have this review step.
… Users have muscle memory of where their apps are and so might notice when something changes maliciously.

dmurph: Alan at Google is working on this right now. Reach out to him or me.

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.

Getting display modes out of CSS and back to the manifest spec

dmurph: I think we've been a bit blocked on CSS.

marcosc: We just need to find Florian and get this merged.

ericwilligers: Does this group want this back?

marcosc: Yes.

<scheib> do work on issue, not discussed here. https://github.com/w3c/csswg-drafts/issues/7306