User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030521 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030521 There are several problems with the text size interface in Firebird, which are inherited from Mozilla. As the point of Firebird is to make the UI easier to understand, I thought it be worth reconsidering that interface. The key problems are: * Three different ways to specify text size (dpi, 'default size', text zoom) * Text zoom preferences are maintained from site to site when they shouldn't be, but are not maintained when they should be (when you return to a site that you previously enlarged) (this is already reported as bug 108931) These contribute to making text sizing difficult to manage, especially with reference to the confusing preferences screen. (I mean, where does it say what that 'text size: 16px' actually means? It doesn't bear any reflection to the actual text size on many web pages... how are users supposed to realise this?) This RFE is just my suggestion for an improved interface in general. You can ignore it if you like but having spent some time thinking about it I thought it would be worth posting here. 1. Create a single toolbar button 'text size' - The functionality (i.e. what happens when you use it to enlarge text) is the same as 'text zoom' already is - When clicked has a dropdown with larger, smaller, and common percentages - Always (on the face of the button) displays the current size setting (as a percentage) - Remembers setting on a per-domain basis [NOTE: I discussed this with others and it has been suggested that a slider control might be more appropriate than a button. This would take up more toolbar space but would give direct access to sizing. Personally I would prefer a simple button, but I thought I would include that suggestion here too.] 2. Edit the preferences page Fonts & Colors: - scrap everything related to relative or default text size (so that at 100% zoom, 1.0 em is *always* 16 pixels or whatever it is) - replace that with a 'default zoom' option for those with limited vision, this affects sites for which zoom hasn't been specified. - (Keep the 'minimum size' option in prefs, that's pretty cool; obviously this would apply post-zoom.) If you do that you have one single number for text size, which makes the whole thing comprehensible. * You can see what it is * If you change it, it works (true of existing text zoom - not true of the text size options in preferences) * The browser remembers your change when you come back to a site (and you can tell it's done that because you can see the number) * It doesn't get applied to every other site you visit in the same window The only drawback I can see to this is dealing with domains that host multiple sites or areas, which might have different text size requirements; then you need a more complex algorithm for determining 'what is a site' than just the domain name. [It can be done, but might make mistakes. See various comments in bug 108931] As you can see, this addresses three main problems in current browsers: - incomprehensible settings (three different numbers) - minor lack of visibility of option (in menu, not toolbar) - wrong persistence of setting (persists when you go to different site in same window, doesn't persist when you come back to the same site in a different window) The disadvantage is that it occupies toolbar space, but you could always turn it off if you didn't like it. I think text size is an important enough function to be on toolbars by default, but others might disagree. I think the most important point here is reducing three numbers to one, which could really make text sizing comprehensible. (You could argue that text zoom, with the current 'larger' 'smaller' and nothing else options is already comphrensible - yes it is, but it doesn't work in a very convenient manner. And the preferences page isn't comprehensible.) One future-proofing note: Longhorn and presumably future non-Windows OSes as well are going to begin including support for high-resolution screens (>150 dpi) which might start meaning that the 96 dpi assumption becomes a bit silly. However, this system doesn't really make that problem any worse as when it comes up, it needs to be handled automatically not by having the user type in a new number... Anyway this is just my opinion, maybe there are some issues with it (and if this is a dupe, sorry, I couldn't find it but I suck at bugzilla searching). Reproducible: Always Steps to Reproduce:

Ugh - sorry, I typed the bug number wrong when referencing. bug 108391 is the one I meant re per-site text zoom. (Also, I forgot to mention that maybe the toolbar button could have kind of +/- 'sides' to click on to change the number directly, without needing a dropdown - that could be a better interface.)

This is either a WONTFIX or a really low priority Future fix, there's a lot of work involved in this level of change. --> NEW

Ben is re-examining the Fonts dialog stuff, bug 214271 adding to dependencies, removing deprecated RFE tag All/All

The high resolution problem is solved by setting the size of text in points/mms/inches, not pixels. Mozilla should be able to get the dpi value from system and allow the user to modify it in case it is wrong. However, it can display the selected text size in both as expected physical size and as number of pixels. For readability both minimum size and minimum number of pixels may be needed. But with current hardware minimum number of pixels should be sufficient. There may be problems with web pages that set text size explicitly. Web pages that specify size in points should be OK, but sizes in pixels are bad.

Hear, Hear! to the "Minimum Text Size" proposition. But would that not fly better as a separate bug? I'd be happy to write it, if so.

see also bug 174854 which is currently being patched.