[BUG] Fonts with relative paths load from the wrong location

[tremby]

Describe the bug

Possibly related to #274

I'm seeing my fonts load just fine, but then as soon as the polyfill kicks in, I see 404s for each custom font in my console and the fonts are replaced with defaults. The URLs it's attempting to load the fonts from are incorrect.

To Reproduce
I can't share the codebase I'm working on. Let me know if you need a reproduction repo and I'll try to put one together, but I am thinking this is a regression, since the issue referenced above sounds like it covered exactly this issue and it was closed as "completed".

My situation:

I'm running a Nextjs application. I have some fonts imported from Fontsource packages, self-hosted. I'm in development mode right now. The @font-face rules it provides have lines like

src:url(../media/inter-latin-wght-normal.4f851744.woff2)format("woff2-variations");

and this CSS file was served from /_next/static/chunks/_b7db3667._.css. As such, the font should be loading from /_next/static/media/inter-latin-wght-normal.4f851744.woff2, and it is, at least before the polyfill runs.

But once the polyfill loads, I see failed requests for files such as

/media/inter-latin-wght-normal.4f851744.woff2

i.e. not under the /_next/static subtree.

Browsers tested on
Firefox 138 on Linux.

[jamesnw]

Thanks for reporting!

• Prior to Replace blob approach with style elements #324, no relative paths worked
• Replace blob approach with style elements #324 resolved the case where paths are relative to the document's baseURI

You've surfaced the use case of relative paths that are relative to something besides the document's baseURI.

In #323 I explored an alternative method of solving that case that involved parsing all URLs and resolving relative to the baseURI. One path forward might be to revisit #323, and resolve paths relative to the stylesheet they are relative to.

If you'd like to work on that, we'd welcome a contribution!

I'm not sure of a work around, unless you are able to make the paths absolute, either directly in the CSS or via a preprocessor.

[wileycoyote78]

First of all, thanks a bunch for y'all's hard work on this polyfill.

I am having the same problem.

I am building a Word Press theme for a personal blog. One of the things I noticed when I encountered this issue was that it only happened if I set the margins for the containing element.

Something like

*{ margin: 0; }

causes the font url to be "downloaded twice," the first time with the correct URI, the second being the incorrect one. If I disabled the margin declarations, the URIs to the fonts would not be touched. I don't know why, but that is what I isolated my issue to (FF 141.0.3 Linux).

I managed to work around the problem by moving the font declarations into a separate CSS file.

@tremby, I don't know your environment. As I said, I am working on a Word Press theme, so I used the enqueue styles function to load the separate font style sheet. Perhaps your project has a similar loading function, or perhaps you could just declare the fonts directly into the head of the file?

Alas, I am not familiar enough (by which I mean not at all) with TypeScript to offer any coding contributions.

[jamesnw]

I managed to work around the problem by moving the font declarations into a separate CSS file.

This is a good idea for a workaround. Essentially, the polyfill has to track all uses of properties that might impact anchor positioning, including margin. If it encounters one, it updates that stylesheet, which would break any relative paths in that stylesheet. Moving these paths to a separate file avoids that issue.