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

[past]

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.

[hober]

I'd like to attend, thanks!

[jensimmons]

I would, too. Thanks!

[past]

Great, added you both!

[domenic]

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]

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]

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

[hober]

Great, added you both!

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

[past]

@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]

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]

Meet an hour later

[past]

Keep the current time

[past]

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

[Kaleidea]

@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]

@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]

@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]

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.

[Kaleidea]

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

3. 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.