Upcoming WHATNOT meeting on 2024-10-24

[past]

What is the issue with the HTML Standard?

Yesterday we held our weekly triage call (#10692) and I will post the meeting notes there in a bit. The next one is scheduled for October 24, 9am PDT. Note that this is 1 week later in an Americas+Europe 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.

[past]

Thank you all for attending the meeting today and a special thank you to Chris for taking meeting notes! Here are the notes from this meeting (the next one is at #10720):

Agenda

Attendees: Panos Astithas, David Baron, Tantek Celik, Keith Cirkel, Emilio Cobos Álvarez, Mason Freed, Siye Liu, Olli Pettay, Noam Rosenthal, Kagami Rosylight, Benjamin VanderSloot, Anne van Kesteren, Chris Wilson, Joey Arhar, Di Zhang
Scribe: Chris Wilson

1. Review past action items
   1. Joey to ping Chromium folks for [images] Lazy loading and out of band loads
      1. Joey asked, and Philip will try to look at it as soon as possible.
2. Carryovers from last time
   1. Anne and Dom to review select PRs
      1. No progress from Anne, likely to look at it in November. Joey would like someone to look at Define base appearance for <select> #10629
   2. Khushal will incorporate the feedback to the Canvas Place Element explainer.
      1. Not done yet. Carrying over.
   3. Dom will follow up with Noam and loop in ARIA folks on Atomic move operation for element reparenting & reordering.
      1. A11y folks are OK as long as the a11y tree is updated. Anne, Emilio and Noam agree to do the simplest thing possible. Anne will check with Ryosuke on his concern. Keith points out the risk of frameworks behaving differently, leaving users of multiple frameworks with inconsistent behavior.
   4. Simon will take a look at content model and 'what' to render for stylable <select> elements.
      1. Simon hasn't commented, but a lot of activity happened in other PRs around this already.
3. New topics
   1. [Di] tabindex vs reading-flow property
      1. Di will add an example with a shadowdom and update the spec as well. Anne and Olli will look at the open standards positions for WebKit and Gecko respectively.
   2. [Domenic] Add expect-no-linked-resources Document-Policy to Speculative parsing
      1. Olli will discuss this with Henri. Mason will ask Alex to come to a future meeting to give us more context.
   3. [Keith] Add an event for when a user attempts to submit
      1. Noam suggested an interesting direction in the issue.

Action Items

1. @annevk will check with Ryosuke on his concern in Atomic move operation for element reparenting & reordering.
2. @dizhang168 will add an example with a shadowdom and update the spec for tabindex vs reading-flow property.
3. @smaug---- will discuss Add expect-no-linked-resources Document-Policy to Speculative parsing with Henri. @mfreed7 will ask Alex to come to a future meeting to give us more context.

Minutes

PA: past action items: lazy loading?
JA: asked in chat, Philip said it's his team and he'll put it on the list but may not have time to look soon.
EA: does he agree it's a bug? It does seem weird.
AvK: he should be able to take a quick look.
OP: it is causing webcompat issues.
JA: I'll ask him to take a quick look.
PA: select PRs?
AvK: no progress; I'll be traveling next week, so early Nov.
JA:
Noam: Talked to accessibility, they are OK as long as the a11y tree is updated. We are updating the spec for focusin/focusout.
AvK: Last time the focus nuances were hard to explain, Can you expand on it?
NR: It's a bit of a judgment call. The way it currently works is that focus stays on the element it awas, but the element might move across trees. Ryosuke suggested sending focusin/out events in both trees.
AvK: for shadow tree?
NR: No. Never a question of ??? events.
OP: we should just talk about focus and blur
NR: seems sensible to ask for a use case for focus-out and focus-in. Happy to not send them at all. Concerned about features breaking when those events aren't sent
AvK: same pages opting in to new primitives?
KC: but large pages opportunistically opting in, can't assume it's new content.
NR: authors can always dispatch events themselves. Can't do the opposite (unsend if we send them). My personal tendency would be to not send.
AvK: I agree. Ideally the simplest possible thing that move can do; any additional functionality we should defer.
NR: if there's consensus, happy to revert.
AvK: I'll ask Ryosuke if his concern is strong.
KC: can't imagine a lot of userland code is going to be calling move before, whereas a lot of framework code will be. We're just going to delegate that decision down to the framework. Could have ramifications, if react is using move before and decided not to dispatch focus events, suddenly I might not be able to set a11y properties on parent nodes because I need to do focus/fixup work. Dispatching events kind of skipped that by mandating it as part of the platform.
NR: perhaps delegating to frameworks is not so bad. Might receive this feedback from frameworks when they try to integrate it, we could decide to mandate it then.
KC: might seem like a deficiency in the platform. Focus is already seen as very inconsistent across the platform across the framework ecosystem.
NR: I see the point, don't know how to move forward from here. Action item to drop a comment to garner stronger opinions about this.
AvK: if we do a move, we need to update the live ranges and selection automatically?
NR:yes
AvK: if you have those kinds of libraries, you could write a wrapper function that dispatches the relevant events. If it becomes really common, add it.
KC: many frameworks abstract a lot away, don't give you fine-grained insight into how things are moving around the tree. Decisions we make impact the frameworks. Every framework would need to come up with a consistent way to manage this.
AvK: if you use a framework they will each have their idiosyncrasies.
PA: but then each framework would have a different mental model. How large is the constituency of devs who use multiple frameworks?
KC: changing from one to another is common
AvK: I don't think it's on us to solve differences between framework models.
KC: yes, but this is a second-order effect.
AvK: I feel like it would be really weird to fire focus events when focus doesn't change
KC: might be observable in CSS, but not observable in JS.
EA: if you apply that reasoning, it should apply to mouse events or whatever. This makes me lean toward not firing.
NR: a11y addons have access to this info via mutation observers. So they do have events in JS
OP: what about moving elements inside different trees?
PA: want to timebox, but we need a direction for frameworks
AvK: as per Emilio, we should be consistent across focus hover and active.
PA: Keith, do you want to think about that?
KC: makes it more difficult
NR: we do the fixups in rendering. Focus-in, focus-out are not in the standard right now.
OP: yes but not different from focus/blur
NR: you don't fire focus events on removal anyway. I suggest starting with not sending those events. Revisit if it becomes a pattern.
PA: the other direction does seem more difficult.
NR: yes; creates more questions than answers.
PA: moving on to the next topic: simon/ content on styelable select elements.
JA: Getting a clear review, just fold this into the PRs we talked about earlier.
PA: Did Simon have any objection?
OP: he just wanted to take a look, but hasn't had time.
PA: next topic: tab-index vs reading flow
Di: issue we created after discussion at TPAC. We came up with a proposal that didn't have objections. I'm working on that, adding definitions for reading flow scope owner for focused navigation. 1) is the element itself a flow container 2) display: content with layout pattern/inflow container; 3) reading flow item/siblings. For the first two I call it reading flow container scope. Wanted to bring back to the group to check if we still like this proposal.
AvK: thanks for the example. Looks good to me. Might help to put more tab-index values in the example; not entirely clear. This is the model we discussed at TPAC, still seems reasonable. Direct children don't adhere to tab index, but their direct descendents adhere to tab index.
OP/MF should have another example on shadow DOM.
Di: will update.
MF: sounds like we're roughly in agreement, good to proceed with PR?
AvK: yes. Will find someone to add a position.
PA: next topic: Add expect-no-linked-resources Document-Policy to Speculative parsing. Domenic's not here.
OP: I don't understand this at all. What are we trying to optimize? Need to discuss with Henri
EA: I guess the idea is you wouldn't need to do the speculative loading stuff. But in Gecko that doesn't help at all? Maybe in style elements? That's the only out-of-band scanner we have. Webkit and blink have a different code path for speculative parsing.
OP: feels like just a workaround.
MF: no, it is a hint
NR: I was in Alex' presentation of this, and it did come up in real websites that were large.
EA: we don't really have a separate codepath for speculative scanning, so there's no need to have a separate pass.
MF: speculative parser is an optimization though
EA: we have speculative loading without two passes over the content, though. We speculatively parse which triggers the speculative loads. We use the actual HTML parser for this, not two separate scans.
AvK: would be interesting to see if whatever motivated this feature is an area reproduced in Firefox.
PA: Is it fair to say we'd like Alex or someone to come to this meeting, or are we deferring to WebPerfWG?
AvK: would like more information.
PA: Next item: Add an event for when a user attempts to submit
KC: This is from Konnor who works on the Web Awesome component library. There's not really a way to know when the user wants to submit. Invalid event has various issues', submit event doesn't fire. Ask is a pretty reasonable, well described issue.
AvK: problem is reasonable, but "this other API has a problem so we should add a new API" is maybe not great. Specific problem is that invalid doesn't bubble if form elements are outside the form.
KC: also if you're a participant of a form, would like to know when you could run a routine to validate the data that doesn't happen on blur of a field. Like, form is being prepped for submission. Not just about invalid; also about knowing when a valid form is about to submit.
NR: What would work today is to put keys and values on your submitter, maybe just submitter to form data event.
KC: sounds interesting, yeah. I asked Konnor to join us but he was unavailable.
/NR: if your submitter has a key and value then it wouldn't appear in your form data.
AvK: doesn't the click event just work?
KC: you can also hit enter on the input field, which submits but doesn't hit onclick.
AvK: doesn't it hit the default one?
PA: sounds like we need more informed commentary; carry over.