Re: [w3ctag/design-reviews] Scheduling APIs (#338)

It feels like the main use case [given in the overview](https://github.com/WICG/main-thread-scheduling) for the prioritized post task API is about coordination within a single site -- although this does include third party context in nested browsing contexts.

I agree with @bzbarsky that it's valuable to allow browser flexibility to schedule differently across third-party boundaries; such boundaries are quite opaque to begin with and it feels like heavily constraining the relative priorities between origins could interfere with useful things that browsers could do to help users.  Whereas within a single site, where there's already much closer interaction, it feels more like there's value in having things clearly-specified -- as the HTML spec currently does, since there's only a single task source.  So specifying these priorities as being something meaningful within a single task source, but not across task sources, feels like a good approach to me.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/338#issuecomment-529770601