| 02:14 | <devsnek> | how come browsers still add new history entries with replaceState? |
| 07:55 | <annevk> | gsnedders: well, W3C still enabled them to do so; I feel like that line of reasoning is too often used to absolve the W3C, which certainly carries a certain amount of authority and power on its own |
| 09:26 | <Ms2ger> | annevk, is https://infra.spec.whatwg.org/#list-contain supposed to be used with an item or an index? |
| 09:55 | <hsivonen> | annevk: Do we care if TextEncoder.encodeInto() can throw on OOM after already having written something to the provided buffer? |
| 09:57 | <hsivonen> | annevk: OOM can occur due to JS engine-internal bookkeeping when the input string is a rope |
| 09:57 | <hsivonen> | annevk: I _could_ make it so that all memory is allocated up front and OOM is thrown before anything is written, but that would be a tiny bit slower for the non-OOM case |
| 10:00 | <hsivonen> | how recoverable are OOM exceptions in JS anyway? |
| 10:02 | <annevk> | Ms2ger: either I think |
| 10:03 | <annevk> | hsivonen: JS OOM is undefined behavior unfortunately |
| 10:03 | <hsivonen> | annevk: not in the C sense, I hope |
| 10:03 | <annevk> | hsivonen: there’ve arguments that it should crash the agent cluster |
| 10:04 | <hsivonen> | annevk: I guess that means that it's OK to have written something in the buffer then |
| 10:04 | <annevk> | hsivonen: until OOM is defined, yes |
| 10:05 | <hsivonen> | annevk: thanks |
| 12:35 | <gsnedders> | hsivonen: OOM exceptions are… sometimes recoverable in JS? |
| 12:35 | <gsnedders> | hsivonen: normally with things that allocate big chunks |
| 12:36 | <gsnedders> | Things that cause smaller allocs should in theory be recoverable in all major VMs, AFAIK, but then you get into rarely tested OOM branches. |
| 12:37 | <gsnedders> | hsivonen: in general things like TextEncoder.encodeInto() are kinda undefined if they OOM during the operation |
| 13:06 | <hsivonen> | gsnedders: OK. In this case, chances are the OOMing allocation would not necessarily be huge. could be 128*sizeof(void*) or any double of that |
| 13:06 | <gsnedders> | hsivonen: yeah, I wouldn't worry too much about behaviour in that case provided it is safe |
| 14:34 | <JakeA> | TabAtkins: ta, that worked |
| 21:25 | <zcorpan> | MikeSmith: "From the W3C specification for the Anchor tag:" https://www.bennadel.com/blog/3693-anchor-tags-can-contain-block-level-elements-as-of-html5.htm |
| 21:25 | <zcorpan> | points to http://w3c.github.io/html-reference/a.html#a-changes |
| 21:26 | <zcorpan> | maybe that needs a warning banner |
| 21:54 | <MikeSmith> | zcorpan: I thought I had already set up a redirect for that.. |
| 21:55 | <zcorpan> | MikeSmith: the w3.org url redirects. not the w3c.github.io |
| 21:55 | <MikeSmith> | Ok |
| 21:55 | <MikeSmith> | I'll fix it today |