Re: Priority Hints - fetchpriority and iFrames

It's part of the discussion on the PR for incorporating fetchpriority into
the html spec:
https://github.com/whatwg/html/pull/8470#discussion_r1106835444

I can open a separate issue if it would help but that PR probably has the
best context and would be the best place to weigh-in.  If it stays then we
need to figure out exactly how to spec the language so it works (which is
where some of the issues came up).

On Thu, Feb 16, 2023 at 3:35 PM Sean Feng <sefeng@mozilla.com> wrote:

> Hi Patrick,
>
> I think Gecko is implementing it, do you mind file a spec issue so that I
> can let more folks to take a look?
>
> Thanks!
> Sean
>
> On Thu, Feb 16, 2023 at 1:48 PM Patrick Meenan <pmeenan@google.com> wrote:
>
>> Would anyone be particularly concerned if we removed iFrames from the
>> list of elements that support fetchpriority?  It's not currently
>> implemented in Chrome and as we go through the spec process, it isn't
>> immediately clear that trying to prioritize the document fetch is the best
>> way to control the scheduling of the iFrame.
>>
>> Specifically:
>>
>> - The fetch will be in a different document context from main-document
>> subresources and may not be able to be scheduled within the browser
>> relative to the other requests.
>>
>> - The network fetch may not be on a connection where it could be
>> prioritized against other requests (even if they happen to be from the same
>> origin) depending on how browsers choose to partition the network state
>> across frames for privacy.
>>
>> - It doesn't control the scheduling of non-fetch iFrames.
>>
>> I'm thinking that we'd be better off thinking about scheduling of iFrame
>> instantiation as it's own thing with imperatives that match what dev's
>> would like to control.  i.e. would a "defer" make sense for an iframe to
>> delay starting the loading of an iframe until the main DOM is ready?  Kind
>> of like there's already loading=lazy for matching the image behavior.
>>
>