We have received a webcompat issue about this site using ü and other umlauts, which are rendered with additional spacing in Firefox, see the attached screenshot.

The site is not using an UTF-8 ü (0xC3BC), but rather a lowercase u and combining diaeresis (0x75 0xCC88). On macOS, this causes additional spacing after the umlaut, and on windows, the diaeresis are placed next to the u, not on top of it.

This may be related to, or a duplicate of, bug 940944, but in that issue, the font was broken in all browsers. The webfont in this case seems to render completely fine in Chrome and Safari, so maybe that's something to dig into.

Actually, if you look more closely in Safari, the u-umlaut combination (where they've used <U+0075, U+0308> rather than the precomposed U+00FC) gets rendered in a different font from the surrounding text -- at least that's what I see.

The issue is that the webfont they're using doesn't support the combining dieresis U+0308. Browsers handle that in various ways. Chrome applies Unicode NFC normalization, which changes <U+0075, U+0308> to U+00FC, which is supported by the font. Safari looks for a fallback font for the entire <U+0075, U+0308> cluster, so it renders kinda OK, but the font doesn't match the rest of the word. Firefox does fallback for the individual U+0308 codepoint, but then the positioning of the umlaut may be bad because it's split from its base character for text-shaping purposes.

This is a reason why the W3C recommendation is for authors/sites to use NFC normalization; it's much less likely to run into rendering issues like this (among other things).

Bug 543200 would help here, though it would also be much better if the site fixed its content.

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

See bug 1547409. Migrating whiteboard priority tags to program flags.