2023-04-03
[07:13:51.0395] <ryzokuken>
Richard Gibson: the tool I tried failed, although I was hopeful since it uses webkit too

[07:14:03.0893] <ryzokuken>
I tried to print it using chrome, let me know what you think

[07:18:05.0396] <ryzokuken>
some tables don't look great

[07:18:12.0424] <ryzokuken>
especially the first one

[07:18:23.0354] <ryzokuken>
so we might need to fix that

[07:18:37.0581] <ryzokuken>
or I could try to find a good webkit-based browser available on my system and try it

[07:34:12.0408] <Richard Gibson>
I'm fine with the first table since it's not actually missing content, but Table 15 (GetOperands) _is_ missing content. Can you try again with custom CSS that includes `table.real-table { overflow-wrap: break-word; }` and `table.real-table td { overflow-wrap: anywhere; }`?

[07:35:03.0625] <Richard Gibson>
that's the only hard blocker I see

[07:42:15.0186] <ryzokuken>
sure we can

[07:44:43.0643] <ryzokuken>
okay now the word breaking is a bit ugly

[07:44:51.0066] <ryzokuken>
but the table is no longer missing content

[09:04:14.0424] <Richard Gibson>
agreed, but all the content is visible so that works for me

[09:18:24.0237] <ryzokuken>
Are you already working on the other changes? If not I could do a quick meta PR later today and then propose the printed version of that (with the added CSS) for the opt-out

[09:28:47.0664] <sffc>
How do we stand on merging the two Stage 4 proposals into ES2023?

[09:30:08.0082] <sffc>
Intl Enumeration looks like it might be mergeable. Intl NumberFormat V3 has been waiting for review since January and has a half-review from Richard.

[10:17:43.0085] <ryzokuken>
thanks for the reminder, Shane 

[10:17:57.0356] <ryzokuken>
https://github.com/tc39/ecma402/pull/716 was indeed waiting on my review and was quite brief. 

[10:18:02.0807] <ryzokuken>
Richard Gibson: can I hit merge?

[10:19:03.0288] <Richard Gibson>
716 was just waiting for you, so good to go after that

[10:19:24.0153] <Richard Gibson>
but we should try to get in NumberFormat V3

[10:19:38.0425] <justingrant>
Last I heard from Richard about Intl.Enumeration, he was only waiting for your review before merging.

[10:19:48.0054] <justingrant>
Jinx

[10:19:59.0885] <ryzokuken>
> <@gibson042:matrix.org> but we should try to get in NumberFormat V3

I'm reviewing it right now


2023-04-04
[09:10:33.0733] <ryzokuken>
okay, done

[09:10:45.0569] <ryzokuken>
ECMA-262 is ready for opt-out, what do we aim to do

[11:26:16.0428] <sffc>
Thanks for the feedback ryzokuken ; I'm responding to it today

[12:05:48.0359] <Richard Gibson>
@sffc there are also some unresolved comments from my first pass:
* https://github.com/tc39/ecma402/pull/753#discussion_r1123431803
* https://github.com/tc39/ecma402/pull/753#discussion_r1123438659
* https://github.com/tc39/ecma402/pull/753#discussion_r1123444050
* https://github.com/tc39/ecma402/pull/753#discussion_r1123447388

[12:07:00.0084] <sffc>
Yep; I plan to resolve them at the same time

[12:07:07.0150] <sffc>
Do you still plan to give numberformat.html another pass?

[13:23:46.0519] <Richard Gibson>
yes, just about done now

[13:33:23.0061] <Richard Gibson>
done

[13:48:52.0531] <justingrant>
Richard Gibson and I opened an editorial PR (https://github.com/tc39/ecma262/pull/3035) for ECMA-262 to refactor how time zone identifiers are handled. Feedback welcome!

The goals of this PR are:

- Clarify/simplify existing 262 text dealing with time zone identifiers (non-402 implementations can use IANA TZDB, so identifier-related text was already in 262).
- Rationalize overlapping spec text between 262, 402, and Temporal. Doing this will simplify 402 now and also make it less disruptive to 262 and 402 spec text when Temporal is merged later.
- Avoid the need for 402 to override 262 AOs relating to time zone identifiers.
- Centralize implementation-defined logic in a smaller number of AOs.
- Add optional recommendations to avoid TZDB footguns. In the future, these recommendations may be changed and/or strengthened as part of [proposal-canonical-tz](https://github.com/tc39/proposal-canonical-tz).
- Make it easier to make changes to identifer-related logic in the future, like what Richard and I are working towards in proposal-canonical-tz. (Although changes in this PR are IMO helpful even if that proposal doesn't move fwd.)

I'd particularly like feedback on a naming thing: Richard is concerned that the terms "canonicalization" and "canonical identifier" are too strong given that canonicalization can change over time in IANA TZDB and because other uses of "canonical" mostly refer to canonicalizing of upper/lower case. So in the PR we're using "resolving" and "primary identifier" instead. If you have an opinion about this term change, then we'd like to hear it.


2023-04-05
[19:14:03.0540] <sffc>
Responded to the NFv3 feedback.

[19:14:43.0083] <sffc>
NFv3 should be ready for a final pass and merging ryzokuken Richard Gibson 

[01:35:06.0380] <eemeli>
sffc: Should the proposal repo for NFv3 mention that it's at Stage-4, or is that not yet technically the case even though it was approved in January?

[01:48:37.0813] <ryzokuken>
> <@eemeli:mozilla.org> sffc: Should the proposal repo for NFv3 mention that it's at Stage-4, or is that not yet technically the case even though it was approved in January?

It's quite certainly stage 4, it's not merged into the spec yet but that doesn't matter so I'll make a PR to that explainer 

[11:36:35.0125] <Richard Gibson>
sffc ryzokuken one final round of commentary on the NFv3 PR: https://github.com/tc39/ecma402/pull/753#pullrequestreview-1373347941


2023-04-12
[06:01:36.0352] <ryzokuken>
Richard Gibson: time to push the meta commit and cut the spec?

[09:24:26.0145] <Richard Gibson>
yes, I think so. I wonder if we should also summarize changes in the Introduction like ECMA-262, but that hasn't happened in many years

[09:48:27.0183] <ryzokuken>
> <@gibson042:matrix.org> yes, I think so. I wonder if we should also summarize changes in the Introduction like ECMA-262, but that hasn't happened in many years

Right

[09:48:35.0480] <ryzokuken>
I mean, I don't have a very strong opinion here

[09:48:59.0028] <ryzokuken>
But maybe since we're already a bit late this year around, why not leave it as if for now and plan ahead for next time?

[09:49:08.0768] <Richard Gibson>
ok, then I guess the path of least resistance is to leave it for now and revisit next year

[09:49:12.0625] <Richard Gibson>
:+1:

[09:49:13.0138] <ryzokuken>
* But maybe since we're already a bit late this year around, why not leave it as is for now and plan ahead for next time?

[09:49:18.0600] <ryzokuken>
Perfect 

[09:49:43.0728] <Richard Gibson>
 * 👍️

[09:50:41.0775] <ryzokuken>
Did you already have the commit ready? I suppose we'll have to branch out, push the commit and then produce the PDF.

[10:04:05.0816] <Richard Gibson>
I can prep it now... should we use today's date?

[10:04:37.0666] <ryzokuken>
I think so? What are our options?

[10:05:32.0134] <Richard Gibson>
¯\_(ツ)_/¯

[10:05:34.0600] <Richard Gibson>
 * ¯\\_(ツ)\_/¯

[10:05:54.0520] <ryzokuken>
let's just go with today's

[10:42:16.0209] <Richard Gibson>
https://github.com/tc39/ecma402/tree/es2023
https://github.com/tc39/ecma402/pull/775

[11:45:17.0903] <ryzokuken>
PTAL and let me know how it looks

[11:45:40.0257] <ryzokuken>
after a while (and hopefully approvals from a few of you) I'll send it out to Istvan

[11:58:51.0677] <Richard Gibson>
LGTM 👍️


2023-04-13
[01:57:38.0038] <ryzokuken>
Given there's no new comments, I'll send it out to ECMA. Thanks!


2023-04-28
[16:31:32.0800] <Chris de Almeida>
https://github.com/tc39/Reflector/issues/469