rem

There is no need to go into rem here. If you are interested, you can read the first Day of the Responsive Decameron: Using REM to Set text Size, which gives a detailed introduction to REM.

use

Responsive layouts are especially important in wireless development, not to mention the increasing variety of screen sizes on the iPhone, but android alone has a myriad of sizes to accommodate.

Before REM, it was very difficult to adapt the different resolution 1 as the designers wanted. With REM, things are much easier, you can use it to set the width, height, spacing of elements… , then calculate and set the corresponding root font size for different resolutions, and then the elements automatically adapt to the current resolution as if scaled, greatly reducing the adaptation work.

The Demo:

The image above shows the same page on Apple iPhone 5 and Samsung Galaxy S4. From the 320px iPhone 5 to the 360px S4, the image looks like equal proportion enlargement. Let’s analyze the principle:

Assume that the root font size is 32px at 2 width=320px.

  • Width =320px

The root font size is 32px, so an element 1rem wide at this resolution would be 1 * 32 = 32px in the browser;

  • Width =360px

The true width of an element 1rem wide in the browser should be 32 * (360/320) = 36px to achieve the effect of proportional scaling, so the root font size at the resolution width=360px is 36px.

This shows that proportional scaling is achieved by controlling the root font size, which is proportional to the screen width.

Fractional pixel

In the example above, 1rem is 32px at width=320px and 36px at width=360px, both integers.

What if it’s 1.75rem?

IPhone 4/4s/5/5s 320px 56px Samsung Note 3, Nexus 5… 360px 63px iPhone 6 375px 65.625px Google Nexus 6 412px 72.1px iPhone 6 Plus 414px 72.45px

You can see that some models have decimal pixels, so how do browsers deal with decimal pixels?

As shown in the figure, each color block in the first group is 1.75rem x 1.75rem, and each color block in the second group is 1.85rem x 1.85rem;

But the actual render sizes are different: some are 66px wide, some are 65px wide, and the order is random.

This results in confusion for me, if the browser is uniformly rounded, then all the color blocks should be the same size, not rounded up and rounded down.

After a long and fruitless period of thinking, I made a bold assumption that the rounding done by the browser at render time only applies to the render size of the element, and the actual space occupied by the element is still the original size.

This means that if an element is 0.625px, the render size should be 1px, leaving 0.375px space filled with adjacent elements. Similarly, if an element is 0.375px, the render size should be 0, but it takes up 0.375px of the adjacent element. Thus, the following ideas were verified:

  • The width of the first color block is 65.625px, and the final rendering size is 66px according to the rounding principle. The 0.375px space is filled by the second color block.
  • Add 0.375px to the left of the second color block, which is equivalent to a reduction of 0.375px, leaving 65.25px. The final rendering size is 65px according to the rounding principle, and the extra 0.25px will occupy the space of the third color block.
  • The third color block is taken up by 0.25px, which is equal to 65.875px. The final rendering size is 66px according to the rounding principle. The 0.125px is filled by the fourth color block.
  • The fourth color block has been added 0.125px to the left, which means that it has been reduced by 0.125px to 65.5px. The final rendering size is 66px according to the rounding principle, and the remaining 0.5px is filled by the fifth color block.
  • The fifth color block is added 0.5px to the left, which means that it is reduced by 0.5px to 65.125px. The final rendering size is 65px, which is 0.125px more according to the rounding principle. This is exactly the same as the browser output, showing that the browser is not rounding the decimal pixels directly, the elements are still occupying the proper space, only rounding the elements when calculating the size (this hypothesis was later confirmed by the LayoutUnit — WebKit document).

You can test the second set of blocks using the above principles and then compare the results.

The problem

At present, the most common problem is the background-image problem, which often causes part of the background image to be cut out because of the decimal pixels.

The figure above shows the effect of the same group of ICONS in different models. It can be seen that some of these ICONS are more or less cut out in iPhone 5 and Galaxy S4 because of decimal pixels, which can be seen from Computed Style of elements.

To solve

How to avoid this problem? Here are two suggestions:

  • Use iconfont;
  • If background-image is needed, try to set a certain blank space for the background image, as shown in the figure below:

summary

It’s not just background-images that can cause problems with decimal pixels. There are other bugs that haven’t been encountered yet, but once you understand how browsers handle decimal pixels, these problems become manageable and solvable.

Note:

  • The resolutions in this article refer to browser resolutions. For the relationship between logical resolution and physical resolution, please refer to: what are “pixels”, “rendered pixels” and “physical pixels”? How are they related? ;
  • In order to ensure that the root font size calculated under most resolutions is an integer, the formula for calculating the root font size is: resolution width / 10;

Fed.taobao.org/blog/2015/1…