Skip to content

Latest commit

 

History

History
437 lines (240 loc) · 27 KB

06-17-minutes.md

File metadata and controls

437 lines (240 loc) · 27 KB

TAG Minutes - week of 17 June 2024

Call Agendas

This agenda can be viewed and updated on Github.

Breakout A (Europe / China) - 2024-06-17

Breakout B (California / Europe) - 2024-06-17

Breakout C (California / Australia) - 2024-06-17

Breakout D (California / Australia) - 2024-06-18

Breakout E (Europe / China) - 2024-06-19

Call Minutes

Breakout A (Europe / China) - 2024-06-17

Present: Dan, Max, Matthew, Amy, Yves, Lea

Regrets:

Eligibility for autofill - @cynthia, @torgo

no change

Captured Mouse Events - @hober, @hadleybeeman

Dan: has this timed out?

Matthew: have they requested a11y review? Can't see that they have

Yves: nothing on webkit and mozilla standards positions

Dan: the spec itself hasn't been updated since last july

Yves: no comment since august

Dan: leaves closing comment and marks as timed out

Securing Verifiable Credentials using JOSE and COSE - @hober, @hadleybeeman

Amy: this went to CR in May - the JOSE and COSE stuff is bridging for people who can't agree on what crypto suites to use.

Amy: let's bump it a week and I can do some additional investigation.

HTMLSelectElement showPicker() - @LeaVerou, @matatk

Matthew: there is an update - last month I posted a comment on the WHATWG issue - to make sure our advice was imparted to a wider group. There has been some feedback. Looks like feedback from use cases they have experienced as a developer. Quite extensive feedback. But no more discussion from the people involved... I can have a look at the developer feedback. Our main concern was consistency. There's a window of opportunity if needed. Between all of us we thought of cases on both sides. It needs to be consistent & documented and there needs to be an escape hatch. There was a subplot involving whether the picker or the control can be focused and that hasn't been resolved. Potentially some confusion here...

we agree we should keep monitoring and we can re-review at the f2f

View Transition Classes - @matatk, @plinss

Matthew: APA has a liaison with CSS, who has been following this. CSS WG knows their stuff wrt to a11y. Aware of concerns, so no cocnerns from that perspective. Architectural, cross enging stuff - no position from anyone but chromium, but is documented in fpwd so the group must have consensus. Trying to find where we'd discussed it before... would be nice to see authoring advice from an a11y perspective in the document. Common for there to be an a11y considerations section, but probably some stuff specific to view transitions that might be suitable for one of those documents. Finding the right place for that if it's not there could be an APA thing.

... Wider issue that I don't think blocks this - increasing talk about people who are sensitive to motion, potentially with health implications, or a cognitive load thing. We have prefers reduced motion, but we don't have prefers no motion - and even if we do, what about animated gifs, js animations etc. There's a platform issue there that hasn't been addressed fully that is in the background (not specific to this design review).

... APA will just keep following and offer authoring advice if we see an opportunity to do that.

Dan: close satisfied?

Matthew: yes. Could check my assumption that there is consensus in the group?

Yves: quite common to be missing feedback in standards positions, for various reasons

Dan: we could note here that we're thinking about closing satisfied and we can check in with rest of TAG for more information later this week

Wide review request for Pointer Events Level 3 - @LeaVerou, @matatk

Matthew: handy changelog. A lot of changes since previous version. Haven't noticed anything yet that concerns me. Will keep working on this.

Lea: these are well established

Matthew: there isn't really an explainer, spec talks about use cases.

Lea: good to include the explainer in the spec but.. it's not an explainer

Dan: if we don't think we have any concerns we don't need to push back on that

Others: agreed

Lea: can't see anything alarming

Dan: will just check in slack, say we're thinking about closing it this week

document.caretPositionFromPoint API in shadow DOM scenario - @LeaVerou, @matatk

Matthew: this has cross-engine support. The explainer is in the comment.

Lea: what are they getting?

Matthew: returns a caret position...

Lea: point is relative to...? If there is only one shadowroot why is this not a method on the shadowroot?

Matthew: this is an extension on an existing API...

Lea: it does take multiple shadows. OK.

Matthew: comment at the bottom about alternative that they had which would be more difficult...

Lea: open shadow roots are taken into accounts... Providing the shadow roots argument serves double duty...

Dan: explainer starts with developer need not user need, would like to flag that

Lea: I can post about that too. Also the explainer is not only for the TAG review so it should be standalone.

agree to come back to it in breakout B

Breakout B (California / Europe) - 2024-06-17

Present: Dan, Peter, Amy, Yves, Tess, Lea

Regrets:

Early design review: Document Picture-in-Picture - @LeaVerou, @torgo, @rhiaro

Proposed close

We review Lea's last comment

Dan: satisfied with concerns or unsatsified?

Peter: I agree with Lea's points.. I'd want to have Lea's input before closing

Lea: there's been no response. Unsatisfied

Tess: also unsatisfied. Mostly agree with Lea's comment.

Lea: we've discussed a lot. I don't think this design is architecturally sound, just addresses immediate problem rather than what is best for web platform as a whole.

Tess: writes closing comment

FedCM multi IDP support - @rhiaro, @plinss

Peter: the response that this is the direciton they're going makes me happy - but I wish they would spend the effort on the solution that doesn't require the hacks...

explainer here: https://github.com/fedidcg/FedCM/issues/319#issuecomment-1270753874

Peter: are they thinking this will be useful in the next 3 months?

FedCM: LoginHint, UserInfo, and RPContext - @rhiaro, @hadleybeeman, @plinss

FedCM API extension: Button Mode and User Other Account API - @rhiaro, @plinss

Dan: this one has a slightly better explaienr - tho still an issue comment - https://github.com/fedidcg/FedCM/issues/442#issuecomment-1949323416

Peter: one other concern I have with FedCM - in other reviews, Amy and I identified many things - features we would like to see inyegrated into the browser as opposed to it be in the content. This seemed like yet another one of these... These are patches on the old solution... Why not do the real solution.

... Lots of extensions to handle specific uses cases ...

Peter: the overall goal is to do it right but right now they're doing whatever needs to be done to solve federated identity without third party cookies...

Amy: also with #803 ...

FedCM bundle: Continuation API, account labels, custom parameters, scopes - @rhiaro, @plinss

Amy: this is 5 things in 1... Missing an explainer.

Dan: writes comment

Peter: we're missing how this fits in to the grand scheme of things with these many small requests

Specification review for CSS Anchor Positioning - @LeaVerou, @plinss

Lea: I propose closing ... we expressed some concerns ... the response was some of these things can be done in the future ... or defered ... "this has shipped in chrome" ... It's addressing a major author pain point. I think it could have been designed better. It has been improved from the original version, thanks to Apple. So I think it's a lot better. I worry about the easy of use vs. power curve...

Peter: I would say "satisifed with concerns" as I have concerns. I haven't been as active in the CSS wg... but I don't think Tab has taken any of these concerns back to the working group...

Tess: the wg is asking us to look at their spec - they should be receiving our feedback.

Hi Tab - Thanks for engaging with us here. We are just wondering if the feedback above has been discussed in the CSS working group?

Dan: leaves comment

text-wrap: pretty - @LeaVerou, @plinss

Tess: I saw a message on social media - that authors should apply textwrap:pretty using the universal selector... text wrap: pretty is expensive... It's an attractive nuiscance, but this advice of applying it to all elements could make browsers ignore it... So we don't like to bikeshed names but ... the name is harmful in the IETF sense of harmful.

discussion of the inefficiency and therefore the sustainability of this technology

Peter: a number of different things you can do make text "pretty" - it's not clear what this does and it's up to the UA... it's not clear what it's asking for beyond auto... Maybe the author only wants one of the algorithms, not the whole suite... I think we've left feedback.

Tess: there are times you know that incremental re-layout isn't good... for example, print stylesheets... there are screen cases as well...

Peter: e-book readers are an example...

Tess: common case is... you shouldn't use it in a typical case...

Dan: it's not clear that it would result in people not using it if you change the name

Tess: sure. But maybe less people will use it. Once the amount of content that relies on it is sufficient to cause browser benchmarks to be affected. if wikipedia adopted it.. browsers would have to break the feature. You'd have to make it equivalent to auto.

Dan: considering many developers also care about perf you could also say that one answer is to ensure all developer documentation includes a warning..

Tess: but naming the feature is documentation.. the most immediate form. I don't have to go to MDN to find out it's costly, if it's called text-wrap: costly. Make it viscerally obvious. I think this all came up in the WG. We should give them this advice.

Dan: are we going to keep this open?

Tess: rather wait for a reply.

Amy: could the browser just ... not allow it for universal selector...

Tess: i don't know of any css feature that works like that and in some cases...

Yves: maybe could be applied to print only and not screen...

Tess: Might not be the worst idea...

Peter: also it's an inherited property... so you can set it on body...

Lea: I don't think applying it to print only would fix all the issues.. one of the issues is that this is a high level feature that controls low level knobs. But there aren't enough low level knobs. So people might use this as a proxy for other things which should really have their own controls... You do a high level feature like this when you ...

Tess: browsers can also compete on how they implemen these approaches...

Lea: depends how well that works when approaches are incompatible. Should probably have a principle...

Tess to leave feedback

systemEntropy addition to PerformanceNavigationTiming - @hadleybeeman, @plinss

continued from A: [document.caretPositionFromPoint API in shadow DOM scenario]

Breakout C (California / Australia) - 2024-06-17

Present: Peter, Martin

View Transition Classes - @matatk, @plinss]

  • [we discussed in breakout A and feel we can close as satisfied. See discussion in breakout A minutes. - DKA]

Seems fine to Matrin and Peter

Observable API - @hober, @LeaVerou

View Transitions: list of types - @hober, @LeaVerou

Long Animation Frame API (LoAF) - @hober, @torgo

@plinss and I looked at this today and it seems broadly acceptable. We have a few concerns here, but none of these really change our overall positive disposition.

We observe that the spec claims that thresholding durations is an effective mitigation strategy for timing attacks. This is not correct. Thresholding only limits the rate at which information can be extracted. The specification rightly points out that these measurements are already possible, but claims this does not make things worse. This is also incorrect. Being able to measure multiple timing sources at the same time makes the rate of information extraction much higher. This is still probably a worthwhile trade-off overall, but please do not pretend like the risk has been eliminated.

We also noted the monekypatch of WebIDL, hopefully you're talking to the WebIDL folks to get those changes folded in and will be removing the monkeypatch. See our guidance in this area.

Speculation rules: target_hint field - @hober, @torgo

Updated review of WebNN API - @torgo, @matatk, @maxpassion

Early TAG review request for Playout Statistics API for WebAudio - @hober, @matatk

JS String Builtins for WebAssembly - @hober, @ylafon

Support Video Chapter in MediaMetadata - @hober

Requesting review of HTML Ruby Markup Extensions - @hober, @LeaVerou

[improvements to <details> styling (widget structure)](https://

github.com/w3ctag/design-reviews/issues/965) - @hober, @LeaVerou, @matatk

Martin and Peter are OK to close as satisfied, pinging Matthew in Slack ... closed.

Breakout D (California / Australia) - 2024-06-18

Present: Martin, Peter, Tess Regrets:

Incremental Font Transfer: Patch Subset - @hober, @LeaVerou

Still pending work on dictionary compression.

Web Install API - Same Origin - @hober, @LeaVerou

Adding support for High Dynamic Range (HDR) imagery to HTML Canvas - @LeaVerou, @plinss

Constructors for RTC encoded frames with custom metadata - @martinthomson

Martin to take this offline and do some research.

Web Install API - Cross-Origin - @hober, @LeaVerou

Web Translation API - @LeaVerou, @matatk

Conversion to RGB in VideoFrame.copyTo() - @LeaVerou

CSS calc-size() function - @LeaVerou

Answered David's question, will see how things play out.

Compression Dictionary Transport: Align on a single Content-Encoding for the web? - @martinthomson, @plinss

Closed as unnecessary.

Breakout E (Europe / China) - 2024-06-19

Present: Dan, Martin, Max, Matthew, Yves Regrets:

TAG review for web app scope_extensions - @torgo, @ylafon

Dan: They updated their explainer - considering that they have been responsive to the review comments I'm pretty positive...

Martin: do they need the ability to take an entire registerable domain?

Yves: there is a scope in it that is the path ....

Martin: it looks like a scope and scope extensions ... "the following origins are also included" - does that mean just /app under those domains or anything else in that domain... that's unclear to me. Does it meaan that if you want to extend your scope to another origin then you have to follow the same path construction rules?

Yves: weird if you want to import some images ...

Martin: i think this is for the top level navigations... you'd stay with the idea that you are in a particular app in the case that you navigate to another origin... Any subresouces on a top level page would be fine... This is all about navigation.. if there's a link in the page that takes you to another origin do you take them "to the browser" or within in the app.

Dan: i think the main point is to not show a warning ... if navigating to another origin within an app

Yves: linked to caching?

Martin: it shouldn't be - it's "im in an app - and i navigate to another site... "

Martin: another question - the external website doesn't have much of a say of how much the "app" is able to use of it... say you have a payment flow that uses a payment provider... the payment provider stays in app.. but if you've nominated the entire origin - say the payment's provider's home page - might stay in the app which could break the user experience...

Dan: e.g. you're in a payment flow and then you want to view the privacy policy of that payment provider...

Martin: the external web site might want to be able to say "this app can use the following URLs ... otherwise jump out and it's no longer in the app" there's a discussion in the explainer about authorizing with an association file - it only associates with an origin - and doesn't recognize the idea of multiple app...

Yves: in the explainer it's in "future extensions"... so maybe the comment should be that this shouldn't be a future example

Martin: We have a scope parameter on the manifest in the first place... It might be a set of prefixes.

Yves: needs to be in sync with what is done with service worker...

Martin: path prefix thing with a pattern...

Permissions Policy Reporting and Report-Only mode - @torgo, @hadleybeeman

Dan leaves comment

Local Peer-to-Peer API - @LeaVerou, @ylafon, @maxpassion

Yves: I think it would be better to wait...

Matthew: Should we summarize what we talked about in terms of the plenary ... and the call itself and put that on the thread?

Dan: Point them to our minutes and minutes?

Matthew: I'll look at it and see if I can summarize. Certain things about handshaking and security that were signifigant concerns...

Dan: assigns to f2f

Martin: one thing I like about the things they've done: the device is explicitly opting in...

Timing Info for ServiceWorker static routing API

Dan: explainer missing a security & privacy section...

Martin: cache is a shared resource... It's worth nudging...

Hi @quasi-mod - thanks for sending us this. One thing that came up immediately in our initial discussion was the lack of a security & privacy discussion in the explainer (info on writing explainers). It seems that since this is dealing with timing, there might be some additional security issues that need to be explored or discussed beyond what was done already for Static Routing API. This is probably fine, but anything that touches timing carries some risk, particularly when it touches on resources that might be shared, like caches.

We're continuing to discuss and will provide additional feedback.

Martin: this looks totally fine other than that... as Yves pointed out it's probably partitioned...

ServiceWorkerAutoPreload - @torgo

discussion on source as "explainers from googlers"

Dan: noting comment from anne on the webkit standards position...

we agree that it's too early for tag review but that we have generally good feedback on the idea and the next step is that it should be discussed in the working group

noopener-allow-popups value in COOP