What it is
HTML (HyperText Markup Language) describes the structure of a document: headings, paragraphs, links, forms, buttons, images. The browser parses tags into the DOM, a tree scripts can change. CSS (Cascading Style Sheets) describes presentation: colour, type, spacing, and layout. You attach styles with selectors that match elements. The cascade decides which rule wins when several match. JavaScript is a third layer, behaviour, covered on its own page.
Frameworks do not make this obsolete. React components render HTML. CSS modules, Tailwind, or plain stylesheets are still CSS. If you cannot read the elements panel in a browser, you cannot debug a layout, no matter which framework emitted it.
Why and when it is used
Every web UI ends as HTML and CSS in a browser, including AI chat panels and admin tools. Use semantic HTML (a button for a button, a label for an input, headings in order) because accessibility tools and keyboard users depend on it. Use CSS for layout rather than nested tables or JavaScript measuring pixels.
You do not need to memorize every property. You do need the box model, normal flow, and one layout method (flexbox is enough to start; grid when the page is two-dimensional). Skip pixel-perfect recreations of a native app until the document is solid. A page that works without your fancy font is a page that works.
How it works
The browser downloads HTML, builds the DOM, applies CSS to produce a layout tree, and paints. Later changes from JavaScript cause style and layout recalculation. Expensive style changes in a loop make a page jank. The box model means every element is content plus padding, border and margin. box-sizing: border-box makes width include padding, which is what most people expect. Specificity decides which rule wins: an id beats a class, a class beats an element, and inline styles beat almost everything. !important is a trap you use when you already lost.
Media queries adapt layout to the viewport. A form submits with a real form and button even if JavaScript later intercepts it. If the script fails, the HTML should still make sense.
Technologies and dependencies
A browser and a text editor are enough to start. JavaScript comes next for behaviour. React or Next.js are optional frameworks. Devtools in the browser are the main instrument: inspect an element, see which rule won, toggle a property. Accessibility is not a library. It is headings, labels, contrast, and focus states. A reset or a small set of base styles is fine; a 200-kilobyte CSS framework you do not understand is a delay.
How to get started
- Write
index.htmlwith a heading, a paragraph, a link and a form with a labelled input and a submit button. Open it in a browser. Do not install a bundler. - Add a stylesheet. Use flexbox to put the form in a column with a gap. Resize the window.
- In devtools, change a colour and a margin live. Then copy the change back to the file.
- Add a focus style so keyboard users can see where they are. Tab through the form.
- Only then add JavaScript, or a framework, to enhance the form.
- Check contrast and that the button is a
button, not a clickablediv.
If a tutorial's first step is a CLI that scaffolds fifty files, do this page's step 1 anyway. You need to see the document the browser sees.
Cautions and trade-offs
Div soup (everything is a div with a click handler) breaks accessibility and search. Absolute positioning everything breaks when text wraps or the language is longer than English. Fixed pixel layouts break on phones. z-index wars mean the stacking context was never designed.
CSS-in-JS and utility frameworks are fine when the team agrees. They are not an excuse to ship unused styles or to ignore the cascade. Animating layout properties (width, top) is slower than animating transform and opacity. And do not hide critical content behind a script that fetches it if the content could have been HTML. The document is the product. The script should improve it, not be the only way it exists.