From the www-style style mailing list: "Maybe if browsers ship with a minimum font size . . . out of the box . . . web designers will realize that they have misunderstood what their readers want and that the browser window isn't something they control, but something they share with millions of other people." Bug 209879 gave this to Camino users. We should give this to Firefox users. My personal preference is to set it to 11px. 11px is the closest integer under 70% applied to our 16px default. 70% is from https://bugzilla.mozilla.org/attachment.cgi?id=125604 as it would apply to http://lxr.mozilla.org/seamonkey/source/layout/style/nsStyleUtil.cpp#199 where we set the default scaling factor (sFontSizeFactors) for size xx-small. I realize this will break some pages that set container sizes in px, but believe that in effect those pages are already broken both when users have set their own minimums and/or when they zoom, since the resulting overlapping or hidden text really isn't any less useful than too small text. Bug 286254 is same bug for Seamonkey.
The job of a browser is to render the page as the author wrote it, unless the *user* *specifically* overrides something (it's great that they can do this btw). Arbitarily choosing to overwrite part of my design, is not something that should be pre-set in the browser. I urge WONTFIX.
A browser is a user agent, not a web page author agent, user meaning a person who starts it up to use for viewing web pages. See bug 86194 blocked by this.
Before I'd even consider changing this, we would need to test against at least the top100 sites, and ensure that we're not breaking them. And if we were, we'd have to evangelize them first. We've made huge strides in site compat, and breaking that out of a desire to pressure content authors is only going to annoy users, and unless IE did the same, we'd just shoot ourselves in the foot. Trying to screw with the egos of designers isn't what Firefox wants to do. Yes, we want to encourage good design, but punishing "bad" design isn't in our mandate. I don't think this is a true 86194 blocker, since we do support this. Its just not on by default. Basically, unless you can prove that this only breaks marginal sites that we can effectively evangelize, I'm thinking WONTFIX.
The area of the screen within the viewport is/should be controlled by the web page author unless the user specifies otherwise. If the *user* wants to override the font settings of my page, that's fine by me. It's their computer, and they are reponsible for it. If the *user* wants to replace all my blue backgrounds with yellow, that's fine. It's their conscious choice to do so. But by making this the default, you would be overriding the author, but not at the users request. That's not "more power to the user", it's "we think we know better than you, standards be damned".
(In reply to comment #3) > Before I'd even consider changing this, we would need to test against at least > the top100 sites, and ensure that we're not breaking them. I think I can probably find time for that. > And if we were, we'd have to evangelize them first. This too should be doable, if you mean no more than top 100 members. > We've made huge strides in site compat, and > breaking that out of a desire to pressure content authors is only going to annoy users, In spite of what the quote says, I think there is another purpose served here, of equal or greater importance: to help users who don't know about it. > and unless IE did the same, we'd just shoot ourselves in the foot. > Trying to screw with the egos of designers isn't what Firefox wants to do. Yes, > we want to encourage good design, but punishing "bad" design isn't in our mandate. The only pressure would be on the bad ones. Fixing container heights is a very bad practice. Some pressure can be a good thing for such a problem. Having it set by default would help the users who both need it and need to learn about the existence of both the default and minimum size options at their disposal. It would be an easy to make partial substitute for the as yet unfixed bug 24846. If that were fixed, this would probably be pointless. > I don't think this is a true 86194 blocker, since we do support this. Its just > not on by default. It doesn't help anyone who doesn't know about it though, just like the existence of user definable default size doesn't help anyone who doesn't know about that. > Basically, unless you can prove that this only breaks marginal sites that we can > effectively evangelize, I'm thinking WONTFIX. It's mostly only going to break sites that are already a problem. 30%+ is a reasonable floor under the default, and that's good for users. I'm guessing few top100 sites would be so bad, leaving evangelism for the remainder doable. (In reply to comment #4) > The area of the screen within the viewport is/should be controlled by the web > page author unless the user specifies otherwise. Says who? http://www.alistapart.com/articles/dao/ http://www.evolt.org/article/I_am_USER_hear_me_roar/4090/60295/index.html http://www.digital-web.com/articles/fluid_thinking/ Author stylesheets are supposed to be rendering suggestions, not commandments. Fixing this might help some poor designers discover the concept of graceful degradation.
>Author stylesheets are supposed to be rendering suggestions, not commandments. So we should invalidate/wontfix all the CSS bugs filed in bugzilla? If CSS is only a 'suggestion', then IE never got the box model wrong... Without user instructions to the contrary, author stylesheets are "commandments" to be followed to the best of the browsers ability. Only style rules that users have marked 'important', should overwrite author stylesheets *per CSS spec*. Setting something like this as the default choice is not letting the user decide what is important to them. CSS explicitly categorizes UA stylesheets (i.e. the default settings) and puts them at the bottom of the food chain. Minimum font sizes are something that need to go at the top of the food chain, as something the user actively chooses to override author styles.
to clarify - by 'default settings', I didn't just mean settings as shipped, but 'base rendering styles'
In any case, late cycle is not the time to make big scary changes like this. After 1.1 ships, we can revisit this and maybe seen how many sites it breaks if we checked it in.
Target Milestone: --- → Future
(In reply to comment #8) > In any case, late cycle is not the time to make big scary changes like this. > > After 1.1 ships, we can revisit this and maybe seen how many sites it breaks if > we checked it in. For reference (quoting hyatt) >...Safari also instituted a minimum font size pref, never allowing fonts to >shrink below 9 pixels in size. It turns out that this caused sites to >misrender, since sites commonly use small font size spans as spacers. These >sites would misrender (quite badly) in Safari, and so the minimum font size >restriction was lifted.
Previous quote is from http://weblogs.mozillazine.org/hyatt/archives/2003_06.html#003552 and its pretty tough real-world experience to argue with. Breaking stuff that works in IE is not going to do anything but drive users away from Gecko, and the greater good of respecting standards is going to be a big loser. In the end, pragamtism wins.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WONTFIX
"Misrendering" is not the bad thing is sounds like, as long as it doesn't mean missing or overlapping content. CSS is not a page layout language. The web is a fluid medium. Pixel perfect is not expected, contrary to what many who publish to the web think. Ultimately, respecting standards needs to be the winner. Seems to me resolving wontfix now is like saying conditions can never change, and that revisiting after market share is higher as previously suggested could be nothing but a waste of time. Wontfix highlights the need to fix bug 24846 and include it in Firefox.
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
You need to log in before you can comment on or make changes to this bug.