Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It is not defined what "The PerformanceNavigationTiming interface participates in the [PERFORMANCE-TIMELINE-2] " means #46

Closed
smaug---- opened this issue May 16, 2016 · 9 comments
Assignees
Milestone

Comments

@smaug----
Copy link

How does an interface "participate" something else?
Does it just mean that some PerformanceEntry objects are queued? If so, when?

@smaug----
Copy link
Author

Oh, maybe I can understand this now... It is queued

@plehegar
Copy link
Member

indeed, it's queued in step 27 of the processing model. "participates" means it gets exposed through the performance timeline (getEntries*, perf observers). Performance timeline never mentions what participation means. I could certainly add something in perf timeline and then link the word participate to it if you think it would help.

@smaug----
Copy link
Author

yes, that would help and "extends the following attributes of the PerformanceEntry interface." is also very weirdly said, since nothing is extended there.

@plehegar plehegar reopened this May 17, 2016
@plehegar plehegar self-assigned this May 17, 2016
@igrigorik
Copy link
Member

@plehegar do we really need to? Now that we have a hook to queue the entries for delivery via PerformanObserver, I think it's implicit. I think we could just drop the "participates" stuff altogether to keep thing simple?

@igrigorik
Copy link
Member

I believe this is a near duplicate of w3c/resource-timing#55?

@igrigorik igrigorik added this to the Level 2 milestone Jun 29, 2016
@igrigorik
Copy link
Member

Dropped "participates" language in a2b8521. As noted earlier, steps 27 & 28 ("add" and "queue") already provide the necessary hooks.

@plehegar
Copy link
Member

one comment on this one: should we use "affects the following attributes" instead of "extends the following attributes"?

@igrigorik
Copy link
Member

shrug.. not sure on this one. FWIW, we use "extends" in other specs. If there is a strong argument for "affects" I'm happy to change those -- let me know.

@plehegar
Copy link
Member

If you're not sure, then let's keep the text as-is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants