1363454 - allow font-delivered "icons" even when browser.display.use_document_fonts = 0 (forced font override)

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Robert]

Attachment: Firefox-FontOverride-BreaksIcons-5911fdbf.png

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170403080144

Steps to reproduce:


1. "about:config"
2. set "browser.display.use_document_fonts" to 0 (or deselect "Allow pages to choose their own fonts..." in the preferences)
3. navigate to a site that uses font-based icons (e.g. http://lowes.com )
4. observe unexpected brokenness (boxes, non-latin glyphs, etc)



Actual results:

The user intends to set a font for uniformity or increased readibility.

The web developer intends to use a font in place of an sprite image for greater simplicity and maintainability.

Neither would, initially, suspect that their action might yield *worse* results.



Expected results:


Due to the increasing prevalence of font-based icons, IMO Firefox should:
1. have an extended boolean config flag, such as: "browser.display.use_document_fonts.for_icons" (?)
2. if true, allow for the fetching (but not applying) of fonts
3. if true, allow the document-provided font "only if it is an icon" (which can be assured 99% of the time if it is *one character*, and perhaps further if delivered via a CSS "content" directive)

Comment 1

[Jonathan Kew [:jfkthame]]

I don't think there's any reasonable way for us to do this, beyond what was done in bug 789788.

The problem with http://lowes.com, for example, is a site bug (misuse of Unicode codepoints). Note that a few of their icons (e.g. the credit card) -do- still work with use_document_fonts disabled, because they (appropriately) use Private Use Area codepoints. It's the ones that use ASCII character codes (like 'X' for a book, or '!' for the Lowes logo) that will break, because that's a blatant abuse of the codepoints involved.

A "web developer [who] intends to use a font in place of an sprite image for greater simplicity and maintainability" needs to have some understanding of character encoding and fonts if they're going to produce a reliable, usable, accessible site.

Comment 2

[Robert]

(In reply to Jonathan Kew (:jfkthame) from comment #1)
> bug 789788.

Thanks for that reference, it has quite a robust discussion!

> I don't think there's any reasonable way for us to do this, beyond...

I know they might not be 'philosophically correct', but there *are* at least two usable signals here:

* the tag body (or css content) is a single character
* the font-family is usually "icon" or "icons"

> Note that a few of their icons ... work ... because they (appropriately) use Private Use Area codepoints. 
>
> It's the ones that use ASCII character codes (like 'X' for a book, or '!' for the Lowes logo) that
> will break, because that's a blatant abuse of the codepoints involved.
> 
> A "web developer [who] intends to use a font in place of an sprite image for
> greater simplicity and maintainability" needs to have some understanding of
> character encoding and fonts if they're going to produce a reliable, usable,
> accessible site.

So it sounds like your position is: these icons *should* render broken to alert webdevs to their folly.

Which would mean... the deeper/real problem is that they *don't* appear broken for the default config?!?

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Robert from comment #2)
> (In reply to Jonathan Kew (:jfkthame) from comment #1)
> > bug 789788.
> 
> Thanks for that reference, it has quite a robust discussion!
> 
> > I don't think there's any reasonable way for us to do this, beyond...
> 
> I know they might not be 'philosophically correct', but there *are* at least
> two usable signals here:
> 
> * the tag body (or css content) is a single character
> * the font-family is usually "icon" or "icons"

The CSS font-family in a case like this is an arbitrary identifier. Yes, people are quite likely to use a name with "icon" in it, but I don't think the browser should start making such assumptions and behaving differently depending on the particular identifiers an author happens to use.

As for checking that the content in question is a single character: well, that won't help the case where the webfont is using ligatures to specify the icons, which is one of the use cases that breaks; and it will have "false positives" for things like initials (think of an index, where there's a single-letter "heading" at the start of each new letter of the alphabet; or single-character markers being generated for an enumerated list).

So while I can see some attraction to the suggestion, I think that on balance it's not reliable or comprehensive enough to include in the web platform, or to justify the effort to implement, document, and maintain such special-case behavior.

> 
> > Note that a few of their icons ... work ... because they (appropriately) use Private Use Area codepoints. 
> >
> > It's the ones that use ASCII character codes (like 'X' for a book, or '!' for the Lowes logo) that
> > will break, because that's a blatant abuse of the codepoints involved.
> > 
> > A "web developer [who] intends to use a font in place of an sprite image for
> > greater simplicity and maintainability" needs to have some understanding of
> > character encoding and fonts if they're going to produce a reliable, usable,
> > accessible site.
> 
> So it sounds like your position is: these icons *should* render broken to
> alert webdevs to their folly.
> 
> Which would mean... the deeper/real problem is that they *don't* appear
> broken for the default config?!?

It would arguably be good if we could do that, but unfortunately there really isn't any way for the browser to "know" whether an author is encoding their content in a sensible way.

It's a bit like... suppose an author chooses to deploy a webfont where the character "a" is rendered with a glyph that looks like "α", the character "b" looks like "β", and so on. Then they can write a page that looks (visually, using their font) like Greek text. But if a user disables use_document_fonts, they'll see Latin-script garbage. Authors shouldn't do things like that, for lots of good reasons (imagine what it does to screen-reader support, searchability, etc), but as long as they have the ability to deliver a custom font for their content -- and THAT's a feature of the web platform that isn't going away! -- we can't actually prevent them doing it, or fix the user experience problems that it causes.

Comment 4

[Robert]

(In reply to Jonathan Kew (:jfkthame) from comment #3)
> 
> > * the font-family is usually "icon" or "icons"
> 
> The CSS font-family in a case like this is an arbitrary identifier. Yes,
> people are quite likely to use a name with "icon" in it, but I don't think
> the browser should start making such assumptions and behaving differently
> depending on the particular identifiers an author happens to use.

Well... new font-family identifiers have to originate from somewhere, and it is interesting that (being technically invalid) this is already so prevalent in the wild.

Furthermore, it is far easier to prescribe that a broken site apply a css rule change (like "set font-family to 'icon' to fix your icons!") than to ask them to re-code all of their characters (in CSS, html, & dynamic templates), that were probably generated by a 3rd-party utility in the first place, that they cannot modify.

> 
> > * the tag body (or css content) is a single character
> 
> that won't help the case where the webfont is using ligatures to specify the
> icons, which is one of the use cases that breaks;

I'm sure they exist, but I have not run into any "obvious" cases such as that; so I assume they are comparatively rare.

> and it will have "false positives" for things like initials (think of an index,
> where there's a single-letter "heading" at the start of each new letter of the
> alphabet; or single-character markers being generated for an enumerated list).

True, but in this case... a "false positive" would mean that the single character would be rendered in the font that the webdev wanted, instead of the user. Assuming the user set it for readability (as opposed to security), which implies words lines and paragraphs, I would find this failure mode *entirely* acceptable (when compared to broken icons).

> 
> So while I can see some attraction to the suggestion, I think that on
> balance it's not reliable or comprehensive enough to include in the web
> platform, or to justify the effort to implement, document, and maintain such
> special-case behavior.
>

I'm sure that work can be splintered off into a separate (set of?) bugs... :)

But I do suspect that any use of 'icon' font-family should probably be reported to w3, or... whoever is considered the SoA for that.

> > So it sounds like your position is: these icons *should* render broken to
> > alert webdevs to their folly.
> > 
> > Which would mean... the deeper/real problem is that they *don't* appear
> > broken for the default config?!?
> 
> It would arguably be good if we could do that...

Which I originally meant as "the default for use-document-fonts should be false", but you interpreted deeper...

> ... but unfortunately there
> really isn't any way for the browser to "know" whether an author is encoding
> their content in a sensible way.

+1

> It's a bit like... suppose an author chooses to deploy a webfont where the
> character "a" is rendered with a glyph that looks like "α", the character
> "b" looks like "β", and so on. Then they can write a page that looks
> (visually, using their font) like Greek text. But if a user disables
> use_document_fonts, they'll see Latin-script garbage. Authors shouldn't do
> things like that, for lots of good reasons (imagine what it does to
> screen-reader support, searchability, etc), but as long as they have the
> ability to deliver a custom font for their content -- and THAT's a feature
> of the web platform that isn't going away! -- we can't actually prevent them
> doing it, or fix the user experience problems that it causes.

Yes... you are right, of course, and I know this request has a bit of that unofficial... "tag soup" flavor... but IMO it is not an insurmountable problem, and well worth an extra line of documentation, or an extra bug or two filed for later.

Comment 5

[bzzz]

Hi,
can someone please verify if this code snippet is affected by this bug, or if it is bad implementation of the Material Icons web font? I've somehow got Font Awesome working for me with forced document fonts, but this one fails to load properly. If the use_document_fonts property is set to 1, it works instantly. I think (might be mistaken!) key in FA was installing the font locally, which didn't help here. This is the first occurrence of web font issue after FA was resolved - I just happened to install ioBroker to my RPi, which seems heavily infested with web font icons. Mid-term goal (if ioBroker works for me) would be using it with Firefox, which is out of reach with the current rendering and no option to selectively disable use_document_fonts for specific URLs. I'll attach a screenshot as well.

<div class="user-view center">
<a id="current-user-icon"><i class="large material-icons">account_circle</i></a>
 <a><span class="white-text name" id="current-user">admin</span></a> 
<a><span class="white-text email" id="current-group">Administrator</span></a>
</div>

Comment 6

[bzzz]

Attachment: Material Icons rendering with use_document_fonts disabled

Comment 7

[Jonathan Kew [:jfkthame]]

Yes, this is the issue you're seeing; it's the natural result of how the Material Icons font is encoded & used.

FontAwesome uses Private Use Area codepoints, so it can still work with use_document_fonts set to 0, as the default font won't include those codepoints. Material Icons, on the other hand, uses regular English characters, so naturally they get displayed in the default font when you've told the browser not to use what the website asks for. (See also bug 1638585.)

Comment 8

[Uzix]

Attachment: Google Translate

Firefox 78.5.0esr - same issue in Google Translate.

Comment 9

[Pierre Ossman]

Since this appears to be difficult to solve in Firefox, I was hoping that Greasemonkey could do this more flexibly. E.g. having a white list of popular icon fonts.

Unfortunately, it seems limitations in Firefox prevents a Greasemonkey script from doing the same thing:

https://github.com/greasemonkey/greasemonkey/issues/3151
https://bugzilla.mozilla.org/show_bug.cgi?id=1393022

Perhaps that functionality can be prioritised as a way of resolving this use case?

Comment 11

[Daniel Holbert [:dholbert]]

I'm copying over two comments from dupe bug 1638585, which include a possible way forward & a motivating use-case (i.e. why users might be affected by this):

(Quoting nyanpasu64 from bug 1638585 comment #5)

One possible solution is to add a whitelist of font names to let through, populated with "Material Icons" and users can add more fonts via about:config.

(Quoting Vincent Lefevre from bug 1638585 comment #6)

There may be several reasons to use browser.display.use_document_fonts = 0, but one of them (this is my case) is for readability reasons for text, and in this case this should not apply to word-ligature icon fonts. There should be a way to detect such fonts at some level. But the suggested whitelist solution would probably work in practice, and if there is some default, here are the names I could find:

• Material Icons
• Google Material Icons
• Material Symbols Outlined
• Material Symbols Rounded
• Material Symbols Sharp

Vincent also mentioned that "Matching exact names would probably not be sufficient", and suggested a substring-matching approach -- but I think that exact-matching is probably the best approach to start with, since the number of affected fonts is relatively small, and the complexity (and potential for false positives) would be quite higher if we took a substring-matching-based (or regex-based) approach. Exact string matching has the benefit of being predictable and allowing for users (possibly with the assistance of add-ons) to understand and trivially hand-edit their own allow-list (without needing to understand regex/substring-matching syntax), if needed.

Also: gaming things out, it's worth entertaining a small adversarial concern along the lines of: "Uh oh, now font/site developers might be incentivized to co-opt these icon/symbol font names for completely-unrelated web-fonts, simply to increase the likelihood that the browser will use the site's chosen font despite user preferences." But I suspect in reality there's no strong motivation for sites to get up to this sort of mischief, since the share of users with this configuration (who they'd be focusing on with this sneakiness) is probably quite small.

Comment 12

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1363454 - Create a pref to list icon font families that should be used even when use_document_fonts=0, overriding the browser's font prefs. r=#layout-reviewers

Comment 13

[Jonathan Kew [:jfkthame]]

It's a bit of a hack, but here's a possible patch that adds support for an icon-font whitelist for family names that should continue to be used even when use_document_fonts is disabled.

I initialized the list with the family names quoted in comment 11, plus additional Material Icons versions that I see on Google Fonts; obviously, we may need to add more fonts to the list as we run across them.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cb3d8f3015f6
Create a pref to list icon font families that should be used even when use_document_fonts=0, overriding the browser's font prefs. r=emilio,dholbert

Comment 15

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/cb3d8f3015f6