CSS is a stylesheet language. It controls how a web page looks on screen, in print, or through assistive technology, and it sits apart from the HTML that defines what the page actually contains.
Browsers read it through their own rendering engines. Along with HTML and JavaScript, it’s one of the three languages running on the client side of the web, and new capabilities arrive as modules published by the World Wide Web Consortium.
Stylesheets pile up fast on real sites. HTTP Archive’s 2022 Web Almanac recorded one page loading 1,387 separate external stylesheets during a single mobile crawl.
What Is CSS?
Presentation lives in one place, structure in another. That split is the reason a stylesheet language exists at all: one file can reshape the same HTML page for a desktop monitor, a printer, or a screen reader without anyone touching a tag.
Before CSS, developers packed font tags and color attributes straight into the markup. Fine for a handful of pages. It fell apart the moment a site needed hundreds of them styled the same way.
CSS lives in the frontend layer of a site, running in the browser rather than on a server.
On any given page, CSS governs:
- Color, background, and typography
- Spacing inside and between elements
- Layout and positioning of content
- Visual states like hover and focus
- Print and screen-specific formatting
The W3C’s CSS Working Group, formed in 1997, still maintains the language, counting 176 members as of July 2025.
The CSS Zen Garden project made the argument better than any spec could. Same HTML page, restyled through nothing but the stylesheet, dozens of completely different designs.
How Is CSS Different from HTML and JavaScript?
HTML puts things on the page. CSS decides what they look like. JavaScript is the one that makes them do something once the page has loaded.
Take a single paragraph of text. HTML puts it on the page as a paragraph element.
CSS decides its font size, color, and spacing. JavaScript can then make that same paragraph collapse when a user clicks it.
| Language | Primary Role | Controls | Example Change |
|---|---|---|---|
| HTML | Structure | Elements, content, hierarchy | Adding a new paragraph |
| CSS | Presentation | Color, spacing, layout, typography | Changing the paragraph’s font size |
| JavaScript | Behavior | Interactivity, logic, data updates | Making the paragraph collapse on click |
CSS can’t create new elements or run logic on its own. It needs HTML to give it something to style, and it needs the Document Object Model to connect what it writes to what the browser renders.
JavaScript reads and rewrites CSS rules in real time through that same DOM. That’s why animated menus and dark mode toggles almost always involve both languages at once.
What Is CSS Syntax?
Every rule follows the same shape. Name the thing you want to style, open a set of curly braces, and list property: value; pairs inside. The browser applies each value to every match on the page.
Declaration Blocks and Property Value Pairs
The selector names what gets styled. Everything between the braces is the declaration block. Inside it, the property is the aspect being changed (color, margin, whatever it happens to be) and the value is what that property gets set to.
Drop the semicolon between two declarations and the browser folds the next property name into the previous value, turning the whole thing into one invalid declaration that gets discarded. Parsing only picks back up at the next semicolon or closing brace. The one exception is the very last declaration in a block, right before the closing brace, where the trailing semicolon is optional. Include it anyway. It’s one less thing to fix when someone adds another declaration underneath.
Selector Types
| Selector Type | Example | Targets |
|---|---|---|
| Element | p | Every paragraph on the page |
| Class | .card | Any element carrying that class |
| ID | #header | The single element with that ID |
| Pseudo-class | :hover | An element in a specific state |
Combinators extend selectors further. A space targets any descendant, while a greater-than sign narrows that down to direct children only.
Pseudo-elements work differently from pseudo-classes. They target a specific part of an element, like the first line of a paragraph, rather than a state it happens to be in.
What Is the CSS Box Model?
Every element on a page is a rectangle, including the ones that don’t look like rectangles. The box model is how CSS works out how big that rectangle ends up.
Content sits at the center. Padding, border, and margin wrap around it in that order, each one adding to the space the element takes up.
Working outward from the middle:
- Content, meaning the text, image, or other material inside the box
- Padding, the clear space between that content and the border
- Border, the visible (or invisible) line around the padding
- Margin, the space that pushes other elements away
By default, width and height apply only to the content area. Padding and border get added on top rather than eating into the number you set, which is the part that surprises people.
Setting box-sizing to border-box changes that math. Padding and border now sit inside the declared width instead of stacking on top of it, which is why most modern reset stylesheets turn it on globally.
Chrome DevTools and Firefox’s inspector both draw this stack visually, coloring each layer, so you can see exactly where the extra spacing on a stubborn element is coming from instead of guessing at it.
How Do the CSS Cascade and Specificity Work?
https://www.youtube.com/watch?v=NP8USarU6X0&pp=ygULQ1NTIENhc2NhZGU%3D
Two rules target the same element. Only one of them can win, and the cascade is the procedure that picks it, working through source order, specificity, and importance in that sequence.
Inheritance runs alongside all of that. Properties like font family and color pass down from parent to child automatically unless a more specific rule overrides them.
What actually resolves a conflict:
- Source order, where the later rule wins ties
- Specificity, where more precise selectors outrank general ones
- The !important flag, which overrides normal specificity
- Inheritance, which only applies when nothing else sets the value
Specificity isn’t a simple point score that adds up. It gets compared one category at a time. An ID selector always outweighs any number of class selectors, and a class selector always outweighs any number of element selectors, no matter how many get combined.
That scoring gets confusing fast once a stylesheet grows past a few hundred lines, which is exactly the kind of math a CSS specificity calculator is built to handle.
Teams that lean on methodologies like BEM tend to hit fewer specificity fights in the first place, since flat class names rarely outrank each other.
What Units and Values Does CSS Use?
Some units mean the same thing no matter where they land. A pixel is a pixel, and points and inches behave the same way. Other units measure against something else on the page, which is the group percentages, em, rem, and the viewport units belong to.
The CSS Values and Units spec pins down the conversions that come up most:
- 1 inch equals 96px
- 1 point equals roughly 1.33px
- 1rem equals the root font size, 16px by default in most browsers
- 100vh equals the full height of the viewport
The difference between em and rem trips up a lot of people early on. Em scales against the parent element’s font size. Rem always scales against the root, full stop, no matter how deep the element sits.
That matters once nested components start stacking font-size rules, since em values compound at every level and rem values don’t.
Viewport units like vw and vh size elements against the browser window itself rather than any parent, which makes them useful for full-bleed sections and hero banners.
Color values sit in a category of their own, with hex, rgb, and hsl all describing the same colors through different number systems.
What Are the Main CSS Layout Systems?
Flexbox handles one-dimensional arrangements, a row or a column. Grid handles both axes at once. Positioning and float predate both and still cover manual and legacy placement.
Each one solves a different layout problem, and most real projects end up using more than one at a time.
| System | Dimension | Best For |
|---|---|---|
| Flexbox | One-dimensional | Navbars, toolbars, form rows |
| CSS Grid | Two-dimensional | Page layouts, dashboards |
| Positioning and Float | Manual or legacy placement | Overlays, older layouts |
Flexbox
Flexbox lines elements up along a single axis, either a row or a column, and distributes the leftover space between them automatically.
What it’s good at:
- Handling uneven content sizes without extra math
- Centering items vertically and horizontally with a couple of properties
- Reordering elements visually without touching the markup
It struggles once a layout needs rows and columns to line up with each other, and it can wrap unpredictably on very small screens unless you add rules for it.
CanIUse tracks flexbox support at 99.9% of browsers in global use as of 2024, which makes it safe to use without a fallback on almost any project.
CSS Grid
Grid arranges elements across rows and columns at the same time, using a template that defines both axes upfront.
CanIUse puts grid layout support at 99.39% of browsers in global use as of 2024, just a fraction behind flexbox.
Full-page layouts, image galleries, and dashboards are where it earns its keep, anywhere content needs to line up in two directions. For a simple horizontal navbar it’s overkill, and flexbox does the same job with less setup.
Writing out grid-template-columns and named areas by hand takes practice, and a CSS grid generator shortens that learning curve by building the syntax visually before it gets pasted into a stylesheet.
Positioning and Float
Positioning and float predate flexbox and grid by more than a decade, and both are still doing real work on modern pages.
The position property switches an element between static, relative, absolute, and fixed, plus sticky for scroll-aware placement.
Float was the original layout hack, pulling elements out of normal flow so text could wrap around an image. Most sites now reserve it for exactly that job and hand full-page layout duties to grid.
Positioning, though, hasn’t been replaced by anything. Tooltips, modals, sticky headers, anything that needs to sit on top of other content or track alongside it while the page scrolls.
How Do Media Queries Make CSS Responsive?
Media queries let CSS apply different rules depending on screen width, orientation, or resolution, so one stylesheet can serve a phone and a widescreen monitor.
Mobile traffic sits at 53.37% of global web visits against 46.63% for desktop, according to StatCounter’s July 2026 figures. The majority of your visitors are on the smaller screen, which is why this stopped being optional years ago.
A media query wraps a condition around a block of CSS. Only when the browser window matches that condition does the block take effect.
Common breakpoint ranges developers write against:
- Small screens, roughly up to 600px wide
- Tablets, from around 600px to 900px
- Desktop and larger, above 900px
Mobile-first development writes the small-screen styles first, then layers on media queries for larger widths. It tends to produce leaner CSS than starting desktop-first and overriding downward.
None of it works without a proper viewport meta tag in the HTML head. Leave it out and mobile browsers scale the page as if it were a shrunk desktop layout, at which point the media queries stop matching the way you’d expect.
Ethan Marcotte introduced the term responsive web design in a 2010 article for A List Apart, tying fluid grids, flexible images, and media queries together as one approach rather than three separate tricks.
How Do Browsers Render CSS Differently?
Each browser uses its own rendering engine to interpret CSS, and small differences in how those engines calculate layout or handle edge cases still show up today.
| Engine | Browser | Notes |
|---|---|---|
| Blink | Chrome, Edge, Opera | Shared by most Chromium-based browsers |
| WebKit | Safari | Long required on all iOS browsers; the EU and Japan now permit alternative engines, though most iOS browsers there still ship on WebKit |
| Gecko | Firefox | Independent engine, maintained by Mozilla |
Chrome alone accounts for 69.39% of global browser traffic as of August 2026, according to StatCounter. Since Edge, Opera, and Samsung Internet also run on Blink, the engine’s combined reach is closer to 79% of global traffic, which is why most CSS gets tested there first.
Safari’s WebKit engine follows at 15.83%, with Firefox’s Gecko engine trailing at 2.98%, the same StatCounter dataset shows.
Most of the friction lives in newer features, where one engine ships support months or years ahead of another. Older, well-established properties like margin, padding, and color render almost identically everywhere.
Testing across engines, not across browser brand names, is what actually catches cross-browser compatibility gaps. Chrome and Edge share Blink, so testing both barely adds coverage.
Microsoft rebuilt Edge on Blink in January 2020, retiring its own EdgeHTML engine and folding one more browser into the Chromium ecosystem.
None of this ships as a single, versioned CSS3 anymore. The language lives in separate modules with their own levels, which is exactly why one browser can support a feature like subgrid while another is still catching up.
Inline, Internal, or External CSS: Which Should You Use?
External CSS is the right default for most projects. One file, cached once by the browser, reused across every page that links to it.
| Method | Where It Lives | Caching | Best Use Case |
|---|---|---|---|
| Inline | style attribute on the element | None, reloads every time | One-off email templates, quick fixes |
| Internal | style tag in the document head | None, tied to that page | Single-page prototypes |
| External | Separate .css file, linked | Cached across pages | Full sites, multi-page projects |
Inline CSS earns its place when a single one-time change is all you need and writing a whole rule for it feels like overkill. A highlighted line in an email newsletter, for instance.
Everywhere else, external wins. It keeps markup readable, lets multiple HTML files share one set of rules, and downloads once per visit instead of once per page.
Internal CSS sits in between and rarely earns a permanent place in production code. It shows up most in quick demos, or when someone is testing a style before moving it into the external file.
Mixing all three on one page is common and not a problem by itself. The trouble starts when the same property gets set in more than one place, because then cascade and specificity decide the outcome instead of the developer.
CSS Frameworks and Preprocessors: When Are They Worth Using?
People lump these together and they shouldn’t. A framework ships ready-made components and layout rules. A preprocessor adds programming features to the way CSS itself gets written, then compiles down to plain CSS that browsers understand.
So a framework hands you pre-built grids, buttons, navbars, and form styles, ready to drop into a page. A preprocessor hands you variables, nesting, functions, and math.
Bootstrap remains the most widely deployed framework by a wide margin, used on 13.8% of all websites tracked by W3Techs as of July 2026.
It started as an internal styleguide at Twitter, built by Mark Otto and Jacob Thornton before the company open-sourced it in 2011.
Tailwind CSS sits far behind on raw adoption, at 0.3% of tracked sites in the same W3Techs dataset. Its usage share has grown every year since 2023 while Bootstrap’s has shrunk, which says more about direction than the raw numbers do.
Preprocessors like Sass and Less solve a different pain point entirely. They let a stylesheet reuse a color value as a variable instead of retyping the same hex code fifty times across a project.
For small sites, hand-written CSS still beats both. Loading a framework’s full component library to style five pages adds weight the project never uses.
How Do You Write CSS Step by Step?
The loop looks the same whether you’re styling one page or a hundred, and whether or not there’s a framework involved.
- Pick the target element and decide which selector reaches it: an element, a class, or an ID
- Write the declaration block with the properties and values that need to change
- Save the rule in an external stylesheet and link it from the HTML head
- Reload the page and check the result in the browser
- Inspect the element in DevTools to confirm which rule actually applied, especially if the change doesn’t show up
Step four is where most early mistakes surface. A typo in the file path, a missing closing brace, or a selector that doesn’t match anything on the page.
Before a stylesheet ships to production, most teams run it through a CSS minifier to strip comments and whitespace, cutting file size without changing how a single rule behaves.
When Does CSS Not Apply or Fail to Render as Expected?
CSS fails quietly. No error in the console when a rule gets overridden or ignored, just a page that doesn’t look the way it was written to look.
Roughly in order of how often they show up:
- A more specific selector elsewhere in the stylesheet wins, silently overriding the rule you meant to apply
- A mistyped link href means the browser never loads the stylesheet at all
- A newer CSS feature isn’t implemented in the visitor’s browser or engine version
- A missing semicolon or unclosed brace invalidates everything after it in that block
Specificity failures are the hardest to spot because nothing technically breaks. The page loads fine and looks almost right, just not quite the way the stylesheet intended.
Unsupported properties behave more gracefully than most people expect. Browsers skip the single declaration they don’t understand and keep processing the rest of the block instead of discarding the whole rule.
That graceful degradation is deliberate. It’s part of how the CSS Working Group built the language to stay usable while new properties get added faster than every browser can implement them.
FAQ on What Is CSS
What does CSS stand for?
CSS stands for Cascading Style Sheets. “Cascading” refers to how conflicting rules resolve through source order, specificity, and inheritance.
“Style sheets” describes the separate files or blocks that hold presentation rules, distinct from the HTML markup they apply to.
Is CSS a programming language?
No. CSS is a declarative style sheet language: it describes what an element looks like, not the logic to compute it.
It lacks loops and conditionals, though custom properties and functions like calc() narrow that gap.
Who maintains the CSS specification?
The CSS Working Group, operating under the World Wide Web Consortium, maintains and extends the language.
Browser vendors including Google, Apple, Mozilla, and Microsoft send engineers to the group, and proposed changes are drafted and debated on GitHub before shipping.
What tools do developers use to write and debug CSS?
Most developers write CSS in a code editor like VS Code, then inspect the result with browser DevTools, which shows box model and cascade origin for any selected element.
Linters such as Stylelint catch syntax and consistency issues early.
What happens if CSS is disabled or unsupported?
The page still loads. Browsers render the raw HTML in document order, stacked top to bottom with default user-agent styles, no layout, and no custom colors or fonts.
Content stays readable, since CSS controls appearance only, never meaning.
What Should You Learn Next After CSS?
Responsive layout work comes next. Flexible sizing, breakpoints, and performance budgets applied to real screens, which is where a static stylesheet turns into a system that adapts across devices and connection speeds.
Once the fundamentals hold, the order of operations matters more than people assume:
- Audit specificity conflicts first
- Convert fixed units to relative ones
- Test layouts on real device widths
Fixing specificity first stops new rules from inheriting old conflicts. Switching units before device testing means the test reflects real scaling rather than one fixed size.
That approach costs pixel-perfect control. Relative units render consistently across devices, but spacing shifts slightly with a visitor’s root font size, a trade-off most production teams accept for the reach it buys.
The mechanics behind that shift, breakpoints, fluid type, and device-driven layout, sit inside responsive design, the logical next read after CSS.


