Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
DPI
52 views
Skip to first unread message
pancake
May 15, 2013, 9:05:43 PM5/15/13
to dev...@lists.mozilla.org
I've been playing a while with the simulator, keon and peak and I conclude that there is clear way to work with that.
If you own a Peak you will notice that almost everything looks tiny,
What I found surprising is that the css style size : 2cm is not reliable. Centimeters or inches looks different depending on screen.
When running the js code to get the dpi all of them say 96. Which is not true.
In gaia they solved the issue with a responsive.css which scales the root font size and the rest should use rem units.
Shouldnt b2g provide a way to get screen definition? That will make apps like this much reliable across devices:
http://ruler.ffos.lolcathost.org/install.html
If you own a Peak you will notice that almost everything looks tiny,
What I found surprising is that the css style size : 2cm is not reliable. Centimeters or inches looks different depending on screen.
When running the js code to get the dpi all of them say 96. Which is not true.
In gaia they solved the issue with a responsive.css which scales the root font size and the rest should use rem units.
Shouldnt b2g provide a way to get screen definition? That will make apps like this much reliable across devices:
http://ruler.ffos.lolcathost.org/install.html
Tim Chien
May 16, 2013, 12:11:57 AM5/16/13
to pancake, dev...@lists.mozilla.org
Hi Pancake,
If you read the CSS spec carefully, you would find that on a screen,
these real-world units doesn't have to be sized in the same way on a
physical ruler (though on paper it should).
http://www.w3.org/TR/CSS21/syndata.html#length-units
If you are looking to size an HTML element with physical size, the
non-standard mozmm is the unit you are looking for -- but I am pretty
sure we didn't set the Gecko pref() right on all devices for all FxOS
devices. We should file bugs on that.
MDN is more understandable than the spec on this topic:
https://developer.mozilla.org/en-US/docs/Web/CSS/length
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)
If you read the CSS spec carefully, you would find that on a screen,
these real-world units doesn't have to be sized in the same way on a
physical ruler (though on paper it should).
http://www.w3.org/TR/CSS21/syndata.html#length-units
If you are looking to size an HTML element with physical size, the
non-standard mozmm is the unit you are looking for -- but I am pretty
sure we didn't set the Gecko pref() right on all devices for all FxOS
devices. We should file bugs on that.
MDN is more understandable than the spec on this topic:
https://developer.mozilla.org/en-US/docs/Web/CSS/length
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)
pancake
May 16, 2013, 7:03:36 AM5/16/13
to Tim Chien, dev...@lists.mozilla.org
On 05/16/13 06:11, Tim Chien wrote:
> Hi Pancake,
>
> If you read the CSS spec carefully, you would find that on a screen,
> these real-world units doesn't have to be sized in the same way on a
> physical ruler (though on paper it should).
>
> http://www.w3.org/TR/CSS21/syndata.html#length-units
>
> If you are looking to size an HTML element with physical size, the
> non-standard mozmm is the unit you are looking for -- but I am pretty
> sure we didn't set the Gecko pref() right on all devices for all FxOS
> devices. We should file bugs on that.
>
> MDN is more understandable than the spec on this topic:
> https://developer.mozilla.org/en-US/docs/Web/CSS/length
>
I've tested mozmm on desktop (looks fine), but it doesnt works fine on
> Hi Pancake,
>
> If you read the CSS spec carefully, you would find that on a screen,
> these real-world units doesn't have to be sized in the same way on a
> physical ruler (though on paper it should).
>
> http://www.w3.org/TR/CSS21/syndata.html#length-units
>
> If you are looking to size an HTML element with physical size, the
> non-standard mozmm is the unit you are looking for -- but I am pretty
> sure we didn't set the Gecko pref() right on all devices for all FxOS
> devices. We should file bugs on that.
>
> MDN is more understandable than the spec on this topic:
> https://developer.mozilla.org/en-US/docs/Web/CSS/length
>
Peak or Keon. Should I fill a bug for that?
In the "browser compatibility" doesnt appears 'mozmm', but testing on
iphone it's not supoprted (acording to this table, mozmm should work on
safari too) (mobile safari is not listed).
Is this a bug in the configuration of the keon/peak? or should i avoid
depending on phisical sizes? I don't understand why 'cm' or 'in' units
exists in CSS if they are not honored on any platform/browser..
The other way I thought is .. make this device-independent. But I will
need a way to know in which device I'm running. Which API should I use
to get this information?
Thanks
--pancake
Adán Sánchez de Pedro Crespo
May 16, 2013, 8:42:27 AM5/16/13
to dev...@lists.mozilla.org
I achieve uniform size on PC, Keon and Peak by using these media queries
in my CSS:
@media screen and (orientation:portrait) {
html{
font-size: 5vw;
}
}
@media screen and (orientation:landscape) {
html{
font-size: 5vh;
}
}
@media only screen and (min-resolution: 90dpi) and (min-width: 540px){
html{
font-size: 150%;
}
}
Then you only have to change the units for everything to 'rem', which is
relative to html tag's font size.
in my CSS:
@media screen and (orientation:portrait) {
html{
font-size: 5vw;
}
}
@media screen and (orientation:landscape) {
html{
font-size: 5vh;
}
}
@media only screen and (min-resolution: 90dpi) and (min-width: 540px){
html{
font-size: 150%;
}
}
Then you only have to change the units for everything to 'rem', which is
relative to html tag's font size.
pancake
May 16, 2013, 11:55:25 AM5/16/13
to dev...@lists.mozilla.org
Thanks, I will try later at night.
What would you suggest to get dpi-independent <canvas>?
Scaling is not an option, but theorically, i can measure the size of a
div containing a text in "rem" units, and use this as base to determine
the size of the pixels.
function getdpi() {
var e = document.body.appendChild (
document.createElement ('div'));
e.style.width = '1rem';
e.style.padding = '0';
var v = e.offsetWidth;
e.parentNode.removeChild(e);
return v;
}
I will have to time to do some tests tonight and see if that works..
Another option would be to use SVG to get proper scaling of the ruler,
and that will probably render faster than using a canvas.
What would you suggest to get dpi-independent <canvas>?
Scaling is not an option, but theorically, i can measure the size of a
div containing a text in "rem" units, and use this as base to determine
the size of the pixels.
function getdpi() {
var e = document.body.appendChild (
document.createElement ('div'));
e.style.width = '1rem';
e.style.padding = '0';
var v = e.offsetWidth;
e.parentNode.removeChild(e);
return v;
}
I will have to time to do some tests tonight and see if that works..
Another option would be to use SVG to get proper scaling of the ruler,
and that will probably render faster than using a canvas.
Tim Chien
May 16, 2013, 11:02:18 PM5/16/13
to pancake, dev...@lists.mozilla.org
I tried to illustrate what I meant here: http://jsfiddle.net/timdream/ewJZZ/
It should help you to get a better picture with CSS units.
On Thu, May 16, 2013 at 7:03 PM, pancake <pan...@youterm.com> wrote:
> On 05/16/13 06:11, Tim Chien wrote:
>>
>> Hi Pancake,
>>
>> If you read the CSS spec carefully, you would find that on a screen,
>> these real-world units doesn't have to be sized in the same way on a
>> physical ruler (though on paper it should).
>>
>> http://www.w3.org/TR/CSS21/syndata.html#length-units
>>
>> If you are looking to size an HTML element with physical size, the
>> non-standard mozmm is the unit you are looking for -- but I am pretty
>> sure we didn't set the Gecko pref() right on all devices for all FxOS
>> devices. We should file bugs on that.
>>
>> MDN is more understandable than the spec on this topic:
>> https://developer.mozilla.org/en-US/docs/Web/CSS/length
>>
>
> I've tested mozmm on desktop (looks fine), but it doesnt works fine on Peak
> or Keon. Should I fill a bug for that?
>
Yes, please do. Someone probably already filed that.
FxOS underneath should expose correct dpi information so Gecko would
draw the unit correctly on these small screens.
However, even if the bug is fixed, you should probably avoid using the
unit because it's not widely supported on the web. It's not a "safe"
unit to depend on for web app engineering, nor FxOS web app
engineering, if the latter even exist :-/
> In the "browser compatibility" doesnt appears 'mozmm', but testing on iphone
> it's not supoprted (acording to this table, mozmm should work on safari too)
> (mobile safari is not listed).
No. 'mozmm' is a prefixed unit that only worked on Gecko.
> Is this a bug in the configuration of the keon/peak? or should i avoid
> depending on phisical sizes? I don't understand why 'cm' or 'in' units
> exists in CSS if they are not honored on any platform/browser..
They are indeed honored, if you, say, print out the web pages on a
physical A4, or letter sized, paper (whichever office paper size
scheme your country is using).
On screens, they don't make sense to you because you are only think of
small screens on mobile devices.
The web runs on plenty of devices and screen, e.g. laptop, external
screen, big out-door screen, projectors, etc.; some of them doesn't
even exists yet.
> The other way I thought is .. make this device-independent. But I will need
> a way to know in which device I'm running. Which API should I use to get
> this information?
>
> Thanks
>
> --pancake
It should help you to get a better picture with CSS units.
On Thu, May 16, 2013 at 7:03 PM, pancake <pan...@youterm.com> wrote:
> On 05/16/13 06:11, Tim Chien wrote:
>>
>> Hi Pancake,
>>
>> If you read the CSS spec carefully, you would find that on a screen,
>> these real-world units doesn't have to be sized in the same way on a
>> physical ruler (though on paper it should).
>>
>> http://www.w3.org/TR/CSS21/syndata.html#length-units
>>
>> If you are looking to size an HTML element with physical size, the
>> non-standard mozmm is the unit you are looking for -- but I am pretty
>> sure we didn't set the Gecko pref() right on all devices for all FxOS
>> devices. We should file bugs on that.
>>
>> MDN is more understandable than the spec on this topic:
>> https://developer.mozilla.org/en-US/docs/Web/CSS/length
>>
>
> I've tested mozmm on desktop (looks fine), but it doesnt works fine on Peak
> or Keon. Should I fill a bug for that?
>
FxOS underneath should expose correct dpi information so Gecko would
draw the unit correctly on these small screens.
However, even if the bug is fixed, you should probably avoid using the
unit because it's not widely supported on the web. It's not a "safe"
unit to depend on for web app engineering, nor FxOS web app
engineering, if the latter even exist :-/
> In the "browser compatibility" doesnt appears 'mozmm', but testing on iphone
> it's not supoprted (acording to this table, mozmm should work on safari too)
> (mobile safari is not listed).
> Is this a bug in the configuration of the keon/peak? or should i avoid
> depending on phisical sizes? I don't understand why 'cm' or 'in' units
> exists in CSS if they are not honored on any platform/browser..
physical A4, or letter sized, paper (whichever office paper size
scheme your country is using).
On screens, they don't make sense to you because you are only think of
small screens on mobile devices.
The web runs on plenty of devices and screen, e.g. laptop, external
screen, big out-door screen, projectors, etc.; some of them doesn't
even exists yet.
> The other way I thought is .. make this device-independent. But I will need
> a way to know in which device I'm running. Which API should I use to get
> this information?
>
> Thanks
>
> --pancake
pancake
May 20, 2013, 6:14:55 PM5/20/13
to dev...@lists.mozilla.org
Didnt worked for me :/ peak and keon draw different physical font sizes.
Is there any reliable way to identify the device model (or b2g target build) from javascript? That will allow to load different css depending on device.. That will look like fragmentation, but looks like there's no clear way to solve this on all platforms.
Is there any reliable way to identify the device model (or b2g target build) from javascript? That will allow to load different css depending on device.. That will look like fragmentation, but looks like there's no clear way to solve this on all platforms.
Tim Chien
May 20, 2013, 9:52:32 PM5/20/13
to pancake, dev...@lists.mozilla.org
Please don't work on your app around Keon and Peak just because they
are the only publicly available devices!
They are developer phones, so you really need to workaround its bug if
there are any.
If you come this far to dev-b2g, you should learn that you could
actually re-flash your phone with the latest open source codebase --
most of the quirk behavior should go away, and you should aim your app
to work with that build.
are the only publicly available devices!
They are developer phones, so you really need to workaround its bug if
there are any.
If you come this far to dev-b2g, you should learn that you could
actually re-flash your phone with the latest open source codebase --
most of the quirk behavior should go away, and you should aim your app
to work with that build.
Tim Chien
May 20, 2013, 10:17:02 PM5/20/13
to pancake, dev...@lists.mozilla.org
On Fri, May 17, 2013 at 11:02 AM, Tim Chien <timd...@mozilla.com> wrote:
>>> If you are looking to size an HTML element with physical size, the
>>> non-standard mozmm is the unit you are looking for -- but I am pretty
>>> sure we didn't set the Gecko pref() right on all devices for all FxOS
>>> devices. We should file bugs on that.
>>>
>>> MDN is more understandable than the spec on this topic:
>>> https://developer.mozilla.org/en-US/docs/Web/CSS/length
>>>
>>
>> I've tested mozmm on desktop (looks fine), but it doesnt works fine on Peak
>> or Keon. Should I fill a bug for that?
>>
>
> Yes, please do. Someone probably already filed that.
> FxOS underneath should expose correct dpi information so Gecko would
> draw the unit correctly on these small screens.
>
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=874295 for
>>> If you are looking to size an HTML element with physical size, the
>>> non-standard mozmm is the unit you are looking for -- but I am pretty
>>> sure we didn't set the Gecko pref() right on all devices for all FxOS
>>> devices. We should file bugs on that.
>>>
>>> MDN is more understandable than the spec on this topic:
>>> https://developer.mozilla.org/en-US/docs/Web/CSS/length
>>>
>>
>> I've tested mozmm on desktop (looks fine), but it doesnt works fine on Peak
>> or Keon. Should I fill a bug for that?
>>
>
> Yes, please do. Someone probably already filed that.
> FxOS underneath should expose correct dpi information so Gecko would
> draw the unit correctly on these small screens.
>
this, although I haven't rule out this is a Geeksphone only issue
(will do it now on Unagi)
pancake
May 22, 2013, 11:49:26 AM5/22/13
to Tim Chien, dev...@lists.mozilla.org
On 05/21/13 03:52, Tim Chien wrote:
> Please don't work on your app around Keon and Peak just because they
> are the only publicly available devices!
>
> They are developer phones, so you really need to workaround its bug if
> there are any.
> If you come this far to dev-b2g, you should learn that you could
> actually re-flash your phone with the latest open source codebase --
> most of the quirk behavior should go away, and you should aim your app
> to work with that build.
device specific is always ugly... dunno. maybe i can try to guess
> Please don't work on your app around Keon and Peak just because they
> are the only publicly available devices!
>
> They are developer phones, so you really need to workaround its bug if
> there are any.
> If you come this far to dev-b2g, you should learn that you could
> actually re-flash your phone with the latest open source codebase --
> most of the quirk behavior should go away, and you should aim your app
> to work with that build.
thanks for opening the bug, hopefully it will be fixed if the devices
report the proper DPI information. Will wait until the bug is closed to
continue my 'ruler' app :)
--pancake
0 new messages