Skip to content

Latest commit

 

History

History
472 lines (272 loc) · 28.8 KB

12-18-minutes.md

File metadata and controls

472 lines (272 loc) · 28.8 KB
Raw

TAG Call Minutes - Week-of 18 December 2023

Agenda

Breakout A (Europe / US) - 2023-12-18

triage breakout 1

triage breakout 2

triage breakout 3

Breakout C (APAC / Europe) - 2023-12-19

Plenary Session - 2023-12-20

  • Agenda to be built from issues re-triaged ub Breakouts A and C
  • Breakout Rollup
  • Issue Triage

Minutes

Breakout A (Europe / US) - 2023-12-18

Present: Dan, Matthew, Yves, Peter, Amy, Hadley, Rossen

Regrets:

triage breakout 1

Matthew, Amy, Dan

text-wrap: pretty - @LeaVerou, @plinss

waiting for a reply from Lea - maybe ready to close?

navigateEvent.sourceElement - @leaverou, @torgo

Too small to review?

Suggest to close

The FileSystemObserver interface - @hober, @torgo

Holding comment, Multistakeholder? Current status?

Amy: the use cases in the explainer are not from the user's perspective.

Yves: clearly for developers...

Web Install API - @hober, @cynthia, @LeaVerou

No reply from them since Sept, marked pending external feedback. Dan to nudge Diego

field-sizing CSS property - @LeaVerou, @rhiaro

Amy: originally thought we could fast track this but based on Lea/Sangwhan discussion in slack perhaps not. Need to understand if Lea's thoughts are concerns or not.

we agree it needs Lea to look at it

Relative Color Syntax (RCS) - @LeaVerou, @torgo, @rhiaro

Dan: explainer provided

Amy: multistakeholder is positive. Mostly shipping.

Amy: on a surface level it looks fine...

we think this is probably fine - but need to double-check it with TAG CSS exprerts

HTMLSelectElement showPicker() - @cynthia, @LeaVerou

Matthew: the PR to HTML has been merged... And I'm aware that there's an existing similar thing input.shoePicker method... couple of questions - one is about use cases. Issue of focus management was brought up. Not clear to me. Another question - more practical - how it behaves on certain devices.

matthew to ask questions on the issue

Matthew: developer ask was cited as justification - yes developers are asking for it but not saying what they're going to use it for - so not clear what the use cases will be. I can see "open attribute" - another is "programatically open"... not clear what that is. A particular solution has bee chosen... the ship may have sailed but would be good to know what they're trying to do. If they want to open the popup because of a user action I'd err on the side of not doing focus management... I think they're not doing focus management...

we agree we will come back to it at the plenary

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

Explainer has been updated, ready for review

Matthew: view transitions parent spec doesn't have accessibility considerations. Homework for APA to propose one for CSS. Don't anticipate any concerns.

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

they have replied to rossen's comment - currently waiting for our followup.

triage breakout 2

Hadley, Peter

Captured Mouse Events - @hadleybeeman, @atanassov

Ready to progress -- awaiting reply from Rossen.

systemEntropy addition to PerformanceNavigationTiming - @plinss, @atanassov

Pending external feedback on how it fits with the privacy principles.

Extending the PointerEvent with Unique DeviceId Attribute - @torgo, @atanassov

We had a question, Lea left a comment. Could be ready to close. Marked "propose closing".

Soft Navigations - @LeaVerou, @plinss

Yves: not in the abyss... Latest comments 2 weeks ago...

Looks like we can close it. Concept should not be used for anything user-facing, and we don't want this to be used more broadly.

Marked "propose closing"

TAG review request for the IDP signin status API - @rhiaro, @hadleybeeman, @plinss

Ready to progress. We need to look at their responses.

The CSS word-break: auto-phrase property - @rhiaro, @atanassov

Already set to propose-closing, and has as closing comment. Ready to close?

Partitioning :visited links history - @rhiaro, @plinss

No signals from other browsers, so marking 'multi-stakeholder?' We should probably punt/close and ask them to re-open this one, wait for data from experimentation.

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

Ready for attention, just needs to be worked on.

Feature detection for supported clipboard formats - @LeaVerou, @torgo, @rhiaro

Ready to be worked on.

Observable API design review - @hober, @atanassov

Ready to be worked on.

Side Panel - @plinss, @atanassov

Ready to be worked on.

CSS ::selection Inheritance Model - @LeaVerou, @torgo

Ready to be worked on.

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

Ready to be worked on.

triage breakout 3

Lea, Rossen, Yves

entry and exit animations

incremental font transfer patch subset

bfvache prerendering eviction

document PiP

fenced frames

fullscreen popup

tabbed webapps

css nesting

wasm js promise integration

fedcm login hint

webaudio render capacity

deliveryType

relative color syntax

Breakout C (APAC / Europe) - 2023-12-19

Present: Dan, Matthew, Amy, Yves

Regrets: Max, Sangwhan, Hadley

Verifibble Credential Data Model 2.0

Amy: no reply so far to my message.

assigned to f2f

Verifiable Credential Status List 2021 - @rhiaro, @maxpassion, @hadleybeeman

Amy: A couple of points where we should open issues on their specs.

Dan: Can we close this one then?

Amy: Probably - there's the stuff about malicious issuers of VCs that bothers me but not sure we need to block this particular one...

revisit at plenary

TAG spec review of Storage Access Heuristics - @torgo, @rhiaro, @hadleybeeman

Dan: meta topic of heuristics... we keep hearing that browsers which have deprecated 3p cookies have heuristics so things continue to work, eg. exceptions for youtube. The other area we've heard about heuristics a lot are to do with autofill. These are the hidden functionalities of browsers that are not specified and work differently. It works badly eg. when it tries to autofill a password when what I need is a one-time code. Maybe browsers need to coordinate more on heuristics?

Amy: they might not want to coordinate because some of these heuristics might differentiate browsers... but I don't know

Yves: reminds me of the different heuristics in private mode that are different between different browsers...

Dan: We had a positive review of storage access

Amy: yes but that was because it was multi-stakeholder but are these heuristics multi-stakeholder.

Matthew: There's some info that other broewsers do implement - on MDN. Firefox "includes some heuristics". But Firefox says "feature will be removed at some point in future"

Amy: Wonder if what Firefox has is actually related to this effort to standardize.

Amy: goals - evaluate existing browser heuristics...

Dan: they did evaluate?

Amy: yeah... Might be the right direction...

Dan: all of the spec primary contacts are google...

Amy: yes but fairly early... Want to spend some more time on this... find out how aligned this is with other browsers...

leave until plenary - Amy to do a thorough read

Matthew: "other browsers have implemented some approach to this"...

Early Design Review: Opener Protections - @torgo, @hadleybeeman

Dan: we asked some questions in November.. looks like they've added more information to their explainer

Amy:

Matthew: the payment thing may be a genuine issue

Amy: 3 different but complementary proposals...

Dan to re-read explainer and come back with proposal at plenary

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

Dan: waiting for their response - wrote comment asking for update

Extending Storage Access API (SAA) to non-cookie storage - @cynthia, @torgo, @rhiaro

Amy: was this waiting on Sangwhan to comment on API shape?

Amy: concerned about the wording in Privacy & Security section - "we believe non-cookie storage and communication APIs don’t enable any capability that could not be built with cookie access." Comparing against status quo instead of comparing against web without 3p cookies...

bump to plenary

DisplayMediaStreamOptions monitorTypeSurfaces - @cynthia, @hadleybeeman

Allow transferring ArrayBuffer into WebCodecs object constructors - @cynthia, @torgo

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

Yves: they want to have the webapp serve things on behalf of other origins. Wondering what is their understanding in ensuring things have to be done through https or with something that has the same properties in order to have powerful features, that might be an issue

Dan: Looks like we haven't received a reply from the proposers. Nudge for an update? There shouldn't be an issue with IWA here

Yves: scope extension to a regular webapp

Dan leaves comment

coop: restrict properties

Plenary Session - 2023-12-20

Present: Matthew, Dan, Amy, Yves, Peter, Hadley, Lea

Regrets: Sangwhan, Max

Agenda to be built from issues re-triaged ub Breakouts A and C

Proposed close:

Peter: Fine that they get some data. We don't know what the multistakeholder...

Peter: good/harm

Amy: my opinion is more good than harm

We appreciate the problem you're trying to solve and agree that this is a really important privacy issue. Architecturally, this isn't a huge issue. We want to make sure this is good for users. We think this is fine for experimentation but we would like to see some results of that experiment regarding the impact on users.

We'd also like there to be multi-stakeholder consensus on this to avoid user confusion.

We're going to close this for now. When you have more info to share, can you please re-open this or open a new issue?

peter to leave comment and close

Amy: we were looking for a reply.

Dan: I suggest we close.

closed

Matthew: This has been merged - the ship has sailed - but Lea asked for much clearer documentation on use cases. If we could encourage them to provide clearer documentation on use cases it would be helpful - especially for APA... making the accessibility as good as it can be - APA can do that as a pull request... I'd like to be clear on the use cases... As it has shipped it feels like it falls to APA now to provide guidance and take part in ongoing discussion.

Dan: reasonable to write a closing comment from TAG, and encourage engagement with APA. Does that work? Or would it be better for APA if it's an open TAG issue?

Matthew: I don't want it to block us, feels like we're kind of done with it. Should just wait and see if Lea and Sangwhan come back and want us to press them on this thread for the use cases.

Lea: still unclear - it seems clear on the use cases where authors need to open the picker programmatically... I wonder if we can explore changing input.ShowPicker... If not then having a select showPicker that behaves inconsistently would be worse. Second can we make them both focus the control... better for accessibility. If we can change them to do the right thing that's better.

Matthew: They are having a conversation on focus - the other point there's a difference between focusing the control and focusing the picker. if you focus on the control you get a lot of info - that's useful info - if you just focus the picker then you only get what's in the picker. However James from Mozilla who is a Screen Reader user thought this would make the most sense.. So: what are they actually asking for?

Lea: there was a list with stackoverflow questions

Matthew: I looked at that - some of them were "i just want to do this" - the declarative case - which is niche - a lot of them didn't say why they want to do it.

Lea: it could be to guide the user... i wonder if a use case within scope would be a patterm with a range of dates say on a flight booking web site - 2 controls - that indeed might need the input to not be focused. Is there any action today in browsers that opens a picker without being focused?

Matthew: Agree. we have to be clear on control vs. picker... Maybe worth asking james... Implications for accessibility for doing both ways... It's dubious, you could be skipping over something that people can see - that it's a select. Occurred to me - would it complicate things horribly if there was a parameter to the method that determined whether something was focussed, for control or picker, or an enumeration. Sounds like scope creep, but...

Lea: this is an excellent point that we hadn't noticed. Distinction between picker focussed or control. I'd ask - when a developer selects focus, what is being focused? Sounds like the whole control. If the intent is to focus the control itself, they can do select.showPicker then select.focus. If the intent is to focus the picker, I don't think there's a way to do that in js

Matthew: i don't think there is. James Tay said the picker needs to be focussed - he was very clear about this. But concerns - could cause you to skip over really important things like what am I choosing and why. Would be good to ask him what his thoughts on that were.

Dan: is James one of the people who comment on our issue?

Matthew: no, I linked to an issue from my comment, about should it focus the control. As far as I understand, pickers are below the atomic level on the web, you can't focus a part of a widget like that. Don't think iOS or Safari can focus the picker, it's below the level they work at. It would be very strange and precedent setting to focus a part of a widget

Dan: Should we be closing this and hadning discusison fo accessibility topics to APA? What feedback can we leave on our issue that would help get to the bottom of these topics? Also considering that it's been merged.

Lea: agree we should step back and leave high level feedback, perhpas this list of priorities. Question for Matthew - you're saying that cocussing the picker oculd omit imporatn context, could be a feature not a bug if you want to override it. Does what the screenreader read happen synchronously or asynchronously? If select.showPicker is defined so it focusses the picker but the developer immediately after synchronosuly calls select.focus? Will the screen reader start reading the picker, and then the whole control? Or will it just start reading the whole control?

Matthew: it's hypothetical because you can't focus the picker at the moment. When you explicitly move focus, a screenreader would start reading from there. That's goign to interrupt what ever is going on at the moment. If you focus the picker, and then focus the control, you've just ofcussed the control, you're not going to get the picker. I wonder if the way James envisages it being implemented is if you focus the picker it'd be like focusing a radio inside a fieldset... the default behaviour would be to give you the context and legend of the fieldset.. if they did that with focussing the picker, that alleviates the concern about missing important stuff

Lea: hearing there might be a need for focusing regions of existing controls. Separate issue.

Matthew: would be abig change, could be interesting

Lea: I guess it's about focussing shadow dom. I propose saying the top priority is that whatever you do to select.showPicker, that needs to be the beahviour of input.showPicker - these need to be consistent. Worse for everyone if not. Second thing - what are the use cases, and are there use casses that need the control to not be focussed? Whether it's the picker that is focussed or the control, that might be something we can delegate to accessibility folks. Could be something to take into account how easy it is to override the behaviour. I think the developer can override the focussing behaviour if they need to, eg. if they call control.blur immediately after

Dan: What about the feedback that Matthew already wrote?

Lea: could be useful..

Dan: could Matthew write a comment combining what you've written already and what Lea just said?

Matthew: yes. +1 to everything that Lea said.

Dan: we'll keep it open for now. I've added a11y tracker label. You can mention that some of that needs to be taken up by APA, then we can figure out how to close it.

Matthew: sounds great

Lea: relates to heuristic design principle... developers overriding defaults..

Dan: signals suggest to close positively

Peter: no concerns...

Dan: Suggest we close... let's wait for lea to join the call.

Lea: +1 to closing.

*closed&

Dan: minor change. Therefore suggest we close with no comment. We need a new label. Resolution: no comment.

closed

Check with Lea:

Lea: ok response is good let's close this.

agreed to close resolution satisfied

Lea: tons of use cases - people need to use libraries to do this - it's hard to do this right. I like being able to do this in CSS. However the mental model for sizing in CSS keeps getting more complex. However this has been explored in CSS wg... so they ended up coming up with a CSS property "size form elements based on their content"... having seen how much debate there was i'm inclined to say let's just let this to (approve). I'm not super happy with the design of the feature but there are a lot of constraints to navigate and it's not clear spending more time would result in a better feature. concerned about it being already very complex.

Rossen: not opposed to closing.

Amy: happy to close this with a comment : yes to use cases...

Lea: satisfied: with concerns

We're really happy to see this important use case being addressed. We have concerns about the design, and the additional complexity this brings to the mental model for sizing in CSS, but we understand that alternatives have been explored extensively by the WG. Can you please add alternatives considered, and reasons why those designs weren't chosen, to the explainer, so we have this on record for the future?

Thanks!

Peter: i have the same mixed feelings...

Lea: net win for authors if this ships - with a better design it could be better..

Peter: question is - would a negative tag review cause this to be pushed back?

Lea: i think not since the better design has been explored extensively...

Rossen:

Assign a future milestone (or just do it):

Issue Triage