Meeting minutes
Recording: https://
Slideset: https://
Captured Surface Control 🎞︎
Zoom control 🎞︎
Elad: implemented in Chrome like css zoom
Jan-Ivar: supports the attribute
… there is a separate discussion about where the API should belong
… instead of nullable, you suggest a default to 100?
Elad: re API anchoring, that discussion was around gestures, not for zoom level?
Jan-ivar: let's discuss the anchoring question later
… although it would have been good to discuss this topic first
Cullen: could you tell more about how safe is this approach? given risks of overexposure
Elad: this has indeed been discussed - we're suggesting a layered security approach: the UA ensures the user gives consent to share a specific thing, plus additional consent on zoom/scroll?
Cullen: is the latter implicit or explicit?
Elad: this is in origin trial if you want to try - it comes with an explicit chrome level prompt
Cullen: I'll give it a try - it feels risky
youenn: attribute is an improvement; nullability allows to express whether zoomability has a meaning for the given surface
… re API anchoring, we should discuss this; we had discussed in the past multiple surfaces captured in a single getDisplayMedia
… we need to future-proof the API since that's one use case we know about
RESOLUTION: zoomLevel is an attribute, nullable for now but may be revisited
Jan-Ivar: note that developers will need to test for undefined already since it's only available in one browser atm
HTA: there is a complexity cost to future proofing - I prefer designing for current requirement set
oncapturedzoomlevelchange 🎞︎
Youenn: feels like the event name is too long - we can bikeshed it later
get/setSupportedZoomLevels() 🎞︎
Jan-Ivar: using Youenn's proposal allows to remove getZoomLevels(), which has risks of creating interop issues
… also has nicer safety characteristics to avoid a malicious app to over-zoom
Youenn: +1 to the increase/decrease API; could you say more about the need resetZoomLevel()?
Elad: re removing the need of getZoomLevels, you still need it to know whether you've hit a max
… we've heard the need for reset from product teams
Youenn: at least getSupportedZoomLevels() would only to report the extremes
Harald: setZoomLevel feels more ergonomic
Dom: you could return false to indicate that you've reached an extreme value
Elad: but that doesn't work when starting from the extreme
Elad: I'm hearing support to move forward with increase/decrease/reset, and simplify getSupportedZoomLevels() to a range
RESOLUTION: Use increase/decrease/resetZoomLevel() and simplify getSupportedZoomLevels() to a range
Scroll control 🎞︎
Youenn: the costs for spec authors and implementers seem low
Elad: the implementation cost is not negligible
Dom: you could imagine applying effects on a local capture to e.g. visualize different color scheme on a design
Jan-Ivar: from a logical perspective, this is a one-to-many relationship
Forwarding other gestures 🎞︎
Jan-Ivar: touch events would probably be applicable to e.g. windows tablets
… for scrolling
Youenn: forwardGestures(el, false) is pretty clear - not sure about the meaning of true
… would this be all "true", or all to default value
… re option 3, not clear how you stop forwarding
… I like option 4
Elad: I'm also liking it better now
Harald: defaults that push things in scope feel dangerous; option 1 is simple
… having been to be explicit about the gestures you allow feel like an improvement
Elad: the dictionary would be needed now to help with future-proofing - developers can decide whether they want to be liberal or conservative with gesture forwarding
… the app needs to decide which gestures to consume locally vs forward
Youenn: but part of I'm saying is that "wheel" vs "touch-scroll" is a useful distinction
Jan-Ivar: option 3 won't work given default true values
… I like option 1 (?)
Guido: option 3, default values would have to be false
… I think for safety reasons, option 1 & 3 are preferable
Elad: I suggested default to true for wheel given that's currently the only value, but I understand that's not right
Youenn: wheel is the wrong semantics - it should be about scrolling
harald: but a wheel event can be used for other things that scrolling
Guido: I don't like option 4 - I think we're unlikely to find consensus
Jan-Ivar: in the Chrome implementation, can the Web app intercept the event?
Elad: don't think so, would need to double check
Consideration of limitation to HTMLVideoElement 🎞︎
Jan-Ivar: if you have an interactive overlay , it would need to dispatch events
… to the video element
… I didn't know that `pointer-events: none` prevented dispatching event handlers
… Libraries would evolve to suppor this scenario
Elad: this isn't limited to trusted events; pointer-events make using event dispatch unworkable
Elad: heuristics can be applied independently of what element the API is applied to
Tim: hearing about these heuristics feels like it will be very problematic for developers to make sense of it
… I don't think the target element changes this
… but it feels like testing this will be hard
… if somebody starts scribling over 2/3rd of the screen, will that stop working?
Jan-Ivar: it would be simpler to have it on the video element from an ergonomic perspective, and that pausing the video would stop the scrolling
… in terms of UA mitigations, UA do clickjacking mitigations all the time
Guido: the UA is well positioned to know the binding between capture and the video element
… restrictions are orthogonal to the element
Dom: I'm hearing that security restrictions are mostly orthogonal to that particular API surface,; I'm also hearing a bit of an ergonomic advantage to the video element (and I agree with it); but the issue with annotation and pointer-events is problematic
Jan-Ivar: I would like to have an opportunity to give a bette representation of my perspective
Elad: we're hearing developers request for this to work at least with canvas
Jan-Ivar: this could be something we extend to - it's the case for captureStream() for instance
Guido: supporting the core use case of annotation feels like something any proposal need to demonstrate
Jan-Ivar: I'll look into the pointer-events situation, that's new information to me
Youenn: is there a use case for an HTML element that isn't an overlay to a video element?
Elad: video *or* canvas which is an important part of the MVP for us
… we're hearing requests (e.g. from Meet) to have this supported even if the video is only painted on a canvas
Dom: would be to hear more about the reasoning for these requests (to understand the trade off in adding that support)
Screen Capture 🎞︎
Suggest User Agents treat a captured tab as visible 🎞︎
Harald: when you capture a browser *window* it includes the chrome of the browser
… and a browser could capture the window of another browser
Youenn: the described behavior makes some sense to me; would this be guidance or required?
… I would be fine with guidance, not sure about requiring it, esp for window
Jan-Ivar: I would be happy with SHOULD for both
… we want to avoid having a browser page throttled when being captured
Youenn: SHOULD SGTM
Elad: is this tab-only or window too?
Jan-Ivar: both
Elad: tab would seem to be an easy starting point
Harald: I'm happy with a MUST for tabs, needs more time to discuss if this is feasible for window
… maybe discuss this in a new issue
Dom: re window, are we only talking about browser window of the same UA? is that really harder than a tab?
Elad: a browser cannot necessarily detect that it is being window-captured depending on the OS
… hence why I suggest starting with tabs
Youenn: if a window is fully occluded, an OS may not provide any frame (and thus throttling might actually be the right thing)
… we can give advice in that direction, without having the spec trying to require it
Jan-Ivar: how about MUST for tab capture?
Youenn: SGTM
Tim: I don't see it needed for window - if it works only sometimes, that's harder to explain to users
… let's do it just for tabs, as a MUST
Elad: are there other states that ought be treated the same way as visibility?
RESOLUTION: focus on tab capture and make it a requirement (MUST)
Youenn: we should look into other properties
Elad: e.g. blur (that's the only one I can think of)