December 22, 2013 at 18:15About variables in CSS and abstractions in web programming
I bring to your attention a translation of an article from the blog of the popularizer of web technologies Chris Coyer About Variables in CSS and Abstractions in Web Languages . In the article, the author raises the question of whether CSS really needs add-ons that make it harder to read, and the entry threshold is higher when developers today have the opportunity to go up one level of abstraction .
Variables come in CSS . Today, there are concrete implementations, so now they can not be stopped. In Firefox, they appeared in version 29, and in Chrome they can be used without prefixes in versions 29 and older, if the Enable experimental Web Platform features flag is enabled in your settings(in the Russian locale "Enable the experimental functions of the web platform" - approx. transl.).
I’ll say right away that you can argue about how good or bad it is, but nothing can be changed. However, since I still want to discuss this topic, I will continue.
Recently I made a presentation on the topic of abstractions in computational processes. History knows several key points when we moved to a new level of abstraction. From the “ones and zeros” of machine code to assembler, from assembler to compilers, from compilers to their abstractions. In the end, we were able to create high-level languages such as C ++ .
Browsers¹ are made up of parts, such as a rendering engine and a JavaScript engine . They are written in C ++ . So when we write in HTML , CSS or JavaScript , we go up another level of the ladder of abstraction. HTML , CSS and JavaScriptthey don’t replace lower-level languages, they are above them and depend on these “layers”, which just allow them to do their job as successfully as possible. HTML , CSS and JavaScript are the languages we came up with to create what we wanted to see on the Web — interactive documents.
Time goes by and we want / expect / need the web platform to do more. New features are always added to browsers, but never removed from there². We admire these opportunities and try to fully use them. This makes creating web applications more difficult. But we do not like difficulties, because they cause inconvenience in work and reduce our efficiency.
This has been going on for a long time, so now we are taking a new step on the ladder of abstraction. Abstraction is the natural enemy of complexity, so we take it into service to make writing code easier.
The most necessary abstraction on the Web for us was the simplification of working with HTML . It would be incredibly stupid to work on a website, each page of which would be stored in the form of a full HTML document, starting with
There is an abstraction in JavaScript initially. The language has the appropriate tools - these are variables, loops, functions, and so on.
The last web language that needed abstractions was CSS , and they came into it in the form of preprocessors. There are too many repetitions in CSS , and it provides almost no abstraction tools. And preprocessors give what was so necessary for us, and this seriously helps us.
Another important point is the popularity of the web platform. It is the most successful platform in the history of computers. They create more on it than on any other. In other words, HTML , CSS, and JavaScript are extremely successful . In many respects, they owe the fruits of the efforts of advocates of web standards, but this is a completely different story.
Why is a language like CSSso popular? Because it is very simple. Selectors and key-value pairs. And that’s it. Yes, there are tons of pitfalls and subtleties. Yes, to become a real specialist, it will take a lot of time. But basically this language is very simple. It will take you ten seconds to show the code block to a stranger and explain how it works. This will be enough for him to understand everything.
I am convinced that the secret to CSS success is that its syntax is easy to understand, learn, and teach others. Yes, there is one, for which to blame, but I think that the right decisions were made at the initial moment of CSS development .
Like other languages, CSS has evolved over time . Like the entire web platform, he received new opportunities. Jeremy Kit pointed out that a major shift has occurred with the advent
As Jeremy says:
There’s no guarantee that the CSS fragment necessarily makes any sense.
CSS (the language itself) goes further down the road to becoming fully programmable. If the variables are convenient, the same goes for loops, isn't it? You can imagine the future version of CSS , in which there are so many powerful features of the programming language that it is no longer perceived as the simple, easy to understand and understand language from which it originates. So he is deprived of the simplicity that made it so easy for a beginner to approach him.
I am definitely not opposed to variables or any other programming-related concepts. I like them. They give me more opportunities as an author, simplify my work and allow me to do more. This is what all the (good) layers of abstraction do. So why not leave these concepts as a layer of abstraction instead of changing the basic principles of the language?
Jeremy's Word:
Let me, in the spirit of cross-blogging, answer Jeremy again.
He compares Sass and Haml and says that Sass is good and Haml is bad. In this, for the most part, I agree with him. I worked a bit with Haml and never really felt the special benefits of working with it. Every day I work with Sass , and my impressions are completely opposite. There are two points here.
The context is important here - "after a certain time." When there comes a moment at which we take another step up the ladder of abstraction, there are always several languages that argue among themselves over who will take a place in history. Developers try to keep each other together (as we see now in the CSS preprocessor market ), and over time, a “winner” is identified, who owns the main “market share”, if this term is applicable here.
The winner is that very “good”, as he confirmed his superiority in practice. Losers (probably) were not so good abstractions.
The second point is that I divide the abstractions into “primary” and “secondary”. The chosen terms may not be very successful, but I mean that there is an abstraction that provides the authors with the most important and significant advantages for them - this is primary abstraction, and there are abstractions that add only some details - these are secondary abstractions .
As I said above, the primary abstraction in HTML is templates and storing content in data stores. Haml is a secondary abstraction, thanks to which some developers get more convenient syntax of the language - this is not for everyone. CoffeeScript is a secondary abstraction for JavaScript's built-in abstraction tools.
Sass(or the one who will eventually become the winner) is the primary abstraction for CSS .
Original: About Variables in CSS and Abstractions in Web Languages
Notes:
1 - I know very well that it is customary to write “browsers”, but when I first came across this word, there was no Russian “canonical” version, and spelling through "O", including in specialized literature. Since then, I write it the only way. Sorry to hurt your feelings.
2 - In the comments on the original post, Chris indicates that this is not entirely true.
UPD: Thanks for the makc9I revision suggestions .
Variables come in CSS . Today, there are concrete implementations, so now they can not be stopped. In Firefox, they appeared in version 29, and in Chrome they can be used without prefixes in versions 29 and older, if the Enable experimental Web Platform features flag is enabled in your settings(in the Russian locale "Enable the experimental functions of the web platform" - approx. transl.).
I’ll say right away that you can argue about how good or bad it is, but nothing can be changed. However, since I still want to discuss this topic, I will continue.
Background
Recently I made a presentation on the topic of abstractions in computational processes. History knows several key points when we moved to a new level of abstraction. From the “ones and zeros” of machine code to assembler, from assembler to compilers, from compilers to their abstractions. In the end, we were able to create high-level languages such as C ++ .
Browsers¹ are made up of parts, such as a rendering engine and a JavaScript engine . They are written in C ++ . So when we write in HTML , CSS or JavaScript , we go up another level of the ladder of abstraction. HTML , CSS and JavaScriptthey don’t replace lower-level languages, they are above them and depend on these “layers”, which just allow them to do their job as successfully as possible. HTML , CSS and JavaScript are the languages we came up with to create what we wanted to see on the Web — interactive documents.
Time goes by and we want / expect / need the web platform to do more. New features are always added to browsers, but never removed from there². We admire these opportunities and try to fully use them. This makes creating web applications more difficult. But we do not like difficulties, because they cause inconvenience in work and reduce our efficiency.
This has been going on for a long time, so now we are taking a new step on the ladder of abstraction. Abstraction is the natural enemy of complexity, so we take it into service to make writing code easier.
The most necessary abstraction on the Web for us was the simplification of working with HTML . It would be incredibly stupid to work on a website, each page of which would be stored in the form of a full HTML document, starting with
There is an abstraction in JavaScript initially. The language has the appropriate tools - these are variables, loops, functions, and so on.
The last web language that needed abstractions was CSS , and they came into it in the form of preprocessors. There are too many repetitions in CSS , and it provides almost no abstraction tools. And preprocessors give what was so necessary for us, and this seriously helps us.
Popularity
Another important point is the popularity of the web platform. It is the most successful platform in the history of computers. They create more on it than on any other. In other words, HTML , CSS, and JavaScript are extremely successful . In many respects, they owe the fruits of the efforts of advocates of web standards, but this is a completely different story.
Why is a language like CSSso popular? Because it is very simple. Selectors and key-value pairs. And that’s it. Yes, there are tons of pitfalls and subtleties. Yes, to become a real specialist, it will take a lot of time. But basically this language is very simple. It will take you ten seconds to show the code block to a stranger and explain how it works. This will be enough for him to understand everything.
h1 {
color: red;
}
I am convinced that the secret to CSS success is that its syntax is easy to understand, learn, and teach others. Yes, there is one, for which to blame, but I think that the right decisions were made at the initial moment of CSS development .
Language complication
Like other languages, CSS has evolved over time . Like the entire web platform, he received new opportunities. Jeremy Kit pointed out that a major shift has occurred with the advent
@keyframesof CSS . For the first time, it became possible to write CSS in such a way that it would not make sense at all and might not work until another CSS block appeared ./* Это не имеет смысла... */
.animate {
animation: my-animation 0.2s;
}
/* ...если не будет этого фрагмента, который может находиться где угодно в коде или вообще отсутствовать */
@keyframes my-animation {
to { color: red; }
}
As Jeremy says:
So CSS variables (or arbitrary properties) are not the first crack in the wall of principles on which CSS is based . If I use my other metaphor, he stood on a slippery track even with the advent of @keyframes (and also, possibly, @ font-face).
There’s no guarantee that the CSS fragment necessarily makes any sense.
CSS (the language itself) goes further down the road to becoming fully programmable. If the variables are convenient, the same goes for loops, isn't it? You can imagine the future version of CSS , in which there are so many powerful features of the programming language that it is no longer perceived as the simple, easy to understand and understand language from which it originates. So he is deprived of the simplicity that made it so easy for a beginner to approach him.
Abstraction layer
I am definitely not opposed to variables or any other programming-related concepts. I like them. They give me more opportunities as an author, simplify my work and allow me to do more. This is what all the (good) layers of abstraction do. So why not leave these concepts as a layer of abstraction instead of changing the basic principles of the language?
Jeremy's Word:
Thanks to preprocessors like Sass , we have both the sheep and the wolves full.
Not all abstractions are equally useful.
Let me, in the spirit of cross-blogging, answer Jeremy again.
... not every abstraction is good.
He compares Sass and Haml and says that Sass is good and Haml is bad. In this, for the most part, I agree with him. I worked a bit with Haml and never really felt the special benefits of working with it. Every day I work with Sass , and my impressions are completely opposite. There are two points here.
Chris states that abstraction is, by definition, “good.”
The context is important here - "after a certain time." When there comes a moment at which we take another step up the ladder of abstraction, there are always several languages that argue among themselves over who will take a place in history. Developers try to keep each other together (as we see now in the CSS preprocessor market ), and over time, a “winner” is identified, who owns the main “market share”, if this term is applicable here.
The winner is that very “good”, as he confirmed his superiority in practice. Losers (probably) were not so good abstractions.
The second point is that I divide the abstractions into “primary” and “secondary”. The chosen terms may not be very successful, but I mean that there is an abstraction that provides the authors with the most important and significant advantages for them - this is primary abstraction, and there are abstractions that add only some details - these are secondary abstractions .
As I said above, the primary abstraction in HTML is templates and storing content in data stores. Haml is a secondary abstraction, thanks to which some developers get more convenient syntax of the language - this is not for everyone. CoffeeScript is a secondary abstraction for JavaScript's built-in abstraction tools.
Sass(or the one who will eventually become the winner) is the primary abstraction for CSS .
Original: About Variables in CSS and Abstractions in Web Languages
Notes:
1 - I know very well that it is customary to write “browsers”, but when I first came across this word, there was no Russian “canonical” version, and spelling through "O", including in specialized literature. Since then, I write it the only way. Sorry to hurt your feelings.
2 - In the comments on the original post, Chris indicates that this is not entirely true.
UPD: Thanks for the makc9I revision suggestions .