html icon indicating copy to clipboard operation
html copied to clipboard

[WIP] Temporal proposal HTML serialization support

Open littledan opened this issue 4 years ago • 4 comments

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 https://github.com/w3ctag/design-reviews/issues/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):
    • https://github.com/mozilla/standards-positions/issues/1045
    • https://github.com/WebKit/standards-positions/issues/368
  • [x] Tests are written and can be reviewed and commented upon at:
    • https://github.com/web-platform-tests/wpt/pull/46865
  • [x] 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 avatar Jan 13 '21 12:01 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.

littledan avatar Jan 26 '21 13:01 littledan

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.

Ms2ger avatar Jun 21 '24 15:06 Ms2ger

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

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

we'd write

  1. 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.

domenic avatar Jun 24 '24 07:06 domenic

Thanks!

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

  1. If ...

    1. Set value ...

we'd write

  1. 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.

Ms2ger avatar Jun 26 '24 13:06 Ms2ger

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

annevk avatar Jul 05 '24 14:07 annevk

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.

mgaudet avatar Jul 09 '24 21:07 mgaudet

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

controversial avatar May 08 '25 16:05 controversial

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.

syg avatar May 08 '25 17:05 syg

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

annevk avatar May 09 '25 14:05 annevk