Meeting minutes
Welcome + introductions
Agenda bashing
New Work
MC: new charter https://
MC: Web Locks API
MC: Contact Picker API
MC: User-Agent Client Hints and Haptics
Status updates on each specs
UI Events
[#308](https: //github.com/w3c/uievents/issues/308) | [#31](https://
GK: 21 year old spec... the spec has a very long legacy...there is main spec, but we extracted code and key into their own spec. Key and Code spec are more or less done. I've updated the implementation report. There are two independent implementations each mandatory requirements.
GK: For the core UI spec, the spec was written in a fairly casual style... we need to rewrite it in an algorithmic style. There are a lot of specs depending on this spec (e.g., pointer spec). I've been talking to the editor of pointerlock, and seeing how we can bridge the two. I'm working on the algorithmic draft.
MC: there is a document available?
GK: I'll get a link for it... it's linked from the README
Pointerlock
<mustaq> https://
<garykac_> Link to UIEvents algorithmic rewrite doc : https://
<garykac_> UIEvents code impl report: https://
MA: since last meeting we made one normative change: x, y coordinate from long to a double. This helps with CSS integration. We made some additional editorial changes. We have two pull requests open around user activation. And another for unaccelerated movements.
<garykac_> UIEvents key impl report: https://
<mattreynolds> https://
MR: We need more buying from other browser vendors. We believe have good solutions for MacOS, but looking at how we can support this on Linux.
MR: In Chrome ^^
Intersection Observer
See: https://
SZ: The spec is nearly CR ready. But there are still some outstanding interop issues.
<zcorpan> https://
<szager> Issue #95 to be decided in favor of visual viewport, barring objections.
IMPORTANT^^^^
<zcorpan> https://
<zcorpan> https://
seeking input on: Define content clip (386)
SZ: and "isIntersecting definition doesn't match browsers when thresholds are involved" 432
Emilio: where do implementations differ?
SZ: I'm not sure if there is an interop issue in the wild... but the spec is vague.
Emilio: So it might be a matter of doing a spec cleanup
SZ: I think there might be hidden issues, so just want to make sure we get this right. There are some cases might cause issues in the wild.
SZ: If we could close those three issues, we could get it to CR
SZ: There is also V2 - it covers occlusion [sic], for security reasons ... it's used in about 4% of page loads. Apple does consider this high on their priority list, but is willing to accept patches.
Emilio: I could try make a case in Mozilla
smfr: I implemented everything except the device pixel box
sz: I didnt' know that you have implemented that. The spec does provide some wiggle room.
emilio: we've also fixed up the box types in Firefox, so we are in the same state as Webkit.
ZS: I wonder if folks would be willing to implement the delay for intersection observer, which can help with battery
Emilio: I wonder if we can move that to the V1 spec?
SZ: I'll file an issue
<emilio> https://
ZS: it might be good to show the diff between 1 and 2
<szager> https://
<szager> https://
SZ: the delay parameter we were talking about ^^
smfr: are there web platform tests?
sz: I think there are, I need to check.
Web App Manifest Application Info
https://
<szager> WPT for IntersectionObserver 'delay' feature: https://
ag: there is some debate about making this this a spec to the REC track. Parts of this spec could/has be implemented in browsers (e.g., rich install dialogs). There is some additions being made, like "policies".
<aarongu> Manifest App Info proposals: installation-related client Hints https://
<aarongu> Policies in manifest: https://
<aarongu> Publisher in manifest: https://
Gamepad
https://
MR: big rewrite, modernized the spec to be algorithmic. We also made gamepad objects live. We are looking at adding an event model that satisfy all use cases, specially for cloud gaming clients. We are also looking how we might get raw and events that are tied to requestAnimationFrame().
<mattreynolds> https://
MC: we added permission-policy "gamepad" with allowed "self", shipped in Firefox. But turned out to be not super web compatible. So we might switch it to "all".
RG: to what degree does do we tolerate permission policy change? having the policy is better than not having one. But we should have some kind of guidance to help with these issues.
MC: we should take this up with the TAG for sure.
Image Resource
https://
AG: there doesn't seem to be any blockers for it. It's used throughout the web manifest spec. We talked about other specs potentially using this also (e.g., web payments).
Push API
https://
https://
MC: triaged the issues. Few interop issues on the Firefox side. We don't a push server, so some things are hard to test. Overall, it's in pretty good shape tho.
MC: We've done more integration with the Permissions spec
Screen Orientation
https://
MC: the outstanding issues are mostly editorial. We have interop on Chrome and Firefox. It's nearly done... but left wondering if maybe we could move this to the Fullscreen API.
Web Share
https://
MC: in a good state for CR. There some small issues to take care of around particular URL types to share. Good interop all around.
IndexedDB
<jsbell> https://
<jsbell> https://
JB: very quiet 12 months. In 2019, we have good conversations to add new things... then 2020 happened... so we haven't done too much. WebKit implemented `databases`. Several of the new things in "v3" are currently only in Blink and Gecko.
JB: We did check if batch operations could be performance improvement, but turned out it wasn't so we rolled that back. We are exploring how to make more complex queries more performant. We've had only a very small trickle of feature requests, so we haven't moved on adding anything new. We've been considering making some editorial clarifications. If anyone else is interested in helping edit the spec, then please let me know.
JB: we talked about maybe publishing a FPWD. We could still do that.
Web App Manifest
https://
<zcorpan> https://
<xiaoqian> MC: we had a big meeting yesterday, hoping to get to CR in 6 months, widely implemented
ARIA in HTML
LW: almost at REC. Just going through AC review. We are hoping to be in REC in a month or so and to be using the new Process 2021 for autopublishing RECs
General questions and other things
Intersection observer issue 431
<zcorpan> https://
SP: this is issue I filed while specifying lazy loading images... if you have scrollable container, and that container has lazy images, those images will start loading too late. In my ideal world, the browser should do the right thing here, rather than require special markup to achieve things. There are some open questions: is it ok to use the same margin as the page, or should this be configurable somehow? And how should people opt-int
o this via intersection observer.
Issue title is "Ability to have automatic rootMargin for all nested scroll containers"
SZ: AMP has this problem. But they handle it by having multiple observers... but it's admittedly a bit inelegant. <discussion around root margins>... it's fragile. I'm open to suggestions.
Emilio: We could maybe use a CSS property? E.g. scroll-margin
SZ: I have an objection to doing that
emilio: we could only read this property if intersection observer opted into it?
sz: this can be polyfilled by using a stack of intersection observers
sp: what wouodl the behavior be when you specify 100% root margin when you have a scrollable container ?
sz: I'm happy to go along with whatever is generally useful for web developers
smfr: my actual question for iframes... what happens with lazy loading with iframes?
<discussion around iframes, cross-origin iframes and being able to detect when the parent container gets scrolled, and so on... intersection observer being used as a primitive, and algorithms that are internal to the spec, but not exposed to the API>
sz: the hard part is exposing an public API for this
smfr: we don't need to expose an API, as we are trying to solve this for lazy loading
sz: we don't have a concrete proposal right now
sp: I agree that it's possible without extending the IO API. But I agree that it would be messy because we would need to invalidate a bunch of things.
sz: we just need a clear + detailed proposal
Mc: anyone willing to produce the proposal?
SP: I might get time to do it
sp: there are a few people who know lazy loading, but I might be able to take it on. If a has opinions about different root margins for different scrollers, please comment in the issue.
Meeting adjourned!