#css preprocessor

Khi xây dựng website hoặc landing page bán hàng, CSS đóng vai trò quan trọng trong việc định hình giao diện và trải nghiệm người dùng. Tuy nhiên, khi dự án phát triển lớn hơn, CSS thuần thường gặp một số vấn đề quen thuộc như code lặp lại nhiều, khó quản lý và khó bảo trì.

Đó là lý do các công cụ như SASS/SCSS được sử dụng rộng rãi trong phát triển frontend hiện đại.

Nếu bạn muốn tìm hiểu thêm về lập trình và các công nghệ mới, hãy tham khảo nhiều bài viết hữu ích tại DinhDai.Tech, nơi chia sẻ nhiều kiến thức dành cho developer.

CSS Preprocessor là gì?

SASS/SCSS thuộc nhóm công cụ gọi là CSS Preprocessor. Đây là những công cụ giúp mở rộng khả năng của CSS bằng cách bổ sung các tính năng giống như trong lập trình, chẳng hạn như biến, vòng lặp hoặc điều kiện.

Nhờ đó, lập trình viên có thể viết CSS theo cách logic và dễ quản lý hơn thay vì phải lặp lại nhiều đoạn code giống nhau. Tuy nhiên, code viết bằng CSS Preprocessor sẽ cần được biên dịch thành CSS thuần trước khi trình duyệt hiển thị giao diện.

Trong số các công cụ CSS Preprocessor hiện nay, SASS/SCSS là lựa chọn phổ biến nhất trong cộng đồng frontend.

SASS và SCSS khác nhau như thế nào?

SASS là viết tắt của Syntactically Awesome Stylesheets, một công cụ được tạo ra để giúp lập trình viên viết CSS hiệu quả hơn. Công cụ này bổ sung nhiều tính năng hữu ích như biến, mixin, kế thừa hay khả năng lồng selector.

SCSS thực chất là một dạng cú pháp của SASS nhưng được thiết kế để gần giống CSS thuần. Điều này giúp lập trình viên có thể sử dụng CSS quen thuộc trong file SCSS và bổ sung thêm các tính năng nâng cao khi cần.

Nhờ cú pháp dễ đọc và dễ tiếp cận, SCSS hiện được sử dụng phổ biến hơn trong các dự án web hiện đại.

Khi nào nên sử dụng SCSS?

SCSS đặc biệt hữu ích khi xây dựng các dự án có nhiều file CSS hoặc nhiều thành phần giao diện. Nhờ khả năng tổ chức code theo module và tái sử dụng style, việc quản lý giao diện trở nên dễ dàng và nhất quán hơn.

Điều này rất quan trọng trong các dự án như website thương mại điện tử, landing page marketing hoặc các hệ thống web app lớn.

Nếu bạn muốn khám phá thêm nhiều kiến thức lập trình web hữu ích khác để hiểu rõ hơn về cách xây dựng và phát triển ứng dụng web.

Hey everybody, I have a huge announcement to make! Just a few days ago, we added the final touches to our latest masterpiece in the Jump Start collection: Jump Start Sass. I have been working closely with SitePoint for the past months to write a book on Sass dedicated to people wanting to learn more about the preprocessor, its language and how to use it in daily projects to help boost productivity. [author_more] Miriam Suzanne (the author of Susy and the True testing framework) and I have joined forces to offer you a result that is not only comprehensive, but also simple and accessible. Basically, it’s 157 pages of awesomeness (in my un-biased opinion!). What’s in there? Here is the table of contents and a few words on each chapter to get you hungry: Foreword (by no other than Chris Eppstein) Hello World — An introduction to Sass in modern front-end development, its history, its syntaxes (Sass and SCSS) as well as its competitors (LESS, Stylus and PostCSS). Getting Started — A short explanation on how to install Sass binaries (both the Ruby gem and node-sass) and how to use them to compile Sass stylesheets to CSS. Variables — An extensive chapter on variables, how they work, how to use them, when and why, closed with a comparison with CSS Custom Properties. Functions & Mixins — A chapter dedicated to mastering functions and mixins to start building small systems. Loops & Conditions — A concise explanation of how logical structures work in Sass, mainly loops and conditions statements, and how to use them to build powerful mixins. Nesting — A reminder on the nesting feature, mostly focused on selector nesting, providing helpful tips to avoid being lost in the dreaded horizontal pyramid of selectors. Extend — A solid introduction to the @extend directive and how to avoid bloated output when using it. Warnings & Errors — An introduction to the ability to emit warnings and throw errors directly from within stylesheets, as well as why and when doing so makes sense. Architecture — A massive chapter on different approaches to Sass-powered project architecture, including OOCSS, ITCSS, SMACSS and more. Ecosystem — The final chapter introduces you to the Sass ecosystem, its main toolkits, libraries and frameworks such as Bourbon, Susy, Accoutrement, SassDoc, Sass-Guidelines, Modular Scale, SCSS-lint and many many more. That covers quite a lot, doesn’t it? Who is this book for? As you can guess from the table of contents, this book is essentially targeted to newcomers and beginners, all the way up to the intermediate level. This is part of SitePoint’s Jump Start series, so it’s not aimed at advanced Sass users. However if you feel a bit short on Sass, are not too sure about how to tackle project architecture or simply find yourself in need of a refresher, you’ll be pleased. I promise that. On top of this book, I recommend you bookmark the SitePoint Sass Reference as a quick reference for features tackled in this book, as well as Sass Guidelines to push the quality of your Sass code to the next level. It’s available on SitePoint Premium, SitePoint’s subscription service, or you can order a print or ebook version via O’Reilly. Alright. Go read it now, and let us know what you think! Continue reading %Introducing Our Newest Book: Jump Start Sass% Full Article

With the introduction of any new front-end tool, there comes the important questions with regard to its potential value in an already congested marketplace. Does it offer developers anything new? Is it going to be worth investing the time and effort to learn and implement it? Since its inception, PostCSS has faced an interesting problem. With it vying for attention in a reasonably mature area alongside established CSS tooling such as Sass and Less, there have been a number of misconceptions made relating to its categorization and use. So let’s address some of the most common myths around PostCSS and in doing so show how it can enhance your workflow and improve how you work with CSS. N.B. If you want to find out more about what PostCSS actually is and how to set it up, check out this introduction to PostCSS and then come back here for some mythbusting! Myth 1 – PostCSS is a Pre or a Postprocessor Let’s start with perhaps the biggest point of confusion relating to PostCSS. When PostCSS was first released, it was promoted and categorized as being a ‘Postprocessor’. Many of the first PostCSS plugins took valid CSS and extended it in some way, rather than the previously familiar approach taken by preprocessors of taking custom syntax and compiling it into valid CSS. To call PostCSS a postprocessor is somewhat misguided and actually plays down its capabilities. I prefer to refer to it simply as a CSS Processor, as it can perform a number of different tasks, using PostCSS plugins, at several points in your CSS authoring process. A number of PostCSS plugins take custom syntax and convert it into valid CSS, as you would associate with a conventional preprocessor like Sass. One such example would be the PostCSS Nested plugin which lets you nest selectors – in the same way that Sass and Less implement selector nesting. Other PostCSS plugins take valid CSS and extend it, such as PostCSS’s most well-known plugin, Autoprefixer, which adds vendor prefixes automatically to your stylesheet. Some PostCSS plugins don’t actually transform your CSS at all, but instead provide useful insights into your styles. Stylelint can be used to lint your CSS, while a plugin like Colorguard can help you to maintain a consistent color palette across a project. In addition to all of this, PostCSS can parse SCSS syntax as well as standard CSS. This means that you can extend your Sass .scss files with PostCSS plugins – something which we will go into in more detail in Myth 2. So to bust our first myth — PostCSS is neither a Pre or a Post–processor. It is a CSS Processor that can extend or report on your styles at a number of different points in your workflow. Myth 2 – PostCSS Is an Alternative to Preprocessors like Sass and Less A common misconception among developers is to compare PostCSS as an alternative to already existing preprocessing tools such as Sass and Less. I believe this to be down to the fact that a number of the first PostCSS plugins focused on emulating features commonly seen in preprocessors, such as variables, conditionals, loops and mixins. As the PostCSS community has grown, a much more diverse range of plugins has emerged, offering a number of features that differentiate it from traditional preprocessors. So although you could use PostCSS as an alternative to using a preprocessor like Sass or Less, you could alternatively power-up your existing toolset by extending the features of your favourite preprocessor. PostCSS is capable of parsing both CSS and SCSS syntax, which means that you can use PostCSS plugins to transform your styles both before and after your Sass compilation step. For example, on a current project I use PostCSS to lint my Sass files using Stylelint before it is compiled into CSS. The resulting CSS is then extended with plugins like Autoprefixer and postcss-assets to add vendor prefixes and inline image assets as data URIs. So your workflow could look something like this: Ultimately, how you choose to use PostCSS is up to you. If you want to use it as your sole CSS processing tool, you can certainly do that. But if you’re perfectly happy using Sass or Less, consider that PostCSS is equally capable of working alongside those tools to provide additional features that your preprocessor cannot. Continue reading %PostCSS Mythbusting: Four PostCSS Myths Busted% Full Article

With the introduction of any new front-end tool, there comes the important questions with regard to its potential value in an already congested marketplace. Does it offer developers anything new? Is it going to be worth investing the time and effort to learn and implement it? Since its inception, PostCSS has faced an interesting problem. With it vying for attention in a reasonably mature area alongside established CSS tooling such as Sass and Less, there have been a number of misconceptions made relating to its categorization and use. So let’s address some of the most common myths around PostCSS and in doing so show how it can enhance your workflow and improve how you work with CSS. N.B. If you want to find out more about what PostCSS actually is and how to set it up, check out this introduction to PostCSS and then come back here for some mythbusting! Myth 1 – PostCSS is a Pre or a Postprocessor Let’s start with perhaps the biggest point of confusion relating to PostCSS. When PostCSS was first released, it was promoted and categorized as being a ‘Postprocessor’. Many of the first PostCSS plugins took valid CSS and extended it in some way, rather than the previously familiar approach taken by preprocessors of taking custom syntax and compiling it into valid CSS. To call PostCSS a postprocessor is somewhat misguided and actually plays down its capabilities. I prefer to refer to it simply as a CSS Processor, as it can perform a number of different tasks, using PostCSS plugins, at several points in your CSS authoring process. A number of PostCSS plugins take custom syntax and convert it into valid CSS, as you would associate with a conventional preprocessor like Sass. One such example would be the PostCSS Nested plugin which lets you nest selectors – in the same way that Sass and Less implement selector nesting. Other PostCSS plugins take valid CSS and extend it, such as PostCSS’s most well-known plugin, Autoprefixer, which adds vendor prefixes automatically to your stylesheet. Some PostCSS plugins don’t actually transform your CSS at all, but instead provide useful insights into your styles. Stylelint can be used to lint your CSS, while a plugin like Colorguard can help you to maintain a consistent color palette across a project. In addition to all of this, PostCSS can parse SCSS syntax as well as standard CSS. This means that you can extend your Sass .scss files with PostCSS plugins – something which we will go into in more detail in Myth 2. So to bust our first myth — PostCSS is neither a Pre or a Post–processor. It is a CSS Processor that can extend or report on your styles at a number of different points in your workflow. Myth 2 – PostCSS Is an Alternative to Preprocessors like Sass and Less A common misconception among developers is to compare PostCSS as an alternative to already existing preprocessing tools such as Sass and Less. I believe this to be down to the fact that a number of the first PostCSS plugins focused on emulating features commonly seen in preprocessors, such as variables, conditionals, loops and mixins. As the PostCSS community has grown, a much more diverse range of plugins has emerged, offering a number of features that differentiate it from traditional preprocessors. So although you could use PostCSS as an alternative to using a preprocessor like Sass or Less, you could alternatively power-up your existing toolset by extending the features of your favourite preprocessor. PostCSS is capable of parsing both CSS and SCSS syntax, which means that you can use PostCSS plugins to transform your styles both before and after your Sass compilation step. For example, on a current project I use PostCSS to lint my Sass files using Stylelint before it is compiled into CSS. The resulting CSS is then extended with plugins like Autoprefixer and postcss-assets to add vendor prefixes and inline image assets as data URIs. So your workflow could look something like this: Ultimately, how you choose to use PostCSS is up to you. If you want to use it as your sole CSS processing tool, you can certainly do that. But if you’re perfectly happy using Sass or Less, consider that PostCSS is equally capable of working alongside those tools to provide additional features that your preprocessor cannot. Continue reading %PostCSS Mythbusting: Four PostCSS Myths Busted% Full Article

In the ever-changing world of front-end development, it is quite hard to find a concept that actually makes a difference, and to introduce it correctly enough so that other people are actually willing to try it. When we look at CSS, I would say the last big shift that happened in the way we write CSS (on the tooling side) would have to be the arrival of CSS processors, mostly Sass, probably the most well-known one. There’s also PostCSS, which has a slightly different approach but ends up essentially in the same basket – browser-unsupported syntax goes in, browser-supported syntax goes out. Now a new kid has joined the block under the name CSS Modules. In this article, I’d like to introduce this technique, tell you why it has some good points, and how you can get started with it. What is a CSS Module? Let’s start with the explanation from the official repository: A CSS Module is a CSS file in which all class names and animation names are scoped locally by default. Now, it is a little more complex than that. Because class names are scoped locally by default, it involves some setup, a build process, and a bit of magic that is sometimes hard to grasp. But eventually, we can appreciate CSS Modules for what they are: a way to scope CSS to a component and escape the global namespace hell. No more struggling to find a good way to name your components, because the build step is doing that for you! How does it work? CSS Modules need to be piped in a build step, which means they do not work by themselves. See this as a plugin for either webpack or Browserify. It basically works this way: when you import a CSS file inside a JavaScript module (such as, but not necessarily, a React component), CSS Modules will define an object mapping class names from the file to dynamically scoped/namespaced class names that can be used as strings in JavaScript. Allow me to illustrate with an example: Below is a very simple CSS file. The .base class does not have to be unique on the project as it is not the actual class name that will be rendered. It is just a kind of alias inside the stylesheet to be used in the JavaScript module. [code language=”css”] .base color: deeppink; max-width: 42em; margin: 0 auto; [/code] And here is how you would use it in a dummy JavaScript component: [code language=”javascript”] import styles from ‘./styles.css’; element.innerHTML = `<div class=”$styles.base”> CSS Modules are fun. </div>`; [/code] Eventually, this will generate something like this (when using it through webpack with the default setup): [code language=”html”] <div class=”_20WEds96_Ee1ra54-24ePy”>CSS Modules are fun.</div> [/code] [code language=”css”] ._20WEds96_Ee1ra54-24ePy color: deeppink; max-width: 42em; margin: 0 auto; [/code] The way class names are generated can be configured to make them shorter, or to follow a specific pattern. It doesn’t really matter in the end (although shorter class names mean shorter stylesheets) because the point is that they are dynamically generated, unique, and mapped to the correct styles. Continue reading %Understanding the CSS Modules Methodology% Full Article

You may have recently heard of Grid Style Sheets (GSS) in the world of HTML and CSS. GSS re-imagines CSS layout and replaces the browser’s layout engine with one that harnesses the Cassowary Constraint Solver. Those of you who didn’t understand a word of that…hello, and welcome! GSS promises a better future. GSS promises relative positioning and sizing. GSS promises to center any element inside another with one line of code. And GSS delivers. The question is: How? In this article, I’ll cover a brief history of GSS and an in-depth overview of the features it has to offer. I’ll also look at GSS for constraint-based layouts, the Cassowary constraint algorithm, and walk you through the process of installing and using GSS. Those of you who’d rather not wait around for the W3C or browsers to catch up, I urge you to hang in there and pay close attention while I explain the mystery that is GSS. On that note, let’s start with a little history. A Brief History GSS is a creation of The Grid with Dan Tocchini as its founder and CEO. This answers why the not-so-grid-based style sheets are called Grid Style Sheets. The war between web developers and front-end technology to present ideas onto the web has been going on for years. CSS has proved to be triumphant for the past decade. However, building increasingly complex user interfaces with tools that haven’t evolved with time is something web developers are expected to do on a regular basis. For example, vertically centering an element with CSS has not been the simplest of tasks, especially with variable-height elements. Flexbox is one of the most recent solutions, but even small changes there require you to go deep within your HTML content and CSS presentation and make changes. It’s time for GSS to take the arena. GSS tackles these problems and many more — problems that developers have had for over a decade. Essentially, GSS is a CSS preprocessor and JavaScript runtime that exploits Cassowary.js. Those of you who don’t already know, Cassowary.js is the JavaScript port Apple uses in Cocoa Autolayout. Both GSS and Cassowary are founded on constraint programming, making it ideal for empowering declarative languages like CSS. Constraint programming is a paradigm by which web developers are concerned with declaring the “what” and leaving the “how” up to a mathematical solver. Constraint programming focuses on intentions, not implementation. Now that we’ve established some background information, let’s move on to the features GSS offers. Overview of GSS One of the biggest problems with CSS is relativity. You can expect any CSS element to have an unending list of properties — padding, height, width, float, margins, borders, outlines — but none of this information tells us where the element will be located with reference to other elements on the page (or even the page as a whole). The endless list also doesn’t answer where the element will be displayed with different screen sizes. This brings us to the first Feature of GSS: You define what you want the layout to be. Gone are the days of spending countless hours of trial-and-error, strategizing how the layout should be constructed. Since we already discussed that GSS utilizes Cassowary.js, here is another great feature of GSS: An element can be centered within any other with one line of code. This makes a lot of workarounds unnecessary and things of the past. For instance, if you want to add a Subscribe button in line vertically with, say, a heading on the right side of your site’s page, you would use the following code: [code language=”css”] .subscribe-button[right] == ::window[width]; .subscribe-button[center-y] == .header[center-y]; [/code] Another feature: GSS makes floats, table cells, clearfix, and horizontal/vertical centering obsolete. Bid farewell to the perilous pitfall that is a float because we’ve got the W3C itself saying that floats are not ideal for application layouts. “As websites evolved from simple documents into complex, interactive applications, tools for document layout, e.g. floats, were not necessarily well suited for application layout.” – W3C Grid Layout Module (working draft) What about CSS features like !important? The fourth feature of GSS does something similar: GSS employs constraint hierarchy to prioritize constraints with strengths. We’re talking about four built-in strength levels here: Continue reading %Introducing GSS: Grid Style Sheets% Full Article

If you are part of the front-end scene, you might have heard of Stylus, the distant cousin from Sass that nobody knows very well. Like Sass, Stylus is a CSS preprocessor which is written in Node.js. According to its GitHub repository, it describes itse… Full Article