This is the second article in the H5 Must-Know, Must-know series. As we mentioned, “H5” is supposed to be short for HTML5. However, in China, “H5” is not simply an abbreviation for HTML5. It is more commonly used to refer to web pages embedded in mobile apps. Regardless of whether there is a term “H5” in foreign countries (it should not be), you can say it is “H5” when it comes to the webpage or web application embedded in App in China. Say “H5” and product managers, designers, Android/iOS app developers, back-end engineers all know it.

I have to say, this phenomenon is amazing. Perhaps, in the eyes of those outside the front-end industry, a web page on a mobile screen should have a different name than a page on a big screen. In fact, even in the front-end development industry, having a term that allows us to instantly locate an application form is a very convenient thing to do.

So how does a web page on a mobile phone differ from a web page on a big screen?

First of all, the web page on the mobile phone runs in the mobile browser or the WebView embedded in the App, which can use the unique hardware capabilities of the mobile phone, such as GPS, accelerometer, gyroscope and other sensors. In addition, if the JSSDK of the host App is loaded, you can also access the various capabilities that the App exposes to the web page, such as getting information about the logged-in user, taking photos, uploading and sharing, and so on.

Secondly, web layout Design on mobile phones should be subject to the Interface (UI) Design specifications of native apps, such as Google’s Flat Design, Apple’s Human Interface Guide, etc. In short, a web page on a mobile phone must look like a native App interface, including the use of the same layout components, font ICONS, color schemes, and even interaction modes, such as touch rather than mouse click interaction.

Finally, web pages on mobile phones, especially those running inside apps, are part of a hybrid mobile App that often needs to interoperate with native apps. H5 and native applications need to jointly agree on the basic interface, and determine the specific interaction mode for specific interaction scenarios, including one-way or two-way invocation, synchronous or asynchronous, how to transfer data and credentials, and so on.

The third point mentioned above is exactly the content discussed in the first article of this series “H5 Must-know must-know App interaction”, for interested students to refer to later. Today, this article will focus on the second point above, that is, how H5 can construct a page layout in a realistic, pixel-level way.

Adaptation and reduction: concept elaboration

To say restore, must begin with adaptation.

H5 adaptation mainly has two dimensions:

  • Suitable for different pixel densities
  • Suitable for different screen sizes

Pixel density, as the name suggests, is the number of physical pixels per pixel in CSS. Various generation we to the iPhone screen contrast diagram (source: www.paintcodeapp.com/news), for example:

Start with the iPhone Xs Max and iPhone XR. The former screen measures 414×896 in CSS pixels, and 1242×2688 in actual rendered physical pixels. Simple calculations show that 1242/414 = 3 (or 2688/896 = 3). In other words, the iPhone Xs Max is what people call a 3x screen (or @3x), which is nine physical pixels per CSS pixel (because it’s all three pixels wide and high). The iPhone XR, on the other hand, has what’s often called a 2x screen (or @2x), with four physical pixels per CSS pixel.

And, of course, 1 screen. The last iPhone 2G/3G/3GS in the image above is a 1-x screen, which means there is one physical pixel for every CSS pixel. The original iPhone, which is expected to be extinct, doesn’t need to be adapted because every CSS pixel is a physical pixel on the screen. (Of course, laptops and add-on screens are still 1x, so we don’t need to adapt pixel density just yet.)

When we talk about adaptive pixel density, we usually refer to how images can be displayed on 3x and 2x screens without distortion. Of course, the principle of adaptation is simple: for every image pixel, there is no distortion. To be specific, if the original image is 500×300 pixels (such as [email protected]), then the high-density version is 1500×900 pixels (such as [email protected]) and 1000×600 pixels (such as [email protected]). In this way, every physical pixel corresponds to every image pixel.

Of course, there is a simple and crude adaptation, which is to provide only the highest resolution images for all screens. While low-density screens don’t use as many image pixels, and waste bandwidth and download delays by downloading extra pixels, the result is that images are not distorted on any screen.

The specific technical solution of adapting pixel density is ignored in this paper because it is not the focus of this article. The focus of this article is really adapting to different screen sizes. The principle for accommodating different screen sizes is simple: make sure the page layout is measured in proportion to the screen size.

Sounds simple, but it’s not easy to do. Because here is involved in the design of the problem. For example, a design is usually 750 pixels wide:

At this width, each page component has its own metric. For example, the title “Speak to speakers” measures 112×28 pixels:

The top, right, bottom, and left of the header are 38, 289, 394, and 289 pixels from the current component’s boundary, respectively:

Of course, there are defined pixel measurements in this design for each component to the screen boundary, component to component, and even text size and spacing. The question is, how do we restore all the pixels in the H5 page?

The answer is simple: scale back.

Using the previous design as an example, we know that the design assumes a screen width of 750 pixels (actually it doesn’t matter how many pixels as we are scaling the design), and that the rounded rectangle component is 690 pixels wide, as shown in the following images:

It is 30 pixels away from the top (30 pixels away from the left and right edges) :

With these pixel data, after simple mathematical conversion, it is not difficult to conclude:

  • Component width as a percentage of screen width: 690/750 = 0.92, or 92%;
  • Components on, right, and left margins as a percentage of screen width: 30/750 = 0.04, or 4%.

Now, if we can get the WebView to render at this scale, our component will be able to render at the pixel level of the design — all the pixel measurements of the component and its children will be exactly the same as the design on a 750-pixel wide screen!

More importantly, even if the screen is not 750 pixels wide (in fact, there is no such thing as a 750-pixel mobile screen, note that I’m using CSS pixel widths), the layout of the page will still fit perfectly to the scale of the design, meaning that every aspect of the page will appear larger on a larger screen. On a smaller screen, the entire layout is scaled down.

In fact, in addition to width, height, and spacing, measures like text size (that is, font-size), borders, and shadows can also be used to convert pixels to percentages along the same lines.

Ok, so that’s the concept of adaptation and reduction. Let’s move from concept to practice and take a look at how this works technically.

A global CSS unit

The concept described in the previous section mentioned that proportional adaptation can achieve pixel-level restoration of the design. But is it possible to use percentage units directly in CSS in practice? Unfortunately, no.

We know that CSS Values and Units Module Level 4 (www.w3.org/TR/css-valu…) Definition:

The percentage value is always relative to something else, like length. Each attribute that allows the use of a percentage value also defines the quantity to which the percentage value refers. This quantity can be the value of another attribute of the same element, an attribute of an ancestor element, or even a measure of the formatting context (such as the width of the containing block).

So we also know:

  • Width (width), height (height), spacing (maring/paddingPercentage values are supported, but the default relative reference value is the width of the contained block;
  • Border (border) does not support 100 points;
  • Border fillet radius (border-radiusPercentage values are supported, but the horizontal relative reference value is the width of the box, and the vertical relative reference value is the height of the box;
  • Text size (font-sizePercentage values are supported, but relative reference values are parent elementsfont-sizeThe value of the;
  • Box shadow (box-shadow) and text shadows (text-shadow) does not support percentage values;
  • …

As you can see, even if the percentage value is supported, the percentage reference value is not the screen width we want! In other words, to achieve screen-level adaptation, there must be a unified global unit to refer to. Do we? There is.

First of all, we have rem. Also, according to CSS Values and Units Module Level 4 (www.w3.org/TR/css-valu…) :

Rem is equal to the computed value of the font-size attribute of the root element (that is, the HTML element).

Rem is ultimately a font size, but it is a global unit of measurement, and behind it are pixels. If for fit purpose, according to the value of different screen density dynamic modification of rem (for example, the document. The documentElement. Style. FontSize = rem + ‘p’), not can be achieved in proportion to the adapter? In fact, alibaba mobile Taobao team developed a framework specifically for this: github.com/amfe/lib-fl… . According to the Github repository, the framework took a little over two years, and was officially retired in early 2019. Because we found a new and better global reference unit: VW.

What is VW? CSS Values and Units Module Level 4:

Vw is equal to 1% of the width of the original containing block (HTML element).

In other words, you can think of 1VW as 1% of the screen width. Wow, this unit seems to be tailor-made for us. First, it’s essentially a percentage unit, like 3vw is “3 percentage points of screen width”; Second, it is a global unit that is directly related to screen width. So the example of the two percentages in the previous concept statement can be written in vw units:

  • Component width as a percentage of screen width: 690/750 = 0.92, i.e92vw;
  • The percentage of the component on, right and left margins to the screen width is: 30/750 = 0.04, i.e4vw.

What about VW support in mobile browsers? According to Caniuse.com (caniuse.com/#search=vw) :

Both iOS 8 + and Android 4.4 + support VW, while current mobile apps typically support iOS 9 + and Android 5+. So, in practice, using VW units is perfectly feasible. This is why the mobile Taobao team officially switched to VW unit adaptation at the beginning of this year.

Now, the only problem is that it is too troublesome to manually convert the px to VW units of the design draft. However, if you use compile Webpack packaged in development, so has been developed postcss plug-in: postcss – px – to – viewport (www.npmjs.com/package/pos)… . Configure this plugin so that you can write CSS exactly as the pixels on the design. This plugin converts your px to VW. In this way, what we call “pixel-level artwork” completely eliminates both development and presentation. It’s really pixel-level!

(If, I’m just saying, if you don’t have or can’t use Webpack, you might need to do the calculations manually.)

Using postcss – px – to – the viewport

This section is actually unnecessary. However, for the sake of completeness, let’s briefly describe the configuration of the postCSs-px-to-viewPort plug-in. The following content is taken from the.postcsrc. Js configuration file:

module.exports = { "plugins": { // ... "postcss-px-to-viewport": { viewportWidth: 750, viewportHeight: 1334, unitPrecision: 3, viewportUnit: 'vw', selectorBlackList: ['.usepixel'], minPixelValue: 1, mediaQuery: false }, // ... }}Copy the code

The meanings of several configuration items are as follows:

  • ViewportWidth: viewportWidth, set here to be consistent with the design draft width;
  • ViewportHeight: viewportHeight, randomly set a can;
  • UnitPrecision: The precision of the converted value, 3 means that three decimal places are reserved;
  • ViewportUnit: convert to what viewportUnit, here of coursevw;
  • SelectorBlackList: is an array of selectors that will not convert the pixel units in the declaration.
  • MinPixelValue: the minimum pixel value, which is converted only when greater than or equal to this value.
  • MediaQuery: whether to convert pixels in a mediaQuery.

Finally, we conclude this article with an example. It’s the same design from the beginning of this article, the same rounded rectangle component, and the class name in our application is.card. Here is its CSS source code:

section.card {
  margin: 0 auto;
  margin-bottom: 20px;
  background-color: #fff;
  border-radius: 10px;
  box-shadow: 0 6px 6px 0 rgba(0,0,0,0.02);
  text-align: center;
  padding: 38px 70px 46px;
  font-weight: 300;
 }
Copy the code

That’s right, all these PX values are actually measured from the design (in fact, they are automatically given by the annotation page). After the postCSs-px-to-viewPort plugin converts these values to VW units relative to the viewport width:

conclusion

As the second part of the H5 Must Know, must Know series, this article discusses two aspects of how to restore the design in high fidelity and adapt to different phone screens. First of all, we make clear the content and purpose of adaptation and reduction theoretically or conceptually. H5 adaptation is mainly divided into adaptation of different pixel densities and adaptation of different screen sizes. The purpose of adaptation is to ensure user experience, such as pictures without distortion; And page layouts with the same proportions on different screens of different sizes, which is known as 100 percent artwork, or pixel-level artwork.

Having defined the concepts and principles of adaptation and restore, the key to technical implementation is to find a global CSS unit. We first introduced the REM based adaptation framework of Alibaba Mobile Taobao team (this framework not only dynamically modified REM, but also solved the problem of true 1-pixel frame), and then introduced the more universal VW unit adaptation. Finally, the configuration of postCSS-Px-to-viewport, which automatically converts px to VW units, is briefly introduced.

At this point, the reader might be tempted to guess what is the subject of the third book in the series? Is it about how the H5 uses the special capabilities given to it by the phone or host App? I don’t know. It is possible to share the H5 deployment and o&M strategy for multiple versions. Of course, there is also the possibility of quickly building an H5 project from scratch based on a scaffold and implementing front-end engineering. In short, there are many possibilities for the future. In fact, I also want to know what topic do you want to see? If you have any ideas, leave a comment.