Remove "font" from initiator type value list

[guohuideng2024]

font is no longer a valid "initaitor type" value from resource timing (see the next comment); therefore, it's removed.

Bug: w3c/resource-timing#364

• At least two implementers are interested (and none opposed):
  Chrome/Edge, Firefox, and Safari all implemented "initiator type" feature.
  The test result for the test listed below can be found here:
  https://wpt.fyi/results/resource-timing/initiator-type/style.html?label=master&label=experimental&aligned&q=style.html
  Chrome/Edge and Safari all pass the test, returning "css". Firefox fails the test, returning "other".
  In conclusion, none of them returns "font".
• Tests are written and can be reviewed and commented upon at:
  • https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/resource-timing/initiator-type/style.html;l=42;drc=1d0cf3905ce74eae85ec01cffcb5a438bb042257
• Implementation bugs are filed:
  • N/A, already implemented
• MDN issue is filed: Already completed: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/initiatorType, and this PR is to reconcile the MDN, fetch spec and resource timing spec.
• The top of this comment includes a clear commit message to use.

---

Preview | Diff

---

Preview | Diff

[guohuideng2024]

I am revising/updating the "initiator type" value list.

I may have missed something. But I cannot find anything about the "font" value except here. Chromium code base and WPT test suggest that "font" shouldn't be one of the possible values.

I don't know the history. Could experts who has experience with this value provide some advice?

==== below is what I have found. ==================

I think the "font" is a possible request destination, which works with a initiator type of "css". And "font" is not a "initiator type" value.

In fetch standard, "font" is associated with "CSS' @font-face". See the table right below https://fetch.spec.whatwg.org/#request-initiator-type

In the WPT test, it's "css" that's returned for that.

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/resource-timing/initiator-type/style.html;l=42;drc=1d0cf3905ce74eae85ec01cffcb5a438bb042257

There is also a test that shows "font" as a request destination works with a "css" as a initiator type

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/loader/fetch/resource_fetcher_test.cc;l=1615;drc=e69b5f14cabdba23eb64d347878805c04fb538d6

[domenic]

Can you restore the pull request template?

[guohuideng2024]

Can you restore the pull request template?

Done. Additionally I edited my comments above.

[domenic]

Can you also fill out the template appropriately?

[guohuideng2024]

Can you also fill out the template appropriately?

ah I see I should put "N/A, .... " if the item doesn't apply. Done.
Thank you for your patience :)

[domenic]

Thanks, getting pretty close.

The tests you link to do not appear to test this issue. The first is for scripts, and the second is just a directory, not a specific test. Can you point to the specific test which shows that fetching fonts does not use initiator-type font?

Second, there needs to be multiple implementers in support of a feature, not just Chromium. So, for example, multiple implementers passing the tests that you point to would suffice here.

[guohuideng2024]

Thanks, getting pretty close.

The tests you link to do not appear to test this issue. The first is for scripts, and the second is just a directory, not a specific test. Can you point to the specific test which shows that fetching fonts does not use initiator-type font?

Second, there needs to be multiple implementers in support of a feature, not just Chromium. So, for example, multiple implementers passing the tests that you point to would suffice here.

(This PR is to correct/update the fetch spec, not proposing a new feature. That's why I skipped the templates. The test that shows "font" shouldn't be listed is linked in that comment too.)

Can you please read my first comment below the PR description? I hope someone here knows better about the "font" than I do and can advise. Thanks.

[domenic]

To be clear, the template is required for all normative changes, not only for new features. If there was some documentation that gave you the impression it was for new features only, let us know so that we can fix that documentation.

I read that.

I'm not any more expert on the font initiator than you are. I'm not sure anyone will be. I'm just trying to help you contribute productively to the specification. To do that, it's much easier for the maintainers if you provide the proper information, in the format they expect it, instead of in a bunch of text.

It seems like if you did that, by moving the test you mention into the issue template, then this would be ready for review.

[guohuideng2024]

To be clear, the template is required for all normative changes, not only for new features. If there was some documentation that gave you the impression it was for new features only, let us know so that we can fix that documentation.

I read that.

I'm not any more expert on the font initiator than you are. I'm not sure anyone will be. I'm just trying to help you contribute productively to the specification. To do that, it's much easier for the maintainers if you provide the proper information, in the format they expect it, instead of in a bunch of text.

It seems like if you did that, by moving the test you mention into the issue template, then this would be ready for review.

Thanks. I updated the template. Is it O.K. now?

[domenic]

You missed this part:

Second, there needs to be multiple implementers in support of a feature, not just Chromium. So, for example, multiple implementers passing the tests that you point to would suffice here.

[guohuideng2024]

The reason I feel the template is for new feature only(or, proposing add/change feature), is that I feel these items are to describe such. If a PR is just to edit the text without changing the spec, or like this PR, which is very unusual, is that I am thinking there may be a mistake in the spec. Then I don't know how to fill the template. That's why I ended up answering "N/A" in most of the cases.

"Test" is the item that I actually filled in the first place. But I referred to the whole set of the test about "initiator type", not that particular one, the reason is that, I thought, since I am proposing that "font" doesn't exist, I should refer to the whole set, and say that "font" is not there.

So yes I have been confused with this template. I guess I would know better next time :)

[guohuideng2024]

You missed this part:

Second, there needs to be multiple implementers in support of a feature, not just Chromium. So, for example, multiple implementers passing the tests that you point to would suffice here.

Following your advice I added how multiple browsers do in the test. It's a paragraph describing the situation. is it O.K. now?

The test result shows that none of the browsers return "font". (Firefox returns "other" which is a default value, it may not have implemented the "font face" case)

[domenic]

Thanks! This LGTM.

I've checked that https://drafts.csswg.org/css-fonts/#font-fetching-requirements does not reference this. (It doesn't correctly reference "css" either, but, at least deleting this will not leave a dangling reference.)

[annevk]

I think this needs to be reviewed by @noamr. It also seems rather weird to me that we'd use "css" instead of "font". If we ever add fetching of fonts elsewhere that will surely become quite confusing.

Also, speaking as editor: just because WebKit passes the test, doesn't mean that WebKit agrees with this change. The same goes for Gecko. We need to actually ask them.

cc @smaug----

[smaug----]

The wpt hints that it was written to match Chromium, not to match any spec.
Gecko seems to follow the note in https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-initiatortype
but I haven't yet found any spec defining properly what the initiatorType actually should be in this case.

[noamr]

I think this needs to be reviewed by @noamr. It also seems rather weird to me that we'd use "css" instead of "font". If we ever add fetching of fonts elsewhere that will surely become quite confusing.

But that's the point of initiators... A css style fetching a font would use the css initiator type. A different initiator would use a different initiator type.

However, the font initiator type is used by IFT so I think it shouldn't be removed.