05:09
<annevk>
jmdyck: has to happen while it runs for it to make sense. It would be clearer if it had the same "must additionally run this step" language as the paragraph below.
10:46
<jmdyck>
What if we just moved the "if" clause to after the "must"?
10:50
<annevk>
jmdyck: sounds okay
12:46
<annevk>
smaug: I found a fun edge case while going through DOM issues: https://github.com/whatwg/dom/issues/977#issuecomment-4935401092
12:52
<smaug>
annevk: inner is some window, I assume
12:53
<smaug>
annevk: what do other browsers do?
12:54
<smaug>
(and Gecko should create wrapper when adopting these days. It just recently changed)
12:55
<annevk>
smaug: Chrome and Safari happen to pass that specific test, but fail a bunch of others from the PR. And if I make WebKit have Gecko-like behavior it'll fail that test. Are you saying that creating wrappers on cross-document adoption is not a perf pitfall I should be afraid of?
12:58
<smaug>
We basically had to change behavior because of webcompat. Oh, but we missed something here
12:58
<smaug>
emilio:
12:59
<smaug>
(This is a very recent change)
12:59
<annevk>
smaug: are you talking about Gecko no longer mutating the prototype on adoption? For some reason I thought that changed long ago.
12:59
<smaug>
That was a recent change
13:02
<smaug>
fix should be easy and fast. The usual worry is keeping the other realm alive. But that happens already in the case there is the js wrapper
13:04
<annevk>
Interesting, that was a 2018 specification decision: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567. I guess whenever cross-document adoption happens the script doing that must have access to some wrappers of both realms already.
13:07
<smaug>
I was equally worried about memory leaks 10 years ago as I'm now 🙂
13:07
<smaug>
Well, maybe I'm more worried these days given the recent bad examples
13:10
<jmdyck>
@annevk: In that same sentence, in the phrase "and each subsequent task, that is queued by the networking task source ...", the comma seems incorrect to me. Shall I delete it?
13:10
<annevk>
If it wasn't for custom elements it could still be interesting to pursue, though I suppose it might not be web-compatible anymore either.
13:11
<annevk>
jmdyck: seems fine. Probably the easiest if you just rewrite as you see fit and then we figure out during review if we need to fine-tune a bit.
13:11
<jmdyck>
ok
13:28
<foolip>
Done!
13:29
<jmdyck>
hm, my PR got "Error: Wattsi server error"
16:46
<bkardell>
it would have been a lot funner if hixie had called it whoopsi instead of whattsi
16:47
<bkardell>
"Whoopsie server error"
17:05
<jmdyck>
What does Wattsi mean, anyhow?
17:48
<bkardell>
I'm really surprised I don't know this myself.. Ian Hickson why'd you call it Wattsi?
18:07
<TabAtkins>
clearly a reference to Watt's Spiny Rat (Maxomys wattsi)
18:11
<dbaron>
Based on https://github.com/whatwg/wattsi/blob/main/src/LICENSE it seems more likely to be a reference to https://en.wikipedia.org/wiki/Anolis_wattsii (if anything)
18:13
<dbaron>
... which is also connected to https://pythonhosted.org/anolis/
18:16
<dbaron>
... the canonical repo for which is probably https://github.com/Ms2ger/anolis
19:46
<bkardell>
Ah nice. My colleague 😀
21:19
<TabAtkins>
And I started working on Bikeshed in Feb 2013, a little before that final Anolis documentation was released.
21:26
<TabAtkins>

It's fun to see what the first features were that caused me to start writing it https://github.com/speced/bikeshed/commit/8c13656909cdc6e7e1ca4eca7a6928835f9403de.diff

  1. markdown paragraphs
  2. propdef blocks
  3. indented pre elements
  4. boilerplate

that's it!