Discussion on the Size of Websites in HTML5 Building Touch Screen Website

This article is divided into two parts. The first part discusses the feasibility of cross-platform websites, and the second part discusses how viewport is set up.

It is true that the label width and height can be adaptable, we can do this very early. But you will find that many traditional PC websites still fix the width. (Taobao uses 1000px width, Sohu 950px...) Why don’t we allow the website to adapt to the width and height? That's because if we let the label width be stretched arbitrarily by the browser, it will lead to a very poor experience: you won't want your left bar to turn into noodles when the browser is scaled to 100px; nor will you want your website to look like a netbook for a primary school student when the browser is overstretched. Therefore, it is unrealistic to rely on label adaptation to achieve cross-platforms and is at the expense of user experience. Many times we have to fix the width and height.

We rely on html5 device to check whether the current device is a mobile phone or a tablet, and load the corresponding css accordingly. For example: If you detect that your device is a tablet, I can display three columns horizontally, and if it is a mobile phone, I will only display one column. This sounds not difficult, but it is very complicated to implement. We not only need to develop multiple sets of templates for different devices, but also process the size of the picture. In this regard, we can see how the Boston Globe uses HTML5 to implement responsive design.

In general, achieving cross-platform websites is too expensive and restricted for most websites. Whether it is feasible depends on the actual situation of the website.

Mobile browsers place the page in a virtual window (viewport). Usually, the virtual window (viewport) is wider than the screen, so that each web page does not have to squeeze each web page into a very small window (this will destroy the layout of the web page that is not optimized for mobile browsers). Users can see different parts of the web page through panning and zooming. Mobile browsers have introduced the meta tag of viewport, allowing web developers to control the size and scaling of viewport.

CSS pixels: Abstract units used by browsers, mainly used to draw content on web pages.

device pixels: Displays the minimum physical unit of the screen, each dp contains its own color and brightness.

How much CSS pixels with equivalent values ​​occupies on the phone’s screen is not fixed, it depends on many attributes. After analysis and summary, we can come up with a formula: 1 CSS pixels = (devicePixelRatio)^2 device pixels (^2 means square. As for what devicePixelRatio is, it will be explained later).

PPI, sometimes also called DPI, represents the number of pixels per inch. The higher the value, the higher the display can display images. (Note: The pixels here refer to device pixels.) After we figure out what PPI means, we can easily understand the calculation method of PPI. We need to first calculate the diagonal equivalent pixels of the mobile phone screen, and then place the diagonal (the size of the mobile phone screen is the length of the diagonal line of the mobile phone screen), and we can get the PPI. For accurate calculation announcements, you can refer to the figure below. What’s more interesting is that the PPI of the iPhone 4 calculated based on the formula is 330, which is a little higher than the 326 officially announced by Apple.

Similarly, taking HTC G7 as an example, the resolution of 480*800 and 3.7 inches is calculated to be a PPI of 252.

We calculate PPI to know which density interval a mobile phone device belongs to, because different density intervals correspond to different default scaling ratios, which is a very important concept.

From the figure above, it can be seen that mobile phones with PPI between 120-160 are classified as low-density mobile phones, 160-240 is classified as medium density, 240-320 is classified as high density, and above 320 is classified as ultra-high density (Apple gave it an upstream name-retina).

These densities correspond to a specific scaling value. Take the iPhone 4 or 4s that we are most familiar with, their PPI is 326, which is an ultra-high density mobile phone. When we write a page with a width of 320px and put it on the iPhone to display, you will find that it is actually full width. This is because the page is enlarged twice by default, that is, 640px, while the width of the iPhone 4 or 4s is exactly 640px.

The picture circles the high-density type because this is the statistical data of Android phones. In the domestic Android phone market, high-density devices account for the vast majority of the market share. This is a very important point and it is also a key point that we should pay attention to when doing Android webapps.

Viewport has a total of 5 attributes, as follows:

<meta name="viewport"

content="

height = [ pixel_value | device-height] ,

width = [ pixel_value | device-width ],

initial-scale = float_value , minimum-scale = float_value , maximum-scale = float_value , maximum-scale = float_value ,

user-scalable =[yes | no] ,

target- densitydpi = [ dpi_value | device-dpi | high-dpi | medium-dpi | low-dpi] " />

Among these properties, we focus on target-densitydpi , which can change the default scaling of the device. medium-dpi is the default value of target-densitydpi. If we define target-densitydpi=device-dpi, the device will render the page according to the real dpi. For example, if a 320*480 picture is placed in iPhone 4, it will occupy the screen by default, but if target-densitydpi=dvice-dpi is defined, then the picture only accounts for one-quarter of the screen (one-half of the square) because the resolution of iPhone 4 is 640*960.

If we make the page according to the 320px wide design draft and do not make any settings, the page will automatically scale to a width equal to the mobile phone screen by default (this is because medium-dpi is the default value of target-densitydpi, and it is determined by different scaling ratios corresponding to different densities, all of which are automatically done by mobile devices). So this solution is simple, rough and effective. But there is a fatal disadvantage. For high-density and ultra-high-density mobile devices, the pages (especially pictures) will be distorted, and the more dense the more distorted it is.

In this solution, we use target-densitydpi=device-dpi, so that the mobile phone device will render according to the real number of pixels. In professional terms, it is 1 CSS pixels = 1 device pixels. For example, for an iPhone with 640*960, we can create a page with 640*960, and there will be no scroll bars when it is displayed on the iPhone. Of course, for other devices, pages of different sizes are also required, so this solution is often used to use media queries to make responsive pages. This solution can be perfectly presented at a specific resolution, but with more different resolutions to be compatible, the higher the cost, as separate codes are required for each resolution. Here is a simple example:

<meta name="viewport"content="target- densitydpi =device-dpi, width=device-width " />

#header {

background:url (medium-density-image.png);

}

@media screen and (- webkit -device-pixel-ratio:1.5) {

/* CSS for high-density screens */

#header { background:url (high-density-image.png);}

}

@media screen and (- webkit -device-pixel-ratio:0.75) {

/* CSS for low-density screens */

#header { background:url (low-density-image.png);}

For the vast majority of Android devices, the characteristics of high density and medium density, we can adopt a compromise solution: we restore the 480px wide design draft, but the page system is made to 320px wide (using background-size to reduce the picture), and then let the page automatically scale to scale. In this way, low-density phones have scroll bars (basically no one is using this kind of phone), medium-density phones will waste a little traffic, high-density phones will perfectly present, and ultra-high-density phones will slightly distort (very few ultra-high-density Android phones). The advantages of this solution are very obvious: only one set of design drafts and one set of codes are required (here is only discussing the situation of Android phones).