zcorpan (OOO 22 Nov): suggested forwarding this here. Copying his take from elsewhere:

https://fetch.spec.whatwg.org/#concept-bodyinit-extract
10. Switch on object:
Blob
Set source to object.
Set length to object’s size.
If object’s type attribute is not the empty byte sequence, set type to its value.
...
14. Return (body, type).
that is called from https://fetch.spec.whatwg.org/#ref-for-concept-bodyinit-extract%E2%91%A1
4. If type is non-null and https://webidl.spec.whatwg.org/#this’s https://fetch.spec.whatwg.org/#request-headers’s https://fetch.spec.whatwg.org/#concept-headers-header-list https://fetch.spec.whatwg.org/#header-list-contains Content-Type, then https://fetch.spec.whatwg.org/#concept-headers-append (Content-Type, type) to https://webidl.spec.whatwg.org/#this’s https://fetch.spec.whatwg.org/#request-headers.

I suppose that step could throw if type is null and there's no content-type header, and method is POST (or disallow no content-type for all methods?)

XMLHttpRequest does the same (per spec). You can also use an ArrayBuffer or ArrayBufferView I think

hsivonen: have you been able to verify "recent" UTS46 changes with regards to whether they are a net good? There's https://github.com/web-platform-tests/wpt/pull/48301 and the general Unicode 16.0 issue against URL. I probably need to look into it to see whether all the changes and now failing tests make sense. But we also can't land this now with Interop 2024 almost wrapping up...

With regards to that flag: I think Firefox and Safari are correct, but I also don't understand why it was introduced. I think it would be better if that flag was not there at all. But I guess while it is, we might as well explicitly set it to false and continue to complain to UTS46 authors on the side... (However, updating the URL standard to set it to false would require dealing with the tests situation I suspect or perhaps we could argue that part is covered by existing tests?)

The custom element specification has this wording:

The element's attributes and children must not be inspected, as in the non-upgrade case none will be present, and relying on upgrades makes the element less usable.

What is meant by "non-upgrade case"? Can someone explain the sense of written?

You wrote that directly it is document.createElement("custom-element"). I clarified: "is the element definition present via customElements.define"?

Okay, so the definition for the custom element is present.

That is, if I understand correctly, this describes the case when the definition for the custom element is present and we write document.createElement("custom-element") in the code as you specified. That is, this is what the note in "as in the non-upgrade case none will be present" says?

Right?