00:32
<dbaron>
I think part of the underlying question is around "how much is instanceof useful to modern javascript in this sort of context".
01:02
<bkardell>
Not much, i expect?
01:03
<zcorpan>
I haven't written or updated tests for it yet
01:56
<zcorpan>
https://github.com/web-platform-tests/wpt/pull/63042
05:28
<annevk>
instanceof also breaks cross-realm so it's not a great tool.
05:29
<annevk>
Seeing checked and defaultChecked, how does that correspond to HTML attributes here?
05:32
<annevk>
Having an interface for each element makes sense. Perhaps shared interfaces make sense as well. It would make it easier to extend (for web developers), although in a way that can make our lives harder down the road.
07:06
<annevk>
Hey zcorpan, is multipart/form-data still on your TODO list? Maybe Noam Rosenthal is interested in taking a look as well now he's back?
07:06
<annevk>
Hey Dominic Farolino, are you still planning on looking at the base URL changes?
07:30
<annevk>
FYI: I think I managed to mostly fix WebKit's WPT export problem. The PR titles remain the same for bot purposes so if you only look at those this won't help you, but the commits are a fair bit more meaningful. Example: https://github.com/web-platform-tests/wpt/pull/63023
07:32
<Noam Rosenthal>
I've updated some of the tests already
07:32
<Noam Rosenthal>
(yesterday)
07:33
<Noam Rosenthal>
I'm still updating the HTML part, e.g. the domintro needs to account for the new TypeErrors we're throwing
07:42
<annevk>
freddy Dominic Farolino: do you know why referrerpolicy is not on media elements?
07:44
<annevk>
Oh, we are already tracking this: https://github.com/whatwg/html/issues/7822
07:49
<annevk>
input is missing it too, though not sure it deserves it.
07:58
<Noam Rosenthal>
I saw that it was being reviewed while I was OOO so didn't get to it yet. happy to take a look.
08:54
<Noam Rosenthal>
Luke Warlow: Do we have any guidance on what to put in a trusted types sink name?
Context: https://github.com/whatwg/html/pull/12753
The sink interface for beforeHTMLUnsafe etc. is the ChildNode mixin, which is not something that's usually web-exposed I believe?
Should we dynamically generate it based on node type or something like that? Is that maybe an overkill?
09:24
<Noam Rosenthal>
(or freddy or anyone else)
10:42
<Luke Warlow>

ChildNode seems to be included in DocumentType, Element or CharacterData are there anymore?

I would say Node beforeHTMLUnsafe or Element beforeHTMLUnsafe.

10:43
<Noam Rosenthal>
I'm changing it to be NonDocumentTypeChildNode, so methods like beforeHTMLUnsafe can be called on Element, Text, Comment, ProcessingInstruction
10:56
<Noam Rosenthal>
I've had it as Node beforeHTMLUnsafe originally but one of the Claude reviews from annevk asked me to change it to ChildNode beforeHTMLUnsafe? Maybe Node is better? Not sure about Element given that it can work on Text/Comment/PI as well
11:03
<Luke Warlow>
Yeah I think Node makes most sense, exposing a mixin name feels wrong and it's not something meaningfully known to anyone. Like I write bits of spec and id still have to check its meaning.
11:49
<Noam Rosenthal>
It looks good to me in general but I feel a bit out of my comfort zone with some of the details
11:55
<Noam Rosenthal>
annevk zcorpan I've rebased everything, updated the domintro, added multiple test cases, also updated the PR descriptions. I think this is good for another review pass.
11:57
<annevk>
I don't think we should use mixins for return values.
11:57
<annevk>
Oh wait for the sink names. There too it seems like it would be a tad weird.
12:02
<Noam Rosenthal>
Changed it back to Node
18:40
<bakkot>

webidl in https://webidl.spec.whatwg.org/#idl-exceptions has the following:

A simple exception is identified by one of the following types:

  • EvalError
  • RangeError
  • ReferenceError
  • TypeError
  • URIError

These correspond to all of the JavaScript error objects (apart from SyntaxError and Error, which are deliberately omitted as they are reserved for use by the JavaScript parser and by authors, respectively). The meaning of each simple exception matches its corresponding error object in the JavaScript specification.

18:41
<bakkot>
there's a couple things wrong with this: for one, SyntaxError is not just used for the JS parser (e.g. it is used for JSON.parse); for another, there's two new error types now (AggregateError and SuppressedError)
18:41
<bakkot>
I will try to find a wording to fix the latter problem; for the former, it is actually extremely weird that the web platform throws DOMExceptions whose .name is "SyntaxError" in a bunch of places
20:13
<freddy>
input? you mean, form?
20:15
<annevk>
No input type=image. Did not check form, might be missing there too
20:30
<freddy>
Likely main issue is that nobody continued working on the spec. I don't think you'd find people objecting if you extended it to include other elements and added WPTs
20:33
<freddy>
for setHTMLUnsafe we have just "Element setHTMLUnsafe" as the name
20:34
<freddy>
TT supports shadowroots, no? I think those currently also report "Element inneHTML" as sink name? 🤨
20:36
<freddy>
ah no "ShadowRoot innerHTML" as per wpt