Upcoming WHATNOT meeting on 6/20/2024

[saschanaz]

What is the issue with the HTML Standard?

Today we held our now weekly triage call (#10400) and I will post the meeting notes there in a bit. The next one is scheduled for June 20, 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.

(Shamelessly copypasted from @past's past ones just to put a next meeting link to the minutes comment, please feel free to fix if I messed anything up)

[past]

Terrific job @saschanaz, thank you!

[muan]

I'd like to join.

[past]

I added you to the invite.

[yoavweiss]

I'd like to potentially discuss #10394 (no permissions to "agenda+" it..)

[past]

I tagged it for you.

[past]

Thank you all for attending the meeting yesterday and special thanks to Joey Arhar for copiously taking meeting notes! Here are the notes from this meeting (the next one is at #10422):

Agenda

Attendees: Joey Arhar, David Baron, Mu-An Chiou, Emilio Cobos Álvarez, Brecht De Ruyte, Mason Freed, Sanket Joshi, Olli Pettay, Yoav Weiss, Chris Wilson
Scribe: Joey Arhar

1. Review past action items
   1. Emilio to collect compat data and propose a spec PR for min/max in [forms] Number input intrinsic size.
      1. Not done, carry over.
   2. Ben will ping Emilio for Gecko's take on the contentvisibilityautostatechange event PR.
      1. Done.
2. Carryovers from last time
   1. Emilio to work on pulling out the common points for iframe throttling into the issue about Consider improving interoperability of <iframe> throttling margins, and maybe a spec PR.
      1. Not done, carry over
   2. [Mason] Revisit invoketarget naming discussion. Concrete naming proposal is commandfor/command.
      1. Naming converged
      2. Implicit type change - not clear this can be backwards [sideways] compat
      3. Whether implicit commands are required
      4. AI: Mason to post proposal
3. New topics
   1. [Yoav] Add a noopener-allow-popups value to COOP

Action Items

1. @mfreed7 to post a proposal for moving forward with Invoker Buttons

Minutes

• emilio to collect data for min max

  • emilio: not done yet, recovering

• gecko's take on content visibility

  • chris: done. Did it get filed on the pr?
  • emilio: yes

• common points for iframe throttling

  • emilio: yep same status

• invoketarget

  • mason: I'm curious about the process. We have two implementer support and spec review. Did mozilla supportiveness change? i copied that agenda item but its moved beyond naming. naming seems resolved: commandfor and command. now there are questions about - there's a suggestion for changing type based on forms.
  • olli: that might not be backwards compatible
  • mason: if you add command or commandfor, then the type of the button will be automatically changed to button
  • olli: if the browser doesn't support these new attributes
  • mason: if the devs point is to prevent automatically submitting the form
  • olli: the browser would submit the form
  • mason: oh you're right, that's bad. Ok.
  • olli: other than that i support this
  • mason: also question about implicit commands requiring the command attribute or keeping the pr as it is which it automatically does the thing if you don't have the command attribute
  • olli: i think i would prefer explicit command always so that you actually know, not so magical implicit command. maybe in case you want to move these to be global attributes which i think we will need to do. in my mind these would be global on all elements. if you can make the element focusable or click somewhere underneath that then you trigger that command.
  • mason: they're not global now, only on form controls, but the globalness what really matters is that the target can be anything and you can target anything you like so they are global in some sense.
  • olli: but you can't use these in custom elements
  • mason: the implicit actions of the command depend on the target element
  • mason: last question that has been raised is some sort of toggling feature where the name of the button changes based on the target element
  • olli: we were wondering if that's the case, trying to find that in firefox ui and i couldn't quite find that example in firefox ui. This was something that Anne brought up.
  • mason: there are use cases like that but not primary. popover doesn't do this. select menu for example doesn't do this. Most buttons that open a picker don't do this. That is an interesting feature but I want to keep it separate since it doesn't seem core to the feature.
  • olli: we want to get this right now so we don't have to redesign this later, we are basically replacing popover attributes which we just introduced. Do we need to replace this new thing in a year?
  • mason: yeah i see that point. use case wise im convinced its not the standard use case and would want to be an opt in anyway
  • olli: i don't know whether it should be a button or how would this work with custom elements for example
  • mason: this will post some comments, i will post a proposal for a way forward. I just want to unblock this.

• noopener-allow-popups

  • yoav: i opened an issue and a pr to extend cross origin opener policy with a value that severs the opener relationship in a same origin case, so that when a document opens a document that has this value, that document will not be able to script the document that was opened. that fits very well with the coop model, both the spec and chromium impl also webkit. The main downside is that this is not a cross origin, its same origin, but the model fits very well. Olli has some reservations regarding the use of noopener there. I'd love to talk this through and see if we can reach some conclusions. I saw that you commented on the issue and Anne replied and I'd love to talk through this. i don't necessarily understand your concern
  • olli: that feature is something that people want to use outside of coop. They want to kill the opener relationship. that's my concern
  • yoav: what other side effects does coop have? people that want to do that could just use it?
  • olli: but youre saying this is sameorigin only
  • yoav: for cross origin we already have this. this extends coop to also apply to same origin cases
  • olli: yeah ok that's true. it just feels weird to couple these kinds of different features together. There's an opener relationship feature which we can control with noopener from the other side. now we are coupling coop with noopener and that's a new thing. people need to first understand what is coop in order to use this new feature rather than just have some simple header like please no opener relationships to me
  • yoav: advantage of using noopener here is that it gives us report only mode out the gate. If we were to go with a different header we would end up mapping that header to coop and processing model. It's the same thing. you want to sever opener relationship, you want different browser context groups and this is what coop does. it also gives you other guarantees when it's combined with coop? but that's a separate story.
  • olli: it still feels wrong to combine these together. from the caller side its noopener which has nothing to do with coop and from the other side you have to use coop so you have to use all different headers from the other side. The worry I have is how to make this easy to understand. should the header name be something different or? i don't really have any better names
  • yoav: if we minted a better header name and linked processing model to coop would that work? the developer facing part would be different
  • olli: maybe that works. Maybe it's also about the documentation we have. Someone who is trying to figure out how to break opener relationship that person might not take a look at coop, that's the way to break the relationship. maybe it's partially just documentation in MDN just document it well
  • yoav: that is easy, i am more than happy to add things to mdn and also generally publish documentation on my personal blog, elsewhere, on this ability to sever that relationship. if that's the concern i think it's solvable while using coop.
  • olli: yeah ok. I can live with this. its icky but yeah
  • yoav: we are going to need extensive documentation to point people in the right direction.
  • olli: I wonder if in the spec in those places which talk about bfcache - they may need to use this header in order to break the opener relationship. just about documentation at spec level
  • yoav: i'm not sure i see the relationship between bfcache and this
  • olli: you may not enter bfcache if you have noopener
  • yoav: want to comment on that?
  • olli: yes

• chris: That was the last item. mu-an showed up, more about invoker?

• mu-an: i only caught Olli's comment about how we just shipped popovertarget and it seems like we should be more careful, and that's also what i'm concerned with. i have some ideas but nothing concrete to share yet.