You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For documentation tooling this means that there are now distinct startTime, duration, name, entryType properties for the PerformanceLongTaskTiming, TaskAttributionTiming, PerformanceLongAnimationFrameTiming, PerformanceScriptTiming interfaces. Previously these were just documented with the PerformanceEntry interface once for all.
It seems that no other Performance spec does this. So, for our tooling it means that LargestContentfulPaint, LayoutShift, PerformanceElementTiming, PerformanceEventTiming, PerformanceMark, PerformanceMeasure, PerformancePaintTiming, etc. etc. can all refer to PerformanceEntry for these properties as they are not appearing as "overloading" in their IDLs again. That seems inconsistent with what this spec is doing as of 61a67ee. Maybe I'm missing something, though.
The text was updated successfully, but these errors were encountered:
Why is this specification overloading PerformanceEntry in the IDL? E.g.:
For documentation tooling this means that there are now distinct
startTime
,duration
,name
,entryType
properties for thePerformanceLongTaskTiming
,TaskAttributionTiming
,PerformanceLongAnimationFrameTiming
,PerformanceScriptTiming
interfaces. Previously these were just documented with thePerformanceEntry
interface once for all.It seems that no other Performance spec does this. So, for our tooling it means that
LargestContentfulPaint
,LayoutShift
,PerformanceElementTiming
,PerformanceEventTiming
,PerformanceMark
,PerformanceMeasure
,PerformancePaintTiming
, etc. etc. can all refer toPerformanceEntry
for these properties as they are not appearing as "overloading" in their IDLs again. That seems inconsistent with what this spec is doing as of 61a67ee. Maybe I'm missing something, though.The text was updated successfully, but these errors were encountered: