WHATWG on 2022-10-06

01:54	<Domenic>	Btw I am reproducing this on every navigation to a spec as long as I have DevTools open Interesting, I wonder if DevTools is messing with things? The requests should be "cors" since they use the crossorigin="" attribute.
01:55	<Domenic>	Oh I see that is consistent with the error
01:55	<Domenic>	How did they get an opaque response, indeed...
07:32	<annevk>	Domenic: I strongly suspect https://github.com/whatwg/html/pull/5339#issuecomment-1269482374 is correct, but a quick peek from you might not be a bad idea before people start doing a bunch of work you wouldn't be happy with
07:32	<Domenic>	Yep, just read it, thanks for checking. Will give it a thumbs up
07:43	<Ms2ger 💉💉💉>	I rebased it on Monday :(
07:44	<Ms2ger 💉💉💉>	annevk: so I'm guessing we're looking at either 50 or so web specs or 50 or so TC39 proposals
07:53	<Domenic>	~Or they could just stop changing the meaning of current realm, and pick a new word for shadow-including current realm...~ Wait this is wrong, that's the change TC39 specs option
07:54	<annevk>	Ms2ger 💉💉💉: if we're including proposals there's gonna be more web specs
07:54	<annevk>	Ms2ger 💉💉💉: I suspect it's because there's also some other JS-related refactoring going on and maybe import maps had an impact?
07:55	<annevk>	Ms2ger 💉💉💉: the realm lowercasing wasn't the primary source of conflicts at least
07:55	<Ms2ger 💉💉💉>	Yeah, it's nicolo-ribaudo
07:56	<annevk>	Those darn colleagues always making a mess.
07:57	<nicolo-ribaudo>	Those darn colleagues always making a mess. We ensure job security for eachother
08:01	<Ms2ger 💉💉💉>	Anyway - if I changed to "current realm" (incl SR) and "current principal realm / current principal global object / current principal settings object" (excl SR), that would work for you Domenic annevk ?
08:01	<Ms2ger 💉💉💉>	Then I just need to make sure nobody else complains
08:01	<Domenic>	Yep
08:06	<Ms2ger 💉💉💉>	I hope the light at the end of the tunnel isn't an oncoming train :)
08:44	<annevk>	Oh, some of my decl shadow DOM comments echo those I made in 2020.
10:04	<Ms2ger 💉💉💉>	Pushed some initial changes in that direction, more after lunch
12:39	<sideshowbarker>	About the `slot` element document-conformance requirements, did we ever consider making the spec require that a `slot` element must have a `template` ancestor? Is there any reason not to make such a requirement? Is there any use case for a `slot` element that’s not a descendant of a `template` element? (I vaguely recall that I may have asked this question before, but if so I don’t remember what the answer was…)
14:08	<annevk>	sideshowbarker: an actual descendant of a `template` element? Or being part of its "contents"? Did you look at the original `slot` element PR? I vaguely recall there being at least some discussion about it.
14:41	<dlrobertson>	At what point does a cluster of issues become a interop <year> effort?
14:44	<dlrobertson>	I've started working on upstream tests for https://github.com/whatwg/fetch/issues/1436, https://github.com/whatwg/fetch/issues/1464, and https://github.com/whatwg/xhr/issues/357
14:45	<dlrobertson>	but they're all very much related, so I wasn't sure if they'd be worth an interop issue
14:45	<dlrobertson>	also they're very much just a random nit picked up to learn more about the specs... not something I've seen extensively in the real world
15:00	<annevk>	dlrobertson: there was a somewhat random bucket last year for assorted issues; it seems worth proposing these and perhaps they can be captured in a similar thing
15:00	<annevk>	dlrobertson: jgraham prolly has better advice
15:01	<annevk>	(Also, I think I've said this before, the yak shaving is appreciated!)
15:07	<dlrobertson>	awesome! thanks for the info
17:29	<TabAtkins>	Wait if we're doing realm work can we settle the WebIDL issue that defines the default realms for everything to the correct option so the rest of us don't have to understand the completely opaque differences between each of the terms?
17:40	<annevk>	TabAtkins: unfortunately that's not really a blocker for anyone's goals here (I agree that would be very very good though if it can be made to work)
17:42	<TabAtkins>	Ugh, it's a blocker for the vast majority of specs to have correct (/any at all) realm information, tho at least the current "most specs don't mention it at all, and implementors just do whatever similar things do, which is generally correct" mostly works in practice.
17:46	<annevk>	Yeah that's indeed the status quo for many allocated objects. 😕
22:39	<sideshowbarker>	yeah, to be more clear: I meant just in the context of the markup — the serialized source markup The specific context is https://github.com/validator/validator/issues/1438, where the OP has this markup: `<!DOCTYPE html><html lang=en><title>!</title> <span><slot></slot></span>` … and the checker gives an odd/unexpected message — because the checker sources/schema don’t (yet) know anything about a `slot` element: nothing about where it’s allowed or what content model it might have. (The “Contexts in which element slot may be used: Where phrasing content is expected.” snippet that the OP quotes isn’t from the checker sources/schema but is instead is just some text that we pull and build from a copy of the HTML spec.) And the reason the checker doesn’t know anything about a `slot` element is that the only use case I know of for `slot` is if the markup has `<template>…<slot>…</slot>…</template>` — in which case the `slot` doesn’t get parsed into the document. And so for the purposes of the checker, we never need to know that `slot` exists or care where it’s allowed or what its content model is — because we can’t check it (since the checker checks the parsed document tree, not the markup). So while I could update the checker sources/schema to recognize the `slot` element in `template`-less cases like that `<!DOCTYPE html><html lang=en><title>!</title><span><slot></slot></span>` one, I’m not sure there’s any point in changing anything if there’s no real-world case for ever having slot-with-no-template markup like that.