2026-06-01 [08:04:54.0452] I always assumed that the spec cycles though decimal, alphabet, roman steps indefinitely but it looks like after six nesting levels it just uses roman - why is that? [08:05:05.0815] e.g. GDI step 12 [08:09:51.0232] I've got some comments on PR #3802 (but I haven't finished my analysis), so you might not want to merge just yet. [08:12:56.0160] linus: That might just be an artifact of how MS Word worked. [08:34:02.0636] yep, I think we just matched MS Word when we converted it [08:36:38.0814] https://github.com/tc39/ecmarkup/blob/82954937fa8b14f6b3a9a7067e52d3fc738c6295/css/elements.css#L484-L520 [08:38:19.0942] fun [08:38:56.0828] are we fine with adding css to cover whatever the current max nesting level is or not worth it? [08:41:19.0231] I'm fine with it. But even better would be never going so deep at all. [08:43:57.0922] what do you mean by adding CSS to cover? [08:44:03.0913] the CSS already does cover that, I linked it [08:44:34.0750] adding more css so it doesn't give up after 7+ [08:45:06.0501] or somehow letting the browser do the % 3 logic automatically [08:47:50.0680] I think I'd probably prefer not to change the step numbering scheme without a better reason [08:48:07.0603] it'd be unfortunate to break references to particular steps that people may have in code or documentation [08:49:48.0291] such references break all the time through editorial refactoring already [08:50:42.0743] yeah but I consider that "good reason" [08:51:07.0850] you just want it to loop through the different numbering schemes? [08:51:53.0715] yeah, that's what i assumed it does anyway, i never noticed it has a limit where it stops looping [08:52:06.0859] I'm writing myself a tool that needs to imitate nested spec rendering and got that part wrong [08:53:28.0305] i'm fine with hardcoding this constraint but wanted to at least bring it up beforehand :) [09:00:36.0021] I can see merits to both choices, so if you feel strongly, I wouldn't oppose it [09:13:58.0442] looks like current word and gdocs limit to 9 nesting levels but cycle until then - given our max level is 8 (GDI, EDI) i'd adjust the styles to support that but not more [09:14:05.0326] don't feel strongly about it tho [09:14:56.0402] would you change any step numbers that are nested less than 8 levels? [09:15:08.0651] or just the ones that are extremely deeply nested? [09:15:49.0708] level 7 turns from roman into decimal [09:16:13.0267] everything before that already renders "as expected" [09:33:26.0274] eh, yeah I guess it'd be an overall win [10:34:14.0483] is https://github.com/tc39/ecma262/pull/3875 ready for merging too? i'll go through the queue this afternoon [11:34:15.0999] for discussion at editor call: https://github.com/tc39/ecmarkup/pull/699 2026-06-02 [13:55:03.0185] just noticed that IteratorZip is affected by this 😅 [13:56:26.0647] oh yeah, easily [13:56:48.0432] we go 9 layers deep 2026-06-03 [21:23:40.0832] re PR #3885, I think we need an ecmarkup lint to detect when a section should have a `type` attribute but doesn't. Problem is detecting when it should. One heuristic: if it directly contains an ``, then it should probably have a `type`. Currently 24 exceptions. If we gave `type` attributes to those 24 (e.g. `type="shorthand"`), then the lint would work. [21:24:07.0058] (Or we could give a `type` to every section, but that's a bigger job.) [21:25:04.0745] * re PR #3885, I think we need an ecmarkup lint to detect when a section should have a `type` attribute but doesn't. Problem is detecting when it should. One heuristic: if it directly contains an ``, then it should probably have a `type`. Currently 24 exceptions. If we gave `type` attributes to those 24 (e.g. `type="shorthand"`), then we could use that criterion for the lint. [02:24:44.0203] I like the spirit, but I don't like adding a `type=` for no reason other than to mark it for exclusion from an ecmarkup heuristic [04:14:53.0835] so make up a better reason then [05:22:19.0317] It's not the *only* reason, it's just the reason that's relevant to 3885. [06:26:15.0501] if we gave a type to the macros like IfAbruptCloseIterator, that plus "h1 contains parentheses" would have no false positives [06:26:27.0556] * if we gave a type to the macros like IfAbruptCloseIterator, that plus "h1 ends with parentheses" would have no false positives [06:29:43.0292] Depends how you feel about ` B.1.2.9 Static Semantics: ParsePattern ( _patternText_, _u_, _v_ )` I'd call that a true positive though. [06:30:26.0124] ah, my selector did not include emu-annex 2026-06-04 [04:08:01.0639] travelling today; i'll try to join the call but don't wait for me if i can't make it [08:02:11.0605] [@michaelficarra:matrix.org](https://matrix.to/#/@michaelficarra:matrix.org) joining? 2026-06-06 [17:02:17.0519] Editorial-Conventions 'Comparisons' used to have an "(except in asserts)", then 3844 took it out. Was that intentional? (Asking before I change my code.) [17:53:32.0477] No, we generally don't apply the same editorial conventions to asserts, including comparisons. We should add the exception back. [17:56:10.0759] we should first check if there are any cases where it matters. But I'd personally be fine with e.g. `Assert: _x_ = 0`, and suspect we already have steps like that [18:03:40.0545] Why not apply the same editorial conventions to asserts? [18:06:51.0508] Sometimes things like "When x is y, some invariant holds" read better than "When x = y, ...", even though the latter would be mandated if our conventions apply. [18:07:10.0884] or god forbid SameValue [21:55:40.0430] so it turns out there's a couple handfuls of assertions that would be in scope for this, but honestly most of them read just fine to me with =/≠. Here are some examples that would change: * Number.prototype.{toExponential,toFixed}: `If _fractionDigits_ is *undefined*, then _fractionCount_ is 0.` → `If _fractionDigits_ is *undefined*, then _fractionCount_ = 0.` * {Array,%TypedArray%}.prototype.{includes,indexOf}: `If _fromIndex_ is *undefined*, then {_startIndex_,_n_} is 0.` → `If _fromIndex_ is *undefined*, then {_startIndex_,_n_} = 0.` * DecodeFinalBase64Chunk: `_chunkLength_ is 3` → `_chunkLength_ = 3` * The Abstract Closure Specification Type: `_value_ is 42` → `_value_ = 42` * CreateJSONParseRecord: `_valueLength_ is _length_` → `_valueLength_ = _length_` In fact, the only two cases that I think would be made worse by such a switch are in Decode and RegExp.escape: `The length of {_octets_,_hex_} is {_n_,2}` → `The length of {_octets_,_hex_} = {_n_,2}`. I'd be willing to narrowly scope an exception for those (_something like "the length of … is …"_), or alternatively just refactor them away as e.g. `_octets_ has exactly _n_ elements`/`_hexLength_ = 2`. 2026-06-11 [08:08:06.0990] my prior meeting is running late, but I should still be able to join 2026-06-18 [17:29:22.0529] so it took me just about the whole work day to complete my review of 1 of the 14 Temporal sections [17:29:28.0482] this is going to take forever [17:29:50.0795] my boss isn't going to be super happy if I spend 3 weeks reviewing a single ECMA262 PR lol [13:00:57.0377] @gibson042:matrix.org do you also want us using `’` instead of `'` for possessives (e.g. `date’s` in Temporal)? [13:01:37.0622] * @gibson042:matrix.org do you also want us using `’` instead of `'` for possessives (e.g. "position of the date’s year within its era" in Temporal)? [14:43:03.0628] straight quotes are typographically incorrect in prose, so I’d hope so [15:34:59.0937] I think I'd like that, but detection and/or auto-fixing could be challenging [15:36:33.0174] well maybe open an issue to track it then [15:37:06.0587] `/\w'(s|es)\b/`? [15:37:10.0603] well, maybe _detection_ might not be too bad... I think U+0027 APOSTROPHE (`'`) would always be invalid in non-code text [15:37:14.0304] * `/\w's\b/`? [15:38:00.0586] but auto-fixing would be challenging because it sometimes represents half of a quoting pair and other times an actual apostrophe [15:38:24.0997] we use single quotes for things in ecma262? [15:39:09.0027] I don't think _we_ use them, but they could nevertheless appear in e.g. an excerpt from something that we reference [15:40:09.0695] that sounds unlikely [15:40:50.0229] * `/\w's\b/`? I forgot how english works [15:51:09.0371] in ECMA-262, I see lots of `'s` possessives, many contractions (`don't`/`we've`/etc.), some bare plural possessives (`workers'`, `events'`), and one year group (`OOPSLA '97`), all of which I think can be replaced with U+2019 RIGHT SINGLE QUOTATION MARK (`’`) in ECMA-402, I see similar possessives and contractions, along with one use of `'` for quoting that can be replaced (in [CanonicalizeUValue](https://tc39.es/ecma402/#sec-canonicalizeuvalue): «recommended that implementations use the 'u' extension data») [15:52:58.0917] so I suppose we could just have auto-formatting replace every non-code `'` with `’` [16:02:27.0942] https://github.com/tc39/ecmarkup/issues/703 2026-06-22 [12:50:16.0546] i have to drop after 30mins of the editor meeting today [14:57:55.0071] sorry for missing today; work intruded [15:12:54.0122] no worries, we just talked about some of my feedback on the temporal PR [15:12:58.0234] see recent comments for conclusions 2026-06-23 [17:13:11.0507] we *really* need to get rid of the Terms and Definitions section, it is actively harmful 2026-06-24 [04:05:01.0572] [ljharb](https://matrix.to/#/@ljharb:matrix.org) any chance we could get #3000 merged? it's free of conflicts right now :) 2026-06-25 [06:01:23.0285] editor meeting in 2 hours? [06:46:44.0020] yes [07:09:01.0164] I may be late to the call. [08:03:00.0774] Meeting time! [08:55:38.0017] @nicolo-ribaudo:matrix.org yeah seems like we should start looking at the agenda for things that need review next week, and we'll prepare our slides the week after [09:03:36.0968] https://github.com/tc39/ecmarkup/pull/704 is green and approved; should I go ahead and merge now? 2026-06-26 [18:50:24.0921] At the end of https://tc39.es/ecma262/#sec-asyncblockstart, there's a Note about the possible sources of `_result_`. What I don't understand is, if it's coming from Await, how do you know it's `~unused~`? (Seems more like it would have to be an ES lang value.) [18:59:26.0848] it's actually `empty` not `unused` afaict [18:59:50.0889] but by "coming from Await", it means coming from (what is now) RunCallerContext step 4 [19:00:15.0995] which Await invokes in its step 8, passing `empty` https://tc39.es/ecma262/multipage/control-abstraction-objects.html#await [19:01:34.0529] I think Await should probably be passing `unused` there [19:04:11.0182] it used to in the 2022 edition, got changed sometime between then and 2023, let me see [19:05:58.0924] AsyncBlockStart used to use `*undefined*` [19:06:32.0330] what I mean is, https://tc39.es/ecma262/2022/multipage/ecmascript-data-types-and-values.html#await step 10 is `unused` [19:06:53.0873] whereas https://tc39.es/ecma262/2023/multipage/control-abstraction-objects.html#await step 10 passes `empty` [19:10:54.0920] changed in https://github.com/tc39/ecma262/pull/2665 [19:11:09.0825] Let me see... [19:16:13.0521] When AsyncBlockStart invokes RunSuspendedContext, there's a transfer of control to asyncContext, and this note is saying that the only way control can transfer back is via Await's call to RunCallerContext, or via completion of the closure above (if there's no call to Await). [19:16:25.0310] * When AsyncBlockStart invokes RunSuspendedContext, there's a transfer of control to asyncContext, and this note is saying that the only way control can transfer back is via Await's call to RunCallerContext, or via completion of the closure above (if there's no call to Await)? [19:16:40.0344] correct [19:17:18.0675] and that in both cases, the value which is passed when doing that transfer of control is supposed to be `unused`, except that in Await it's actually `empty` as of the above PR [19:17:35.0544] What prevents some other call to RunCallerContext? [19:18:20.0196] the only other caller is Yield, I think? and, uh, probably nothing, I suspect that sentence predates async generators [19:19:05.0962] (and so became incorrect when it was added) [19:19:44.0820] oh, no, async generators use AsyncGeneratorStart [19:20:17.0825] so, what prevents it is that the only callers are Await and Yield (+variants), and AsyncFunctionStart is not used to invoke things which can Yield [19:20:23.0954] * so, what prevents it is that the only callers of RunCallerContext are Await and Yield (+variants), and AsyncFunctionStart is not used to invoke things which can Yield [19:27:54.0357] RunCallerContext is invoked by GeneratorYield, AsyncGeneratorYield, and Await. So is it true that - GeneratorStart's closure can only call RCC via GeneratorYield, - AsyncGeneratorStart's closure can only call RCC via AsyncGeneratorYield, and - AsyncBlockStart's closure can only call RCC via Await ? [19:33:31.0728] yes [19:33:40.0283] or, no [19:33:47.0260] AsyncGeneratorStart can also call it via Await [19:33:48.0589] but otherwise yes [19:34:01.0468] ok [19:35:05.0713] AsyncBlockStart's closure can result in more than one call to Await, right? [19:35:44.0507] correct [19:36:12.0001] but only the first one returns to AsyncBlockStart [19:36:36.0610] subsequent ones return control to... whatever transferred control to them in the first place, which is usually the promise machinery I believe [19:37:11.0734] * subsequent ones return control to... whatever transferred control to them in the first place, which is usually (possibly always?) the promise machinery I believe [19:37:55.0564] hm. [19:38:30.0990] And is that machinery prepared to receive `~unused~` from Await's RCC? [19:39:12.0584] sorry, currently `~empty~`, but you're suggesting change to `~unused~` [19:39:17.0304] well, it already receives ~unused~ from AsyncBlockStart step 1.i (assuming there was at least one Await), so I would hope so [19:39:33.0462] but I'd need to figure out what that machinery actually is to confirm [19:41:23.0743] oh, it's just the Await steps 2.b and 5.b [19:41:25.0507] which ignore it [19:41:31.0490] > b. NOTE: The Completion Record returned by RunSuspendedContext is intentionally ignored. [19:41:49.0691] so, yes, they are indeed so prepared [19:46:54.0152] I'm looking at the return types of RunCallerContext and RunSuspendedContext, which is the type that can be "passed back" by each's transfer of control. [19:47:52.0257] Or *should* be that type, but isn't currently. [19:51:37.0735] For RunSuspendedContext, it looks like the proper return type is a throw comp or a normal comp containing ES lang value or ~empty~ or ~unused~. [19:53:00.0648] For RunCallerContext, throw comp or return comp or normal comp containing ES lang value or ~empty~ [19:53:44.0136] afk [20:03:09.0432] that sounds right, though presumably Await should be fixed so it uses `unused` instead of `empty`, and then RunSuspendedContext would no longer include Normal Completion containing `empty`, yes? [20:24:04.0443] yeah, I think so. [20:27:52.0049] really I ought to have finished https://github.com/tc39/ecma262/pull/2429 instead of closing it [20:27:55.0991] I will re-do the relevant bits [20:28:23.0462] and I guess include the other stuff we've been discussing [20:29:21.0932] I was going to put it in 2962 [20:33:27.0251] but I guess it could be a standalone PR [20:53:00.0794] opened https://github.com/tc39/ecma262/pull/3896 [20:53:39.0887] generally easier to review things as individual PRs than a whole bunch of changes in one PR [20:53:47.0634] at least when they are logically independent [21:29:23.0508] okay with me, i just hope it doesn't slow things down. [21:30:53.0561] I'd split 2962 into ~4 PRs if I thought it would speed things up, but I doubt it would. [21:32:55.0238] or maybe it would, i dunno [21:33:24.0754] opinions, editors? [21:34:27.0219] smaller PRs would probably speed things up, yes [09:42:22.0881] I canceled the editors meeting that overlapped with plenary next month. the Monday editors meeting remains. should that one be canceled as well? [09:42:40.0226] * I canceled the editors meeting that overlapped with plenary next month. the Monday editors meeting remains (occurs after plenary that day). should that one be canceled as well? [09:45:39.0497] yes, no editor meetings the week of plenary 2026-06-27 [00:57:39.0831] Given that there is one person raising some concern about the normative change in https://github.com/tc39/ecma262/pull/3728 (i.e. requiring the global object creation to be infallible), we should probably briefly present it to plenary for consensus rather than considering it "within editorial discretion" 2026-06-29 [16:20:26.0947] @ljharb:matrix.org Can we get this one merged soon? https://github.com/tc39/ecma262/pull/3895 CI is broken