Upcoming HTML standard issue triage meeting on 3/9/2023

[past]

Today we held our biweekly triage call (#8873) and I will post the meeting notes there in a bit. The next one is scheduled for March 9, 1 am PST. Note that this is 2 weeks later in an APAC+Europe friendly time.

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 in all WHATWG repos and we would like to invite anyone that can contribute to said issues to join us.

[annevk]

@past could you please add @nt1m to the recurring invite for all meetings? Thanks!

[past]

Added Tim.

[annevk]

@past I created internal calendar entries for folks to know when these are happening, but I can't quite seem to recreate the schedule. I had 3 entries each repeating every 6 weeks. But for instance that makes me expect a July 13 meeting at 1AM PT but "you" have that at 9AM (same as four weeks prior). (It also seems that some are in PT and others are in CET.) Do you have any insights?

[past]

Yeah, sorry about that. Because of the recent tweaks and constraints that we added, my approach has been to set the calendar for the next 6 months in the beginning and middle of the year. So anything after June is not correct. It's quite a bit of mundane work to make these updates, unfortunately.

So far I just have a single recurring bi-weekly meeting that I manually tweak for the changes that we agree on. We changed the frequency and length of the meeting in #8106. We agreed to change one of the meeting slots around daylight savings time (#8494). I don't recall setting any slot's timezone to CET, which one were you looking at?

Would it make things easier for you if I added you as a co-host (assuming that allows you to edit the invite) so that you could easily export/import it to your internal calendar?

[annevk]

How about we make it match my attempt at emulating? That is, we'd have three invites each repeating every 6 weeks. We could also fixate the time zone for each individually, e.g., aligning the meeting "for" Japan with the time zone there. The only downside would be having to duplicate the invite list. (I would be happy to help manage the invite list and add people as needed.)

[past]

OK, I will give this a try. Event guests already have permission to modify the event, so feel free to add people as needed.

[past]

Thank you all for attending today! Here are the notes from this meeting (the next one is at #9002):

Agenda

1. Review past action items
   1. Marcos & Anne to kindly look for ways the proposed solution here might run into problems.
      1. Anne commented slightly, discussion will continue async.
   2. Feedback from everyone is welcome on Anne's PR to Give ElementInternals element-reflecting attributes more power, will discuss this again next time.
      1. Mason took a look and is in spirit supportive.
      2. Olli will take a look.
2. Carryovers from last time
   1. [Mason] Add DOMParser option to parse declarative shadow DOM
      1. Both Mozilla and Chromium representatives believe adding such an option to DOMParser is a reasonable path forward for the whole-document case.
      2. No need to support XHR since it's a legacy API. DOMParser has no replacement now.
3. New topics
   1. [Connected to DOMParser discussion] setHTML: entry point to the sanitizer, or a generic HTML setter?
      1. Question: are we OK adding a sanitizing method where sanitizing cannot be turned off?
         1. Daniel: this is very important
         2. Olli: no strong opinions. Simon: OK with this. Freddy seemed to be warming up to this idea.
      2. Question: do we want to add a non-sanitizing method?
         1. Mason: This is necessary for key DSD use cases, like script-containing custom elements.
         2. Olli: This is also important for performance.
      3. Question: do we want to add the variant methods (e.g. [unsanitized, sanitized] x [prepend|append|set] x [XML|HTML])?
         1. Mason/Daniel: the [unsanitized] branch of this seems like adding more dangerous things, but OK to compromise if other people really want them
         2. Some discussion of using options bags to reduce the number of methods, but nobody really in favor.
         3. Simon: we can defer the [XML] branch, especially since we don't know how DSD will work there anyway.
      4. Future question: how do we support sanitization in a future streaming HTML parser API? (First we need to design the streaming HTML parser API...)
         1. Simon: This would need fundamental changes to the sanitizer spec, working on the tree builder instead.
         2. Daniel: This seems doable, even if a lot of work. Pointers from Simon appreciated.
      5. Discussion will continue async!!

Action Items

1. @zcorpan to open an issue about streaming sanitized parsing, with pointers to help @otherdaniel understand how we could build that in the future.