This is a question from the past and it was raised a bit strange. But the answer below is more than relevant.

Shoveled a dozen articles, I began to realize that ppi - a big stick in the wheel. How to deal with it is not yet clear.

So, we have an elementary page: jsfiddle.net

We want 14px (for example) - as the main font size. Suppose that it was in the PSD from the designer. From this we will make a start.

We turn around all the content in div.font-size-setting , which we set the font-size: 1.4em (since after normalization we had 10px ).

We look at the page from different devices:

alt text

If there were iphone4, the font and the square would be even smaller. The problem is obviously a big difference in ppi ( pixels per inch ) devices. Regular monitors have 96ppi . Do iphone3 163ppi . Whit 220ppi .

The obvious solution is to determine the ppi device and increase the font. There are no problems with the latter. We set in div.font-size-normalize and depending on the dpi set the appropriate font: jsfiddle.net

We get:

div.font-size-setting - to set the font size from the designer,

div.font-size-normalize - we make this font of the same size (visually) on all devices.

alt text

Yablofon slightly stretched the font itself or increased the distance between the lines, but in fact it all fits. Anyway, the square with the dimensions in em is the same everywhere, even with a ruler.

The question is how to determine ppi ?

1. media queries - resolution Media queries are able to determine not only the width and height, but also many other characteristics, including dpi ( dots per inch ). In general, dpi is a meaningless parameter for the display, since it is a parameter for printing by the printer, but in our case it is the same as ppi .

I decided that it would not be bad to take a step at 0.1em . This is approximately every 10ppi . Taking our 96ppi for 1em made up a tablet and counted the range so that the values ​​of interest are in the middle. Made requests:

  @media screen and (min-resolution: 90dpi) and (max-resolution: 100dpi) { .font-size-normalize { font-size: 1em; /* normal desktops */ } } @media screen and (min-resolution: 101dpi) and (max-resolution: 111dpi) { .font-size-normalize { font-size: 1.1em; } } @media screen and (min-resolution: 112dpi) and (max-resolution: 122dpi) { .font-size-normalize { font-size: 1.2em; } } /*...*/ @media screen and (min-resolution: 158dpi) and (max-resolution: 168dpi) { .font-size-normalize { font-size: 1.7em; /* iphone3 */ } } /*...*/ @media screen and (min-resolution: 216dpi) and (max-resolution: 226dpi) { .font-size-normalize { font-size: 2.3em; /* ps vita */ } } /*...*/ @media screen and (min-resolution: 322dpi) and (max-resolution: 332dpi) { .font-size-normalize { font-size: 3.4em; /* iphone4 */ } }

http://jsfiddle.net/AHzYJ/3/

Recent versions of desktop browsers have worked through media queries. Browsers iphone3 and ps vita are not mastered. I think the last apple apples, apple pads, droid players will still cope, but nevertheless the solution is far from bulletproof: (

2. media queries - devicePixelRatio and the canonical pixel dip - density(device)-independent pixel - something like a canonical pixel. Equal to one physical pixel at 160ppi . On the other hand, we have the devicePixelRatio parameter, which can be used as an argument of a media query relative to the canonical pixel:

 @media screen and (device-pixel-ratio: 1) {}

You can write a lot of queries similar to the example above:

 @media screen and (min-device-pixel-ratio: 1) and (max-device-pixel-ratio: 1.1) { .font-size-normalize { font-size: 2.3em; /* ps vita */ } }

But I haven’t really done it for any device / computer / browser. It seems that this parameter can only be an integer: unit - for iphone3 , deuce - for iphone4 . Moreover, vendor prefixes are required, which at least indicates a lack of cross-browser or cross-device design. Another inconsistency is that the “ device-pixel-ratio: 2 ” (meaning 320ppi ) works on iphone4 , which has 326ppi .

3. JS

 alert(window.devicePixelRatio);

I think it works in the same way as the second method. On iphone3 I saw "1", as well as in the desktop browser and on Windows, which is of course nonsense. Iphone4 showed "2", but after the previous files it does not matter anymore. Another problem: the brakesill failed and showed undefined .

4. Compiled JS functions defining ppi . Something like take device-width and divide by width . It works on mobile devices, since you cannot flatten the browser window, but in the desktop browser we can simply reduce the window size and everything will break.

In the end, I did not find a single full-featured solution. I think it just has to take time until the " device-pixel-ratio: n " will be understood by all. In the meantime, you need to figure out how to maximize the number of successful ppi definitions. After all, the methods described above are partially, but still work.

Who thinks what about this, what solutions can be offered and how can you summarize the above methods into one half-working option?

  • five
    And what is the final meaning of operations? After all, on mobile devices for these purposes zoom is used. It's one thing that the text is readable at the initial zoom, and another thing is that the whole page fits on the screen - five iPhones are not enough to display, say, Yandex.Ru with a monitor. therefore, they also share the mobile version of the site and the usual one, that not only a different font is used, but also the layout is different. By the way, will you scale the pictures in the same way? - Yura Ivanov
  • 2
    In fact, it is a lotion for adaptive layout in a welded sense (according to Itan Markot, depending on the width). Zoom is not appropriate there, because then adaptive layout is not needed at all. I want to develop in such a way that the user does not want to zoom at all. About the rest of the elements, yes, firstly adaptive layout, secondly dependence on ppi. For a smart, such layout, you should always keep a parameter at hand - some kind of factor by which all sizes will be multiplied. It would be possible to start a SASS variable, for example, but we already have a native natural factor — the font size. - Cypher
  • Line #logo {width: 8.714285714285714em; } may seem wild at first glance. But why not? The designer drew a 122px logo with a 14px font. We translated 122px to em and set this size. Desktop users will see the 122px logo. Iphone3 users will see the logo at 207px, since the coefficient for them is 1.7em, but it will be the same size. Similar to the square in my first example. Here, of course, there are other problems: it can be slightly wasteful, take the user iphone3 207px to the logo, but this is solved by media requests for width. - Cypher
  • I understood the idea, did not understand the practical application. For example, Yandex, for example, instead of zooming, you will have scrolling at best, vertical (with floating layout), or even horizontal, in addition. but the logos, besides that do not fit the width of the iPhone, will apparently also be scaled without smoothing. If you take, for example, applications for android, then under each ppi they make their own resources - both pictures and markup ... SASS variables look, by the way, a more systematic approach. - Yura Ivanov
  • Turning a few days began to doubt such a strong dependence on em. I constantly rest on the fact that there is no connection with the width. As for the main mass of graphic elements and blocks, yes, either percentages and rubber (regular or in resolution ranges) or pixels and more media queries. Thinking about your words, he calmed down the ardor :) This one works well when there is no dependence on width. For example, when we typeset a mobile version or use an HTML5 framework like sencha touch for mobile applications. - Cypher

1 answer 1

After some time, I came to the conclusion that it is necessary to work on the second method I proposed. The essence of the Rabta is approximately the following. The site is made up "as usual", all sizes are given in pixels. Only now width: 100px does not mean a width of 100 physical pixels of the display. These are 100 some abstract pixels (device independent pixel). And then the operating system (or browser) already decide how to display one such abstract pixel on the display. The devicePixelRatio parameter helps them in this. If this parameter is equal to one, then the abstract pixel is shown one-on-one with the physical pixel. If it is equal to two, then a square of four pixels is used.

If we take a random site that is not optimized at all for high pixel density displays, it will not compress on the retina. It will appear as on a regular display.

It turns out that the dimensions do not need to be monitored. Widths, heights, borders, shadows, etc. can be set in regular pixels. And not worried about what will be there on the retina. But over the graphics will have to sweat. Pictures on devices with high pixel density look stretched. They should be replaced with pictures enlarged in the appropriate number of times. For example.

 div { background: url(cake.png) no-repeat center top; } @media screen and (-webkit-min-device-pixel-ratio: 2), screen and ( -moz-min-device-pixel-ratio: 2), screen and ( -o-min-device-pixel-ratio: 2), screen and ( min-device-pixel-ratio: 2) { div { background-image: url(cake@2x.png); background-size: 100%; // или вариации } }
  • four
    Modern syntax query for pixel density: @media (min-resolution: 2dppx) . - Cypher