Skip to content

Upcoming WHATNOT meeting on 2025-12-11 #11989

Description

@cwilso

What is the issue with the HTML Standard?

Today we held our weekly triage call (#11982) and I will post the meeting notes there shortly. The next one is scheduled for December 11, 9AM PDT. Note that this is 1 week later in the same EMEA-Americas friendly time, and also directly follows our joint OpenUI-WHATWG-CSSWG call (#11889).

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

Activity

  1. added
    agenda+To be discussed at a triage meeting
    on Dec 4, 2025
  2. leotlee commented on Dec 10, 2025

    @leotlee
    Member

    We'd like to discuss issue #11839.

  3. KurtCattiSchmidt commented on Dec 11, 2025

    @KurtCattiSchmidt
    Contributor

    I'd like to discuss #11981

  4. removed
    agenda+To be discussed at a triage meeting
    on Dec 12, 2025
  5. cwilso commented on Dec 12, 2025

    @cwilso
    ContributorAuthor

    Our next meeting is #12015.

    Minutes:

    • Focus without User Activation Policy #11839 Taylore Givens presented a document on "focus without user activation", summarizing that the policy aims to limit programmatic focus for iframes but allows those limitations to be lifted under certain conditions, rejecting an all-or-nothing approach. Taylore clarified that the goal is to prevent child iframes from disruptively taking focus from ancestor frames, and they believe that the ancestor or top-level frame should have unrestricted admin privileges to take focus back from any child frame. Anne van Kesteren expressed unease about crossing the origin boundary, questioning why an ancestor frame of a different origin should be able to steal focus from a child iframe of a different origin, and pointed out that Web security typically does not define such a hierarchy for documents. Taylore responded that their design assumes the hierarchy grants the ancestor frame such admin privileges. Dominic Farolino asked if the proposed behavior differs from the current state, and Taylore Givens explained that while a parent can currently take focus from a child (which they are not changing), the main new addition is restricting the child frame from taking focus from an ancestor.
      The discussion clarified that the spec already includes a policy to disallow a child from stealing focus. Taylore and Fernando Fiori shared that their testing indicated that in most browsers, there are no restrictions on programmatic focus, except for WebKit, which implements a version where a child (B) cannot steal focus from a parent (A), but A might be able to take focus back from B, though the latter is harder to test without user activation considerations. Emilio Cobos Álvarez, looking at WebKit's code, suggested that it seems WebKit always allows the parent frame to steal focus, unless they are missing context.
      Anne noted that WebKit's code only seems to allow the parent to steal focus if the parent has user interaction, suggesting the current proposal might allow stealing focus even if the child already had it. Dominic identified the new part of the proposal as allowing a parent to always take programmatic focus from a child iframe, regardless of the parent's transient activation status, especially when the parent is not the topmost level and is not the same origin as the topmost document. Taylore reaffirmed this consensus on the desired behavior for the spec.
      Emilio Cobos Álvarez raised a tangential point about Olli's concern regarding full screen, noting that when an element goes full screen, non-full-screen iframes conceptually become inert and non-focusable, which may negate the concern. Fernando and Taylore agreed that this might not be an issue and planned to relay this information. Anne stressed the need for clarity on the proposed behavior, particularly in complicated multi-document setups like pop-ups, as the current PR's use of "entry document" makes it non-reviewable. Dominic suggested creating a list of complicated multi-document scenarios, including pop-ups and multiple windows, to define the desired behavior for consensus before finalizing the spec concepts.

    • Deferring Commit of Same Origin Cross Document Navigations #11819 Noam Rosenthal presented the API design for allowing deferring commit of same origin cross document navigations, outlining features like checking if a destination is ready (without render-blocking resources), using defer page swap on the navigate event with a handler, and an optional immediate history change. They also explained the restore call back which can revert to the previous state if navigation is aborted or the page is restored via BF cache. Noam stated they would move the draft PR forward for review as there were no objections.

    • Module Preload for Scripts and Styles #11981 Kurt Catti-Schmidt provided an update on the module preload for scripts and styles, stating they addressed Anne’s comments, including removing JSON from the preload . Kurt confirmed that tests (WPTs) and an MDN draft are ready, and Anne advised landing the spec and WPTs around the same time. Anne also noted that conformance requirements related to not allowing JSON in the preload attributes might be missing from the PR, and confirmed that WebKit's agreement could satisfy the requirement for two implementers.

    • Menu Element Specification and Stage Two Request #11729 Dominic provided an update on the menu element proposal, announcing a spec draft PR that defines most of the API shape. Dominic requested a stage two review for the PR, noting that they anticipate potential pushback on the use of fieldset to wrap checkable menu items. Dominic asked for Anne and someone from Mozilla (such as Olli or Kagami) to review the API shape, activation behavior, and other integrations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions