Shulou(Shulou.com)06/01 Report--

This article mainly introduces what is the static UI component refactoring strategy of color attributes. It is very detailed and has a certain reference value. Interested friends must read it!

First, the faint pain points of traditional static UI components.

As we all know, a website, as long as the designer is a little professional, some of the basic colors of the site are throughout.

The main color, link color, warning color, and various state colors, etc., are all in the same line, if the red of the text of your station and the red of the button are not the same red, the green of the text and the green of the button are not a green, the blue of the text and the blue of the button are not a blue, I can only express my deep regret.

The traditional implementation, including almost all the implementation routines on the mobile side, is as follows: whether it is a label or a button, first set a basic class name, write down the basic style, and then rename a state class name with different colors. override the default border color or background color or text color, write whatever color it is.

Let's take a look at the implementation of buttons in Wechat's open source weui: https://weui.io/#button

HTML section:

Button confirm button

The corresponding CSS implementation is as follows:

.weui-btn {position: relative; display: block; margin-left: auto; margin-right: auto; padding-left: 14px; padding-right: 14px; box-sizing: border-box; font-size: 18px; text-align: center; text-decoration: none; color: # FFFFFF; line-height: 2.555556; border-radius: 5px; overflow: hidden;}. Weui-btn_primary {background-color: # 1aad19 }. Weui-btn_default {color: # 000000; background-color: # F8F8F8;}. Weui-btn_warn {background-color: # E64340;} / * below are two wireframe buttons * / .weui-btn_plain-default {color: # 353535; border: 1px solid # 353535;}. Weui-btn_plain-primary {color: # 1aad19; border: 1px solid # 1aad19;}

Basically, this is how we all implement it, and it's okay to use it, but I don't know if you feel redundant and verbose when writing code similar to the above. It's just that the color is different, but you have to rename a class name, and then rewrite the color; as long as you have one more state, you have to write another batch. What a trouble!

Why does it feel like this vaguely?

Let me take you to analyze it.

1. Button statu

In essence, buttons have three states, common state, default state and warning state, but from the point of view of the number of class names, there are 5, and the naming is long and verbose, which is really hard to bear. If you mix it with the disabled style of buttons in weui, it is so long that it is not enough to look at my arms. For example, the disabled state of the following small green button indicates:

Button

In fact, we can separate the state out of abstraction, such as: default, primary, warn, mini, disabled, and the base button style to generate UI effect, so that the use of class names in HTML will be much more refreshing, and the cost of memory is reduced.

Its core ideas and technical details can be found in the article I just wrote: "web front-end interactive development based on state class names such as active,checked".

If the above button applies this strategy, the code should look like this:

HTML section:

Button confirm button

The corresponding CSS implementation is as follows:

. weui-btn {.}. Weui-btn.primary {background-color: # 1aad19;}. Weui-btn.default {color: # 0000000; background-color: # F8F8F8;} .weui-btn.warn {background-color: # E64340;} / * below are two wireframe buttons * / .weui-btn_plain.default {color: # 353535; border: 1px solid # 3535;} .weui-btn_plain.primary {color: # 1aad19 Border: 1px solid # 1aad19;}

Of course, for open source projects like weui, the above strategy based on state class names is not necessarily appropriate because it is mixed with other projects and is prone to conflict.

two。 A variety of colors

For example, the primary state is exactly the same as # 1aad19, but it appears three times up and down. If you use Sass, the Less variable is fine. If you use the traditional CSS method, if you change the color later, you may have to replace it one by one.

Write a batch of colors for each state, if you encounter scenes with many states (such as the screenshot of the project design draft below):

Shit, that style is much more boundless, a line of all border color text color, border color text color, but everything has to look at both sides, at least this code looks spectacular.

Each color state should be written once the color attribute and border attribute, this feeling of coolie no one will like, clearly repetitive things, can not be front-end engineering?

In fact, the above two subtle pain points can be solved all at once, which is to adopt the "UI component refactoring strategy based on color attributes" introduced in this article.

2. Implementation strategy of static UI components driven by CSS color attributes.

The implementation strategy is as follows:

Extract a special color class name

For example, something like this:

Dark {color: # 33373d;}. Gray {color: # 969ba3;}. Blue {color: # 4284ed;}. Green {color: # 7ed321;}. Orange {color: # f0643a;} .yellow {color: # f0c53a;} .purple {color: # a091ff;} .red {color: # ed424b;}. White {color: # fff;}

Then, it is recommended to put it at the bottom of all common styles.

All dynamic colors of static UI components go to native variables

For example, the border border color defaults to the color of the color property, so when writing border, the color value can be directly defaulted, directly:

. btn-normal {border: 1px solid;}

For the background color, we can go to the currentColor variable of CSS. For the currentColor variable, see my previous article: "currentColor-CSS3 ultra-high school level easy to use CSS variable."

. btn-normal {background-color: currentColor;}

Color class names play both the role of state class names and the role of color control.

HTML directly becomes something like this:

Red button, blue button, green button.

The great task has been completed!

Let's look at a specific example to deepen our understanding of the implementation of solid buttons. Again, we have a basic class name and basic style:

.btn-normal {font-size: 14px; line-height: 30px; display: inline-block; padding: 0 16px; text-align: center; border-radius: 2px; background-color: currentColor;}

Note that unlike the traditional implementation, we specify the background color directly here, but in the form of the currentColor variable, that is, the background color is consistent with our text color.

What? Background color and our text color! Isn't that a mixture of button text color and background color? look at it!

Yes, the text color of the button cannot be the same as the background color, but since there is usually only one line of text on the button, note that the best part of this article is here-considering that the text on the button is all white, so we can deal with it like this:

.btn-normal::first-line {color: # fff;}

Use:: first-line pseudo-element, so the color on the .btn-normal tag is actually set to background-color, while the real button color has been firmly set by:: first-line pseudo-element, so you don't have to worry about the mixing of text color and background color.

As a result, with the basic color class name, all kinds of color buttons come out.

To implement the designer's green and red buttons, directly HTML:

Green button, red button.

Later, the designer suddenly found that the two color buttons were not enough, and designed a blue button of the same size. if it is a traditional implementation, it must rename the solid button and wireframe button respectively, and continue to add the relevant background color and border color style code in the CSS code. Do you think it's annoying? If it is based on the color attribute implementation, I will, the workload is not too easy, just HTML and add a blue class name:

Blue button

Yes, it's over. The CSS file doesn't need to be opened. In fact, a basic button style is written, which is equivalent to all the buttons of all colors.

A discerning person can tell at a glance which is better or worse.

And, most importantly, buttons are not the only static UI components in this slightly heavier project!

All kinds of color text are also UI components in nature, and then, various level tags, honor labels, special buttons, analog controls, and so on.

If all these static UI components adopt the strategy based on the color attribute, then these colors will become the real color variables throughout the project, which will greatly reduce the cost of maintenance in the future, especially without the use of precompiled tools such as Sass,Less and Styus.

Moreover, the workload of CSS writing and the amount of CSS code are significantly reduced, and the HTML level code is more concise and straightforward, super good memory. You know, HTML code is often maintained by developers at a later stage. Unless you are well documented, how do developers know how to change the color of the button? But if you use the independent class name of the color keyword, a developer who doesn't know CSS at all can easily maintain it.

All in all, all kinds of cool and comfortable!

With regard to the implementation of all kinds of static UI components based on color attributes, I have specially sorted out a completed large demo, all of which are derived from real projects. You can click here: static UI components based on CSS color attributes to develop demo

Several color class names have completed the following more than 30 static UI controls with different colors and styles. It can be said that hundreds of lines of CSS code are missing:

Finally, again, the key skill that this strategy can achieve is the use of:: first-line pseudo elements of the text color control technology.

III. Technological Development and Transformation of thinking

The development of technology will often bring about corresponding changes in the way of thinking, so that we can complement each other and give full play to the potential of new technologies. If we still use the previous mode of thinking, it has the feeling that Rolls-Royce is running with 9% gasoline.

The CSS writing of buttons in weui is a typical traditional implementation strategy, solid and solid, a legacy of traditional best practices.

Because after all, PC was developed first, and our thinking is also limited due to the limitations of technology.

For example, because IE6 browsers have serious bug support for cascading class name styles such as .a.b, and considering that its efficiency is the lowest in the selector, for a long time, our coverage strategy for button styles is not based on state, but on the full button class name + state class name, because IE6 is well supported and conflicts are almost impossible.

In the display world, most projects are self-contained and will not be directly mixed with other projects, so the risk of conflict can be appropriately reduced; second, there is only one person who writes the page for many projects. because you don't have to worry about meeting your butter hand colleagues, as long as you write strictly according to the guidelines, simple code and fast writing will bring higher benefits.

For example, because currentColor variables are only supported by IE9 browsers, long-term PC project development does not make refactoring students realize that when we work on mobile projects now, we can change the color of buttons or icons or labels directly through a color attribute without messy style. If the world appears first on the mobile side and then on the PC side, I think our writing strategy for static UI components may be, as mentioned in this article, a system based on color attributes and throughout writing, rather than a guerrilla strategy of one shot and one shot.

In other words, although CSS3 technology brings a lot of great things, our way of thinking seems to remain in the old PC era, perhaps because we are only focused on the superficial performance of CSS3.

4. Reconstruction of UI components based on CSS color applicable projects and scenarios

No strategy is common to one side. Although the color strategy in this paper is exquisite and has many benefits, it also has its limitations.

The first is the compatibility limitation, which is supported by currentColor IE9+ browser, which is one of the key technical points. Therefore, it is suitable for mobile development and some projects that do not need to manage lower versions of IE browsers. Although the progress of browsers, I believe it will not be long before the PC project will see the popularity of this strategy.

Second, it does not apply to open source projects. Open source means that it will be mixed with projects of many other users, and there will be specification constraints when developed in our own team, but once mixed up, short-named class names like .red can easily be washed out by .red class names in other styles. Therefore, from this point of view, the implementation strategy of weui is actually the most appropriate. Using the color attribute strategy of this article, it is easy to mention issues, but the details can be further improved, for example:

.weui-btn_plain-default {color: # 353535; border: 1px solid # 353535;} .weui-btn_plain-primary {color: # 1aad19; border: 1px solid # 1aad19;}

It can be written directly as:

.weui-btn_plain-default {color: # 353535; border: 1px solid;} .weui-btn_plain-primary {color: # 1aad19; border: 1px solid;}

The border:1px solid can then be placed in the base style, so the CSS is further reduced to:

.weui-btn_plain-default {color: # 353535;} .weui-btn_plain-primary {color: # 1aad19;}

See, it's essentially a dark and green color class name.

Supplement on the following day

Some commentators mentioned that if the button is going to change from blue to green in the future, the naming now will be very troublesome, and the style and semantics will not match. Although I have written the page for so many years and have not encountered similar changes, it is difficult to guarantee that other items will not. Therefore, for the naming of buttons, it is safe to use state-based naming, or use more obscure naming, such as primary, default, etc., but the style still uses color control. The two do not conflict.

For example (Sass):

.primary {@ extend .green;}

Or:

.green, .primary {color:...;}

However, for many kinds of color tags, obviously, it is best to deal with them based on color, otherwise, you will have a headache for a long time if you just want to name it. In the end, it is often *-1, color 2, color 3. In the end, God knows what the label is corresponding to 1pm / 2pm / 3.

Some people in the comments also asked what to do with hover and Action. In fact, there is a hint on the button on the demo page. You can use box-shadow inner shadows or background-image gradients, such as CSS:

.btn-normal:active {background-image: linear-gradient (to top, rgba (0,0,0,.05), rgba (0,0,0,.05);}

All buttons are deepened together, and if you want to brighten, you can try a light white transparent cover.

Fifth, there is no conclusion always feel strange

But people are sleepy and tired, and they can't think of anything to complain about. I already paid homage to the previous article in the early years.

Then put whatever words you want:

According to BBC, 70% of babies are pretending to cry at night in order to attract adults to play together, while 90% of male parents pretend not to wake up so that mothers can get up and take care of them.

Yes, I am the 90%!

This is all the content of the article "what is the static UI component refactoring strategy for color properties?" Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.