WHATWG on 2024-07-11

02:59	<sideshowbarker>	About Mutation Events: is Chrome going ahead with shipping this month with support completely removed, as planned? https://developer.chrome.com/blog/mutation-events-deprecation ← mfreed
03:55	<Domenic>	Oh, "create a fresh top-level traversable" nice. Though I wonder if this should have some more arguments so you can set userInvolvement? My use case is automatically opening a URL when an end user clicks a notification. What do you think Domenic? In theory sounds reasonable, but in practice I'm not sure userInvolvement does anything when you're navigating from about:blank?
05:12	<annevk>	Domenic: ah okay, I hadn't looked that far
05:13	<annevk>	Domenic: although if this accurately represents an end user interaction perhaps it could be used by `Sec-Fetch-User` and text fragment navigations?
05:13	<sideshowbarker>	If I have some data that’s in some encoding other than UTF8, but — under the mis-assumption that it is UTF8-encoded — I do some processing on it, to extract substrings as UTF-8: If the strings only have ASCII-range characters, then me assuming they are UTF8 will actually work for those ASCII-range characters in some non-UT8 encodings, right?
05:14	<sideshowbarker>	And if Yes, then for which other encodings would that actually work?
05:15	<annevk>	sideshowbarker: only UTF-16 and iso-2022-jp are ASCII-incompatible, from the Encoding Standard
05:16	<Domenic>	Domenic: although if this accurately represents an end user interaction perhaps it could be used by `Sec-Fetch-User` and text fragment navigations? True, that is an outstanding work item. https://github.com/w3c/webappsec-fetch-metadata/issues/71 https://github.com/whatwg/html/issues/5381 https://github.com/whatwg/html/issues/9133
08:02	<freddy>	I am sort of my way to the WHATNOT meeting but it seems Firefox Nightly + Google Meet do not get along with each other as of today?
08:04	<annevk>	keithamus: are you joining?
08:09	<keithamus>	Yes! One minute
08:11	<freddy>	User Error 🤐
16:51	<Timo Tijhof>	I'm trying to untangle some XHTML/HTML5 heritage. I'm aware there's unresolved differences here, but wondering if there's an interop approach here that's recommended in the interim. In a nut shell, when using `document` to create elements for the current document, this creates Element instead of HTMLElement when executed in an XHTML document, despite the elements parsed from the server on the same document, being HTMLElement. The impact is that generic JavaScript code like `var dropDown = document.createElement('div'); dropDown.style.display` fails in XHTML context because Element.style is undefined. This works in Firefox but fails in Chrome/Safari. Even after attaching to the body, it remains an Element.
16:53	<Timo Tijhof>	I found a couple related issues like https://github.com/whatwg/dom/issues/643 , and https://github.com/whatwg/dom/issues/217, and open ones about un-merging HTMLDocument, but this seems to be something else.
16:55	<Timo Tijhof>	It seems like step 5 here appears to require this, but I imagine this would have been fixed already if there isn't some other interop issue here that I'm missing. https://dom.spec.whatwg.org/#dom-document-createelement
17:03	<Meghan Denny>	are you able to verify in the network tab that the file is being served with `application/xhtml+xml` ?
19:54	<Timo Tijhof>	Hm.. well it was, but it isn't now. That might be it. So does this mean there is some kind of in-between mode where if the doctype/xml tag does XHTML, that informs JavaScript, but then the parser/DOM ignores that and just does HTML5 based on content type?
19:55	<Timo Tijhof>	Interesting, yeah, I have two different static file servers. One basic nodejs, and one python3 and the latter supports correct mime types for .xhtml out of the box. It all works correctly there.
19:56	<Timo Tijhof>	Meghan Denny: Thanks! That solves my mystery for now. It is an odd quirk for sure, but I can work around this for now.
21:44	<mfreed>	About Mutation Events: is Chrome going ahead with shipping this month with support completely removed, as planned? https://developer.chrome.com/blog/mutation-events-deprecation ← mfreed Yes! It is set to be disabled at 100% starting with Chrome 127, which goes to stable around July 23. Pending, of course, any compat issues that pop up.