Closed Bug 661454 Opened 14 years ago Closed 14 years ago

Layout.css.dpi no longer works in Firefox 4.0.1 on Windows

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mail+community+mozilla, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 As per my earlier bug report, this setting functioned perfectly fine on Windows in Firefox 3.6 when manually set (Detection from Windows itself didn't seem to work.) but i just updated to 4.0.1 and it now no longer has any effect no matter what i set it as. The KB article for the setting is outdated and states it only works on non-Windows versions and is not a default value on Windows, but this was obviously untrue for 3.6 and should still still be the case in 4.0.1. Reproducible: Always Steps to Reproduce: 1. Set layout.css.dpi to a value other than -1, 0, or 96 Actual Results: The relationship between px and absolute values in CSS remained the same. Expected Results: The relationship between px and absolute values in CSS should change to relfect the value of the setting.
This is probably a consequence of the change to fix to 96 DPI no matter what the "system" DPI is, so I suspect this bug is wontfix... but roc's call.
Try changing layout.css.devPixelsPerPx instead.
devPixelsPerPx is just not an acceptable alternative to properly changing the relationship between px and absolute units. But sadly, is essentially what all user-agents are doing. I can't blame you, it's the CSS2.1 spec that ill concieved the notion that the 96 DPI relationship should always be retained and instead px be relatively scaled and used as the anchor for the rest, but it's just not practical to design that way, and being DPI aware already offered a better solution to the same problem.
I'm not sure what you're trying to do, but one genuinely ill-conceived notion was that it made sense to use physical units for Web sites that might be viewed at widely varying viewing distances (phone vs desktop screen). You can read more about this decision on my blog: http://weblogs.mozillazine.org/roc/archives/2010/08/css_units_chang.html
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Rather than repeat myself in full: http://static.zealous-studios.co.uk/projects/web_tests/PPI%20tests.html Regarding your comment: View distance adjustments should be transparent and applied post DPI adjustments, they are serpate systems for different purposes and combining them is what has lead to rampant misuse of scaling functions by users and complaints when the results are not as expected. Using physical units for any varied media type is perfectly valid to produce the correct surface results, what a view distance scaler does from that point is a variable that is expected to occur and need not be controlled by or known to a designer beyond knowing that a further change in DPI may provide oppertunity to provide higher resolution images and that the dimensions of the viewport or device may have changed so adapting content to prevent scrolling may be wise. Again, it seems like you've created a solution to a problem that didn't really exist, and as a result it's a problem itself. Print media scales an inch to be an inch, simple and that is done with the DPI of the printer, without concern of scaling it fit the page unless told to. When using screen media you scale a px to whatever you want it to be, which ideally you should be scaling using the DPI of the display device to produce a consistant result of 1px being what it is @ 96 DPI, which still produces the same result of an in being an inch, so the two methods are essentially the same. This is how CSS2.1 is defined, and what you alread did to my knowledge. Layout.devPixelsPerPx still seems to do this, but naturally it can make things look ugly for those designers that didn't realise a px was always meant to be relative a pixel and is itself defined as an absolute unit with a 96 DPI relationship to the others. You had a fall back to use with layout.css.dpi for such a case (A UI to switch modes, or a detection of when to use which would have been the next logical step.), so i don't see why you removed it, moved to remove it as an option despite being fairly well hidden as it was. It was nice having layout.css.dpi to toy with as a potential future option that eliminated some of the problems that CSS 2.1 introduced by changing what a px is.
The solution you're suggesting is the same as what Beat Stamm suggested in his comment on my blog post. See my reply for why automatically rescaling px is harmful. We did it for a long time and people constantly complained about it.
Sadly my net just died for a while, but i wanted to just say that the page i linked is actively being edited for clarification and resolving some poorly thought out explanations. It was intended just to get the notes down quick while i was testing behaviour. I'm unsure as to what you mean though. What you do atm increases the size of a px in relation to a pixel, scaling those designs using a px unit to match the result of 1px @ 96 DPI to their DPI (Manually or automatically.), but you may see issues where it was clear the designer intended to have 1 pixel and the result may be overly large or small. What you did with layout.css.dpi was leave a px as a pixel and scale the other absolute units only, resulting in aspects of a design defined in px appearing too big or too small depending on DPI, but it allows those sites that intended for some of those aspects to appear as 1 pixel to remain so (namely some images, positioned elements, borders etc.). The one you use now is that the one that automatically rescales, so please correct me if the case is otherwise, as that is not my observed results. :S You stated "[...] even where they avoided px and sized everything in physical pt, their sites almost certainly are not usable on both a desktop monitor and a handheld device.". Which is not actually true. As part of the research i've been doing, it i've been looking at how units are handled by webkit on smartphones. While is actually does many things against spec (And i have to say, kudos to the Gecko team for being the only browser to get so many aspects of DPI and media queries correct), it specifically functions in a way to make such design to work as well as any other that is not specifically designed for the device. You also said "Physical units are simply not a good way to size fonts when you don't know the distance from the eye to the screen --- which you don't, on the Web." Which again, is simply not true. Px doesn't inherently mean it's optimised for viewing distance, it has the 96 DPI relationship to the other units, they're all equivalent in every device for a user-agent that supports CSS 2.1+. A device is encouraged to scale a px to be equal to a pixel at the intended viewing distance, any by very nature of maintaining the relationship, that scales all other units too, so an in appears as an inch at the intended viewing distance anyway. There's no difference between the two beyond a past where px started as always being a pixel, and a continued assumption of that by some people, so treating is not being a pixel can create incorrect results. If anything, that makes px the worst option of a unit to use in all cases. I think some people may believe people that want to design using physical units want it to be at that unit no matter the context, but that's not the case and certainly not desirable in any way i can think of. The CSS 2.1 spec alredy described how to handle view distance and this is satisfactory, but it doesn't describe how to handle DPI adjustments, so the obvious solution is to handle it in the same way you do for view distances. That's exactly what you do already and is perfectly fine. I was actually describing using both methods for however, as they both come with their problems and benefits. I'd like to see the layout.css.dpi become the standard for the future, and a shift away from the use of px (Which means browsers stop forcing px units for fonts on users.) as this encourages the consistent use of DPI settings and values for media queries, instead of the ratio between a pixel and a px which is already a result of a 96 DPI relationship to the other absolute units anyway and requires an unnecessary layer of extra math. The current method would be used as a fallback so that px are scaled up with the rest of the units and keep the 96 DPI relationship. As that's perhaps sometime in the future if at all, i don't see why support for it simply should be removed because it's not as actively used. It's a fairly hidden setting, and it should perhaps default to -2 as having it disabled, but i'd much rather have it as an example of how to treat scaling in alternative cases where it can provide better results, than see it removed completely. As great as em is as a unit, it is nothing but an alias for whatever font-size unit you use. Currently that's enforced as px due to all user-agents defining it as such, preventing designers from creating flexible designs based on physical units that use a user's chosen default font-size setting. This really seems to be something that people forget about when recommending the use of em (And similarly overlook the fact that a base font-size can't use a % unit when recommending the use of %). User-agents really should be using pt or pica by default (I'm not someone that comes from a print background that actually likes these traditional units.), or at the very least allowing custom units to be chosen.
(In reply to comment #7) > I think some people may believe people that want to design using physical > units want it to be at that unit no matter the context, but that's not the > case and certainly not desirable in any way i can think of. The CSS 2.1 spec > alredy described how to handle view distance and this is satisfactory, but > it doesn't describe how to handle DPI adjustments, so the obvious solution > is to handle it in the same way you do for view distances. That's exactly > what you do already and is perfectly fine. I find it difficult to follow what you're saying. Here it sounds like you agree with what we've done. > I was actually describing using both methods for however, as they both come > with their problems and benefits. I'd like to see the layout.css.dpi become > the standard for the future, and a shift away from the use of px (Which > means browsers stop forcing px units for fonts on users.) as this encourages > the consistent use of DPI settings and values for media queries, instead of > the ratio between a pixel and a px which is already a result of a 96 DPI > relationship to the other absolute units anyway and requires an unnecessary > layer of extra math. The current method would be used as a fallback so that > px are scaled up with the rest of the units and keep the 96 DPI relationship. Here I really have no idea what you're suggesting we do.
Sorry for not being clearer. Simply put, yes i do agree with what you are already doing, but i also wish to see layout.css.dpi kept as an alternative to what you're doing, because under some circumstances it will provide better results.
You need to log in before you can comment on or make changes to this bug.