w3c
Remove PerformanceEntry.id and rephrase id generation.
- Removing PerformanceEntry.id, since it's shadowed by PerformanceElementTiming.id, see https://github.com/w3c/performance-timeline/issues/218
- Rephrasing how navigation ids are generated:
- no more mention of id, but the mechanism is the same as before, a random navigation id for each new document, which is then incremented for navigations that don't change the document
- changes the order of the sections for queing so that it first talks about navigation performance entries, since these change the navigation ids, and only after that other entries
I swapped the sections back for now, so it looks that in Github's file view it's now easy to see a diff of the modifications relative to the 'production' version. I think with the wording, you're right, it's probably just the most recent navigation id that matters here. I think this is also what I'm seeing in the Chromium change that I'm preparing actually, the entry isn't kept around, just the id. And, there may be one more state that can occur, when there isn't a document yet - in the code I'm using 0 thus far in that case (for 'uninitialized'?), but I don't know yet whether that value ever actually surfaces via the API (so it wouldn't need to be in the spec, just an implementation wrinkle). If it's cool, I'll come back to this spec update in a little while with more knowledge (1-2 days).
I uploaded a new version, main changes are:
- In the initial section, as suggested, specified "current navigation id" and "current document navigation id", both initialized to 0.
- In the IDL for PerformanceEntry, revised the type of navigationId to long (meaning a signed int32). I think this is better for json and javascript APIs; the extra range of unsigned long long isn't needed and may cause clipping / loss of precision (e.g. the 54 bit limit) and/or things getting emitted as floating point numbers with a decimal dot.
- Revised Generate a navigation id to use current navigation id and current document navigation id.
- Merged the case of queing a navigation performance entry into Queue a PerformanceEntry.
Sorry for the delay on review here. I scanned through, and I do like the change.
Before reviewing the wording, can you remind me: Did you find when/why PerformanceEntry.id was added in the first place? Specifically I'm curious if:
- Was this accidentally added which trying to add support for navigationId, and we should clean it up, or
- Was this a really old part of PerformanceEntry spec that has been forgotten about (and not implemented in Chromium) but perhaps has some value on some other platform?
It has been a while-- but if this can still land clean we should resurrect this work, its still a good idea!
(Aside: as a followup we probably want to move the navigationId spec out to the soft-navigations spec repo as a monkeypatch)