CSS & Modern Layout
The layer that turns a document into a design
Category: Frontend
Learning Path: What → Why → Learning Modules → Production Example → Interview Prep
Before you start: you need basic comfort reading and writing HTML — knowing what an element, an attribute, and nesting are, and having written at least a handful of Think of an HTML page as a skeleton — the bones are there (a heading, a paragraph, a list, a button), correctly ordered and structurally sound, but with no skin, no clothes, no sense of style. CSS (Cascading Style Sheets) is everything layered on top of that skeleton: color, spacing, typography, layout position, motion. The same HTML skeleton can be dressed as a newspaper, a dashboard, or a mobile app menu — the bones don't change, only the styling layer does. That separation — structure in HTML, presentation in CSS — is the actual design principle behind the language, not just a historical convention. Technically, CSS is a rule-based language: a selector (which elements) is paired with a declaration block (which properties, set to which values). The browser reads every applicable rule for a given element and resolves conflicts using the cascade — a defined, learnable set of priority rules (origin, specificity, source order) that decides which declaration wins when two rules disagree. "Cascading" is not a marketing word; it names the actual conflict-resolution algorithm the browser runs on every element, every time. Before a separate styling language existed, presentation was tangled directly into markup — a It's a fair question whether CSS still matters given how dominant utility-first frameworks (Tailwind and similar) have become in production codebases — the honest answer is that those frameworks are still CSS underneath, generating actual CSS rules and still resolved by the same cascade, specificity, and box-model mechanics covered in this course. A utility class like How every element is sized, spaced, and how conflicting rules actually resolve Topics covered: The two layout systems that replaced float-based and table-based hacks Flexbox arranges items along one axis at a time (a row or a column) and excels at distributing space among items whose sizes can flex — a navbar, a card's internal content, a button group. CSS Grid is two-dimensional by design — rows and columns together — and is the right tool once a layout genuinely needs both axes controlled at once, like a full page layout or a photo gallery. They are not competitors to pick one over permanently; production layouts commonly nest Grid (for the page-level structure) around Flexbox (for the alignment inside individual regions). Topics covered: One codebase, every screen size — plus the features shipping now Topics covered: PSR Formula: Answer every question: Problem → Solution → Result. 45-90 seconds max. Q1. What's the difference between Flexbox and Grid, and how do you decide which to use? A: Problem: picking the wrong layout system for a given structure leads to fighting the tool — forcing Flexbox to do two-dimensional work with wrapping hacks, or reaching for Grid on a simple one-axis alignment problem. Solution: Flexbox is one-dimensional (a row or a column) and excels at distributing/aligning items along that single axis; Grid is two-dimensional (rows and columns together) and is the right tool once a layout genuinely needs both axes controlled explicitly. Result: in practice, most production layouts use both together — Grid for the outer page structure, Flexbox for alignment inside individual regions — rather than picking one exclusively. Q2. Explain CSS specificity — how does the browser decide which of two conflicting rules wins? A: Problem: two rules targeting the same element with different values for the same property will conflict, and the resolution isn't "last one written always wins." Solution: the browser computes a specificity score per selector — inline styles beat everything, then ID selectors, then class/attribute/pseudo-class selectors, then type selectors — and the higher score wins regardless of source order; only when specificity ties does source order (later wins) decide. Q3. What's the box model, and why does A: Problem: an element's actual rendered size is not just its Q4. How would you build a responsive layout without a framework? A: Problem: a layout that only looks correct at one viewport width breaks the product for the large share of real traffic on other screen sizes. Solution: mobile-first media queries ( Q5. What causes layout shift (CLS), and how do you prevent it? A: Problem: content that loads asynchronously (an image without dimensions, a web font swap, an injected ad slot) pushes surrounding content around after the user has already started reading — a real, measured Core Web Vital, not just a cosmetic annoyance. Solution: always set explicit Q6. What are CSS custom properties, and how are they different from a preprocessor's variables (like Sass)? A: Problem: hardcoded values repeated across a stylesheet (a brand color, a spacing unit) are painful to update consistently and can't respond to runtime conditions. Solution: CSS custom properties ( Q7. What's the difference between A: Problem: using the wrong relative unit causes compounding sizing bugs that are hard to trace — a nested element's Q8. How do CSS Grid's A: Problem: building a responsive grid (say, a card layout that should show more columns on wider screens) without media queries used to require JavaScript or a lot of manual breakpoint tuning. Solution: Q9. What's the difference between A: Problem: both remove an element from normal document flow, which is exactly why they're easy to confuse, but they position relative to different reference points. Solution: Q10. Container queries and A: Problem: "new CSS feature" and "safe for production" aren't automatically the same thing, and this specific pair had a real adoption gap not long ago. Solution: as of current major-browser baselines both container queries and Open any HTML page (even a blank one with a couple of / tags by hand. You do not need any prior styling experience, any JavaScript, or familiarity with a CSS framework — this course starts from the raw language itself. See the Prerequisites tab for the full detail and time estimate.What is CSS?
Why CSS?
tag here, an inline align="center" there — which meant changing a site's look meant hunting through every page's markup individually, and meant screen readers and other non-visual consumers of the same HTML had to wade through presentation noise mixed into content. CSS solves this by keeping one clean HTML document and letting one (or a few) stylesheet(s) control the look of an entire site — change a single rule, and every page using that class updates at once.flex items-center justify-between is Flexbox, exactly as covered in Module 02 — knowing what the utility actually does under the hood is what separates copying classes from a component library and being able to fix a genuinely broken layout, debug a specificity conflict a framework didn't anticipate, or write custom CSS when a project doesn't use a framework at all.Learning Modules
Module 01 — Box Model & The Cascade
box-sizing: border-box vs the default — 🟢 Beginner!important — 🟡 IntermediateModule 02 — Flexbox & Grid
grid-template-columns/rows, fr units — 🟡 Intermediategrid-template-areas — 🟡 IntermediateModule 03 — Responsive Design & Modern Features
%, vw/vh, rem/em vs px — 🟢 Beginner:has() and cascade layers (@layer) — 🔴 AdvancedProduction Example
Interview Prep
Common Interview Questions
!important overrides normal specificity entirely and should be treated as an escape hatch, not a habit. Result: understanding this precisely is what turns "my CSS isn't applying and I don't know why" into a five-second diagnosis using DevTools' specificity display in the Styles panel.box-sizing matter?width/height — padding and border add to it by default, which silently breaks layouts built around exact pixel widths. Solution: the box model is content → padding → border → margin, each layer adding outward; box-sizing: border-box changes width/height to include padding and border in that number instead of adding them on top, matching how most developers intuitively expect sizing to work. Result: setting box-sizing: border-box globally (, ::before, *::after { box-sizing: border-box; }) is close to a universal production default for exactly this reason.min-width breakpoints layered upward, not max-width layered downward), relative units (rem for typography/spacing so it respects user font-size preferences, %/fr/vw/vh for fluid sizing), and Flexbox/Grid's own built-in wrapping and minmax() behavior, which handles a surprising amount of responsiveness before a media query is even needed. Result: a genuinely mobile-first build tends to need fewer, simpler media queries than a desktop-first one retrofitted downward, because the base styles are already the constrained case.width/height (or aspect-ratio) on images and video before they load so the browser reserves space up front, use font-display: optional or preload critical fonts to reduce font-swap shift, and reserve space for any content that loads late. Result: CLS is one of the few performance metrics that's almost entirely a CSS/markup discipline problem, not a JavaScript one — most fixes are a missing width/height attribute or a missing reserved-space rule.--brand-color: #2563eb;, read with var(--brand-color)) are real runtime values the browser resolves live — they cascade, can be overridden per-selector (including inside a media query or a :hover state), and can be read/written from JavaScript. Sass variables, by contrast, are compile-time only — they're substituted once when the stylesheet is built and don't exist in the shipped CSS at all. Result: this is exactly why custom properties are the right tool for anything that needs to change at runtime (a theme toggle, a JS-driven dynamic value) and why Sass variables alone can't do that.em and rem, and when would you use each?em value multiplying against its parent's already-scaled font-size rather than a single, predictable base. Solution: em is relative to the current element's own font-size (and compounds through nesting); rem is relative to the root (html) element's font-size only, regardless of nesting depth. Result: rem is the safer default for most spacing and typography specifically because it doesn't compound; em is genuinely useful for values that should scale with a specific element's own font-size, like padding on a button that should grow proportionally if that button's own font-size changes.fr unit and minmax() work, and what problem do they solve together?fr is a fraction of remaining space after fixed-size tracks are accounted for; minmax(240px, 1fr) combined with repeat(auto-fit, ...) lets the grid decide how many columns fit — never smaller than 240px, filling remaining space fractionally — entirely without a media query. Result: grid-template-columns: repeat(auto-fit, minmax(240px, 1fr)); is one of the most reused, genuinely elegant one-line responsive patterns in modern CSS.position: absolute and position: fixed, and a common bug each causes?absolute positions relative to the nearest ancestor with a non-static position (or the initial containing block if none exists) — the common bug is forgetting to set position: relative on the intended parent, causing the element to jump to an unrelated ancestor. fixed positions relative to the viewport itself and stays put on scroll — the common bug is a fixed element unexpectedly breaking inside an ancestor that has a transform set, which creates a new containing block and silently changes fixed's reference point. Result: both bugs are diagnosed the same way — check the DevTools Layout panel for which element is actually acting as the containing block, rather than assuming it's the one intended.:has() are relatively new — are they safe to use in production?:has() have strong support across Chrome, Firefox, Safari, and Edge (needs verification — recheck exact support percentage on caniuse.com before citing a number, since this changes) — the honest practice is checking caniuse.com for the project's actual supported-browser matrix rather than assuming either "it's brand new, avoid it" or "it's definitely fine everywhere" without checking. Result: for most current production audiences both are genuinely usable today; the discipline is verifying against the specific browser support target for the project, not going by general impression.Official Resources
Try It (2 Minutes)