2023-08-02 [15:44:28.0695] shu: oh, the other reason I care about things being in TC39 instead of WHATWG is that WHATWG has an IMO completely batshit policy of restricting all new things to secure contexts [15:44:37.0666] this rendered randomUUID completely unusable, for example [15:45:02.0588] (https://github.com/WICG/uuid/issues/23) [15:45:39.0463] i see 2023-08-03 [14:02:47.0006] ljharb: https://github.com/tc39/ecma262/actions/runs/5664165524/job/15603200826?pr=3131 fails the IPR check, but I think only because it needs to be rebased [14:03:42.0992] it is otherwise ready [14:05:17.0821] bakkot: we are getting ready to ship to set methods proposal. test262 would be nice, else we'll upload our tests to staging [14:24:03.0949] shu: https://github.com/tc39/test262/pull/3816 is all I've got for you [14:24:24.0142] not yet updated for https://github.com/tc39/proposal-set-methods/pull/101 and https://github.com/tc39/proposal-set-methods/pull/88 though [14:25:23.0090] if you are writing your own tests, https://github.com/tc39/test262/issues/3738 lists the cases I thought of [14:25:38.0221] I will try to get time to get test262 tests for the rest of the methods soon [14:43:33.0523] > <@bakkot:matrix.org> ljharb: https://github.com/tc39/ecma262/actions/runs/5664165524/job/15603200826?pr=3131 fails the IPR check, but I think only because it needs to be rebased Thanks, I’ll do a sweep in the next 24 hours or so [14:58:57.0399] bakkot: sgtm, we'll wait 2 weeks or so for fuzzing anyhow 2023-08-06 [06:26:20.0749] I just noticed that my PR #3063 un-defined ids like "thisbooleanvalue" (which have been around since the merge of #2103, about 3 years ago). Would you like me to file a PR to reinstate them as oldids on "sec-thisbooleanvalue" etc? 2023-08-07 [16:22:24.0659] jmdyck: sure, that would be nice 2023-08-08 [18:06:07.0485] bakkot shu for your consideration: https://github.com/tc39/ecmarkup/pull/542 [18:06:58.0153] does that work for every kind of thing which can be referenced? [09:11:36.0796] I think so? [09:22:19.0739] bakkot: it does now: https://github.com/tc39/ecmarkup/blob/ed43098ecc208aab3d5866f831d688419de9541a/js/menu.js#L232-L255 [09:55:38.0262] sure why not [09:56:06.0758] i don't think i really look at that name in any case but this is better than the id [09:59:57.0189] thoughts on changing the text selection colour to something more ECMA-y? [10:00:28.0587] oh god no [10:00:42.0393] lol k [10:00:45.0800] please never mess with text selection color unless you've also messed with background color [10:00:58.0108] also don't mess with background color in this instance [10:01:26.0736] "make things more ECMA-y" is not a sentence i want to hear 2023-08-11 [15:00:18.0202] ljharb: do you know what these lines in package.json are about? https://github.com/tc39/ecma262/blob/c316ec72f6e227d88d4ef67a3e16b486c5ca356d/package.json#L8-L10 [15:00:24.0739] we haven't used travis in a long long time, have we? [15:01:13.0052] yeah i just kept the scripts [15:01:35.0581] i think we can remove them at this point since we have other ways of testing the build [15:01:53.0021] ok cool [15:02:07.0506] I ask mostly because they're still using the old `--js` flag to ecmarkup, which I am maybe going to rip out [16:40:54.0797] JS ⇒ 🗑️ 2023-08-12 [14:57:34.0373] re Delegates room: Maybe the process I used to convert 262 to ecmarkup would work on 404. 2023-08-13 [15:06:30.0239] that'd be great [15:06:47.0269] it's not hard, it's just a bunch of manual tedious work, so i haven't made time for it 2023-08-16 [15:41:53.0866] https://github.com/tc39/ecma262/pull/3140 is also ready to go if someone wants to stamp it [15:41:59.0008] Michael Ficarra ^ [15:48:15.0529] I still don't love the choice of alias names, butsure 2023-08-29 [13:35:38.0818] we need an editor call label for ecmarkup 2023-08-30 [18:24:49.0742] I'm all caught up on my editor reviews [18:24:58.0100] if you think something else needs my review, let me know [05:55:35.0260] Thanks for reviewing mine. There's also 2886, which is pretty straightforward. [16:38:43.0050] shu: regarding the kebab-case lint, are you OK with continuing to have things like `~key+value~` or `100%` or whatever? [16:38:58.0756] or do you want specifically letters-or-numbers [16:39:20.0429] because I personally am fine with `~key+value~` but Michael Ficarra thinks we agreed not to do that [16:40:23.0721] bakkot: i am also fine with `~key+value~` [16:41:03.0212] my position is more accurately "lowercase, breaking up words with punctuation instead of capitalization" than kebab-case [16:43:16.0923] shu: what about things like emoji, uncased letters, and logographs? [16:43:38.0989] i don't know why they would come up [16:43:43.0653] I don't necessarily want those but I don't care to lint against them [16:44:11.0750] we're trying to figure out whether we consider the rule to be "no uppercase letters or space" or "lowercase letters and numbers split by some punctuator" [16:44:36.0399] the former would permit those things, while the latter would not [16:44:52.0141] i think the former? [16:45:24.0553] like it's a lint, if it filters out most of the cases we'd reject, there's still a human reviewing if we come up against a case we didn't think of that we don't like [16:46:05.0452] sure for our use case, it's not like the input is malicious [16:46:16.0984] but we do have to consider the 402 others and potentially other users [16:46:30.0600] * but we do have to consider the 402 editors and potentially other users [16:46:41.0089] that more convincingly argues for the former, no? 2023-08-31 [07:11:05.0057] > <@michaelficarra:matrix.org> but we do have to consider the 402 editors and potentially other users as a 402 editor, I look forward to replacing the camelCase spec enums and am generally in favor of aligning guidance and lint behavior. These values are all arbitrary anyway; we can and should remove any gap between "allowed" and "machine-verifiable" [07:12:17.0044] > <@michaelficarra:matrix.org> but we do have to consider the 402 editors and potentially other users * as a 402 editor, I look forward to replacing the camelCase spec enums and am generally in favor of aligning guidance and lint behavior. These values are all arbitrary anyway; we can and should remove any gap between ~~"allowed"~~ "well-formatted" and "machine-verifiable" [07:12:21.0669] * as a 402 editor, I look forward to replacing the camelCase spec enums and am generally in favor of aligning guidance and lint behavior. These values are all arbitrary anyway; we can and should remove any gap between ~"allowed"~ "well-formatted" and "machine-verifiable" [07:12:28.0439] * as a 402 editor, I look forward to replacing the camelCase spec enums and am generally in favor of aligning guidance and lint behavior. These values are all arbitrary anyway; we can and should remove any gap between "well-formatted" and "machine-verifiable"