Upcoming WHATNOT meeting on 2024-08-01

[cwilso]

What is the issue with the HTML Standard?

Last week we held our weekly triage call (#10496) and I will post the meeting notes there in a bit. The next one is scheduled for August 1, 9am PDT. Note that this is 1 week later in an Americas+EU friendly time.

People interested in attending the next call please respond here or reach out privately to @past, @cwilso or the spec editors. We will be tagging issues for the next call again using the agenda+ label in all WHATWG repos and we would like to invite anyone that can contribute to said issues to join us.

[cwilso]

Thank you all for attending the meeting today and special thanks to Kagami Rosylight for filling in note-taking with me! Here are the notes from this meeting (the next one is at #10538):

Review past action items

• Addison to answer Henri’s questions in Validating internationalized mail addresses in <input type="email"> #4562 (comment)
  • Not done, carryover
• Chris W to file issue in W3C Process around path for definitive-reference glossaries a la the i18n glossary, that are REC-like but easy to keep up to date.
  • Done: Glossaries: a different pattern needed? w3c/process#904.
• Domenic: add checkpoint for “will this conflict with i18n glossary” to the infra checkin
  • not here, carry over

Carryovers from last time

• Anne will move Tie in AbortControllers with CustomElements to the DOM repo and Keith will update the title.
  • Done
• Yoav will ask Artur and Arthur to comment on the Severing a document's opener relationship regardless of origin issue.
  • Arthur has, Artur has not? Carryover to next meeting.
• I18n issues: [addison]
  Validating internationalized mail addresses in
  Freshly recreated PR: Add support for internationalized email addresses #10522
  • Carryover: for eu time zone when Anne/Henri are available
• [rendering] animation frame callback handling when iframes are involved [emilio]
  • Stefan from Chrome is looking into this.
  • Carryover to make sure it’s progressing.

New topics

• Reading-flow issues (Overall feature proposal,display:contents issue)

Action Items

Minutes

Emilio: Af callback: what’s needed is basically agreeing the spec is sensible qand then write tests, or fix implementations. But getting gecko work - emilio pointed out that blinks behavior is kind of close to what the spec says, we just need to get implementations to match.
ChrisH: interested in interop, getting tests to match
Emilio: I think the mediaquery tests were written by me, poke me if there are problems. I think it matches the spec, but if it doesn’t, let me know.

Di: reading-flow is new CSS property that I’m prototyping for chrome. For a11y screen reader for flex and grid and masonry they are not always displayed in reading-flow order. To solve this, WG is working on specific keywords to influence type navigation. We want to use a similar approach as past efforts, using a reading flow container as a focus scope owner. The proposal has a lot more details, I wanted to see if people thought this was a good approach. Second issue is more open discussion of specific cases of display content because these contents don’t have info about where they fall in existing reading order. There are two potential options listed. Any input?
Mason: CSS WG didn’t resolve how to do the display contents issue - that’s why there’s a proposal.
Emilio: for abs pos elements, is this well defined? This had make elements that are outside of the tree in the container tree, elements escape the flow, etc.
Mason: this is true in normal CSS - abs pos things can be out of order and won’t be tabbed, etc in appropriate order naturally.
Emilio: so does it not change? If reading order is the containing block?
Mason: Very good questions, don’t have great answers.
ChrisH: if abs pos element is a direct child of flexbox, does it go in dom order?
Mason: everything is traversed in dom order
ChrisH: if true, we already have a situation where it’s different
Emilio: yes, but we don’t have something in the layout tree that introduces focus owner scope thing.
ChrisH: you’re not saying it’s a blocker, but we need to define?
Emilio: yes. I don’t have a strong suggestion or preference. Maybe we should consider these two cases similarly.
Mason: Yes. Both proposals sort of iterate the dom children and check for display contents.
Di:I can investigate a bit more and open a new issue for abs positioning [action]
Mason: there are two options - one is just to stick the display contents at the end, but there’s is a known place at the end. The other is to make display contents elements a scope owner but that doesn’t work so well for abs positioned elements.
Di: Overall do people think this is a good direction? Open to potentially starting a PR?
Emilio: both of those alternatives sound reasonable. Do we have use cases that would favor one or the other?
Di: There is an a11y concern here; Aaron Leventhal would prefer option 2 because there are restrictions on crossing parent child reln
Mason: I don’t know that we’ve heard the use cases for display contents.
Emilio: focusable display content elements are already pretty rare to begin with. Picking the easier to implement option is probably do, we should discuss on a separate issue.
ChrisH: should we make a PR or discuss on another issue first?
Emilo: I think we need to eventually define for abs pos as well. So maybe make a PR, but file a separate issue on abs pos.
ChrisH: in general, for gecko support for eventually landing, is that on track?
Emilio: yes: impl-wise in gecko may take a while, but no objections here.

Emilio: somebody familiar with image load timing stuff? I found something very weird, can’t make sense of what I see. The whole image load timing.
Yoav: I think it’s a bug, WebKit wasn’t waiting for microtask when it should have. Basically I have a webkit fix in the pipeline but I have to make it fix around that
…
Yoav: So this is why I’m seeing failures in test
ChrisH: Stefan Zager is looking in to this now for Chrome.
Emilio: will ping there.
ChrisH/Mason: any implementer support for popover-hint?
Emilio: I can try to poke at it more. I think it looks good.
ChrisH: anything we can make progress on for command API?
Mason: Many things got resolved, incl naming, open task is to update the spec PR and impls.
Keith: yes,
Mason: Mozilla is supportive [in add to Chrome], but API has been changed since that, so…
Keith: Olli’s been on the last few calls, no major objections, but should check in.
Emilio: Olli’s in traveling today so we can ask him