WHATWG on 2021-06-29

12:44	<sideshowbarker>	Domenic: would be good to have you take a look at https://github.com/tabatkins/bikeshed/pull/2094 when you have time
12:45	<sideshowbarker>	basically, for domintro sections, it causes Bikeshed to output `-dev`-suffixed IDs in the same way as we do for the HTML spec
12:49	<sideshowbarker>	however, unlike what we do for the HTML spec — which relies on hardcoding `subdfn` attributes (and which we anyway added for a different purpose, for preserving link targets in the developer version) — that Bikeshed patch doesn’t require any new markup in the spec source; instead it does it solely based on the presence of a `class=domintro` ancestor
12:53	<sideshowbarker>	if it were to turn out that doing it solely based on the presence of a `class=domintro` ancestor doesn’t actually ensure stable `-dev` IDs for the stuff we want, then I guess we would need to add some hardcoded attributes in the spec sources — but from testing I’ve done thus far, it seems like it’s not in fact going to be necessary to change the spec sources at all
13:41	<Ms2ger>	Hm, wiki.whatwg.org still links to IRC if you're not logged in
15:00	<Domenic>	Hm, wiki.whatwg.org still links to IRC if you're not logged in Oh, interesting, I probably messed up the caching config. Thank you for finding that.
15:05	<Domenic>	basically, for domintro sections, it causes Bikeshed to output `-dev`-suffixed IDs in the same way as we do for the HTML spec This seems really cool and elegant!
15:05	<sideshowbarker>	we’ll see what tabatkins thinks of it
15:05	<Domenic>	Oh, interesting, I probably messed up the caching config. Thank you for finding that. Cannot reproduce across a couple computers...
15:49	<Domenic>	Oh, that message, I thought you meant the sidebar or homepage links
15:52	<Domenic>	I fixed https://wiki.whatwg.org/wiki/MediaWiki:Anonnotice but now I think there's some caching issue...
15:54	<Ms2ger>	`?action=purge` fixes it, thanks
16:32	<bakkot>	does anyone know how the TextEncoder interface came to be so... java-y, instead of just like `TextEncoder.encode('string')`? I think that every single time I have ever constructed a TextEncoder or TextDecoder it has been to invoke a single method on the new instance and then discard it
16:37	<Luca Casonato>	bakkot I assume to mirror the decoder interface which is stateful because it is capable of streaming? It would be nice to have a static method on `TextEncoder` / `TextDecoder` for single use encoding...
17:58	<bakkot>	bleh. the stream transformer usage is fundamentally pretty different, it seems a shame they were conflated in TextEncoder
17:58	<bakkot>	ah well
19:33	<Domenic>	+1 to a static method. A bit dangerous people will use a sequence of static method calls when they should use the stateful instance, but probably worth it on the balance.
19:38	<Luca Casonato>	I'll open a spec issue
19:49	<Luca Casonato>	https://github.com/whatwg/encoding/issues/267
22:26	<bakkot>	+1 to a static method. A bit dangerous people will use a sequence of static method calls when they should use the stateful instance, but probably worth it on the balance. is the instance actually stateful in any way other than holding onto its options bag?
22:26	<Domenic>	Yes it can hold half of a surrogate pair
22:27	<Andreu Botella (he/they)>	Yes it can hold half of a surrogate pair No, `TextEncoder` doesn't have a streaming mode
22:27	<Andreu Botella (he/they)>	`TextDecoder` does keep the decoder state in streaming mode though
22:28	<bakkot>	That's `TextDecoderStream`, right?
22:28	<bakkot>	not actually `TextDecoder` itself?
22:28	<Domenic>	TextDecoder itself
22:28	<Luca Casonato>	See the stream option on .decode
22:29	<Domenic>	The danger is people will think because it's safe with TextEncoder, it's safe with TextDecoder. Or they will just always use the static method with TextDecoder for one-shots (where it's OK) but then carry over that experience to use it for chunks of a larger byte stream (where it's not)
22:29	<bakkot>	oh, right, I forgot the decoder is not the same as the encoder here
22:30	<Domenic>	i.e. `let str = ""; while (hasBytes()) { str += TextDecoder.decode(getBytes()); }` is very bad.
22:30	<Andreu Botella (he/they)>	`const decoder = new TextDecoder(); console.log(decoder.decode(new Uint8Array([0xC3]), {stream: true})); // "" console.log(decoder.decode(new Uint8Array([0xA1]))); // "á"`
22:30	<Luca Casonato>	The danger is people will think because it's safe with TextEncoder, it's safe with TextDecoder. Or they will just always use the static method with TextDecoder for one-shots (where it's OK) but then carry over that experience to use it for chunks of a larger byte stream (where it's not) Feel like we already have this though as stream: true is not the default.
22:30	<Domenic>	Yeah fair point
22:30	<Luca Casonato>	People should just use the whatwg stream variant anyway 🙃
22:31	<Luca Casonato>	(Cough cough Firefox)
22:35	<bakkot>	manually feeding items to a stream is a bit annoying IIRC
22:35	<bakkot>	but yeah does seem like using a stream for that case seems better than having a `stream` option
22:37	<Luca Casonato>	manually feeding items to a stream is a bit annoying IIRC TextDecoderStream is a TransformStream style API with a readable and writable, so should be as easy as `writable.write(chunk)`
22:38	<Luca Casonato>	Or if you already have a ReadableStream (for example a fetch response body or Blob) you can just call .pipeThrough on it 🙂
22:39	<bakkot>	`> (new TextDecoderStream).write undefined` hmmmm nope
22:39	<bakkot>	well, right, if you have streams already gluing them together is pretty easy, but I rarely do
22:39	<Luca Casonato>	new TextDecoderStream().writable.write
22:40	<bakkot>	`> new TextDecoderStream().writable.write undefined`
22:40	<Andreu Botella (he/they)>	`new TextDecoderStream().writable.getWriter().write("something")`
22:41	<Luca Casonato>	`new TextDecoderStream().getWriter().write("something")` Oh right. Would it make sense to have a utility method that locks, writes, unlocks?
23:32	<timothygu>	Domenic: is ObservableArray being used anywhere? I thought I remembered some usages in Typed OM but I can't find it there or in Chromium
23:33	<Domenic>	timothygu: still being implemented, but in spec the usage is intended as https://github.com/WICG/construct-stylesheets/pull/117
23:34	<Domenic>	Oh right. Would it make sense to have a utility method that locks, writes, unlocks? Probably. https://github.com/whatwg/streams/issues/1072
23:59	<Adam Rice>	I think `writable.write("something")` is okay, but generally I prefer the (also not specified) syntax `ReadableStream.from(["something"]).pipeTo(writable)` because it also closes the stream for you.