Closed Bug 661139 Opened 13 years ago Closed 13 years ago

Absolute values in CSS3 media queries do not respect the layout.css.dpi setting

Categories

(Core :: CSS Parsing and Computation, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 569266

People

(Reporter: mail+community+mozilla, Unassigned)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17

Absolute values reported to CSS3 media queries ignore the layout.css.dpi setting, and as such if you have set a value for this setting to enforce PPI awareness, an absolute value in your stylesheet will not match the same value reported by the user-agent for media queries. They are both CSS units, and should be treated the same for calculating absolute values.

Reproducible: Always

Steps to Reproduce:
1. div { position: absolute; top: 0; left: 0; width: 6in; height: 1em; background-color: green; }
2. @media only screen and (max-width: 6in), screen and (max-device-width: 6.25in) { div { background-color: red; } }
3. <div></div>
4. Reduce the size of the window from >6in to <6in.

Actual Results:  
When reducing the size of the window below 6in, the <div> will change colour to red long after the div has caused scrolling outside the viewport.

Expected Results:  
The <div> should change colour as soon as the viewport drop below 6in, the same time it reaches the edge of the <div>, and before scrolling occurs.
Attached file Simple test case (obsolete) —
Attached file Simple test case
Attachment #536598 - Attachment is obsolete: true
Attachment #536600 - Attachment mime type: text/plain → text/html
The steps to reproduce using the testcase work fine for me on Mac in Firefox 3.6 (with a random value chosen for layout.css.dpi to test that it all actually works).
This is why i hate reporting bugs myself... The discrepncy is not observed in the test case, because it does not scroll. There appeared to be a bug with this due to the difference being very close to a simple PPI difference when calculating.

In fact it's confusion over the following:

"The ‘width’ media feature describes the width of the targeted display area of the output device. For continuous media, this is the width of the viewport (as described by CSS2, section 9.1.1 [CSS21]) including the size of a rendered scroll bar (if any)."

Depending on the interpretation of "including" it should be viewport + scrollbar = width, or viewport - scrollbar = width. For a fixed scrollbar that changes the layout to fit it as it blocks the view of content permenantly, the former is of more use and what Webkit uses in such a case, as the size of a scrollbar is unknown to a designer. The latter is only useful for scrollbars that do not change layout and simply overlay on top of the content being scrolled and hide at all other times. The latter is what is used in mozilla products, IE and Opera regardless of that consideration, while Webkit takes it into consideration and only uses it when the size of a scrollbar does not matter for layout.

Will leave it up to you if it's something work changing. I hope so.
*worth
And switch the two calculations around.
...
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Resolution: INVALID → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: