Closed
Bug 113013
Opened 23 years ago
Closed 22 years ago
Default font size pref should affect "absolute" font sizes
Categories
(Core :: Layout: Text and Fonts, defect)
Core
Layout: Text and Fonts
Tracking
()
VERIFIED
INVALID
People
(Reporter: jesup, Assigned: lorikaplan)
References
(Blocks 1 open bug)
Details
(Keywords: access, fonts, intl, Whiteboard: WONTFIX? DUPLICATE? (py8ieh: see comment 18 points 5 and 6))
There are significant problems with the current font size preferences. (was discussing this with akk, Heisi, timeless and biesi and a few others on IRC.) You can adjust the font size in prefs. However, it doesn't affect font sizes specified in px units (and perhaps some others). This can lead to lots of pages with Really Tiny Fonts that you can't read on a 100dpi (or higher) display. It confuses users because they think they increased the font size, and it seemed to work in most places. There is a Text Zoom menu item, but it isn't saved. (And there are bugs with em-sized non-font-elements.) Also, unlike 'normal' font sizing, it's done in %. There's a pref with no UI for a minimum (point?) size for fonts. There should be two prefs (for variable and fixed fonts), and it needs a UI. Note that this doesn't take the place of the other two mechanisms since it loses all font size information at or below the value you set for it. These issues affect accessibility (for the visually-impaired) and readability on high-DPI displays. Proposal: the basic mechanism should not be the tables in nsStyleUtil.c. THe basic mechanism presented to users should work via textZoom. If the user picks a larger font, pages in px should be enlarged too. Yes, this _is_ a spec violation, so perhaps there should be a checkbox or Advanced button, but note that the POLC (principle of least confusion) dictates that users who want larger fonts be given larger fonts in all cases. Note that this implies that there may be separate zooms for proportional and fixed fonts, which would be tricky. Perhaps we should instead expose the textZoom factor instead of letting the user specify font size in points. We have 3 mechanisms; one of which has a UI and is saved, one is saved, and one has a UI but isn't saved. They use different units, and their relationship is confusing to users. We need one unified pref page (or page plus advanced, etc). We need at least a moderately intuitive way to adjust font sizes that works for pages that use px (like CNN, espn, etc).
Comment 1•23 years ago
|
||
I guess this is why IE only has Smaller, Small, Medium, Large, and Larger for font size choices, as it completely avoids the problems with specifying exact sizes. However, I find IE's implementation very annyoing, as every choice always seems a bit too small or too big. So I suppose my 2 cents' worth is to make sure any new implementation doesn't end up like IE's.
Comment 2•23 years ago
|
||
Well, I worry making pixels not mean pixels based on a change in font prefs will just continue to encourage authors to put text in images. Authors should almost never specify fonts in pixels (but of course they do). Beyond that, how would you decide when a pixel shouldn't be a pixel? What if I want a pixel to be a pixel, but I want my default font to be 12px? What if I want a pixel to be 1.5 pixels, but I want my default font to be 24px? I'd propose the following: * we keep the meaning of the font-size pref the same (but perhaps also expose it in a menu, although the Zoom should be more prominent) * we scrap the current "text zoom" and replace it with a real zoom that zooms everything -- i.e., by changing the p2t value on the device context that is used for conversion to the display, but not when converting to nscoords. Such a zoom would scale text, images, everything sized in ems or %ages, etc., but would still allow the page to fit horizontally within the viewport unless it is badly designed.
Cc:ing other folks and putting on the intl radar. My preference would be to patch the existing stuff (bug 61883) before contemplating a crusade that involves change that are unlikely to happen in the short term.
Comment 4•23 years ago
|
||
I agree with the objections raised by dbaron but I don't think that a low-level pixel zoom would be the solution because people usually want to enlarge the text, not the images. Nobody reports bugs saying "The images are displayed too small in my browser" (or if they do, they should use a lower resolution on the monitor). See bug 4821 for more details on the full zoom feature. A solution could be to implement the "min font size" pref, but then we have to make sure it applies to the line-height too. We have a similar problem with text zoom (bug 95267).
Comment 5•23 years ago
|
||
I don't think that's true. There are many web pages that use images to display text. For example, http://www.excite.com/ or http://www.apple.com/ . Some users might want to enlarge the images in order to read the text in them. That's what the Zoom feature is for.
Reporter | ||
Comment 6•23 years ago
|
||
While I agree with dbaron that text in images is an issue (and is for me), I consider that a separate issue which is handled under bug 4821. Quite honestly, all pixel measurements should be deprecated IMHO. They're only of any real use if you assume a more-or-less standardized DPI, viewing distance, and display size (and assume the user has normal visual acuity). They should never have made it into the spec. The minimum font size pref has it's uses, but that's really just a backstop; you lose considerable amounts of contextual information once that minimum becomes equal to or larger than the "normal" font size. The same logic that scales all <font size=N> sizes according to the user's font pref should apply. If you set your "font size" in prefs to 30 points (you have bad eyesight), that makes your size 1 font size around 18 points or so (and people have been arguing that the font sizes should be even more tightly clustered around the selected size). <font size=N> is deprecated, but users can only affect fonts specified with that deprecated (but still extremely common) construct. This is a problem. The textZoom stuff does solve the problem, more-or-less, but in a much less precise manner, and it has bugs, plus it can't be saved. Minimum font size sort-of solves part of the issue, but at the expense of losing formatting information and compressing everything to a single font size (except perhaps ultra large headlines). And, as stated to start with, font sizes are in three places with three different ways to change them: a prefs panel, a menu item that isn't saved, and the third only accessible by editing user.js.
Comment 7•23 years ago
|
||
Pixel measurements are strongly discoraged by CSS gurus -- but physical units on screen media are even worse still, since OSes very rarely have proper settings. The main solution here is evangelism of page authors -- I don't think there's any UI that we're going to come up with that the majority of users will understand how to use. There are legitimate uses for pixel-size text (when used along with images), and we shouldn't change the meaning of a pixel for text without changing it for images as well.
Comment 9•23 years ago
|
||
Exposing the minimum font size pref we already have would go a long way toward helping the people and platforms most affected by this problem. Granted, it loses some contextual information; but in practice that seldom seems to be a problem, and in any case the alternative is to set the "use my fonts" pref and have mozilla ignore all document specified fonts, which loses a lot more contextual info than a minimum font size does. Not to say that the rest of rjesup's suggestion (scale all absolute-specified fonts along with the main font) is a bad idea. I think it's a good idea, and I'd use it, but we'd still need minimum font size (and it should be exposed), for all the Windows-based page authors who see IE's scaled-up default fonts and so use <font size=-1> over their whole page to make the fonts look normal sized, making the page unreadable on Mac and Linux.
Reporter | ||
Comment 10•23 years ago
|
||
Perhaps a checkbox for "Adjust all font sizes" or "Adjust absolute font sizes as well" (any wording you like). Perhaps in an "advanced" box along with the override checkboxes (or as another in the set). The real problem here is that there's a conflict between the (rather annoying) spec, and what people expectations and wishes are. Most people who adjust their font size in prefs really will expect that to apply to all fonts. HTML (and CSS) are NOT page-layout languages, for all that people keep trying to make them into page-layout langs. Pixels are a particularly bad mechanism for specifying font sizes, since god knows how much space a "15px" font is actually going to take up given all the variances of OS, font family, font foundry, display device, DPI, scaled vs bitmap, etc, etc. If page authors would avoid px sizes, that would be a different story - but they don't, and we don't have the clout to make them. Witness cnn.com. I want to provide the users with a way to make pages reasonably usable, whether they're on a high-DPI X display with bad "small" fonts, or have visual acuity problems, or just feel less eyestrain reading larger fonts. To me, that's more important than strictly following the spec even when the user requests otherwise. IMHO
Comment 11•23 years ago
|
||
>Perhaps a checkbox for "Adjust all font sizes" or "Adjust absolute font sizes >as well" (any wording you like). Perhaps in an "advanced" box along with the >override checkboxes (or as another in the set). For the record, CSS has a powerful concept that goes into achieving what you mentioned in a spec-compliant manner. It is called |font-size-adjust| with values: none | number | inherit. The property scales the so-called "actual" font-size by a factor depending of the x-height of a font against the x-height of a base font (see bug 74186). There are also prefs for that, but they only work in GfxWin and there is no plan to expose them. The back-end support for that (which I added as part of my landing in bug 99010) proved to be much involved and so it is unlikely to happen in other platforms in the short term.
Updated•23 years ago
|
Hardware: PC → All
Comment 12•23 years ago
|
||
Pardon my ignorance, but what is "p2t" and how does it relate to font scaling and/or page zoom?
Reporter | ||
Comment 13•23 years ago
|
||
pixels to twips - conversion between internal sub-pixel calculations and pixels.
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 14•23 years ago
|
||
Despite my min font size prefs, this site still has tiny text : http://jimmac.musichall.cz/themes.php3?skin=2 Is this because the style sheet using px ? (Also I cannot select only part of a line, bug nr. would be appreciated)
Comment 15•23 years ago
|
||
UE issue, over lori
Assignee: ftang → lorikaplan
Status: ASSIGNED → NEW
Component: Preferences → User Interface Design
Comment 16•23 years ago
|
||
I agree with everything David Baron said. Things I specced in bug 28899 which aren't implemented yet are: (1) UI to finish bug 61883 (different sizes for differently legible font families) (2) UI for the minimum font size. That design is as complex as I dared make it -- I think adding any more features would tip it too far into incomprehensibility.
Comment 17•23 years ago
|
||
Possible fix: userContent.css I've had this same issue with Galeon, had been told that this was addressable with CSS, using a default stylesheet, but had found no examples of one that did what is being requested. I've since created and used a stylesheet which I've been using for the past four months or so, with excellent results. The stylesheet itself (heavily annotated) is available at http://kmself.home.netcom.com/Download/userContent.css Examples of pages with and without the stylesheet (note: users with an existing stylesheet may have results differing from the default) are at: http://kmself.home.netcom.com/Download/test.html (without) http://kmself.home.netcom.com/Download/test-css.html (with) The stylesheet forces all fonts to the faces and size(s) specified in the users' browser preferences. All absolute and relative "size" tags or CSS directives are ignored. All "font" face directives are ignored. Headers are also specified. Because a minimum font isn't specified, it's still possible to scale a page using the zoom control. Text will increase/decrease appropriately, and can be greeked. This is a Good Thing. The one thing the CSS doesn't render right (IMO) is the virtual directory page returned when you're browsing a filesystem or a website that returns a filesystem listing. If I could get this fixed I'd be in heaven (please reply at the address above). I've found precisely one website which breaks in ways that are at times unreadable with this style sheet. It's http://www.law.com/. Certain pages within the site use absolutely scaled regions which break when text is resized. Other than that, this stylesheet gives me the web the way I want it given to me. Much happiness. Shipping a CSS (or providing pointers to one similar to mine) might resolve this bug. It might also raise the awareness level of web designers who break things in the first place.
Comment 18•23 years ago
|
||
IMHO: 1. Font Zoom should be _exactly_ as it is now. A transient zoom for text only intended simply as a way to quickly make small text more readable on a temporary basis and which may well break the layout of badly written pages. (done) 2. We should implement Page Zoom as a separate feature, and that should work exactly like it does in Opera. It should not be transient (although I'm not sure if it should affect all pages when multiple windows are open). 3. Text Size prefs should control the default font size ('medium' in CSS terms). There should only be one font size control. 4. The font selection should let the user pick fonts for each of the generic font families, and should let the user pick which generic font family to consider the default. (done) 5. We make the 'font' shorthand not reset 'font-size-adjust' and we set 'font-size-adjust' on the root element to the aspect ratio of the default font-family as given in step 4. This will automatically take care of making the font sizes of other font families resize to match the aspect ratio of the default font. 6. We add an option to the font pref panel to control whether or not to do what it says in step 5. (i.e., whether or not to set f-s-a to the aspect ratio on the :root element or whether to set it to none.) We make the default be 'none' (pref unchecked). 7. We keep the minimum font size pref exactly as now. (done) This is actually *very* close to what we have now, UI-wise. The only real changes are the introduction of Page Zoom (a four-digit bug), the removal of the font size pref for Monospace, and the addition of a pref to reimplement the behaviour of the latter using font-size-adjust. w.r.t. the initial comments: The font size prefs *shouldn't* affect pixel-sized text. If authors size text in pixels, then by default we must honour the contract we have with the author that a 10x10 pixel image will be roughly the same as 10px text. (By "by default" here I mean ignoring any transient controls like font zoom or any accessibility features like minimum font size.) The font zoom is exactly correct -- it isn't saved, and it's done in %. That's what we want. Bugs in font zoom were recently fixed. In any case, bugs in a feature should never be a consideration for implementing another feature in a different way -- the effort should just be spent fixing the first set of bugs. We have a minimum font size pref for getting around pages designed with ridiculously small fonts. Set it to be whatever you find is the smallest text you can comfortably read. We should have page zoom. I agree with that. > Proposal: the basic mechanism should not be the tables in nsStyleUtil.c. We need those tables regardless of what we do. Those tables are how we go from xx-small to xx-large in CSS. (Unless I am thinking of something else.) Those tables are fine. They have been carefully tweaked and work great. > The basic mechanism presented to users should work via textZoom. If the user > picks a larger font, pages in px should be enlarged too. That's what the minimum font size pref is for. > Yes, this _is_ a spec violation, so perhaps there should be a checkbox or > Advanced button, but note that the POLC (principle of least confusion) > dictates that users who want larger fonts be given larger fonts in all cases. Evangelisation and education are key here. We have to get page authors to understand that they should honour user preferences by using only 'em' units, and we have to get users to understand that page authors have that choice. How we do that is our of scope of my comments. > Note that this implies that there may be separate zooms for proportional and > fixed fonts, which would be tricky. And horrible. I am against that. > We have 3 mechanisms; one of which has a UI and is saved, one is saved, and > one has a UI but isn't saved. They use different units, and their > relationship is confusing to users. Which is the second? > We need one unified pref page (or page plus advanced, etc). We have one unified pref page. The Font Zoom stuff isn't a pref, and shouldn't be a pref. It's similar to the Use Stylesheet menu item, it's not a pref, and should not be in the prefs dialog. > We need at least a moderately intuitive way to adjust font sizes that works > for pages that use px (like CNN, espn, etc). Yep. Minimum Font Size (a pref, works now) and Page Zoom (RFE). I think this bug is a dupe of bug 4821 (well, bug 112108 really). If there is support for what I proposed at the top of this comment (points 5 and 6), then I'll file new bugs.
Comment 19•23 years ago
|
||
> There should only be one font size control. [ ... ] > the removal of the font size pref for Monospace That would be a huge loss in usability on linux. Like it or not, the X font model just isn't very good, and fonts don't always appear at their advertised sizes. Trying to find a size that's right for both the chosen proportional font and the chosen monospace font is impossible; one of them will be either too big or too small. Perhaps on platforms that use only scaleable fonts, this isn't a problem, but it's a big problem on Unix. > The font size prefs *shouldn't* affect pixel-sized text. I understand Hixie's arguments for this, but won't it be confusing for users (who don't and shouldn't have to know how the font was specified in the html) when they choose text zoom and the text doesn't zoom? Shouldn't the user's wishes override those of the page designer? Otherwise I have no argument with Hixie's comments. The existing font zoom works well for me -- I use it fairly often even though a set a minimum font size, since pages that force a font other than my chosen one often end up too small.
Comment 20•23 years ago
|
||
>> There should only be one font size control. > [ ... ] >> the removal of the font size pref for Monospace > > That would be a huge loss in usability on linux. I used to buy that argument. However, I no longer do. For the last 6 months I've been using Mozilla on Linux as my primary platform, and I have it set up so that both my font size prefs are set to 16px. I haven't installed any special fonts (except those required for MathML, and those aren't either my default serif or default monospace fonts). And you know what? It works fine. I don't have any Huge Loss of Usability. Web pages look prefectly normal. > Like it or not, the Xfont model just isn't very good, and fonts don't always > appear at their advertised sizes. The monospace font pref isn't helping with that problem in any noticable way. And anyway. If you re-read my proposal, you'll see that I specifically provided an alternative solution to that problem in the point I numbered 5. > Trying to find a size that's right for both the chosen proportional font and > the chosen monospace font is impossible; one of them will be either too big or > too small. WORKSFORME on a 6-month old standard Mandrake 8.1 installation. >> The font size prefs *shouldn't* affect pixel-sized text. > I understand Hixie's arguments for this, but won't it be confusing for users > (who don't and shouldn't have to know how the font was specified in the html) > when they choose text zoom and the text doesn't zoom? Again. Please re-read what I said. I explicitly stated that *font zoom* should zoom *all* text, including pixel sized text, *as it does now*. It's the default font size prefs that shouldn't affect pixel-sized text. That's exactly what pixel sized text means in CSS. It the page author says "I want 25px text" then CSS says that he should get 25px text. That's what "25px" *means*. The author may be stupid to say so, but then that's why we have the (potentially layout-destroying) font zoom feature. We even have a minimum font size feature. And we should have a (persistent) page zoom pref. > Shouldn't the user's wishes override those of the page designer? Yes, that's what page zoom, font zoom, and minimum font size are for. It's not what the *default* font size pref is for. Here is how I see our features fitting in with each other: Default Font Size, Default Page Colours, user stylesheets, etc: Set what the web looks like by default, on pages whose authors have honoured the user's preferences. Minimum Font Size, !important user stylesheets, etc: Force certain features on web pages, so that pages all remain readable despite the author's ignoracne of the user's preferences. Font Zoom: Transient changes to the font size, for pages that use large amounts of text at the minimum font size or for when the reader is tired or at some distance from the monitor. Page Zoom Pref: A persistent increase in the size of all features of the web, for users with poor vision or very high resolution monitors. Page Zoom Chrome UI: A quick access to the page zoom pref for taking a closer look at a web page.
Whiteboard: WONTFIX? DUPLICATE? (py8ieh: see comment 18 points 5 and 6)
Reporter | ||
Comment 21•23 years ago
|
||
>>> There should only be one font size control. >> [ ... ] >>> the removal of the font size pref for Monospace >> >> That would be a huge loss in usability on linux. > >I used to buy that argument. However, I no longer do. > >For the last 6 months I've been using Mozilla on Linux as my primary >platform, and I have it set up so that both my font size prefs are >set to 16px. I haven't installed any special fonts (except those >required for MathML, and those aren't either my default serif or >default monospace fonts). And you know what? It works fine. I don't >have any Huge Loss of Usability. Web pages look prefectly normal. Whether or not you have problems with this is highly dependant on a slew of factors. I regularly use 3 different RH Linux machines, and a few different FreeBSD 4.x machines running XFree86 3.6 and 4.x. Of those machines, only the RH 7.2 using 1Kx768 resolution doesn't seem to have major problems - and it still has some (monospace). >> Trying to find a size that's right for both the chosen proportional >> font and the chosen monospace font is impossible; one of them will >> be either too big or too small. > >WORKSFORME on a 6-month old standard Mandrake 8.1 installation. Change your resolution to 1280x1K, or 1600x1200 and try again. Or try it on a "standard" Xfree86 distribution instead of Mandrakes (which probably has a bunch of non-standard fonts, etc). Or try it with some font other than the default. >>> The font size prefs *shouldn't* affect pixel-sized text. >> I understand Hixie's arguments for this, but won't it be confusing >> for users (who don't and shouldn't have to know how the font was >> specified in the html) when they choose text zoom and the text >> doesn't zoom? > >Again. Please re-read what I said. I explicitly stated that *font zoom* should >zoom *all* text, including pixel sized text, *as it does now*. > >It's the default font size prefs that shouldn't affect pixel-sized >text. That's exactly what pixel sized text means in CSS. > >It the page author says "I want 25px text" then CSS says that he >should get 25px text. That's what "25px" *means*. The author may be >stupid to say so, but then that's why we have the (potentially >layout-destroying) font zoom feature. We even have a minimum font >size feature. And we should have a (persistent) page zoom pref. You're correct, that is what 25px means, and you're correct that the author was probably stupid to say so. The problem is that that stupidity is commonplace, unlikely to go away, and that stupidity confuses users. They thought they selected a larger font size, and then they hit a page where everything is small and hard (or impossible, in some situations) to read, perhaps even mixed in with correctly sized text. >> Shouldn't the user's wishes override those of the page designer? > >Yes, that's what page zoom, font zoom, and minimum font size are for. It's not >what the *default* font size pref is for. The whole issue mostly comes down the old argument: does the user (via the user-agent aka the browser) get to decide what to display and how (even if that isn't what the page author intended), or does the page author get to decide even if that means that the particular user is inconvenienced or unable to use the page? Traditionally, browsers provided a number of ways in which a use could override the page author. Font size and style (originally, before CSS), window size, whether images are displayed or not, whether JS code is run (which can affect a page FAR more, and is saved), etc. >Here is how I see our features fitting in with each other: > > Default Font Size, Default Page Colours, user stylesheets, etc: > Set what the web looks like by default, on pages whose authors > have honoured the user's preferences. The last phrase is the important one. > Minimum Font Size, !important user stylesheets, etc: Force certain features > on web pages, so that pages all remain readable despite the author's > ignoracne of the user's preferences. Until CSS, font size (base size) used to be in this section. Minimum font size loses information. > Font Zoom: Transient changes to the font size, for pages that use large > amounts of text at the minimum font size or for when the reader is tired > or at some distance from the monitor. Again: there are people who really need for this to be saved, unless they want to use a large minimum size and lose all the information meant to be conveyed by relative sizes. > Page Zoom Pref: A persistent increase in the size of all features > of the web, for users with poor vision or very high resolution > monitors. AaronL might be able to provide more real feedback on this, but I imagine that sight-impaired users might NOT want to zoom images by default. Full Zoom (bug 4821) also tends to cause large scrollbars, which make the browser tough to use. (I know this.) > Page Zoom Chrome UI: A quick access to the page zoom pref for > taking a closer look at a web page. I can't imagine a good way to make this easier that doesn't have other negative impacts.
Comment 22•23 years ago
|
||
> Change your resolution to 1280x1K, or 1600x1200 and try again. I use 1600x1200 on a 15" laptop monitor. I do grant you that it is possible that some Unix systems have bad font setups, but I am not convinced that we, in the 21st century, should still have to be implementing work arounds for problems that other platforms have had solved for decades, and that some modern Unix systems have shown need not exist. > Does the user (via the user-agent aka the browser) get to decide what to > display and how (even if that isn't what the page author intended), or does > the page author get to decide even if that means that the particular > user is inconvenienced or unable to use the page? Neither. There is a third option, the one I described in my previous comment, and the one that the specs specify. The user gets to pick default settings. The author gets to selectively override some of those. Then the user gets to selectively override the author's choices. In the case of font size, there is one pref on the "user default" side, and there are four on the "user override" side. See my list in my previous comment on this bug. > Traditionally, browsers provided a number of ways in which a user could > override the page author. And since the advent of CSS User Stylesheets, the number of ways is even bigger. > Until CSS, font size (base size) used to be in this section. "Before CSS" is over 6 years ago now, by the way. This isn't exactly a new change. Half of the life of the web has been this way. Incidentally. Other browsers (Opera, IE) implement a subset of what I am describing. Do they also lack the font size preferences you are advocating? > Again: there are people who really need for [foont zoom] to be saved Pages that use pixels for sizing (and thus are not affected by the default font size prefs) are those that font zoom destroys. I don't understand why anyway would want us to destroy these pages. Page zoom gets around this. Could you give me more details on these users? > unless they want to use a large minimum size and lose all the information > meant to be conveyed by relative sizes. In practice this is not an issue. Minimum font sizes that are small enough (e.g. around the 16px mark) not to totally destroy web pages do not lose any meaning of consequence. Users that would pick minimum font sizes that _do_ lose meaning should be using page zoom, not the minimum font size pref. > AaronL might be able to provide more real feedback on this, but I imagine that > sight-impaired users might NOT want to zoom images by default. I imagine the opposite. Therefore we have a stalemate until someone can provide some hard evidence either way. > Full Zoom (bug 4821) also tends to cause large scrollbars, which make the > browser tough to use. (I know this.) LOL. How can you assert knowledge about bugs in a feature that we don't have??? > I can't imagine a good way to make [page zoom chrome UI] easier that doesn't > have other negative impacts. What's wrong with the UI seen in, e.g., Opera? Or a UI similar to what we have now for font zoom? I mean no disrespect, but I am baffled by your arguments.
Updated•23 years ago
|
Summary: Font size prefs need to be redesigned; functionality problems → Font size prefs need to be redesigned; functionality problems (font zoom ui)
Comment 23•22 years ago
|
||
I think the need of users to have changes to "default font size" prefs work consistently within and across existing pages outweighs the need of site owners to be able to coordinate image sizes with text sizes. I don't think the "minimum font size" pref helps much.
Summary: Font size prefs need to be redesigned; functionality problems (font zoom ui) → Default font size pref should affect "absolute" font sizes
Comment 24•22 years ago
|
||
I'd much rather stop supporting absolute font sizes entirely. (Note that Jesse retitled the bug in his previous comment so as to make the bug INVALID in my opinion.)
Comment 25•22 years ago
|
||
Indeed, bug 131236 comment 3 offers one good reason why the newly-summarized bug should not be fixed. Bug 96096 comment 18 offers another reason (whether that reason is a good one is, I suppose, not is not for me to say).
Comment 27•22 years ago
|
||
http://ln.hixie.ch/?start=1045789943&count=1 : "I recently increased my default font size to 24 pixels."
Comment 28•22 years ago
|
||
Indeed. From this experience I have learnt that: 1. We need Page Zoom urgently. I would much rather like to have my prefs set as font size = 16px, page zoom = 200%. At the moment, I can't read any of my web comics without using your "zoom in images" bookmarklet. 2. We need Text Zoom to be per-site. Whenever I hit a site that uses pixel-sized units, I hit Ctrl-+ twice. When I click through a link to a site that respects my font prefs, the text size becomes ridiculously large and I have to hit Ctrl+0. I don't see how my experiences validate this bug.
Comment 29•22 years ago
|
||
200% of 16px is 32px, probably not what you want or need if your default is 24px. I find 16px is about right at 1024x768. Divide 1600 by 1024 and multiply times 16px, and the result is 25px. So, like IH, I find 24px default at 1600x1200 works nicely, considering the higher resolution produces vastly superior letter forms with "right size" text compared to lower resolutions. I don't think there's any way for the request here to be satisfied. MPT's comment at http://bugzilla.mozilla.org/show_bug.cgi?id=96096#c18 also seems to confirm. This bug looks awfully similar to bug 96096.
Comment 30•22 years ago
|
||
invalid.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•