URL: https://www3.nhk.or.jp/news/
Browser / Version: Firefox 78.0
Operating System: Mac OS X 10.13
Tested Another Browser: Yes Chrome
Problem type: Something else
Description: (perhaps unintentional) line breaking in the link next to the logo in Gecko
Steps to Reproduce:
The button-like link "おうちで学ぼう!for School" next to the NHK logo looks "fine" on Chrome 84 and on Safari 13.1; however, it looks slightly "broken" on Firefox.
Chrome and Safari renders those strings in two lines; it lay text out as if there were hard line breaks after "!", thus looking like:
おうちで学ぼう!
for School
Firefox does it differently... Not only it does faux-put hard line break after "!" but also faux-put before the "う", forming the following look:
おうちで学ぼ
う!
for School
Is it something about the difference between Gecko and others how do 禁則処理 processing?
(for what it is see https://en.wikipedia.org/wiki/Line_breaking_rules_in_East_Asian_languages )
View the screenshot

Browser Configuration
_From webcompat.com with ❤️_
So the <a> element is a sole item inside a flex <div> with no grow-shrink factor specified so the container and the item (link) should fit-to-content IIUC.
Things get weirder here. The <a> has white-space: pre-line so it depends the (not faux!) hard line break after "!"
<div class="nr-common-header-portal-title"><a href="https://www.nhk.or.jp/school/ouchi/?cid=dchk-commonheader">おうちで学ぼう!
for School</a></div>
And I found the property who caused the three lines. It's letter-spacing: .02em set on body. striking the property using DevTools fits text to two lines.
So, it looks more like letter-spacing and fit-content calculation rather than 禁則処理.
<div class="nr-common-header-portal is-hidden">
<div class="nr-common-header-portal-title">
<a href="https://www.nhk.or.jp/school/ouchi/?cid=dchk-commonheader">おうちで学ぼう! for School</a>
</div>
</div>
Indeed removing letter-spacing fixes it.
/* reset-v2.css | https://www3.nhk.or.jp/news/parts16/css/reset-v2.css */
body {
/* letter-spacing: .02em; */
}
I'm tempted to close it as a duplicate of 🥁 this 15 years old bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=299943
@jfkthame what do you think?


In the meantime it would be cool to contact NHK. My previous attempts for other issues were unsuccessful. They were not interested in supporting other browsers. But we can try again.
And I don't anyone working for them.
They have definitely in-house devs
https://api-portal.nhk.or.jp/en
It would be good to contact them. Could you try @myakura ?
https://www.nhk.or.jp/css/
Thanks.
I'm tempted to close it as a duplicate of 🥁 this 15 years old bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=299943@jfkthame what do you think?
I don't think this is really the same as that bug, which is about where the additional spacing appears in relation to the glyphs (or, equivalently, where the glyphs are positioned within their expanded spaces).
This looks more like it's an issue with letter-spacing, fit-content, and white-space:pre-line. Reduced example:
<!DOCTYPE html>
<style>
div { float: left; clear: left; border: 1px solid silver; letter-spacing: 0.1em; }
.test { white-space: pre-line; }
</style>
<div>Two lines<br>of text</div>
<div class=test>Two lines
of text</div>
Curiously, if I change white-space: pre-line here to be white-space: pre instead, the issue doesn't occur.
Not sure if we have a bug on file about this... I feel like I've seen somewhat similar issues before, but maybe not this exact one.
Thanks I created a bugzilla issue for it.
Close as duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1643215
Aha - I'd just filed bug 1643126 for this :) so marked yours as a dupe. (Sorry, I meant to comment here but didn't get to it in time!)
Most helpful comment
Aha - I'd just filed bug 1643126 for this :) so marked yours as a dupe. (Sorry, I meant to comment here but didn't get to it in time!)