Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upcoming HTML standard issue triage meeting on 10/7/2021 #7014

Closed
past opened this issue Sep 2, 2021 · 3 comments
Closed

Upcoming HTML standard issue triage meeting on 10/7/2021 #7014

past opened this issue Sep 2, 2021 · 3 comments
Labels
agenda+ To be discussed at a triage meeting

Comments

@past
Copy link

past commented Sep 2, 2021

Today we held our monthly triage call (#6936) and I will post the meeting notes there in a bit. The next one is scheduled for October 7th, 9 am PST. 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 and we would like to invite anyone that can contribute to said issues to join us.

@alystair
Copy link

I'd like to attend as a guest to get an idea of how things operate, if possible.

@past
Copy link
Author

past commented Oct 7, 2021

I'd like to attend as a guest to get an idea of how things operate, if possible.

I have added you to the calendar invite.

@past
Copy link
Author

past commented Oct 11, 2021

Thanks everyone for attending! Here are the notes from this meeting (next one is at #7201):

Agenda

  1. Review past action items
    1. Panos will clean the agenda labels after the meeting.
      1. Cleanup done.
    2. Domenic will do extra testing for browser behavior with no user activation. Consensus that the proposal is reasonable. Also need to think about whether third-party frames can show pickers. (Modals are on top of other pages, file pickers are particularly scary.)
      1. Carry over.
    3. On Directionality in Shadow DOM, Eric will present a proposed text change to the CSS WG and get their feedback.
      1. Carry over (it is on fantasai's review queue after brief discussion/intro in the CSSWG)
    4. Mason will roll back the recent Chromium change around element restoration and Domenic will send a PR to clarify the spec about not firing events in these cases.
      1. Rollback happened, will check on PR next time.
    5. Domenic and Anne will respond to the &nnbsp; issue.
      1. Done: not in the issue, but the response is now in the spec.
    6. On custom validity checks for fieldsets, the group would like to see a little more developer support. There is also some small compat risk that is being considered. Domenic will try to get more signals.
      1. Carry over.
    7. The group is generally supportive of a search element, Domenic will follow up in the issue. There is a small concern about potential confusion if the name "search" is used.
      1. Done. Next steps to be discussed next time.
    8. People are encouraged to review and comment on the Improve autofocus and delegatesFocus interaction PR.
      1. Reviews and comments by Sean and Mason. Next steps include landing the tests.
    9. Mason will look into the issue about ensuring PDF browsing contexts have no DOM.
      1. Liked the idea. Biggest concern is impl difficulty. Will come back next time with more feedback.
    10. Domenic will take Anne's counterproposal on Newly created browsing contexts will almost always reject history.pushState/replaceState to Chromium for consideration.
      1. Anne's proposal was accepted.
    11. Mason will add a use counter for <object> without "data" attribute probably needs to consider params to figure out its URL.
      1. Use counter was added. Data is higher than the usual thresholds. Will wait for use counter to reach stable and then investigate HTTPArchive.
  2. Carryovers from last time
    1. None.
  3. [Anne] <embed> elements (HTMLEmbedElement) do not have contentWindow or contentDocument
    1. No interest to pursue this since <embed> is deprecated.
  4. [Simon] :active pseudo-class specification doesn't account for children/labels of disabled form elements
    1. Agreement to make this behavior more interoperable. We will revisit next time after everyone has had more time to think about this.
  5. [Chris] Renderblocking attribute quick introduction.
    1. Feedback appreciated.
  6. [Mason] Standardize a popup's condition and UI opened by window.open
    1. Mason's research identified compatibility concerns. Anne will talk to arai and come back with another proposal.
  7. [Anne] Focus the dialog element instead of the first focusable item
    1. Mason will look into this some more and discuss with Domenic. Firefox is ready to ship <dialog> and there is alignment with WebKit and a11y community.

Action Items

  1. Discuss next steps on the proposed search element.
  2. Land tests on the Improve autofocus and delegatesFocus interaction PR.
  3. Mason will bring more feedback on the issue about ensuring PDF browsing contexts have no DOM.
  4. Mason will wait for use counter for <object> without "data" attribute probably needs to consider params to figure out its URL to reach stable and then investigate HTTPArchive.
  5. Revisit :active pseudo-class specification doesn't account for children/labels of disabled form elements after everyone had more time to think about it.
  6. Deliver feedback to the Renderblocking attribute issue.
  7. Anne will talk to arai and come back with another proposal around Standardizing a popup's condition and UI opened by window.open.
  8. Mason will look into the issue Focus the dialog element instead of the first focusable item and discuss it with Domenic.

@past past closed this as completed Oct 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
agenda+ To be discussed at a triage meeting
Development

No branches or pull requests

2 participants