Closed Bug 590817 Opened 10 years ago Closed 9 years ago

Use physical units (mozmm) for core CSS lengths

Categories

(Firefox for Android Graveyard :: General, defect)

defect
Not set

Tracking

(fennec2.0b4+)

RESOLVED FIXED
Tracking Status
fennec 2.0b4+ ---

People

(Reporter: mfinkle, Assigned: mfinkle)

References

Details

Attachments

(2 files, 1 obsolete file)

In an effort to better support a variety of platforms, we are going to switch from pixels (px) to millimeters (mozmm) in the core CSS files.

We have a few common pixel lengths that we use consistently, and a few wildcards too. We'll need to come up with corresponding millimeter lengths and start converting.

This is part of the foundation work we need to do before the Android theme, with it's HDPI, MDPI and LDPI variants.

(for nostalgia, bug 494551 landed the millimeter CSS back in the day)
Blocks: 590777
Blocks: 575403
OS: Mac OS X → All
Hardware: x86 → All
tracking-fennec: --- → 2.0b1+
tracking-fennec: 2.0b1+ → 2.0b2+
Assignee: nobody → mark.finkle
I am waiting for the new theme to land before working on this. It will be very tight to get in for beta 2. Moving to blocking final.

We really want this for Android mdpi and hdpi support more than any other reason.
tracking-fennec: 2.0b2+ → 2.0+
tracking-fennec: 2.0+ → 2.0b3+
Depends on: 612978
Notes for triage: depends on bug 612978
Rather than using mozmm in the theme, we might want to use the CSS "resolution" media query, and set different sizes and images for, say, under 200dpi and over 200dpi.  (This is similar to what Android does with its HDPI/MDPI/LDPI layouts and assets.)

The advantages to this approach are (a) that images and other theme elements can be used together more predictably, and (b) it can be made more consistent with other Android applications (which use logical units of "dips" which act somewhat like CSS px, not physical units like mozmm).
(In reply to comment #3)
> Rather than using mozmm in the theme, we might want to use the CSS "resolution"
> media query, and set different sizes and images for, say, under 200dpi and over
> 200dpi.  (This is similar to what Android does with its HDPI/MDPI/LDPI layouts
> and assets.)
> 
> The advantages to this approach are (a) that images and other theme elements
> can be used together more predictably, and (b) it can be made more consistent
> with other Android applications (which use logical units of "dips" which act
> somewhat like CSS px, not physical units like mozmm).

We will use media queries for any image resources. But for padding, margins and other lengths, we should use mozmm. We want a consistent, touch-friendly size and spacing.
We can start this for b4
tracking-fennec: 2.0b3+ → 2.0b4+
Blocks: 476478
Attached patch wip (obsolete) — Splinter Review
This patch is the basic re-organization of the CSS to make it easier to switch between different core units.

Next patch will create a "mozmm" version
Attachment #503363 - Flags: feedback?(21)
Attachment #503363 - Flags: feedback?(mbrubeck)
Nearly all the substitutions are exactly as they were previously, except for a few that I didn't think were critical. Also, I made some changes to the orientation to bring it in-line with what Madhava wanted. I might pull those out into a separate patch.
Comment on attachment 503363 [details] [diff] [review]
wip

I think I like the defines.inc file and the way it is done. It sounds easy to me to refer to this file but I'm not sure of how it is supposed to be used. Is the plan to have multiple directories with a different defines.inc use at buildtime?
Attached patch wip 2Splinter Review
This patch shows how I was planning on handling defines.inc for now. This patch also adds a first attempt at px->mozmm for Android only. No need for Maemo or Desktop.

Some screenshots of this running on a DroidPro (mdpi):

http://people.mozilla.com/~mfinkle/fennec/screenshots/droidpro-awesomescreen.png
http://people.mozilla.com/~mfinkle/fennec/screenshots/droidpro-controls.png
http://people.mozilla.com/~mfinkle/fennec/screenshots/droidpro-tabs.png
http://people.mozilla.com/~mfinkle/fennec/screenshots/droidpro-addons.png
http://people.mozilla.com/~mfinkle/fennec/screenshots/droidpro-preferences.png

Obviously, making some mdpi images is the next phase.
Attachment #503363 - Attachment is obsolete: true
Attachment #503363 - Flags: feedback?(mbrubeck)
Attachment #503363 - Flags: feedback?(21)
Attached patch patchSplinter Review
Attachment #503564 - Flags: review?(mbrubeck)
Comment on attachment 503564 [details] [diff] [review]
patch

This patch adds cropped versions of some of our images - there was too much transparent space around the image. I cut them down from 64px to 42px - but did not resize the image itself, only a crop. That was enough to make the images usable from an mdpi device (droid pro).

The patch renames those images to *-hdpi.png from *-64.png

The patchadds some margin to the appmenu images, which were counting on the dead transparent space in the images.

Some after screenshots:

http://people.mozilla.com/~mfinkle/fennec/screenshots/droidpro-addons-after.png
http://people.mozilla.com/~mfinkle/fennec/screenshots/droidpro-awesomescreen-after.png
http://people.mozilla.com/~mfinkle/fennec/screenshots/droidpro-controls-after.png
http://people.mozilla.com/~mfinkle/fennec/screenshots/droidpro-tabs-after.png
http://people.mozilla.com/~mfinkle/fennec/screenshots/droidpro-dropmarker.png

There are two issues I have found:
* the thumbnail is slightly offset in it's frame
* the dropmarker is slightly stretched

Neither of these should hold back this patch, imo. The hdpi devices show no problems at all. This only affects the mdpi devices.

I can file a followup bug to fix the mdpi issues.
Attachment #503564 - Flags: review?(wjohnston)
Comment on attachment 503564 [details] [diff] [review]
patch

Looks good to me.  Some things start to break down at extreme dpi settings (<100 or >300), but this is definitely good enough for MDPI support.

>+#alerts-container {
>+  width: 300px;
> }
> 
> @media (max-width: 499px) {
>   #alerts-container {
>     width: 200px;
>   }
> }

All of the lengths here could use physical units, though I guess the above
rules will work okay on the devices we've seen so far.

(Same for other @media min-width/max-width queries.)
Attachment #503564 - Flags: review?(mbrubeck) → review+
Comment on attachment 503564 [details] [diff] [review]
patch

I scanned pretty hard and don't see anything overtly wrong either. I don't have a device, so I've been testing on Desktop, which isn't really a reliable indicator of anything (although I can actually repro 624749 on desktop with the android ifdefs removed).

From the screenshots I mostly worry about the urlbar encaps, which look like they aren't themed at all? Looks like they need a background-size property added so that they will resize to fit the element?

I think we're best to land this and just file follow ups for whatever breaks.
Attachment #503564 - Flags: review?(wjohnston) → review+
Yep, urlbar-endcaps do seem to have a solid white background
Depends on: 625513
pushed:
http://hg.mozilla.org/mobile-browser/rev/db032f826288

filed bug 625513 for remaining things to fix

We need to test this mainly on an mdpi device, like the Droid Pro. But we should make sure that nothing is broken on hdpi devices too. Those are using mozmm too.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.