Temporal proposal HTML serialization support

[littledan]

This patch lets Temporal objects be serialized, both in storage and with
postMessage, if they use built-in calendars and timezones. This is the
only expected integration of Temporal with HTML/DOM expected initially;
see earlier discussion in w3ctag/design-reviews#311

The current draft just includes Temporal.PlainDate, and it will be extended
to all of the Temporal types after initial review. This patch should not be
landed until (at least) Temporal reaches Stage 3.

• At least two implementers are interested (and none opposed):
  • Temporal - structured clone mozilla/standards-positions#1045
  • Temporal - structured clone WebKit/standards-positions#368
• Tests are written and can be reviewed and commented upon at:
  • Add tests for structured cloning of Temporal objects web-platform-tests/wpt#46865
• Implementation bugs are filed:
  • Chrome: https://issues.chromium.org/issues/349393391
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1904790
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=275897

(See WHATWG Working Mode: Changes for more details.)

---

/infrastructure.html ( diff )
/structured-data.html ( diff )

[littledan]

The changes that @Ms2ger made to include all appropriate Temporal objects and serialize exclusively built-in things LGTM. AFAIK, these are all the changes needed to integrate Temporal into HTML.

[domenic]

I rebased this and fixed some editorial nits. It LGTM but needs implementer interest (probably we have it through the TC39 process?) and, most importantly, tests.

[domenic]

Calendar user code thread seems to not yet be resolved?

[domenic]

OK cool. Just waiting on tests, implementer interest, and browser bugs then before we can merge.

[Ms2ger]

I updated this to match the consensus from the 102nd TC39 Meeting (12 June), notably dropping Calendar and TimeZone objects. (These changes have not all made it into the proposal spec text yet.) I also wrote a wpt PR with some tests. I'm not sure if this needs independent implementer interest signals / implementation bugs, but if so, I'll deal with that next week.

[domenic]

Editorial nit: we prefer to avoid single-step <ol>s, so instead of

28. If ...
    1. Set value ...

we'd write

28. If ..., then set value ...

Because of the force-pushing, I can't tell if this has been there the whole time and we hadn't caught it previously (sorry if so!), or if it was introduced in recent revisions.

Anyway, normative contents still LGTM.

It would be good to have independent bugs, since structured serialization is often dealt with by different browser teams.

For implementer interest, if you have some indication that TC39 consensus includes structured serialization, then that's enough. (I'm unclear whether the consensus you're referring to in the above comment is for structured serialization, or whether it's for dropping Calendar and TimeZone objects.)

When should we merge this? I guess Temporal is stage 3, which is when we've merged things into HTML in the past. So I'm happy to merge once the checkboxes are checked, as long as you are.

[Ms2ger]

Thanks!

Editorial nit: we prefer to avoid single-step <ol>s, so instead of

28. If ...

    1. Set value ...

we'd write

28. If ..., then set value ...

Because of the force-pushing, I can't tell if this has been there the whole time and we hadn't caught it previously (sorry if so!), or if it was introduced in recent revisions.

The previous version had substeps to handle user-defined time zones and calendars. I'd like to maybe slightly push back against this comment, though, because I think merging the substep into the previous paragraph would be somewhat less readable due to the quite big records I'm creating. I defer to you if you do still want me to do it, though.

Anyway, normative contents still LGTM.

It would be good to have independent bugs, since structured serialization is often dealt with by different browser teams.

Filed those.

For implementer interest, if you have some indication that TC39 consensus includes structured serialization, then that's enough. (I'm unclear whether the consensus you're referring to in the above comment is for structured serialization, or whether it's for dropping Calendar and TimeZone objects.)

Sorry for the confusion - the TC39 consensus was for dropping Calendar and TimeZone objects. My understanding is that structured cloning hasn't really been discussed in TC39. I filed standards positions issues to make sure.

When should we merge this? I guess Temporal is stage 3, which is when we've merged things into HTML in the past. So I'm happy to merge once the checkboxes are checked, as long as you are.

I guess we can give a bit of time for people to respond to the standards positions, but apart from that, I'd be happy to merge.

[annevk]

I heard that V8 doesn't want to add this per the latest TC39 meeting? What about SpiderMonkey? JSC is somewhat neutral.

I agree that normally we'd just add Stage 3, but if implementer interest is not really there I'm less sure.

cc @syg @codehag @mgaudet

[mgaudet]

Regarding structured clone, we'll work through the Mozilla standards position to develop a real position. I can't speak for V8, but I don't think Temporal's trajectory has changed particularly.

[controversial]

I heard that V8 doesn't want to add this per the latest TC39 meeting

@annevk could you point to the spot in the tc39 meeting notes where that’s established? I couldn’t find it in a quick scan through the 2024-06 notes

[syg]

Sorry I don't actually remember discussing serialization of Temporal objects. At this time I can't reconstruct any reasons why V8 would be against it.

[annevk]

No implementer being against it is good, but not sufficient. Is any implementer interested in doing this?