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 12/2/2021 #7299

Closed
past opened this issue Nov 5, 2021 · 18 comments
Closed

Upcoming HTML standard issue triage meeting on 12/2/2021 #7299

past opened this issue Nov 5, 2021 · 18 comments
Labels
agenda+ To be discussed at a triage meeting

Comments

@past
Copy link

past commented Nov 5, 2021

Yesterday we held our monthly triage call (#7201) and I will post the meeting notes there in a bit. The next one is scheduled for December 2nd, 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.

@past past added the agenda+ To be discussed at a triage meeting label Nov 5, 2021
@hober
Copy link
Contributor

hober commented Nov 10, 2021

I'd like to attend, thanks!

@jensimmons
Copy link

I would, too. Thanks!

@past
Copy link
Author

past commented Nov 10, 2021

Great, added you both!

@domenic
Copy link
Member

domenic commented Nov 23, 2021

I would like to add whatwg/dom#1032 to the agenda, even though it's outside the HTML Standard repository. Specifically to discuss whether the timers there should suspend while the document is in bfcache/worker is suspended, or not.

Edit: actually I suspect that will be resolved asynchronously. I'll add another update if that ends up being the case...

Edit edit: we decided on this asynchronously, so no need to discuss.

@Kaleidea
Copy link

I'd like to discuss implementation details of the <search> element with implementers from the 3 major browsers. In preparation I've drafted the specification and basic implementations for Chromium and WebKit (Firefox in progress) regarding which I'm seeking feedback from developers who will be implementing this feature. Eventually, I'd like to submit patches to move forward the implementation.

@Kaleidea
Copy link

@past I'm not familiar with the meeting's process. Could you please link to some introductory material? Thank you in advance.

@hober
Copy link
Contributor

hober commented Nov 29, 2021

Great, added you both!

I never got the calendar invite. Did you send it to eoconnor at apple dot com?

@past
Copy link
Author

past commented Nov 30, 2021

@hober thanks, I had used another address, but now I added this one as well.

@Kaleidea Not sure if there will be time in this meeting given the current list, but have you opened an issue or PR with your proposal (apart from the gist) and invited feedback? This is about all the process that we have in place: folks tag issues and PRs with agenda+ when there are specific details to be discussed in a high-bandwidth medium. Most issues continue to be resolved asynchronously, but occasionally it is useful to get everyone in a room to move things forward faster.

@past
Copy link
Author

past commented Nov 30, 2021

I found out that several people have a conflict this time. I wonder what everyone's appetite is for rescheduling or keeping the same time. I'm personally OK with every option, but can I get a thumbs up or down for what works or doesn't work for you all?

@past
Copy link
Author

past commented Nov 30, 2021

Meet an hour later

@past

This comment has been minimized.

@past
Copy link
Author

past commented Nov 30, 2021

Keep the current time

@past
Copy link
Author

past commented Nov 30, 2021

The overwhelming preference is for moving it one hour later, so the new meeting time is December 2nd, 10 am PST.

@Kaleidea
Copy link

Kaleidea commented Dec 1, 2021

@past I have just two questions:

  • What technical constraints and difficulties were identified for including form functionality in the <search> element?
  • Whether these cause any issues to the simple implementations I've submitted?

The issue I've made did not reach the implementers. I've made a PR now: #7382.
Primarily I'm seeking contact and feedback from implementers who are familiar with the HTMLFormElement and the HTMLTreeBuilder (nsHtml5TreeBuilder in Firefox) classes and related areas.

@past
Copy link
Author

past commented Dec 2, 2021

@Kaleidea great, thanks for summarizing your questions and I hope that the participation agreement will be approved soon. Can you share your email address so I can add you to the calendar invite? The agenda is pretty packed so I can't promise that we will have time to discuss this, but I can certainly ask any implementers in the room to take a look after the meeting.

@Kaleidea
Copy link

Kaleidea commented Dec 2, 2021

@past I've sent you an email.

I can certainly ask any implementers in the room to take a look after the meeting.

That would be very helpful, thank you!

@past
Copy link
Author

past commented Dec 3, 2021

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

Agenda

  1. Review past action items
    1. Domenic and others will spec the proposed search element.
      1. Done. Further discussion in item 9 below.
    2. Mason will add some example URLs in the <object> without "data" attribute issue, Domenic and Anne will take a look at them.
      1. Done. Mason will add the use counter. Tess will provide feedback in the thread.
    3. Domenic will look into the :active pseudo-class specification doesn't account for children/labels of disabled form elements and post a comment.
      1. Done. Domenic to update the spec.
    4. Xiaocheng will post an update to the Renderblocking attribute issue.
      1. Done. Further discussion in item 5 below.
    5. We need volunteers for an HTML spec PR on Directionality in Shadow DOM.
      1. None so far, but Eric will be discussing with Elika the validity of the current proposal. We will ask for volunteers afterwards.
    6. Everyone is encouraged to add feedback to the issue: <input type=password> should provide UI to show/hide its value.
      1. Feedback was provided. Tess will add a proposal to the thread.
  2. Carryovers from last time
    1. None.
  3. [Mason] Selection APIs for Shadow DOM
    1. More feedback is welcome. Ready to spec incrementally, Mason and Anne will collaborate.
  4. [Domenic] Adding scriptElement.exports for configuration use cases
    1. More feedback is welcome.
    2. Domenic to add a comment expanding on the re-ordering requirement. Also note that inline CSS/JSON modules are complicated (asserts, different parsers, etc.) and should not be bundled with this.
  5. [Xiaocheng] Feature proposal: blocking="render" attribute on <link> and <script>
    1. No significant concerns, Xiaocheng will start speccing and summarize the current status in the thread. Be sure to include the implementation-defined timeout in the spec.
  6. [Domenic] <object> element can tell whether child document loaded or not
    1. Domenic to investigate compat impact of removing the fallback behavior, since removing error events without removing fallback behavior is not actually a security win.
  7. [Domenic] Add showPicker() to <input> elements
    1. Didn't have time for this.
  8. [Domenic] popstate/hashchange dispatching doesn't match what browsers do
    1. Didn't have time for this.
  9. [Domenic] Add the <search> element
    1. Didn't have time for this.
  10. [Kaleidea] Search element specification with form functionality
    1. What technical constraints and difficulties were identified for including form functionality in the <search> element?
    2. Do these cause any issues to the simple implementations Kaleidea has submitted?
    3. Didn't have time for this, but Anne has provided some feedback on Matrix.
  11. [Dominic F] Images refetching upon insertion if <base> URL changes
    1. Didn't have time for this.

Action Items

  1. @mfreed7 will add a use counter for the <object> without "data" attribute issue. @hober will provide feedback in the thread.
  2. @domenic to update the spec for the :active pseudo-class specification doesn't account for children/labels of disabled form elements issue.
  3. @meyerweb will be discussing with Elika the validity of the current Directionality in Shadow DOM proposal. We will ask for volunteers afterwards.
  4. @hober will add a proposal to the <input type=password> should provide UI to show/hide its value thread.
  5. @mfreed7 and @annevk will collaborate on a spec for Selection APIs for Shadow DOM.
  6. @domenic will add a comment expanding on the re-ordering requirement for Adding scriptElement.exports for configuration use cases. More feedback from everyone is welcome.
  7. @xiaochengh will start speccing and summarize the current status of Feature proposal: blocking="render" attribute on <link> and <script> in the thread.
  8. @domenic to investigate compat impact of removing the fallback behavior in <object> element can tell whether child document loaded or not, since removing error events without removing fallback behavior is not actually a security win.

@past past closed this as completed Dec 3, 2021
@Kaleidea
Copy link

Kaleidea commented Dec 7, 2021

Thank you for the invite. It was great to see all the progress made.

  1. Didn't have time for this, but Anne has provided some feedback on Matrix.

The feedback from Anne clarified the root of some concerns, thank you. I'm looking for more if any implementers happen to come by the 2 questions related to the <search> element.

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Dec 16, 2021
This CL applies the new agreements for a <slot> elelement on the
standards meeting[1][2].
 - Resolve the slot element's directionality from the flattened tree
 - Apply one exception that the slot element's directionality should
   be the same as a shadow host's directionality if the slot element
   has a dir=auto attribute and has no slotted content.

This CL adds the unit tests on blink and WPT tests will be added on [3].

[1] whatwg/html#7299
[2] whatwg/html#3699 (comment)
[3] #29820

Bug: 1236384
Change-Id: I43ca7351fc4d65dd4f72fe4f9627ffa5382e5c20
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Dec 21, 2021
This CL applies the new agreements for a <slot> elelement on the
standards meeting[1][2].
 - Resolve the slot element's directionality from the flattened tree
 - Apply one exception that the slot element's directionality should
   be the same as a shadow host's directionality if the slot element
   has a dir=auto attribute and has no slotted content.

This CL adds the unit tests on blink and WPT tests will be added on [3].

[1] whatwg/html#7299
[2] whatwg/html#3699 (comment)
[3] #29820

Bug: 1236384
Change-Id: I43ca7351fc4d65dd4f72fe4f9627ffa5382e5c20
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 12, 2022
This CL applies the new agreements for a <slot> elelement on the
standards meeting[1][2].
 - Resolve the slot element's directionality from the flattened tree
 - Apply one exception that the slot element's directionality should
   be the same as a shadow host's directionality if the slot element
   has a dir=auto attribute and has no slotted content.

This CL adds the unit tests on blink and WPT tests will be added on [3].

[1] whatwg/html#7299
[2] whatwg/html#3699 (comment)
[3] #29820

Bug: 1236384
Change-Id: I43ca7351fc4d65dd4f72fe4f9627ffa5382e5c20
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 12, 2022
This CL applies the new agreements for a <slot> elelement on the
standards meeting[1][2].
 - Resolve the slot element's directionality from the flattened tree
 - Apply one exception that the slot element's directionality should
   be the same as a shadow host's directionality if the slot element
   has a dir=auto attribute and has no slotted content.

This CL adds the unit tests on blink and WPT tests will be added on [3].

[1] whatwg/html#7299
[2] whatwg/html#3699 (comment)
[3] #29820

Bug: 1236384
Change-Id: I43ca7351fc4d65dd4f72fe4f9627ffa5382e5c20
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 18, 2022
This CL applies the new agreements for a <slot> elelement on the
standards meeting[1][2].
 - Resolve the slot element's directionality from the flattened tree
 - Apply one exception that the slot element's directionality should
   be the same as a shadow host's directionality if the slot element
   has a dir=auto attribute and has no slotted content.

This CL adds the unit tests on blink and WPT tests will be added on [3].

[1] whatwg/html#7299
[2] whatwg/html#3699 (comment)
[3] #29820

Bug: 1236384
Change-Id: I43ca7351fc4d65dd4f72fe4f9627ffa5382e5c20
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 20, 2022
This CL applies the new agreements for a <slot> element on the
standards meeting[1][2].
 - Resolve the slot element's directionality from the flattened tree
 - Apply one exception that the slot element's directionality should
   be the same as a shadow host's directionality if the slot element
   has a dir=auto attribute and has no slotted content.

This CL adds the unit tests on blink and WPT tests will be added on [3].

[1] whatwg/html#7299
[2] whatwg/html#3699 (comment)
[3] #29820

Bug: 1236384
Change-Id: I43ca7351fc4d65dd4f72fe4f9627ffa5382e5c20
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 20, 2022
This CL applies the new agreements for a <slot> element on the
standards meeting[1][2].
 - Resolve the slot element's directionality from the flattened tree
 - Apply one exception that the slot element's directionality should
   be the same as a shadow host's directionality if the slot element
   has a dir=auto attribute and has no slotted content.

This CL adds the unit tests on blink and WPT tests will be added on [3].

[1] whatwg/html#7299
[2] whatwg/html#3699 (comment)
[3] #29820

Bug: 1236384
Change-Id: I43ca7351fc4d65dd4f72fe4f9627ffa5382e5c20
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 20, 2022
This CL applies the new agreements for a <slot> element on the
standards meeting[1][2].
 - Resolve the slot element's directionality from the flattened tree
 - Apply one exception that the slot element's directionality should
   be the same as a shadow host's directionality if the slot element
   has a dir=auto attribute and has no slotted content.

This CL adds the unit tests on blink and WPT tests will be added on [3].

[1] whatwg/html#7299
[2] whatwg/html#3699 (comment)
[3] #29820

Bug: 1236384
Change-Id: I43ca7351fc4d65dd4f72fe4f9627ffa5382e5c20
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

5 participants