This article is an internal sharing precipitation, biased to the basic but involves some interesting details, the writing is limited, the talent is shallow, if the article is not correct, hope to inform.

One of the main tasks of the front-end is to accommodate the behavior of the page in different browsers with different cores, different devices, and different resolutions, so that the page can work properly in a variety of host environments.

The theme of this paper — compatibility and performance optimization of mobile terminal development is to clarify the development of Web mobile terminal from some common mobile terminal development problems, the development process of some technologies, the optimization means of some problems and give some common compatibility problems solutions.

What is responsive design

Let’s start with responsive design, which has a lot to do with mobile development.

Responsive Design is RWD, Responsive Web Design.

A Search on Baidu or Google will give you a variety of answers. Here’s an excerpt from what I think is a great answer on Zhihu: What is responsive layout design?

According to Wikipedia and its references, responsive interfaces can theoretically be adapted to different devices. One of the most famous phrases to describe responsive interfaces is “Content is like water,” which translates into Chinese as “Content is like water if the screen is a container.”

Why design responsive interfaces

Why bother trying to unify all the devices?

  • Even among PC or Mac users, only half of them have a full-screen browser, and it’s hard to tell what type of browser the rest of us use.
  • Desktop, projection, TV, Laptop, phone, tablet, watch, VR… Smart devices are on the rise, and the concept of “mainstream devices” is disappearing;
  • Screen resolutions are skyrocketing, and the same image can look vastly different in size on different devices.
  • Mouse, touch screen, pen, camera gestures… Unpredictable manipulations are emerging.

Four levels of a responsive interface

  • The same page should look comfortable at different sizes and scales;
  • The same page should look reasonable at different resolutions;
  • The experience of the same page should be uniform under different operation methods (e.g. mouse and touch screen);
  • The same page on different types of devices (phone, tablet, computer) should interact in a customizable way.

Basic rules for responsive interfaces

  • Scalable content blocks: Content blocks can be automatically adjusted to a certain extent to ensure that the entire page fills

  • Freely arranged content blocks: The ability to reduce/increase the number of arranged columns when the page size varies greatly

  • Margins to fit the page size: As the page size changes more, the margins of the block should also change

  • Proportional images: For common width adjustments, images remain aesthetically usable when the sides are hidden

  • Automatic concealment/partial display of content: for example, large sections of descriptive text displayed on a computer can only be shown in small amounts or completely hidden on a mobile phone

  • Foldable navigation and menus: expand or fold depending on the page size

  • Get rid of pixels: use dp(or rem, for the front end) sizes to make sure pages look the same across devices with vastly different resolutions. It was also requested that the images should be larger than expected to accommodate the high resolution screen

I think the above paragraph has covered the vast majority of responsive design, which can be summarized as follows:

  1. Media Queries && Break points
  2. Content Scalability (Flexibel Visuals)
  3. Fluid grids
  4. Main content and high quality images

Responsive vs. adaptive

Responsive Web Design (RWD), Adaptive Web Design (AWD). Often people confuse the two, or fail to distinguish between responsiveness and adaptation at all.

In fact, at the time I wrote this article, I couldn’t distinguish between the two.

RWD and AWD are both technologies designed to adapt to different mobile devices and improve user experience. The idea is to use technology to adapt web pages to different screen resolutions, from small to large (and now to very large). RWD is generally considered a subset of AWD.

RWD: Ethan Marcote’s article is considered the origin of RWD. His RWD solution is realized through HTML and CSS media query technology, with fluid layout. RWD tends to change only the appearance of elements without drastically changing the content. Jeffrey Zeldman concludes by defining RWD as anything that can be used to optimize the visual experience for a variety of resolutions and device performance.

AWD: Adaptive Design is the title of Aaron Gustafson’s book. He sees AWD as more mobile in its ability to manipulate HTML with Javascript in addition to CSS media query techniques including RWD. AWD may subtract content, subtract functionality for mobile users. AWD can be optimized on the server side to deliver the optimized content to the terminal.

A picture is worth a thousand words.

RWD is, by definition, a set of code that applies to all screens. AWD is multiple code. This article won’t dwell too much on the difference between responsiveness and adaptation. I think the essence of both is to improve the user experience by adapting to different devices.

Quora – Responsive Design vs. Adaptive Design? Zhihu — The difference between Responsive design and Adaptive design

Incremental enhancement vs. graceful degradation

  • Progressive Enhancement: Build the page for the lower version browser to ensure the most basic functionality, and then improve and add features for the advanced browser to achieve a better user experience.

  • Graceful Degradation: Build full functionality from the start and then make it compatible with older browsers.

The difference: Elegant downgrading starts with a complex status quo and tries to reduce the supply of user experience, while progressive enhancement starts with a very basic, functional version and expands to fit the needs of future environments. Downgrading (functional decay) means looking backwards; Incremental enhancement means looking forward while keeping its roots in a safe zone.

Progressive enhancement/graceful degradation is another technical term usually associated with AWD. Essentially, the functionality gets progressively stronger as the screen size changes.

It is also commonly used for advanced CSS3 properties. We use some CSS properties for feature checking, or even without feature checking. The result is that this property is displayed normally on the pages that support it, but does not take effect on the pages that do not support it, but does not affect the basic use of users.

The typical example is CSS3 gradually recognized and used by the public, PC pages began to change from IE678 to the more compatible IE9+, Chrome, Firefox browser. We can use attributes like shadows, rounded corners, and so on for page elements. For the lower versions of IE that do not support it, there is no loss, while for the advanced browsers that do support it, it gives users a better interactive visual experience, which is called progressive enhancement.

Mobile terminal screen adaptation scheme

Here are some specific cases. The first is the hi-fidelity restore design, which is how to adapt to the cumbersome screen sizes of mobile devices.

Typically, designers will only come up with a single resolution design, and what we need to do is to use that design as a baseline for all different sizes of mobile devices.

Before we get there, there are some basic concepts to understand.

Some conceptual things, most people are difficult to remember at once, or remember again and again, I think the memory of this thing more skills, such as association method, imagination method, these rigid concepts and some of our common knowledge associated with memory, often can get twice the result with half the effort.

Device independent pixel

For iPhone6/7/8, here we open Chrome Developer Tools:

What does 375 * 667 stand for here? It stands for device-independent pixels (DIP), also known as CSS pixels, also known as logical pixels:

Device independent pixel = CSS pixel = logical pixel

How do you remember it? CSS pixels are used here to remember, that is. A div with a width of 375px is just enough to fill one line of the device, and a height of 667px is just enough to fill the entire screen.

Physical pixel

OK, so what is a physical pixel? When we go to e-commerce websites to buy mobile phones, we will have a look at the parameters of the phone, taking iPhone7 on JD as an example:

As you can see, the iPhone7 has a resolution of 1334 x 750, which describes the actual physical pixels of the screen.

Physical pixels, also known as device pixels. The display is made up of physical pixels, with 1334 x 750 representing the number of pixels the phone has vertically and horizontally. By controlling the color of each pixel, you can make the screen display a different image. The physical pixels on the screen are fixed in pt from the day the screen comes out of the factory.

Device pixel = physical pixel

Device Pixel Ratio (DPR) Device Pixel Ratio

OK, with the above two concepts, it’s a logical progression to the next concept. DPR (Device Pixel Ratio) refers to the Pixel Ratio of a Device, which is related to what is commonly referred to as a Retina display.

The device pixel ratio describes the initial ratio of physical pixels to device-independent pixels in the unscaled state.

Simple calculation formula:

DPR = Physical pixels/device-independent pixels

Let’s apply the data of iPhone7 above (take the physical pixel width of the device and the device independent pixel width to calculate) :

IPhone7’s DPR = iPhone7’s physical pixel width/iPhone7’s device independent pixel width = 2

750/375 is equal to 2 or 1334/667 is equal to 2

You get a DPR of 2 for the iPhone7. This is what we call a retina screen.

The Retina screen is a marketing term Apple “invented”. Apple calls screens with a DPR > 1 a retina screen.

In a retina screen, using DPR = 2 as an example, using 4(2×2) pixels as one pixel makes the screen look more refined, but the size of the element itself does not change:

OK, let’s take a look at the iPhone XS Max:

Its physical pixels are 2688 x 1242, as shown above,

With CSS pixels of 896 x 414, it’s easy to say the iPhone XS Max has a DPR of 3.

The above three concepts (CSS pixel, device-independent pixel and DPR) are the most important ones in my opinion. PPI and DPI will not affect the subsequent content, so you can deepen your understanding by yourself.

OK, so here we have a little milestone. We usually say that H5 mobile phone adaptation refers to these two dimensions:

  1. Fit different screen sizes, that is, fit CSS pixels under different screens
  2. Adaptation to different pixel densities, that is, adaptation to different screens under the DPR inconsistency caused by some problems

Suitable for different screen sizes

Fit different screen sizes, that is, fit CSS pixels under different screens. The earliest CSS pixel adaptation solution for mobile screen is CSS media query. But can not achieve high fidelity close to 100% restore.

Adapting to different screen sizes is really just a matter of making sure the page element size is proportional to the screen size. That is: restore the design draft to scale

Let’s say we now have a 375*667 design with one element labeled as follows:


Based on page width, then,

  • The element width is:209/375 = 55.73%
  • The height of the element is:80/375 = 21.33%
  • The top left and right margins of the elements are computed in sequence…

This way, whether the CSS pixel width of the screen is 320px, 375px, or 414px, the same percentage of the screen will always be correct.

However, the ideal is full, the reality is very skinny. The core of implementing the percentages scheme above requires a globally common base unit against which all percentages are displayed, but in CSS, as defined by CSS Values and Units Module Level 4:

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).

To be specific:

  • Percentage values are supported for width and spacing (maring/padding), but the default relative reference value is the width of the contained block;

  • The size of a percentage is the height of its parent element;

  • Border does not support 100 points;

  • The percentage value of the border-radius is supported. The horizontal reference value is the width of the box, and the vertical reference value is the height of the box.

  • Percentage values are supported for text size, but the relative reference value is the font size value of the parent element;

  • Box-shadow and text-shadow do not support percentage values.

First, measure attributes that support percentage units have their own reference bases, and second, not all measure attributes support percentage units. So we need to do something different.

Rem adaptation scheme

Before VW scheme, the most widely accepted scheme is to use REM for adaptation, because REM can be a global reference unit as mentioned above.

Rem (font Size of the root Element), defined in CSS Values and Units Module Level 3, is to set the font size according to the root element of the page, The difference between EM (Font Size of the Element) and REM (font size of the Element) is that EM is set based on the font size of its parent element, while REM is set based on the HTML of the page.

flexible

Based on this, Taobao implemented a rem – based adaptation scheme: Lib-flexible. Its core approach is:

  • Dynamic rewriting based on the DPR of the device<meta>Tag to set the zoom of the viewport
  • to<html>Element adds a data-dPR attribute and dynamically overwrites the value of data-dPR
  • According to thedocument.documentElement.clientWidthThe dynamic change<html>The rest of the page uses REM as the length unit for layout, thus achieving the page isometric scaling

On the first two points, lib-Flexible libraries don’t do this anymore. They don’t resize Viewport, and they use REM font sizes

hotcss

Hotcss is not a library, nor is it a framework. It is a mobile layout development solution. Using HotCSS makes mobile layout development easier. The essential idea is exactly the same as flexible.

Some summaries of the REM scheme

There are some problems with using flexible/ HOTCSS as a screen width adaptation solution:

  1. There is some risk in changing the Viewport dynamically, for example, after changing the zoom of the page through the ViewportinnerWidth/innerHeightIf the business logic has access to this height and width for other calculations, it may cause unexpected errors;

Today, there are many rem solutions that evolved from flexible, some of which do not scale the Viewport and handle the 1px border themselves.

  1. Flexible/HotCSS are not pure CSS solutions and require some Javascript code to be introduced
  2. Rem was not designed to solve such problems, and using REM for page width adaptation feels a bit of a hack
  3. There are compatibility issues and viewport scaling is not supported for Android versions below 4.4. (Of course, flexible handles Android series with DPR of 1 and no viewport scaling.)

Vw adaptation scheme

Strictly speaking, using REM for page adaptation is actually a hack, and the rem unit itself is not intended for page width adaptation on mobile terminals.

Today, there is a better alternative, which uses VW for adaptation.

The core of the percentage adaptation scheme needs a universal benchmark unit. Rem is good, but it needs Javascript to dynamically change the font size of the root element. Vw/VH (vmax/vmin) makes up for the shortcoming of REM requiring JS assistance.

According to CSS Values and Units Module Level 4: vw is equal to 1% of the width of the initial containing block (HTML element), i.e

  • 1vwIs equal to thewindow.innerWidth1% of the value of
  • 1vhIs equal to thewindow.innerHeight1% of the value of

Taking the elements of the above design drawing as an example, then,

  • The element width is:209/375 = 55.73% = 55.73vw
  • The height of the element is:80/375 = 21.33% = 21.33vw
  • The top left and right margins of the elements are computed in sequence…

According to relevant tests, vw can be used for length units as follows:

  • Container size fits, can use VW
  • Text size adaptation, can use VW
  • Vw can be used for borders, rounded corners, and shadows greater than 1px
  • Inside and outside, you can use VW

A simple page, look at the effect, is completely equal scale effect:

CodePen Demo (open on mobile) : Use VW for page adaptation

Automatic conversion plug-in

When we use REM as a unit of length, we usually implement a conversion function with Sass/Less, like this:

$baseFontSize: 100; $baseFontSize: 100; @function px2rem($px) { @return $px / $baseFontSize * 1rem; }Copy the code

Similarly, in vw scheme, we just need to rewrite this method:

@function px2vw($px) {@return $px / 375 * 100vw; }Copy the code

Of course, we can also use some plug-in packages to implement automatic conversion, such as postCSs-px-to-viewPort, to improve efficiency

vw polyfill

Vw still has compatibility problems after all, let’s look at compatibility:

In fact, the vast majority of devices have been covered, so if the business uses and there are really compatibility problems, how to deal with? There are two ways to downgrade:

  • CSS Houdini: The CSS Houdini handles VW and calls the CSSUnitValue API provided by CSS Typed OM Level1.
  • CSS Polyfill: The corresponding Polyfill is processed by corresponding Polyfill. Currently, Polyfill for VW Units mainly includes vminpoly, Viewport Units Buggyfill, Vunits. js and Modernizr

Some summaries of vw solutions

Vw does look great, but it has some problems:

  1. It also failed to solve the display problem of 1px frame in HD screen, which needs to be handled by itself
  2. As VW scheme is fully proportional scaling, one of the problems brought by fully proportional restoration of the design draft is that the maximum and minimum width values cannot be well defined. As REM scheme is based on Javascript, REM is more flexible than VW in this regard

Of course, both solutions can be used at this stage or even together. Read on for more details:

  • Talk about the adaptation of the mobile page
  • H5 will know the pixel level restore design draft
  • Responsive And Fluid Typography With vh And vw Units
  • Use VH and VW for true fluid typography

1 px line

As mentioned above, one of the disadvantages of using VW fit screen size scheme is that the real 1px physical pixel line can’t be displayed well on Retina display.

The border the designer wanted for Retina: 1px is actually 1 physical pixel wide, not 1 CSS pixel wide, for CSS:

  • When DPR = 1, 1 physical pixel is equal to 1 CSS pixel width;
  • When DPR = 2, at this time 1 physical pixel is equal to 0.5 CSS width pixel, can be consideredborder-width: 1pxHere 1px is actually 1 CSS pixel width, which is equal to 2 pixels physical width, what the designer really wantedBorder - width: 0.5 px;
  • At DPR = 3, where 1 physical pixel equals 0.33 CSS width pixels, the designer actually wanted border: 0.333px

Border-width: 0.5px; border-width: 0.5px; border-width: 0.5px;

Here are a few methods:

  • The gradient implementation
  • Using scaling
  • Using images (Base64)
  • Implemented using SVG (embedded background URL)

Implementation of 1px line under Retina screen

Picture adaptation and optimization

Images often make up the majority of downloads on the web. Optimizing images often minimizes the number of bytes downloaded from a site and improves site performance.

Usually, there are some general optimizations:

  1. Eliminate redundant image resources
  2. CSS3\SVG vector images are used to replace some raster images
  3. Use font ICONS sparingly and use web fonts instead of text encoding in images
  4. Choose the correct image format
  5. Provide the best picture size for different DPR screens

This article focuses on how to keep images from looking distorted on different DPR screens.

The first is the second point above, as far as possible to use CSS3\SVG vector images to replace some raster images. Some simple geometric ICONS, graphics that can be quickly implemented with CSS3, should avoid raster images as much as possible. This ensures that they are not distorted at any size.

Secondly, even if raster images are necessary, there are many ways to ensure that the image is not distorted in various scenarios.

Anencephaly polyploidy

On the mobile terminal, suppose we need an image with CSS pixel of 300 x 200. Considering that there are already devices with DPR = 3, we may need an original image of 900 x 600 at most to ensure the normal hd display of the image on devices with DPR = 3.

In this way, regardless of whether the device’s DPR is 3, we use the 3x graph uniformly. Even on devices with DPR = 1 and DPR = 2, you can display images very well.

Of course, this is not desirable, resulting in a lot of wasted bandwidth. Modern browsers provide a better way to provide images of different sizes depending on the DPR of the device.

Srcset with 1x 2x pixel density descriptor

In simple terms, srcset can pull pictures of corresponding sizes according to different DPR:

<div class='illustration'>
  <img src='illustration-small.png'
       srcset='images/illustration-small.png 1x, images/illustration-big.png 2x'
       style='max-width: 500px'/>
</div>
Copy the code

The 1x, 2x in srcset above represent pixel density descriptors, and represent

  • Is used when the DPR of the screen is 1images/illustration-small.pngThis picture
  • Is used when the DPR of the screen is 2images/illustration-big.pngThis picture

The srcset property works with the SIZES property W width descriptor

The 1x and 2x notation up here is a little bit easier to understand.

In addition, the srcset property has a W-width descriptor, which is used in conjunction with sizes to cover more surfaces.

Take this code as an example:

<img 
        sizes = "(min - width: 600px) 600px.300px" 
        src = "photo.png" 
        srcset = "[email protected] 300w.photo@2x.png 600w.photo@3x.png 1200w,
>
Copy the code

Analyze:

Sizes = “(min-width: 600px) 600px, 300px” means that if the screen’s current CSS pixel width is greater than or equal to 600px, the image’s CSS width is 600px, and vice versa.

The sizes property specifies the CSS width for images of different widths. The width of the image on the large screen is 600px, and the width of the image on the small screen is 300px. (Specific media query code is implemented by CSS)

The sizes property here only states CSS widths for images of different widths, but the code to make images 600px wide on screens larger than 600px needs to be implemented by CSS or JS, which is a bit confusing.

Srcset = “[email protected] 300W, [email protected] 600W, [email protected] 1200W 300W, 600W, 900W are width descriptors. How do you determine which image will be selected for the current scene?

Current screen DPR = 2, CSS width 375px.

The current screen CSS width is 375px, so the image CSS width is 300px. Divide each of the three width descriptors by 300.

  1. 300/300 is 1
  2. 600/300 is 2
  3. 1200 divided by 300 is 4

The values 1, 2 and 4 calculated above are the effective pixel densities, which are equivalent to the x descriptor. Here, the 2 calculated by 600W satisfies the condition that DPR = 2. Select this graph.

The current screen DPR = 3 and CSS width is 414px.

The current screen CSS width is 414px, so the image CSS width is still 300px. Calculate it again:

  1. 300/300 is 1
  2. 600/300 is 2
  3. 1200 divided by 300 is 4

Since DPR = 3,2 is no longer sufficient, 1200w will be selected.

The current screen DPR = 1 and CSS width is 1920px.

The current screen CSS width is 1920px, so the image CSS width is 600px. Calculate it again:

  1. 300/600 =.5
  2. 600/600 is 1
  3. 1200 divided by 600 is 2

Since DPR = 1, the image corresponding to 600W will be selected.

To do this, try CodePen Demo — srcset with w width descriptor and sizes

The significance of this scheme lies in that it takes into account the complexity of responsive layout and the diversity of screens. By using the above rules, it can be adapted to the large SCREEN on PC side and the HD screen on mobile side at one time, with more than one arrow.

For more details, check out:

  • Google Web Fundamentals — Web Responsive Images
  • Srcset New definition of SIZES property W descriptor

Font adaptation scheme

The font size

Font is a lot of front-end development students tend to ignore a point, but there are many small knowledge points.

The first thing to know is that browsers have minimum font limits:

  • Font size=12px on PC
  • Minimum font size=8px on your phone

If less than the minimum font, the font defaults to the minimum font.

Second, many early article specifications advised against using odd-numbered units to define font sizes (e.g. 13px, 15px…). , easy to cause font blur on some low-end devices, appear serrated.

Font selection display

In font adaptation, we need to consider performance and display effect from two dimensions.

A single font resource is too large, so we should try to use fonts that already exist on the user’s device, rather than download additional font resources to make the loading time significantly faster.

From the display effect level, the use of system font can better match the current operating system use, get the best display effect. Therefore, we should try to follow a principle in font use, which is also the strategy used by most websites in font adaptation:

Use the default system fonts on each supported platform.

Take care of each operating system

Common operating systems include Windows, Windows Phone, Mac OS X, iPhone, Android Phone, and Linux. Of course, for ordinary users, Linux is not a concern.

Here is the latest font family of CSS-TRICK website as an example, to see how they do in the font selection to adapt to each operating system

{
  font-family: 
    system-ui,-apple-system,BlinkMacSystemFont,segoe ui,Roboto,
    Helvetica,Arial,
    sans-serif,apple color emoji,segoe ui emoji,segoe ui symbol;
}
Copy the code

The font-family keywords

Font family in CSS has two types of values.

  1. One is a specific font family name definition like this: font-family: Arial where we define a specific font style, the font family is Arial;

  2. One is the generic font family name, which is an alternative mechanism for giving a better font when the specified font is not available, like this: font-family: sans-serif.

Among them, sans-serif table sans serif font family, for example, “Open Sans”, “Arial”, “Microsoft Yahei” and so on.

In CSS Fonts Module Level 3 — Basic Font Properties, there are 5 common Font family names:

  1. Serif serif font family
  2. Sans-serif family of non-serif fonts
  3. Monospace is a font in which every word is the same width
  4. A cursive font
  5. Fantasy is mainly typefaces that have special artistic effects

Added common font family keywords

In CSS Fonts Module Level 4 — Generic Font Families, several keywords have been added:

  • System-ui Indicates the default system font
  • Emoji used for compatible emoji characters
  • Math applies to mathematical expressions
  • Fangsong this font series is used for Chinese (imitation song) fonts.

Let’s look at the system-UI that we use the most.

system-ui

In short, the purpose of font-family: system-ui is to automatically select the default system font for different operating system Web pages.

Defaulting to the system font for a particular operating system can improve performance because the browser or WebView doesn’t have to download any font files and instead uses existing font files. The advantage of the system-ui font setting is that it matches the fonts currently in use by the operating system, so it can be displayed most appropriately for text content.

San Francisco Fonts

OK, that’s a brief overview of the System-UI font family. But things like -apple-system and BlinkMacSystemFont don’t appear in the latest standards. What do they mean?

Before I do that, I need to know the San Francisco Fonts.

San Francisco Fonts, also known as San Francisco Fonts, are a type of Western font. With the iOS 9 update, WatchOS will be available quietly alongside Apple Watch, and it will also be available in the new tvOS on Apple TV.

San Francisco Fonts are used on iOS as an alternative to upgrading another Western font, Helvetica Neue. Apple has made some important changes to make it a better, even perfect, Spanish font for the platform.

-apple-system/BlinkMacSystemFont

Anyway. As every front-end developer knows, it’s one thing to get a feature into the specification and another to get it into the browser.

Fortunately, the adoption of system-UI is fast. Chrome and Safari can fully support it on a variety of platforms. Only Mozilla and Windows are behind.

Can I Use system-UI — system-UI

Look closely at the last two lines of the image above:

  • Supported as the -apple-system value (only on macOS and iOS)
  • Supported as the BlinkMacSystemFont value (only on macOS)

For different platforms and backward compatibility, we need to use -apple-System and BlinkMacSystemFont to be compatible with the System-UI standard on macOS and iOS.

Segoe UI

Segoe UI is the default Western font family for Windows starting from Vista. It has only Western characters and does not support Chinese characters. It is a sans serif font.

It also represents a series rather than a single font. Font-family: Segoe UI; font-family: Segoe;

Roboto

Roboto is a family of sans serif fonts designed for the Android operating system. Google describes the font as “modern, yet approachable” and “affectionate.”

This font family includes Thin, Light, Regular, Medium, Bold, and Black with matching italics.

To summarize

At this point, we can sum up. Take the definition of font-family from CSS-Tricks as an example:

{
  font-family: 
    system-ui,-apple-system,BlinkMacSystemFont,segoe ui,Roboto,
    Helvetica,Arial,
    sans-serif,apple color emoji,segoe ui emoji,segoe ui symbol;
}
Copy the code
  1. System-ui, using the default system font on each supported platform
  2. -Apple-system, on some lower versions of Mac OS X and iOS, it is updated to use the more appropriate San Francisco Fonts for Neue Helvetica and Lucida Grande Fonts on older versions
  3. BlinkMacSystemFont, for some Chrome browsers on Mac OS X, uses the system default font
  4. Segoe UI, select the system default font on Windows and Windows Phone
  5. Roboto, for Android and some new versions of Chrome OS
  6. Helvetica,Arial, after using the default system font for different operating systems and platforms, for some of the lower versions of the browser downgrade scheme
  7. Sans-serif, to ensure that the font style is uniform, at least sans serif font

The above five font family definitions are defined in descending order of priority. It can be seen that none of them is a specific font, and the basic core idea is to select the default system font on the corresponding platform.

The operating system covers iOS, MAC OS X, Android, Windows, and Windows Phone.

The main reason for using the system default font is performance. Fonts are usually one of the largest/heaviest resources loaded on a website. If we could use fonts already on the user’s machine, we wouldn’t need to get font resources at all, making the load time significantly faster.

And the advantage of the system font is that it matches the current operating system, so its text display must be a comfortable display effect.

Of course, the above definition of font-family is not necessarily optimal. Font-family: “PingFang SC”,miui,.. They must also have business considerations. However, some fallback schemes have the same idea of backward compatibility, which is worth studying.

For more details on fonts, check out these articles:

  • Font-family: arial, sans-serif
  • Font-size: 14px “> < span style =” font-size: 14px
  • Using UI System Fonts In Web Design: A Quick Practical Guide
  • System Fonts in CSS
  • Apple ‘s San Francisco the Font

Compatibility of the front end layout

A big part of a front-end engineer’s job is page layout. Whether on PC or mobile, compatibility of page layout is a top priority. In the course of the development of the whole front-end, the layout of the method is constantly innovating.

Layout development history

To put it simply, the development of the front-end layout has experienced the following processes:

Table Layout –> Location Layout –> Floating Layout –> Flexbox Layout –> GridBox layout

Each layout plays an important role in a particular period, and each new layout is often because the existing layout has been unable to meet the needs of developers in this period, unable to meet the increasingly popular way of page layout.

Take the Flexbox, for example, before it was widely accepted. We’ve been using a positioning + floating layout. Like this layout:

The width of the container varies, and the three elements inside are evenly arranged and occupy the entire space, and are vertically centered. If you use a positioning + floating layout, you won’t quickly figure out the best solution. When three elements are side by side, they must be floating or absolutely positioned, the width of the container is variable and the middle element is always centered, so there are many things to worry about. Maybe text-align: justufy is a hack, and so on.

However, with flexbox layout, you only need:

.container {
    display: flex;
    justify-content: space-between;
    align-items: center;
}
Copy the code

Flexbox, a one-time solution to flow layout, flexible layout, arrangement and other problems. And it’s simple, it’s manageable.

For another example, center an element horizontally and vertically. Using flexbox is probably the easiest:

.container {
    display: flex;
}

.item {
    margin: auto;
}
Copy the code

The most convenient way to center vertically

CSS Grid Layout

OK, flexbox is good enough, why girD grid layout and why? What does it solve that Flex layout doesn’t solve very well?

Take a look at the chart below:

Flexbox is a one-dimensional layout that can only place your content blocks in a straight line; The grid is a two-dimensional layout. In addition to the flexibility to control the horizontal direction, it can also easily control the vertical layout pattern. For a nine-grid layout like the one above, it can be done easily.

In a nutshell, flexbox:

Gridbox:

The image was taken from Chen Huijing’s presentation on CSS Layout in the New Era at the 5th CSS Conference 2019

At this stage, mobile layouts should be done more with Flexbox (as opposed to those that still use float layouts), allowing for the evolution of future page layouts. Grid layouts should be treated like flexbox a few years ago, and as compatibility becomes more widespread, Grid layouts will become mainstream.

The last

Well, the end of this article, I hope to help you 🙂

More technical articles are collected on my Github — iCSS. Please click star to subscribe.

If there are any questions or suggestions, you can exchange more original articles, writing is limited, talent and learning is shallow, if there is something wrong in the article, hope to inform.