froisois wrote:

See also [[fr:Wikipédia:Le_Bistro/12_décembre_2013#Espace_fine_et_ponctuation_double|this thread]].

froisois wrote:

(In reply to comment #1)

Unfortunately, the thin space appears to be replaced by an unsightly « ▯ » in some browsers. (Especially the Wii U won’t display it correctly.) I don’t know whether this is due to the font or to the browser, but it seems to be a vetoing issue.

Narrow/thin non-breaking spaces are also incompatible on iOS devices and Safari on macOS, the space is simply invisible.

See this thread.

Having no space displayed as fallback is not necessarily worse than having a full space for everybody, as many French-speaking people do not add the space before these punctuation marks (e.g. people from Quebec; actually I often find articles of the French Wikipedia having missing spaces in these places).

As a consequence, while browsers replacing with “▯” or equivalent are a real blocker (if there are many left?), I don’t think browsers simply ignoring it should be considered as such.

Quebeckers do put a thin space before these punctuation marks, same for the Swiss, and same for the French.

Having no space (even as fallback) is not typographically or even grammatically correct. French is not English.

Quebec: I saw this table, yes. For all three marks mentioned in the description of this task, it says “Pas d’espace ou une espace fine” and the text at the top says “Dans le cas contraire [Si l’on ne dispose pas de l’espace fine], l’espace fine est supprimée et équivaut à une absence d’espacement.” I thinks this is incompatible with your last statement.

Switzerland: The message about this specific site’s fallback (“certains navigateurs ne supportent pas encore l'espace fine, nous avons donc préféré ne pas les mettre”) is unclear and could be interpreted both ways. [Edit: The site being currently in maintenance mode, I am unable to use an existing text as a way to chose the correct interpretation of the sentence.]

France: I re-read the “Ponctuation” section of LRTUIN (sixth edition; the source of the Unicode page) and no fallback is explicitly indicated, but the sencence “[Ces signes] ne seront jamais collés au mot qui précède” is clear enough. (Furthermore, being French myself, I have to agree that the commonly accepted fallback here is the full space.)

I’m not sure why you mention the grammar here, this problem seems purely typographic to me.

Just tested with the last version of Safari with different fonts, Safari shows either a zero-width non-breaking space (no space at all) or a tofu character ("▯"), so it's clearly a bug.

Until it is fixed by Apple, we need to stick to NBSP.

EDIT: See also:

• https://bugs.webkit.org/show_bug.cgi?id=172205
• https://bugs.webkit.org/show_bug.cgi?id=180744
• https://bugs.webkit.org/show_bug.cgi?id=194985
• https://bugzilla.mozilla.org/show_bug.cgi?id=1424679

The bug is now fixed in iOS 14 and Safari 14 in macOS.

While iOS and macOS now show the character correctly, it seems now that there's another bug: the U+202F character is invisible if the text is in bold and sans-serif. There seems to be a bug with the default bold sans-serif font for iOS Safari: Helvetica Bold and Helvetica Neue Bold, default fonts cannot be changed on iOS, other bold sans-serif fonts - if specified in CSS - show the character correctly (it was not the case before). I didn't test on macOS yet.

Until this bug is fixed, I think it wouldn't be a good idea to switch to narrow non breaking spaces, since iOS (and probably macOS) users will think there's no space before a punctuation mark in the lead of an article and add one, resulting of two spaces that contributors will have to fix every time. Also you'll need the consensus of the French-speaking community, mainly the French Wikipedia.

EDIT: Yup same problem on macOS, it impacts other browsers as well since they use the same default fonts as Safari (we can't change them on Safari but fortunately we can on other browsers like Firefox and Chrome in the settings but the average user don't know how to do that).

I submitted a feedback via https://www.apple.com/feedback/

Fixed on iOS 15.

Also fixed on Safari on macOS Monterey but now there is another problem: the U+202F is invisible with the default serif font (and various other serif fonts like Georgia, Times, etc.), other browsers are not affected.

EDIT: Also the sans-serif font Lucida Grande for some reason.

Here's two screenshots, the first taken on Safari 15.3 and the second on Firefox 97.0.2, on macOS Monterey 12.2.1.