Open Bug 1351338 Opened 8 years ago Updated 2 years ago

Maximum font size user setting

Categories

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

Product:
Core
Component:
Layout: Text and Fonts
Type:
defect

Tracking

()

People

(Reporter: mozilla, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170327004003 Steps to reproduce: 1. Go to a website that uses a very big font, say http://www.zeldman.com/ or https://codepo8.github.io/redact.js/ with a smallish screen height (mine: 768pixels) Actual results: 2. You cannot display more than a few (4 to 6 in my case) lines of text. Legibility is very limited. Expected results: One should be able to set a maximum font size in the settings, the way a minimum font size already exists. Legibility is a serious accessibility issue, and accessibility to all users has always been professed as an important UX leverage for Firefox. PROPOSED SOLUTION: In advanced font settings, add a "Maximum font size" beside "Minimum font size" to enable the user to normalize it. This could be stored as `font.maximum-size.*`.
USE CASES (sorry I forgot to mention all use cases - these are real use cases, not invented for the sake of demonstration): - People with a small screen (enterprise or older computer) - People whose system settings have been zoomed because of lower sight (older people with big screens but Windows globally zoomed to display in 1024*768)
I agree, it would be great to have such a setting for some sites that have really huge fonts.
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: Text
Ever confirmed: true
Product: Firefox → Core
I agree too. However, should be applied on body text only, not titles (h1 to h6).
I would apply it on titles too. My 2c
Hello Nicolas, If everything is set on - say - 1rem, would be difficult to know where titles are. What about having 2 max-font-size ? One for body text and the other for titles.
Can't you just zoom out by a few steps, if an author has chosen to use overly-large text?
s/titles/headings/ (I'm correcting for non-French readers) ;) IMHO the simpler, the better: (In reply to emmanuel clément from comment #3) > I agree too. However, should be applied on body text only, not titles (h1 to > h6). Headings can be incredibly big, what makes you think that they should be excluded as this would defeat the whole purpose of this proposition? (In reply to emmanuel clément from comment #5) > If everything is set on - say - 1rem, would be difficult to know where > titles are. > What about having 2 max-font-size ? One for body text and the other for > titles. With minimal font size we're already "breaking" things (as in: wonderfully crafted vertical rhythm), but we know what we're doing: it's for the benefit of the user, even if it somehow slightly breaks the "perfectly intended" design. One setting would already be great (I'm considering the overworked implementers here) ;) But yeah, two settings would be awesome, true.
(In reply to Jonathan Kew (:jfkthame) from comment #6) > Can't you just zoom out by a few steps, if an author has chosen to use > overly-large text? Sadly no, as sometimes you can find very big fonts with 16px fonts for other stuff. If you zoom out, smaller things become unreadable at the other end of the spectrum.
Another use case: > Letting users limit how large the text can go also spares them the hassle of horizontal scroll in many cases. By Adrian Roselli on Twitter https://twitter.com/aardrian/status/847073804811735040
Jonathan: Do you think implementing this could be a mentored bug? Could it be a similar implementation to the font.minimum-size.* one?
Flags: needinfo?(jfkthame)
It could be, I guess. For anyone who considers implementing this: Unlike the font.minimum-size.* prefs (which are per-language, or rather per-langGroup, which is a somewhat obsolete concept anyway), I think it would be sufficient to have a single font.maximum-size pref that applies globally. So the implementation won't be entirely parallel to font.minimum-size.*; it should be simpler.
Flags: needinfo?(jfkthame)
Oh, the other point to consider: it's one thing to implement a font.maximum-size pref (settable in about:config and handled by the gfx code); this would be fairly straightforward, I think. It's a whole different thing to expose this in the Preferences UI alongside the existing font settings (as proposed in comment 0). That UI belongs to the Firefox front-end design/UX people, I presume, and it would be for them to decide whether this merits inclusion there. (Personally, I'm not entirely convinced; I'd rather see that UI simplified than extended.) So before anyone dives into that side of things, the front-end team needs to be consulted.
Priority: -- → P3
(In reply to Jonathan Kew (:jfkthame) from comment #12) > So before > anyone dives into that side of things, the front-end team needs to be > consulted. Hi Jonathan, how do we consult said team? Do we have to CC someone/a team, or do we have to open a new issue? I don't know Bugzilla customs too well.
Adding an option to the Preferences user interface would be best handled as a separate bug. It'd be an entirely different component, Firefox::Preferences rather than Core::Layout, and might or might not be accepted at all -- it's possible the designers would feel the benefit doesn't justify the added complexity in the Preferences UI, even if we implement the core functionality in layout. Perhaps a good step, before filing a specific bug about user interface for a feature that doesn't yet exist in the core, would be to post to the firefox-dev mailing list and see whether there seems to be general support for the idea.

It seems there already is a maximum font size setting, although it is quite large. I implemented a zoom rule on a test page, to allow user adjustment of the font, and for kicks I tried really big numbers, and eventually the font quit increasing in size, although the spacing kept going up. Is this documented anywhere?

(In reply to Glenn Linderman from comment #15)

It seems there already is a maximum font size setting, although it is quite large. I implemented a zoom rule on a test page, to allow user adjustment of the font, and for kicks I tried really big numbers, and eventually the font quit increasing in size, although the spacing kept going up. Is this documented anywhere?

First time I hear about it, can you share a source file please?

There's a max size imposed in gfx code: https://searchfox.org/mozilla-central/rev/465dbfe030dfec7756b9b523029e90d48dd5ecce/gfx/thebes/gfxFont.h#56

(That's in device pixels, so the CSS px size it represents would depend on the devicePixelRatio of the screen; e.g. on a Retina display it'd be 1000px.)

Interesting. I couldn't find references to documentation, so thanks for the source code reference. I wonder if there is some particular reason for the limit, or if it is just arbitrary? I mean, if someone wants to have a web page for admiring a single glyph on a 4K screen, why stop them?

I suspect this was originally done because one or more of the various platform font back-ends couldn't reliably handle really enormous glyphs -- I seem to remember there was also some comment or code related to this in cairo somewhere. There may have been cases where specifying huge font sizes could be used to trigger a crash or potential security exploit deep in the font rasterizer, for example.

I wouldn't be very surprised to learn that whatever originally prompted the limit is no longer an issue, and it could safely be removed. We'd need to look into the background more carefully before considering something like that, though.

This would be useful.

I have an astigmatism, and by default, most text is uncomfortably small for a lit screen, and headers are uncomfortably large. I've been using user css to force it all to the same size, but that is hard to adjust in an emergency.

The standard solution for small text is full-page zoom, which just worsens the problem with big text.

If we use user css to set font sizes, we can get everything to a single readable size, but a lot of icons break. If we rely on about:preferences, then a lot of headers are just uncomfortably large.

For anyone who considers implementing this

Does anyone consider implementing this? ;)

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.