Re: Priority Hints - fetchpriority and iFrames

I added comments to the Mozilla bugzilla issue
<https://bugzilla.mozilla.org/show_bug.cgi?id=1797715> and the WebKit issue
<https://bugs.webkit.org/show_bug.cgi?id=247291> with the link to the spec
discussion so hopefully the engineers working on either will be aware and
comment as needed.

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

> Thanks, this is good!
>
> On Thu, Feb 16, 2023 at 3:43 PM Patrick Meenan <pmeenan@google.com> wrote:
>
>> 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.
>>>>
>>>