WHATWG on 2023-02-14

06:41	<zcorpan>	A friend asked if there’s a better way to do this: https://stackoverflow.com/questions/60262041/is-there-a-way-to-get-child-class-file-path-in-parent-class/60262174#60262174 i.e. in constructor() of A get the url of B, without modifying B’s constructor. import.meta.url only gives A.js. It’s possible to catch an exception and get the stack trace, but that’s not ideal :)
06:42	<shark adsm>	acsebility
07:07	<Domenic>	A friend asked if there’s a better way to do this: https://stackoverflow.com/questions/60262041/is-there-a-way-to-get-child-class-file-path-in-parent-class/60262174#60262174 i.e. in constructor() of A get the url of B, without modifying B’s constructor. import.meta.url only gives A.js. It’s possible to catch an exception and get the stack trace, but that’s not ideal :) No, except for the stack trace loophole, there's generally no way to know what file code comes from.
07:08	<zcorpan>	Domenic: thanks. Do you know if that's intentional or something we should add?
07:08	<Domenic>	I think it's semi-intentional in that implementers really hate having to keep that sort of info around for stack traces (for memory reasons)?
07:10	<zcorpan>	but they do keep it around, yes?
07:10	<Domenic>	It's also pretty fragile in the face of bundlers, etc., which are still widely used.
07:10	<Domenic>	I guess they must, for functions at least. Not sure about how things like inlining, etc. effect that.
07:15	<zcorpan>	interesting, maybe there are cases where the engine knows a function can't throw and can drop the stack information. But an API would mean they can't drop it
13:54	<Yagiz Nizipli>	Is there an incentive to improve the toascii.json in web-platform-tests?
13:58	<annevk>	Yagiz Nizipli: you mean in contrast IdnaTestV2?
14:09	<Yagiz Nizipli>	Yagiz Nizipli: you mean in contrast IdnaTestV2? Yes
14:15	<annevk>	Yagiz Nizipli: I dunno, I guess I'd like us to continue to add tests to toascii.json as we come across browser Interop issues. Perhaps if someone was willing to take the initiative to donate them to Unicode and deduplicate them with IdnaTestV2 that would be better, but I'm not sure if that's an easy process.
15:31	<hsivonen>	I have no opinion about the contents of this, but would you be interested in joining one of ECMA-402’s fortnightly calls to discuss with people who might? It would be nice to make a cross-browser decision about unshipping. Thanks for this. The meeting turned up a use case: Instead of the haystack being a long string from which needle would be searched as a substring, the ECMA-402 API can be used if haystack is a list of strings and the operation is to find the list items that match the needle on a full-string basis. So now I'm aware of a potential use case instead of being totally unaware of a use case. I'm still very skeptical of the presented use case arising in JS programs on the Web in practice. The case mentioned was an address book, but with the ECMA-402 API, the user would have to enter a full given name or a full family name instead of being able to enter a prefix of a name.
15:31	<littledan>	hsivonen: Interesting, so is that to say that you didn't reach a shared conclusion one way or another yet?
15:33	<hsivonen>	hsivonen: Interesting, so is that to say that you didn't reach a shared conclusion one way or another yet? No shared conclusion, but I'm still pursuing unshipping search collation data, but now I'm considering unshipping it less fully and adding more special-casing to try to hide the fact that the data isn't there a bit more carefully.
15:35	<hsivonen>	I'm also trying to understand better what the Korean search tailoring in the search root is trying to accomplish. After reading the CLDR source and issues, I had an expectation of what it would do in Chrome's ctrl-f, but I can't get Chrome's ctrl-f to do anything different from Firefox's ctrl-f for Korean.
15:35	<hsivonen>	Next, I'm going to experiment with cmd-f in macOS Finder in Korean to see if something interesting happens there.
17:10	<zero-one>	i'm writing a URL parser that follows the WHATWG URL spec, and i'm wondering how i can shortcut the implementation a little bit if i assume that all input to the parser is already UTF-8 encoded
17:11	<zero-one>	afaict, all codepoints > `0x7F` end up being percent-encoded byte-by-byte anyway
17:11	<zero-one>	so can i just parse byte-by-byte instead of codepoint-by-codepoint?
17:32	<annevk>	zero-one: you'll need special code for host names, but for determining component boundaries that should totally work
17:33	<zero-one>	can you elaborate? is that because of the opaque-host parsing?
17:33	<annevk>	zero-one: the opposite, for domain to ASCII you need a bunch of logic around code points
17:36	<zero-one>	oh, i see... we percent-decode here and then punycode it or something
17:40	<annevk>	Yeah, it's great 😂
17:40	<zero-one>	but as long as i hack around that, there's no other big roadblock to basically ignoring the encoding and just going byte-by-byte?
17:45	<annevk>	zero-one: for UTF-8 inputs, yeah
17:45	<zero-one>	cool
17:46	<zero-one>	thanks for the help, i'm still trying to wrap my head around everything
17:46	<annevk>	Heh. Me too!