It has been more than 2 decades and we’re still using CSS the same way since its inception. It is simple to learn and here to stay for many years to come. As frontend developer, you are expected to be solid at CSS styling no matter what technologies you’re using.
CSS is very mature, you can easily find tips and tricks to do almost anything. It’s hard to find a topic to write without having a duplication. It’s so mature that in many frontend interviews, the interviewers often assume you know it well and rarely ask about it.
The situation has changed a little bit in recent years following the rise of JavaScript frameworks. More and more projects adopt CSS in JS which some people hate it and some people love it. CSS architecture has been moving to direction of local separate styled components than global shared style sheet.
In frontend interviews, CSS questions are often related to how CSS works than how to style some use cases. This post covers some random topics you normally don’t use everyday but highly likely to be asked in an interview.
CSS standards are developed and maintained by CSS Working Group which is part of W3C.
CSS has various levels — CSS1, CSS2, CSS3, CSS4 — and profiles — mobile devices, printers, television sets — which have been developed into separate independent modules.
Each module will go through a cycle of statuses starting from Working Draft, Last Call, Candidate Recommendation to final Recommendation.
Browsers support CSS features at their own speed. Chrome is clearly the winner and Internet Explorer is absolutely pain in the ass. Depending on your site popularity, you can sacrifice some very low supported browsers to use latest functionalities.
You can use CSS polyfills to patch old browsers but it requires tons of extra code and has poor performance.
The real power of CSS lies in the fact that it allows you specify styles from multiple sources and automatically calculates final styles.
The actual process of handling CSS in browser is complicated, knowing what CSS engine do is too much to be productive.
However, it’s super useful to know how a CSS property computed and understand three most fundamental concepts of CSS — cascading, specificity, inheritance — which control how CSS is applied to HTML and how conflicts are resolved.
The actual process of calculating final CSS property for a given HTML element is the result of very complicated multiple steps:
A frontend developer spend the whole life to layout and decorate websites, you might not be asked about css layouts in interviews but learning these concept deeply will help you super productive.
Every HTML element has a box wraps around margin, border, padding and content. Setting box-sizing: border-box; to include margin and border in total width and height.
The display property controls how an HTML element is displayed inside a document like inline, block, inline-block, flex, grid and more
The position property positioning methods of HTML element like static, relative, absolute, fixed, or sticky.
Float and clear is the old way to layout elements using float property. When an element is floated, it is taken out of normal flow of the document and shifted to left, or right, until it touches the containing box or another floated element.
Managing multiple floating elements is painful, and CSS Flexbox Layout came to rescue, making it easier to design flexible responsive layout structure in a predictable style.
You can layout almost anything with CSS Flexbox but it has one weakness — you need grid css frameworks to deal with two-dimensional grid-based layouts efficiently. That’s why CSS Grid Layout module was added to CSS to make your life easier.
Each layout method has its own use cases. You need to read the whole blog series about different kids of CSS layout and check caniuse.com to use properly.
Coming from how CSS works, the problem with CSS is that they rely on developers to manually maintain them with a high degree of accuracy to be effective. The language is simple and easy to learn, the hard part is how to write CSS in a maintainable and scalable way.
Since the inception of CSS, the community tried to fix above problems of CSS language with many methodologies — naming conventions used by developers to better manage CSS which lacks built-in scoping mechanism.
The state of CSS methodologies is quite stable for years. While BEM is ahead of the pack here, Atomic CSS — Tachyons, ACSS — is also starting to gain ground with its completely new utility-class-driven philosophy. Other solutions — OOCSS, SMACSS, ITCSS, MCSS — are incomplete and fading away.
There’s always a standard of separating styling from markup since the inception of web development. Using external CSS stylesheets has obvious benefit when you can update the styles across a whole website by updating a single document and we’re all hooked with that.
Influenced by the rise of JS frameworks, CSS-in-JS was born and loved by community. It’s moving in the opposite direction of style portability.
CSS at scale has some problems like dependencies, dead code elimination, minification, sharing constants, non-deterministic resolution and isolation. CSS-in-JS avoids these problems entirely by generating unique class names when styles are converted to CSS. This allows you to think about styles on a component level with out worrying about styles defined elsewhere.
There are many CSS-in-JS techniques out there with different quality — styled-components, emotion, polished, jss, radium, aphrodite, glamor, etc.
CSS-in-JS is just a better way of writing CSS, not to be confused with replacing CSS completely. It is till very young compared to 10+ years history of CSS, but it is evolving very fast in recent years. If you think the pros outweighs the cons, then give CSS-in-JS a shot!
CSS frameworks are libraries built to make your life as frontend developer easier by including a mass amount of styling modules and tools.
They are often built with a set of following features: Utilities, typography, base, reset, normalize, icons, icon fonts, grid, general layout, common styled components, general purpose styles.
They bring to the table with many obvious advantages like increased productivity, standardized codebase, responsive by default, browser compatibility, consistent layout.
There are many good CSS frameworks — Bootstrap, Tailwind, Foundation, Materialize, Semantic UI, Bulma, etc — out there, try to find the framework that works for you. Try to understand the CSS code and the quality of that code inside the framework.
There can be some downsides — non transferable learning, heavy unnecessary code, similar style everywhere, painful custom design, vulnerable to changes — to using a css framework if you treat them like a black box. Most of these cons are easily overcome, but you do need to be aware of them. If you are not happy with any public framework then build your own.
CSS is primitive and incomplete. Building a function, reusing a definition or inheritance are hard to achieve. For bigger projects, or complex systems, maintenance is a very big problem. This is where a preprocessor can help.
A CSS preprocessor is a program that lets you generate CSS from the its own unique syntax. To use a CSS preprocessor, you must install a CSS compiler on your web server.
Popular pure CSS preprocessors — Sass, Less, Stylus — will add some features that don’t exist in pure CSS, such as mixin, nesting selector, inheritance selector, and so on.
PostCSS — not a pure preprocessor but you can use it that way if you wanted to by using along with plugins — is a tool for transforming styles with JS plugins. These plugins can lint your CSS, support variables and mixins, transpile future CSS syntax, inline images, and more.
Browsers ship with a set of default styles — most of them are consistent across user agents, however there are some inconsistent styles like header padding, button border, line height, display mode, font size and margin.
Currently there are three popular approaches — Reset CSS, Normalize CSS, Custom CSS - to this problem, different in terms of how much aggressive and opinionated they override styles.
Reset CSS resets the styling of all HTML elements to a consistent baseline, Normalize CSS retains many useful default browser styles, and Custom CSS incorporates the benefits of each of the methods.
There is no absolute right or wrong answer when it comes to browser resets. Each developer will have his or her own opinionated decision on which gets the job done. There are some popular well-maintained CSS resets like minireset.css, normalize.css, or reboot.css.
CSS codes are extremely opinionated across teams and individuals. The problem with CSS conventions is that they rely on developers to manually maintain them with a high degree of accuracy to be effective.
This problem is compounded as styles grow. Each developer needs to know more context in order to effectively style UI. That’s where we need a CSS style guide — a set of standards and rules on how to use and write CSS code in a consistent and maintainable way.
Following a CSS style guide can create a beautiful code base which will make any developer love working on a project. They enable a codebase to be flexible, easily scalable and very well documented for anyone to jump in and work on with other developers.
Following style guides are opinionated, but they have been repeatedly tried, tested, stressed, refined, broken, reworked, and revisited over a number of years on projects of all sizes:
Maintained by companies: Airbnb, Dropbox, WordPress, Google, Bootstrap, ThinkUp, Workable, CodePen
Maintained by individuals: Harry Roberts, Mark Otto, Nicolas Gallagher
CSS style guide aims at improving collaboration, code quality, and enabling supporting infrastructure. It contains methodologies, techniques, and tips that you and your team should follow.
You don’t need to maintain a custom CSS style guide on your own but you need to find one to follow, failing to do so will put you in a position of maintaining an ugly unmaintainable codebase sooner or later.