If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

UNCONFIRMED
Unassigned

Status

()

Core
Layout: Text
P3
normal
UNCONFIRMED
5 months ago
2 months ago

People

(Reporter: Robert, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 months ago
Created attachment 8865959 [details]
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)

Updated

5 months ago
Component: Untriaged → Layout: Text
Product: Firefox → Core
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.
(Reporter)

Comment 2

5 months ago
(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?!?
(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.
(Reporter)

Comment 4

5 months ago
(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.

Updated

2 months ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.