“This article is to participate in the activities of piece call-up, click view: [the back-end, big front double track submissions, waiting for you $20000 jackpot challenge!] (https://juejin.cn/post/697868…”

Introduction: Appropriate use of ICONS in products can make products more vivid, but also more concise. In front end projects, processing and introducing ICONS are essential. The introduction of ICONS into a Web product has gone through the following stages: Use stand-alone images to introduce ICONS, use CSS sprites, use Font ICONS, use SVG (Inline SVG/SVG Sprites), encapsulates components in the front view layer framework. This article will briefly comb through the evolution of the icon-related workflow, as well as some of our attempts in the process of promoting baidu’s design language system.

The full text is 7006 words and is expected to take 14 minutes to read.

1. Use individual pictures

For a long time, the front end hosted ICONS by introducing images. In the days without CSS support, it was only possible to introduce an icon image with the tag.

<a href="/contact.html">  <img src="mail.jpg" alt="email"></a>

When CSS came to support background images, people started using background-images to introduce small images, but essentially it didn’t change the problem of having a separate image for each icon.

Obviously, this approach causes a lot of HTTP requests to be made on a web page with a lot of ICONS, consuming the browser’s concurrent requests, resulting in slow overall load times and a poor experience. For some designs that hover over and then switch ICONS, this approach also causes the problem of waiting for the icon to load the first time you switch. (Sadly, there are still websites that do this.)

Second, the CSS Sprite

Then, in the early years of this century or so, a new technique was found: by introducing image Sprite into the front end, a large number of icon images were cleverly pieced together, and different ICONS were displayed by matching different positions in a backstory position in the style. Such as:

.toolbtn { background: url(icons.png); display: inline-block; height: 20px; width: 20px; }#btn1 { background-position: -20px 0px; }#btn2 { background-position: -40px 0px; }

Although this method only makes one HTTP request compared to one image file per small icon, which is more performance friendly, it still has the following problems:

• The assembled images are very difficult to maintain and need to be carefully adjusted manually. Although there are tools for automatically generating Sprite diagrams, the background-position approach does not allow the generation logic to be flexible enough to accommodate all possible use scenarios.

  

  Photos come from https://www.smashingmagazine…

• When a project has many ICONS, the images will not be displayed until the whole project is downloaded, which may result in a long period of time when all ICONS cannot be displayed. At the same time, due to high maintenance costs, it is difficult to load ICONS on demand, often all the ICONS of the whole site will be merged into the same “Sprite chart”.
• The icon color is fixed and there is no flexibility to adjust the icon color on the front end according to the content context.
• The image size is fixed, and it is difficult to ensure the display effect of the icon after scaling.

In this era, designers and engineers typically work together in a way that the designer delivers the icon file to the engineer, who then maintains the assembled image through an image editing tool or some Sprite generator. Efficiency and maintainability are extremely low.

Third, the rise of font ICONS

Since ICONS can be considered “hieroglyphics” in a way, when CSS started supporting @font-face to introduce Web fonts, people immediately thought of using them to load and display ICONS. Since 2012, the success of FontAwesome, which provided a huge number of free ICONS (FontAwesome 5, which became a commercial, even raised $1 million on Kickstarter), various font icon platforms have sprung up. Alibaba’s Iconfont. Cn platform has become the most popular icon hosting, sharing and management platform in China since many years ago. Font ICONS are still one of the most popular icon schemes on the Web today.

The principle of font ICONS is very simple. By taking up a number of Unicode character encoders (usually in the private use area of U+ e000-U +F8FF, U+F0000-U+FFFFD, and U+ 100,000-U +10FFFD) and drawing a glyph for them, At the same time, generate a bunch of predefined icon names and class names, load resources using Web font mode, and reference ICONS by the corresponding class name. Because different browsers support different font formats for web font compatibility, it is often necessary to generate multiple formats of fonts for browsers to selectively load:

/* iconfont. Cn generates a style file that looks like this: */@font-face {font-family: "iconfont"; src: url('iconfont.eot'); /* IE9 */ src: url('iconfont.eot#iefix') format('embedded-opentype'), /* IE6-IE8 */ url('iconfont.woff2') format('woff2'), url('iconfont.woff') format('woff'), url('iconfont.ttf') format('truetype'), /* chrome, firefox, opera, Safari, Android, iOS 4.2+ */ url('iconfont. SVG #iconfont') format(' SVG '); /* iOS 4.1- */}. Iconfont {font-family: "iconfont"! important; }.icon-flag:before { content: "\e233"; }

Use in HTML:

<i class="icon-flag"></i>

Font ICONS are also difficult to maintain, but have a number of distinct advantages over “Sprite” :

• Font ICONS based on the contours font format are described by bezier curves, which can be scaled freely without distortion, which is particularly important on mobile.
• Fonts can be easily colored using CSS.

However, we can see that this solution already requires the engineering capabilities of the users. In this era, most front-end teams in the industry already have the initial engineering capabilities and are using tools like Grunt/Gulp or even Webpack to customize their engineering solutions based on Node + NPM. However, it is already a lot of work to arrange the Unicode encoding of each icon and generate the corresponding CSS code, not to mention the generation of so many formats of font files, the average engineer can not start. This is an important reason why Iconfont. Cn has attracted a large number of users. Heavy reliance on third-party platforms and relatively high construction costs make the maintainability of ICONS still have a certain pain point.

In addition, while the font icon solves some of the problems with the Sprite image experience, it also introduces a few new ones:

• The font file takes time to load, and until the file is loaded, the icon will not be displayed and the content will easily flicker. In some browsers, the icon in the private use area will even appear as a square character under the default font.

  

  Photo from https://github.blog/2016-02-2…

  This actually has a lot in common with the Sprite chart. While we can use data URIs to inline resources, and for a long time we did use data URIs to encode images or fonts inline into HTML to avoid this loading delay, the encoding itself increases the size of the content by about a third. It’s really just a trade-off and a compromise. Not to mention that font ICONS need to generate so many types of fonts that inline HTML pages will suffer greatly.

• Accessibility issues: For users with visual impairment using screen reader, because the font icon is actually carried by characters, no matter whether the font is loaded or not, the screen reader can not read its content normally, in the default state will even read “pronounceable” which is not expected, You can imagine a web page that uses a lot of font ICONS without any individual annotationsaria-hiddenSuch semantic markup can be very confusing to screen reader users.

Iv. SVG ICONS

SVG has a natural scalability (S in SVG) feature that makes it ideal for implementing ICONS. At the same time, SVG is a text file, and many design tools that support vector editing support export through SVG, so designers can deliver it directly to engineers, eliminating the need to generate font files, greatly easing the maintainability pain point. But if you use it as an image, using or CSS background-image, these advantages alone are not enough to make the icon font obsolete.

4.1 inline SVG

The real power of SVG is that when you enclose it with HTML content, its document model can be accessed and manipulated by the JS/CSS on that page. This opens a new chapter for web ICONS:

• You can control the color and even the specific style of the icon through CSS, making it possible to animate ICONS that are controlled by business logic.
• In terms of display, font ICONS are treated as text in nature and will be affected by the browser’s text anti-aliasing algorithm, which may make them look less “fidelity” under certain operating systems, browsers, and font Settings. SVG, on the other hand, is rendered as an image and is not affected by text anti-aliasing algorithms.
• SVG inline HTML content does not require coding, and repetitive SVG content is also GZip friendly with little performance cost to HTML loading speed.
• No resource requests are required, and the HTML content can be streamed and rendered without any flickering experience issues.
• Icon loading can be done completely on demand, the current page is not used icon output.
• SVG can be accessed through<title>Element tags content and is screen reader friendly.

There is only one disadvantage to loading the font from an image resource or an icon:

• ICONS become part of the HTML content, and you can no longer specify which ICONS you want to use in CSS. Of course, from our practice, this does not constitute a big obstacle.

While inline SVG has many advantages, at this stage, using them in development is not as straightforward as font ICONS (introduce a CSS and the front end is ready to use) and requires a bit of engineering intrusion. GitHub fully enabled inline SVG in 2016. Their technology stack is Ruby back-end rendering, using helper functions defined by server-side scripts for icon font calls:

<%= octicon(:symbol => "plus") %>

Output:

< span style =" box-sizing: border-box; color: RGB (50, 50, 50); line-height: 22px; font-size: 14px! Important; word-wrap: break-word! Important; 16"> <path d="M12 9H7v5H5V9H0V7h5V2h2v5h5v2z"></path></svg>

4.2 SVG Sprite

Since SVG supports a

element that can be displayed as standalone SVG by selecting specific content from inline SVG, an SVG Sprite was designed inspired by the CSS Sprite. To import an entire SVG Sprite resource, you need to inline just one < SVG > element:

<svg> <defs> <symbol id="shape-icon-1"> <! -- icon paths and shapes --> <symbol> <symbol id="shape-icon-2"> <! -- icon paths and shapes --> <symbol> <! -- etc --> </defs></svg>

When using:

<svg viewBox="0 0 16 16" class="icon">  <use xlink:href="#shape-icon-1"></use></svg>

At the same time, there are a lot of Grunt/Gulp/ Webpack building schemes to generate SVG Sprite quickly.

The main problem with this approach is:

• It is not easy to import ICONS on demand.
• It is complicated to use in various scenarios.

The era of front-end component frameworks

Finally, we’re in an era where web-side rendering logic is moving to the front end and front-end engineering is dominated by componentized frameworks. In the use of the React/Vue/presents/Svelte /… We have become accustomed to dismantling and reusing view logic through components. It’s natural to encapsulate the underlying solution by designing an icon component, exposing the front-end to a simpler and more straightforward API to use the ICONS. It’s important to note that this doesn’t fundamentally change the way web ICONS are rendered; the bottom line is still based on the schemes mentioned above. In projects that do not use these view-layer frameworks, we still rely on the low-level implementation described above for development.

Of course, all things considered, encapsulating inline SVG is by far the best option. The GitHub back-end Helper solution above corresponds to the current front-end technical solution, which is actually an inline SVG based icon component. There are also a number of icon components developed on NPM based on various component frameworks, including FontAwesome which has SVG, React/Vue components and more modern solutions built in.

Now that the experience issues are well addressed with inline SVG, we have more energy to think about development efficiency, consistency, and experience at this stage. From our previous practice in Baidu, there are some problems as follows:

• Workflows lack best practices and the use of web icon schemes is not uniform due to a long period of relatively independent technical evolution among teams.
• Under the whole big system, designers across teams do not share icon resources well, and there are some repeated designs.
• There is a library of icon components, but the ICONS are limited. When the business needs to add ICONS, designers often deliver the ICONS offline to engineers, and the front end passes something similarsvg-icon-loaderThe scenarios that bring ICONS into the project are often different. Once such a process is introduced, it is equivalent to adding a fork version to the icon in a particular project, and it is costly for the business to follow up to make uniform changes to the design style in the future.
• For SVG icon components, we don’t have a platform like Iconfont. Cn for process folding, and we don’t have automated package export and distribution capabilities.

Ideally, we want to achieve the following:

• The icon designer maintains the icon source file, and there is no manual intervention to cause the process to fork after the release. There is a fixed icon library platform to provide single source of truth.
• Each team can select the component implementation type to export (React/Vue/San/…) based on their technology stack. .
• Icon data in the icon component library is automatically optimized and compressed.
• The icon component library should be updated with the icon library data.

At present, in the process of promoting baidu design Language system, together with the engineering efficiency team, we have designed the following overall scheme:

Icon platform overall process

5.1 Icon Management Platform

The platform can be thought of as a simple icon CMS, creating/managing an icon library where the icon designer is responsible for adding and managing ICONS. After the data is updated, you have the option to publish the current icon output to the API. The API returns graphic data (SVG source files) and metadata for ICONS in the icon library, and there are two main consumers in the process: the Sketch plug-in for design teams, and the front-end compile/publish service. We allow the icon library to be configured via Webhook to notify compilation services when it is published, so different users can choose to customize the entire compilation and distribution process if necessary.

5.2 the Sketch plug-in

We provide the design team with the Unicom Icon management Platform Sketch plugin, which allows designers to quickly search for the ICONS they need to use. After the online annotation is exported through our plug-in, the unique identifier of the icon in the icon platform will be automatically annotated on the annotation. This is also the identifier we use to generate the icon component, through which the front-end engineer can directly import the corresponding icon component from the icon component package.

5.3 Optimize/compile/publish services

The service does three main things when the icon library API triggers updates:

1. Optimization. The icon data is read from the API and the source file is initially optimized by SVGO. Since we want the icon component inline to HTML to have the flexibility to change the color through CSS, for common monochrome ICONS, we need to remove all hard-coded colors and set them tocurrentColor. In this step we go throughsvgsonTraversing SVG elements handles the associated logic.
2. Compilation. Given the optimized icon data, we need to generate our icon component package based on it. Here we provide component package templates for multiple frameworks. Each template has provided icon component factory functions corresponding to its own framework. By injecting icon data into the template through scripts, component packages required by each business can be flexibly generated according to platform data.
3. Release. Based on the configuration in the Webhook callback path, we can specify the name, description, and other information of the package to be published. The logic for the version number is also simple:

• Delete/rename icon: Major + 1
• Minor + 1 is added
• Change the icon to patch + 1

5.4 Icon Package Template

The compiler service’s only convention for boilerplates is:

1. The compile service outputs icon data in a specific directory.
2. The compilation service, in turn, calls the specific NPM script.

The template provider needs to provide a concrete implementation of the icon component, as well as a build script that converts the icon data into front-end code. If there is no special need, you can get a high quality front-end icon component implementation by using the component templates we provide under the React/Vue framework.

After publishing through the compile service, the front end engineer only needs to know: 1. Which NPM package the icon is from. 2. Give the icon a name and you can quickly introduce the icon into your front-end project. At the same time, the whole process ensures that the designer produces a consistent design, the front-end implementation, and can centrally control the upgrade from the icon platform.

Six, summarized

We front-end engineers have done a lot of research on introducing ICONS into Web products, and we have produced a lot of ancillary tools to improve the overall collaborative process. In the context of modular development, we have established a set of current “best practices” by analyzing the advantages and disadvantages of each solution, which reduces communication and error-prone manual operation in the process, and effectively achieves the consistency of design and implementation. Finally, I hope the content of this article can bring you harvest, thank you.

———- END ———-

Baidu said Geek

Baidu official technology public number online!

Technical dry goods · Industry information · online salon · Industry conference

Recruitment information · Internal promotion information · Technical books · Around Baidu

Welcome your attention