WHATWG on 2023-07-25

00:32	<Domenic>	Because I prefer Bikeshed being robust to failure as much as possible, so you can run with `-f` and still get something reasonable rather than forcing people to have a fully working build. (That is, the messages are intended to be lint-level as much as possible; it's of course reasonable to require zero linting errors to publish/update.) That implies I want visibility into the build result regardless. It is just also the case, again, that I should be capturing the messages so I know when I'm throwing more or different errors than I previously did. Like I said, this is going to be fixed. But again, this is about WHATWG specs. THey don't prefer to be robust to failure; they prefer to fail-fast (like your new HTML parser). We're asking that you reflect that in your test suite, so your test suite gets the same failures as the actual live environment.
00:34	<TabAtkins>	Capturing the build messages will accomplish the same thing (any messages at all are bad for whatwg specs) without making me lose output entirely when there's a change in build messages.
00:34	<TabAtkins>	The thing you're actually asking for (ensure that new messages don't break your build) is on my task list this quarter.
00:49	<Domenic>	I just think there's a lot to be said for having tests match prod
14:09	<KBar>	Hello. I hope this is my last cross-post. I was pointed to this room to ask my question.
14:10	<KBar>	i should probably raise this to whatwg, but i was wondering why are user agents required to load `about:blank` in quirks mode? is there a specific reason? if not, shouldn't step 2 of loading an HTML document include something like Let doctype be the result of creating a document type with the qualified name of "html" … 5 Append doctype to document. or similar steps?
14:16	<Ms2ger>	The answer to "why" is "because that's what browsers have done historically"
14:17	<Ms2ger>	The answer to "and why did they do that" is that that's the result of parsing an empty byte stream (i.e., without a doctype) as html
14:44	<Sam Sneddon [:gsnedders]>	And the answer to "why don't they change that" is it seems relatively risky to change for a relatively small gain.
15:02	<KBar>	The answer to "and why did they do that" is that that's the result of parsing an empty byte stream (i.e., without a doctype) as html Isn't it still populated with `html/head/body`? There doesn't seem to be any parsing done within this branch. That answer doesn't sound plausible to me. Could it have been just an oversight?
15:08	<Ms2ger>	Try feeding an empty html document to your favourite browser and you'll see that it does indeed get html, head and body elements
18:39	<jgraham>	I think if you ask hsivonen or someone else who's worked on this they might s/relatively risky/very risky/ or maybe just say "totally unworkable given webcompat constraints"
18:43	<emilio>	For what is worth, I think inheriting about:blank quirk-ness for frames and popups could be nice. I've seen site bugs related to that. But yeah rather risky, because `document.write()`-ing inside an `about:blank` document is rather common
18:44	<emilio>	I think I'd take or write a patch to firefox to do that behind a pref to investigate compat, if others think it's worth the effort
18:44	<emilio>	But should probably be a cross-vendor effort, and maybe a hill not worth spending resources on
18:45	<emilio>	But yeah hsivonen (away from Matrix until 2023-08-07) would probably have more context