Upcoming WHATNOT meeting on 5/9/2024

[past]

What is the issue with the HTML Standard?

Today we held our now weekly triage call (#10298) and I will post the meeting notes there in a bit. The next one is scheduled for May 9, 9am PDT. Note that this is 1 week later (per #10163) in an Americas+Europe friendly time.

People interested in attending the next call please respond here or reach out privately to me 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.

[ragoulik]

@past we would like to discuss the following drag and drop spec issues:
#10334 #10335 #10336

Can these be included in tomorrow's agenda.

CC: @sanketj @snianu @kashishjain6

[past]

Of course, I added them.

[past]

Thank you all for attending the meeting today and special thanks to Chris Wilson for copiously taking meeting notes! You can see below that the end result is far more accurate to what I've managed to accomplish. Here are the notes from this meeting (the next one is at #10340):

Agenda

Attendees: Joey Arhar, Panos Astithas, David Baron, Keith Cirkel, Emilio Cobos Álvarez, Mason Freed, Rakesh Goulikar, Chris Harrelson, Kashish Jain, Sanket Joshi, Brian Kardell, Una Kravets, Olli Pettay, Anupam Snigdha, Benjamin VanderSloot, Chris Wilson

1. Review past action items
   1. Panos will schedule a meeting to discuss minuting and bring this up again next week.
      1. Pick a scribe: Chris Wilson
   2. Olli will ask Henri to look into HTML parser changes for stylable <select> from a parser point of view.
      1. Henri didn't have time yet, but Simon looked into this. Approach 1 seems the most promising per Olli, Mason and Joey.
   3. Panos will post the agenda for the joint meeting on that issue.
      1. Chris posted it.
2. Carryovers from last time
   1. Emilio will look closer at the use cases for CloseWatcher always fire cancel events.
      1. Emilio thinks this makes sense.
   2. [Addison] Joint session with the I18N WG. Addison will provide a list of topics.
      1. Carry over.
   3. [Yoav] Add subresource integrity support for ES modules, through importmaps
      1. Deferring until May 16.
   4. Olli to review domfarolino's PR about post-insertion tasks
      1. Done
3. New topics
   1. [Anne/Panos] Failed dynamic import should not always be cached
      1. [emilio] CSS at least doesn't cache error responses, are there other resources in the platform that do other than dynamic imports?
   2. [Sanket/Rakesh] The dropEffect column in the Drag and Drop events summary table should clarify it represents default values
      1. Rakesh will write a PR to have a more concrete conversation.
   3. [Sanket/Rakesh] Drag and drop spec allows multiple values for dropEffect which might cause browsers to behave differently
      1. Rakesh will compare the platforms-specific behavior and come up with a concrete proposal.
   4. [Sanket/Rakesh] How should UAs handle web authors setting dropEffect values?
      1. Same AI as above.
   5. [Emilio] Consider improving interoperability of <iframe> throttling margins
      1. It would be good to have someone from WebKit comment with their implementation details.
   6. [Mason/Keith] Add InvokeTarget & InvokeEvent IDLs & invocation steps for Dialog & Popover - has implementer support and a completed review, there's just an open bikeshedding question about the name of "invoke".
      1. Everyone in the meeting agrees that "invoke" is more accurate than "click". Chris Wilson will ask in the WebKit standards position to bring the discussion to the PR.

Action Items

1. @ragoulik will write a PR to have a more concrete conversation on The dropEffect column in the Drag and Drop events summary table should clarify it represents default values.
2. @ragoulik will compare the platforms-specific behavior and come up with a concrete proposal for Drag and drop spec allows multiple values for dropEffect which might cause browsers to behave differently and How should UAs handle web authors setting dropEffect values?
3. @annevk to find someone from WebKit to comment with their implementation details on Consider improving interoperability of <iframe> throttling margins.
4. @cwilso will ask in the WebKit standards position to bring the discussion to the Add InvokeTarget & InvokeEvent IDLs & invocation steps for Dialog & Popover PR.

Minutes

Panos: open item: Henri was going to look at the select issue.
Olli: Henri didn't have time, but I think Simon was looking at that. It would be good, I think, if we could go with approach #1. I'll keep this on my plate to look at.
Joey: agree, I think everyone's saying use #1.
Mason: +1, only concern is webcompat.
Panos: last I was to post an agenda for a joint session (with CSS+OpenUI). Meeting happened yesterday, and will link minutes when they're posted.
…carryovers from last time: close watchers
Emilo: makes sense, I haven't commented on the issue, will do.
Panos: Domenic was asking for this, he can respond to the ticket if there's something to add.
…Addison from i18n was going to propose some topics, but it hasn't happened yet.
— subresource integrity, deferred for may 16th
Olli was to review dom's PR
Olli: yes, still looking, I think we will want to remove the connected with eventually, but I'll comment there.
PA: Dom has a lengthy comment that clarifies, if you can respond there.
Olli: oh, recent comment, will reply.
PA: new topics: first one, Anne suggested we talk about dynamic import. There's a proposal that if dynamic import failures are impacting users, we should address this. Luca from the Deno team made a proposal that fixes the spec to implement the WebKit behavior; no WPT tests yet. Question: is there any other browser in support of this change?
Seems viable, but not complete.
CH: might be better to discuss at a Japan-friendly time zone.
Emilio: Does any other resource cache failure responses? CSS doesn't; I don't know about images. Probably interesting to know, to not create something inconsistent. I'm pretty sure CSS at least doesn't cache failed responses in Gecko.
PA: Should be consistent with TC39
EA: this would be consistent with CSS and TC39, but perhaps there's something else…
PA: Anyone at Mozilla who should look at this?
EA/Olli: Yulia?
PA: anyone from Safari to comment on the delta between current implementation and the PR and whether the delta is big enough to be worrisome?
PA: next topic:
Rakesh Goulikar: (from MS Edge team). Three things to talk about in drag/drop area of spec. First, #10334: trying to convey that it should be a default value. In the spec, the drop effect column describes the default value for the data transfer objects attributes, and that is the drop effect. But it does not clearly convey that it's a default value or should be persisted and cannot be changed by the web model. The suggestion is to explicitly convey that these values represent the default values and the web authors can change it. Comments?
Olli: any way you can make drag/drop easier to understand, +1.
Sanket: not sure if Webkit folks here, but seems like drop effects are not really implemented in safari/chromium. Is FF still working on it?
Olli: It's been a while since I've been through this part of the code.
Olli: is this not implemented in Chromium?
PA/Sanket: it's always "none"
Sanket: it seems reasonable. Safari hasn't implemented it at all, just want to make sure there's no blocker.
PA: Would assume it would be good if you can point out changes in behavior to Webkit.
Olli/Sanket: sounds reasonable.
Sanket: any objection to clarifying it's a default value?
Olli: you can see it in the API design.
Brian: what is it that Safari doesn't implement? CanIuse says green across the board, and this (MDN) page seems to imply it will work?
Rakesh: it's always "none". There are conditions that need to change.
PA: seems like no objections in principle, I think you should propose a PR.
Keith Cirkel: quite interested, happy to help. Been speaking with Alex riddon who has a bunch of issues he'd like to file.
Keith/Sanket: let's have a meeting tomorrow.
Sankey: Either Rakesh or ?? will propose a PR.
Rakesh: #10305: Drag and Drop allows multiple values for the drop effect. This might be a reason there are interop issues. UA can choose a value of drop effect attribute from multiple possible options and it needs to be based on the set effect allowed. You can see if it's a copy link or copy move, the suggestion is copy or if appropriate move. So the definition of "if appropriate" is open to interpretation, I think the spec should be more prescriptive.
Joey: Browsers are doing different things today?
Rakesh: yes.
Olli: What are the differences in what browsers do today?
RG: Chromium and Safari have not implemented this spec yet, so there's no comparison to be made there. But when we want to implement, what is the value or how we should read appropriateness. We want to know what we should do here.
Anupam Snigdha: seems like some platform specific convention. Is it that this value varies on Mac vs Windows, etc? Anyone have history or context?
Joey: if this hasn't been implemented in Chromium or WebKit, I wonder how this was even written.
Olli: API was from Internet Explorer. Probably should test there.
Anupam: disabled on windows now
Sanket: if this is coming from a super legacy feature, should we just deprecate?
PA: fair question. Right first question would probably be for your team to come up with what we SHOULD do, compare it to Firefox's implementation, and explain how it makes life easier for users and authors.
Sanket: I think we have indications that authors want this, and that's why we're trying to implement this part of the spec. If Safari isn't interested, maybe we don't care. Maybe we need to revisit. Happy to do more research. Maybe we should deprecate this part of the spec and take a step back.
Olli: But you say authors do want this, and we do have it implemented. Probably just need to improve the specification.
Sanket: What info would be helpful for the group?
Olli: concrete proposal
Sanket: for each value what specific drop effect?
Emilio: yes: like, have the platform conventions changed, how does this align across macOS/Windows/Linux. If they all do the same thing, great - just do that. Maybe the answer is they do different things, in which case we should make a choice. We need some data on what platforms do.
CH: if that research is done and the recommendation comes in , Emilio is Gecko open tio changing to match that?
Emilio: yes.
CH: seems like few people are using this anyway.
Emilio: yes, I don't expect this to be a large compat risk. We do have internal use we would need to audit. In general, I am happy to make changes to come up with a reasonable end state.
Anupam: for the platform drop effect does Firefox use the system API? E.g. on Windows does it use the IData object to give system feedback to set the default? I don't know if you change the drop effect if it has some effect during drag/drop events.
Sanket: Let's take the action item to propose what we want to have happen here. It may be that we should deprecate.
CH: And sounds like Firefox is willing to work with as well.
Sanket: Let's skip the next item, it is similar.
PA: Next topic: improving iframe margins
Emilio: came up in WG call yesterday. How should view transitions behave in this kind of iframes. All browsers to some extent throttle or prevent rendering updates of in process iframes and out of process iframes, but we'd like to see what is required to improve the spec.
Maybe this struggling also affects timers. In general it seems there was agreement that it needs to be less weird/magic. Stefan pointed to some Chrome code; need to get someone from WebKit to comment on whether they could do some changes if they were sensible. No concrete ask yet.
CH: some number of pixels offscreen?
Emilio: Chrome seems to have some special cases.
CH: Is there spec text already?
EA: no, just a line on rendering update stuff saying something about "all documents that are relevant"
CH: a bug came up just last week that was something like this - race condition/bootup state with a backgrounded tab. Main frame won't run animation frames because the tab is not visible. Just a bug. If you don't do this right, you'll have interop/compat problems.
EA: doesn't have to be the same margins; we have different margins for lazy loading e.g., but we need to define which conditions mean the UA is allowed/not allowed to throttle.
CH: Are you going to pursue, or just asking for feedback?
EA: Ideally, would like someone from Webkit to comment on their behavior and their stance on this, kind of unfortunate no one is here from WebKit.
CH: Do Chromium and FF match behavior?'
EA: oh no. Fixing some stuff on this now. Chromium implementation of throttling as soon as something is out of view makes sense to me. Background tabs aren't compatible.
Ollo : will happen differently in background tabs and whatnot. May happen here in iframes with times or attached dedicated workers, etc.
EA: yes. Would be great to define everything, but this mostly came up in terms of rendering steps. One step at a time.
CH: those are more of a binary in chromium impl - refresh rate of the monitor or not. I'll talk to Stefan about getting more details so we can have this conversation.
EA: I'd like to improve the spec, assuming no objection from WebKit. Just wanted to check.
PA: sounds like people are in approval.
PA: next item: dialog and popover.
MasonFreed: talked about this a few weeks ago; there's a link to a spec PR for invoketarget. And invoke attributes. Has a review, approved. Just one issue about the name "invoke". Anyone from Apple here, can we get approval?
MF: their position is basically we already have a name for this behavior, so the attribute should be called clicktarget. But the counterpoint is that this isn't really forwarding a click over. Two types of innovations are for popovers and dialogs. Invoke is kind of a general term. Hope we don't' get hung up on naming.
CH: Who from gecko reviewed and arrived at a positive position?
Olli: I think that was me. I'm fine with invoke. It's a common command. I think we discussed it at TPAC. click target or something sounds like not the right thing - we don't want some more generic comment type of API. Click is already confusing - it handles key presses and things that are not clicks.
CH: also because I'm not
Keith: there's' a lot of focus on the click event handler and I wonder if that's where some of the concern came from - I wonder if there's a misinterpretation based on the preamble in the explainer.
CH: two implementers and editorial approval means merge, right?
CW: yes
BK: When is the deadline to veto?
<discussion on working mode>
CW: I can take up asking Webkit to move their standards-position bit into the PR
BK: not sure what happens if multiple editors disagree.
CW: Editor wins - others are deputy editors, not editors.
CH: we should bias to finding consensus
CW: +1.
CH: We'll wait until next week to have that discussion. Domenic and Anne should be in attendance.
PA: I'll make sure this is on the agenda for that one.
Keith: there were some comments raised in some of the patches in gecko around naming of events. Mozilla should weigh in. Discrepancy between toggle and toggle popover, raised by Sean Feng?
Olli: I'll ask Sean to weigh in.
BK: <notes that no one in this meeting disagreed with the name invoke>
CW: AI: to note that in the issue.

[domenic]

Thanks for the detailed minutes! Also special thanks for the attention to formatting to make sure they show up nicely in GitHub, including issue cross-links, preventing issue cross-links for #1, and not letting things in angle brackets get accidentally swallowed.