preface
A lot of the company’s business is still stuck in the stage of using PX and flexible layout for style processing, sometimes because of visual requirements, sometimes because of the fear of online problems, so called “break before you break”.
Mobile adaptation solution is a platitude topic. However, different projects and service scenarios may require different adaptation solutions to implement mobile adaptation. The baseline of downward compatibility needs to be set in advance.
High overall width
In fact, the mobile adaptor is just like the following toy, and the corresponding shape can be stuffed into the corresponding container. There is a slight problem, though, that the blocks may not be the same size as the container, and for the front end, the blocks are not made of wood, they should be made of plasticine.
The business environment is the core factor that determines the fit of the overall project. How many environments a set of code needs to be compatible with is determined at the beginning of the project architecture.
On Github, the world’s largest dating site for programmers, all content is clearly limited to a 980-pixel content area.
Its mobile terminal is also clearly a separate layout, the overall width is no longer limited, even iPad Pro width of 1024 pixels, it will still take up the entire screen.
The main site of Taobao is similar to Github, which is divided into mobile page and PC page. The PC page also has left and right white space, so that users can focus their attention on the middle area when the screen is wide.
Currently, most sites use UA to identify users’ devices and then direct them to PC or H5 pages.
The only difference is that Taobao more rigorously redirects pages directly to another link, while Github loads a different CSS file for rendering. Of course, there is no essential difference between the two solutions, and separate H5 pages can be reused better within the client station.
So, if you have enough developers, developing pages for both device types is a friendly solution. If your mobile client is developed based on a WebView, the H5 page can also be embedded directly into the WebView for presentation.
The width of the adaptation
Normal mobile devices have a good aspect ratio for overall width, but devices like the iPad are so wide that normal H5 pages look strange on them. For example, in the display effect of taobao’s main website on iPad, we can see that the navigator on the upper and lower two parts are much elongated, resulting in poor effect. But considering the cost, iPad users are more likely to use apps for access, so the style of the H5 page is less important. Github Mobile does a better job of accommodating widescreen devices.
If you are interested, you can go and have a look at taobao’s H5 page. There is a very interesting place on this page. This place will be mentioned later.
Setting the maximum width of the screen will make it look good on a widescreen device, except that you need to think about what to do with the white space.
With a fixed maximum width, only devices with white space beyond the width need special treatment (background, function buttons, etc.), and the portion with the maximum width in the middle can be reused.
viewport
This blog of Koala team has been very clear, thanks to koala’s partners to provide us with cheap overseas shopping and such a good document output LOL:
PC
In desktop browsers, the normal viewport width is the width of the entire browser window, which is scaled as the browser window shrinks. By default, HTML tags fill the entire viewport if static width of the HTML is not set.
If you use the maximum width of the PAGE on the PC as described above, then zooming outside the maximum width of the viewport does not affect the display of the visible area, but if the page is smaller than the maximum width, the layout of the original page is important. Elastic layouts and percentage layouts ensure that the layout does not crash when the page shrinks.
Layout viewport
On mobile, viewports are no longer related to the width of the mobile browser, but are completely independent. We call this a layout viewport.
The entire page may become so large that only part of it appears in the visible area of the device. The size of the entire page is called a Layout Viewport. This size can be through the document. The documentElement. ClientHeight/clientWidth to obtain.
This early PPK article gives a very clear description of the viewport.
As you can see from the above image, the width and height of the Layout Viewport are variable. The Layout Viewport changes when the page is zoomed to the same size as the visible area of the device. Layout Viewport is exactly equal to Visual Viewport.
Visible viewport
Visual Viewport is the size of the visible area of the screen. Since the physical pixels of the device, the PT units in the CSS, are fixed, the distribution of CSS pixels in the page changes on the device after the page is scaled on the mobile.
Ideal viewport
The Ideal Viewport is a combination of the two. When we set the Layout Viewport width to the width of the screen, we keep the CSS pixels on the page constant.
This TAB ensures that on mobile devices, the page width is the same as the screen width.
The zoom
When zooming in on a phone, the CSS pixels on the page remain the same, but the ratio of pixels in the viewport changes, but disabling zooming can result in a poor experience for some users. Keep the scale within a certain range.
The overall layout
Based on the above content, combined with the current business content — mainly for mobile devices, the maximum width is set and the ideal viewport is set in the meta tag to ensure the overall layout effect on mobile devices and PCS.
Content layout
The current content layout for mobile devices looks like this:
- Percentage, all elements that need to be dynamically adjusted are in percentage width and height, and the font size is fixed in pixels.
- In REM, the ratio of device pixel to CSS pixel is obtained through calculation or JavaScript to determine the font pixel of the root element, and then all units are set in REM according to the font pixel of the root element to determine the size. Base REM changes depending on the device.
- Vw, according to the Visual Viewport width of the current device as 100VW, and then get the width of the unit VW. All elements are arranged in style according to the unit VW.
- Media Query: Use breakpoints to style devices of different widths.
Each of the above methods has its own advantages, so let’s take a look at the effect in practice:
The percentage
Using percentages as a yardstick for content size is fine in most cases, and they do a good job of keeping elements in their place, regardless of screen width.
However, there is a very big problem with the text. Because the text is a fixed size, when the SCREEN DPR changes, the CSS pixel of the text does not change, which leads to the change of the text in the page. As a result, overflow occurs when there is too much text or the screen DPR is too small; However, if you take the small screen as the benchmark, the font size is too small.
Percentages are more compatible with typesetting as section-level elements when applied to current mobile devices. This is also related to the effect of the design. If the design requires a fixed width for an element, use PX to ensure the width.
rem
Rem is a unit similar to em, except that rem and a relative value are computed based on the font size of the root element. Em has a number of drawbacks, such as the possibility of forgetting how big the font size of the previous layer was when you nested layers. Or like today’s modular development, one route is nested within another, and even the parent element has to be found in another file.
To address the em problem, there is also a rem unit in the standard to help with typesetting. All element sizes are in REM, and then in the root element of the page, we explicitly assign font size to the root element, so that all REM units have the same explicit benchmark. When the screen ADAPTS, just adjust this base value to ensure that the size of each element automatically scales.
Ali’s Lib-Flexible solution actually takes advantage of this approach by binding font size and data-dPR attributes to the < HTML > tag to adapt the entire page.
The solution divides the entire page width into 100 portions. The reason for the 100 portions can be seen in another solution below. Every 10 units of width is 1rem, so the width of the artwork is divided into 100 pieces of 10rem. If the artwork is 750px, then 1rem represents 75px. In this way, the scaling coefficient is 75/750, which means that only the pixel value of the design /10 can be used to obtain the corresponding REM value every time the design is converted to CSS.
Through a preloaded JavaScript, calculation of the root node font size, document. DocumentElement. Style. FontSize = window. The innerWidth / 10 + ‘px’; , and then when we write the page code, we just need to take the original pixel value/reference value to get the corresponding REM units. Of course it’s not going to work every time you have to hit the calculator. For ease of use, you can use preprocessors like Less or Sass to process pages.
@function px2rem($px)
// Convert the px of the design to REM,
@return ($px / $unit-px) * 1rem
// Adjust font according to device DPR
@mixin font-dpr($font-size)
font-size: $font-size
[data-dpr="2"] &
font-size: $font-size / 2
Copy the codeIn addition to the element width and height can be restored well, the adaptation of text size is also important. Due to the different DPR of each device (especially iOS devices), many text can be displayed normally on iPhone6+, but the text is too large on iPhone5, resulting in text overflow. Less Mixin above is for font style adaptation.
This method combines the functions of SASS and REM adaptation, plus the necessary percentages and media Query to get better movement performance.
This is how it looks on the iphone6 using this method. The overall display can be seen here, in an example of the rem benchmark style
If you are not satisfied with how the text looks on various platforms, you can use the sass mixin mentioned above to render the text according to the DPR breakpoint.
The problem with this is that it is only applicable to mobile terminals, and landscape adaptation is not possible, because the width of the page changes after landscape, but the baseline value remains the baseline value originally bound to the root node.
Vw (the final solution?)
First of all, let’s take a look at the browser support of VW. Can I use VW support. Using this unit means that you give up PC users below IE11. The weird resolutions and 2x and 3X screens on mobile, as well as the miserable iPad landscape screen, make me want to make a leap every time I try compatibility.)
Vw itself divides the whole viewport into 100 parts horizontally, and each unit is 1VW. The biggest advantage of this unit is that on the mobile terminal, no matter in portrait or landscape, VW is always aimed at landscape. Better than REM’s scheme, it doesn’t crash when the screen size changes (which incidentally is compatible with future mobile devices with adjustable screen size [manual squint]).
For mobile devices, such as iphone6+ 375pxCSS pixel width, 1vw is equal to 3.75px. This unit can solve the above problem of script binding root element font size, and has good effect in portrait and landscape.
After vw decouples CSS and JS, can VW solve all problems by itself?
// First of all, the width of our design draft is currently 750px, which is actually 375px of iPhone6+ as the benchmark
$w-base: 375px
$w-base-design: 750px
@function px2vw($px)
@return ($px / $w-base-design) * 100vw
Copy the codeFirst, the sASS code above can be converted to VW units based on the px units on your design. Of course, the easiest way is to input directly according to the pixels above the visual draft, and then directly output the corresponding VW value. Vscode and sublime will of course have plugins already in place, but personally I don’t like them so much that you won’t be able to get the original pixel value of the artwork. In the later maintenance will add a lot of trouble. This is good to write, to change the crematorium… The effect of vw can be seen in the codepen below.
vwImplementation of the same adaptation page
So the pros and cons
At present, VW is definitely not suitable for use alone, after all, there are still many elements in the page that need absolute size positioning. Px is always essential and vision can’t make everything you own adaptive.
So what problem does VW solve? The first is to replace the majority of % in THE CSS, percentage in the CSS there are many ambiguities, for width, upper and lower margins, left and right margins, inside and outside margin processing is not the same. Even seasoned frontend sometimes have to think about what the current percentages are based on. Vw is an absolute number, based only on a screen width that is unlikely to change.
And the elasticity problem that percentage mainly solves is the problem that VW focuses on solving.
Vw cannot take care of all situations, so this unit is not the final solution at present. We still need to cooperate with other units to help the page display more gracefully.
conclusion
CSS compatibility lies not in the interpreter, but in the screen of the device. Most of the time it’s not just about putting the page in front of the user, it’s about presenting the page to the user in a stable and elegant way.
No matter the percentage, REM or VW, they all locate local container elements. As the lowest leaf element or unit element, PX is used more time to restore the visual draft as far as possible.
Considering this problem in the long run, VW will achieve better results when only mobile terminal access is carried out, because compatibility is not considered, only adaptation needs to be considered. Which method to use in a project depends on the environment compatible with most business needs.