Upcoming WHATNOT meeting on 7/4/2024

[past]

What is the issue with the HTML Standard?

Having skipped this week's meeting (#10422), the next one is scheduled for July 4, 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.

[annevk]

Agenda

• Attendees: Olli, Kagami, Emilio, Luke, Keith, Anne, Brecht, Robert
• Scribe: Anne (with help)

Review past action items

• 1a. Mason to post a proposal for moving forward with Invoker Buttons
  • Done.

Carryovers from last time

• 2a. Emilio to collect compat data and propose a spec PR for min/max in [forms] Number input intrinsic size.
  • The spec has some text to this regard already. Only question is whether we want to make size apply to number inputs. If so, happy to write a PR.
• 2b. 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.
  • Waiting to get review on a Gecko patch that implements what would be my formal proposal, in order to confirm it is web-compatible.

New topics

• 3. [Anne] Severing a document's opener relationship regardless of origin
• <input type=color> enhancements

Action Items

• None

Minutes

Topic: 1a

• Keith: Updated tests for Invoker Buttons along the lines of the latest proposal.
• Anne: Will we regret not overriding the default type?
• Keith: The fallback in older browsers is quite bad. E.g., a website asks “Do you want to delete this?” and then you click the “More info” button and it ends up deleting.
• Luke: Does this mean we can never add a new type?
• Keith: Potentially.
• Anne: I wonder if we should investigate that a bit more to see if we can change the fallback.
• Luke: Perhaps we should require an explicit type attribute?
• Keith: I think that is a somewhat artificial restriction.
• [Lots of unminuted discussion to figure out if we can do better.]
• Rough proposal to do better:
  • Require the type attribute for now with command when inside form.
  • A command without a type attribute when inside a form also changes the default, but the command doesn’t work. (Going from non-functioning to a command seems better than going from submit to command in the future.)
  • In the (far) future we can remove the type attribute requirement.
  • Outside form we default type to button straight away if there’s a command attribute.
  • Separately investigate changing the invalid default for the type attribute.

Topic: 2a

• Emilio will work on an update.

Topic: 2b

• Working on Gecko patch and want to wait to see how well that works before moving forward.

Topic 3 (opener relationship)

• Anne and Olli said a bunch of unminuted words, but largely-but-not-completely agree. Perhaps noopener as additional value makes sense for bfcache.
• Olli: what about COEP?
• Anne: that is a good question, it could in theory maybe combine as it’s close in strictness to COOP: same-origin.

Topic (input type color enhancements)

• Anne: I proposed adding alpha and colorspace attributes to input.
• [Some unminuted discussion about tradeoffs made.]
• Luke: ship it
• Olli: looks quite reasonable, will take a look