Temporal proposal HTML serialization support#6284
Temporal proposal HTML serialization support#6284littledan wants to merge 2 commits intowhatwg:mainfrom
Conversation
|
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. |
81f0aae to
bcfc01a
Compare
domenic
left a comment
There was a problem hiding this comment.
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
left a comment
There was a problem hiding this comment.
Calendar user code thread seems to not yet be resolved?
domenic
left a comment
There was a problem hiding this comment.
OK cool. Just waiting on tests, implementer interest, and browser bugs then before we can merge.
50b7305 to
cd5e85c
Compare
|
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. |
|
Editorial nit: we prefer to avoid single-step
we'd write
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. |
|
Thanks!
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.
Filed those.
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.
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. |
|
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. |
@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 |
|
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. |
|
No implementer being against it is good, but not sufficient. Is any implementer interested in doing this? |
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 Co-authored-by: Domenic Denicola <d@domenic.me> Co-authored-by: Ms2ger <Ms2ger@igalia.com>
cd5e85c to
bfcdbf5
Compare
|
Deno is interested, and we're also happy to do the V8 implementation. |
|
This addition makes sense to WebKit as well. |
I am working on a structured clone integration for Temporal objects in V8 (whatwg/html#6284). This requires that reference years and days are exposed on PlainMonthDay and PlainYearMonth respectively for temporal_capi. Additionally, a numerical month getter is needed for PlainMonthDay. --------- Co-authored-by: José Julián Espina <jedel@startmail.com>
ptomato
left a comment
There was a problem hiding this comment.
The names of some internal slots changed a couple of years ago, and dates/times were organized into Records. As far as I can tell, here's what would be needed to update this PR accordingly.
|
@nicolo-ribaudo will attend |
|
Mozilla voiced support in the WHATNOT meeting, and they want to review this PR. |
|
@anba if you have time, could you have a quick look at the PR? |
|
The overall changes look reasonable to me. I just wonder if calendar and time zones should get re-validated when deserialised, in case the supported calendars or time zones changed in some way. For example when serialising to disk and later deserialising from disk with a newer browser version, it's possible that some calendars or time zones are no longer supported or are canonicalised differently (only relevant for calendar identifiers). |
|
That's a great concern. That makes me wonder whether serializing objects that contain such timezone data to disk is something we should prohibit for v1 until we know more about the landscape. We could use the forStorage infrastructure for this. Especially as these issues would only hit a small percentage of end users. cc @whatwg/i18n |
|
I think we should not prohibit serializing values that have attached time zones, because it would be bad to give Web developers an incentive to prefer UTC offset over cities in values that get serialized. UTC offset does not accomplish the same as a city even within one year in places that have daylight saving time, and more generally, user-perceived time zones over time are attached to political rules in a particular place and not to a particular offset. I think we should explicitly cover the possibility of time zone canonicalization changing over time (Kiev to Kyiv, Calcutta to Kolkata, etc.) and the possibility of a time zone going away. In the case of canonicalization change, we can assume there to be data that enables re-canonicalization under the new rules. I'm not sure what we should spec about time zones going away, but it seem unlikely enough that we shouldn't prohibit serialization due to that possibility. |
|
Fair, filed tc39/proposal-temporal#3294 to discuss this further with TC39. |
|
Possible scenarios I'm worried about: Calendar identifiers:
Even if we're 100% sure neither 1 nor 2 will ever happen for all currently supported calendars, can we assume the same for any future calendar extensions, like tc39/proposal-intl-era-monthcode#18? Time zone identifiers:
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1797225 |
|
This seems ok from the i18n working group perspective. The question related to calendars has more to do with the stability of calendar identifiers than it does with how they should be serialized. Same would apply to time zone identifiers, I would think. |
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.
(See WHATWG Working Mode: Changes for more details.)
/infrastructure.html ( diff )
/structured-data.html ( diff )