Topic 12 · 12 of 43

HTML Best Practices

All in one: every best practice, the right way beside the wrong way

What this example compares

Names and values: <p class="intro"> vs <P CLASS="intro"> vs <P CLASS=Intro>, and class="my box" vs class=my box
Closing and nesting: <p>text</p> vs <p>text vs an unclosed <h3>; <br> vs </br>; <p><b>x</b></p> vs <p><b>x</p></b>
Indent and comment: indented vs all at the margin; a useful comment vs a secret in a comment
The standard start: doctype, lang, charset, viewport and title vs a bare <html><body>
Where the look lives: inline style vs internal <style> vs external <link rel="stylesheet"> vs <font>
Where the script goes: <script> in the head vs defer vs just before </body>
Look hacks vs CSS: <br><br>,   and <h4> for its size vs margin, padding and the right heading level
Going vs doing: <a href> vs <button> vs <a href="#" onclick>
Real vs fake: <h2> vs <div class="h2">, <header> vs <div class="header">
The element for the job: <nav>, <article>, <section>, <footer>, <div>, <strong>, <i>, <del>, <table>, <ol>
alt text: described vs alt="" vs missing
Names for everything: <label> vs plain text, <iframe title> vs none, a link that says where it goes vs “click here”
Speed and steadiness: width + height vs no size, loading="lazy" vs the default
Obsolete tags: <font>, <center>, <big>, <tt>, <strike>, <marquee>, <blink> vs CSS and meaningful elements
Page layout: <frameset> vs <iframe> vs CSS Grid; a layout <table> vs CSS Flexbox on a phone
Before you publish: validate, test with DevTools and a phone, check paths, publish from GitHub
Code review: the page from section 12.7 before and after

Point at any word in the code to see what it means (tap on a phone); click a word to keep its meaning on screen. Read the comment above each numbered panel, press Run, then Edit & experiment to try the TRY lines yourself.

The complete code

Loading the example…

What you should see

You should see seventeen panels. In panel 1 only the third card has no orange bar and only the last card has no dark border. In panel 2 every card looks correct except the third, where “Asha scored 92.” has become part of the big heading. In panel 4 the first tiny page shows a long gold box with ₹500, the bare one a short box with junk letters instead of the rupee sign. Panels 5, 7, 9 and 14 show pairs that look the same, because the difference is in the code, not on the screen. In panel 13 the first card keeps an empty picture box while the second does not. Panel 15 shows the layout table cut off inside the phone while the Flexbox version stacks. Panel 17 shows the old page with a table wider than its box, and the corrected one with its heading, picture box and links. The Console prints three lines, in this order: A. script in head: null, C. before </body>: <button id="save"> and B. head + defer: <button id="save">. Clicking Save in panel 8 adds app.js: Save clicked; clicking the fake Save link adds onclick: fake Save clicked and jumps to the top.

Quick check: in panel 1, <P CLASS="intro"> gets the orange bar but <P CLASS=Intro> does not. Which rule broke it: the capital letters or the missing quotes?

Neither rule on its own. The browser turns tag and attribute names into lowercase, so P and CLASS still work, and a one-word value works without quotes. What broke it is the capital I in the value: values are never changed, so Intro does not match the CSS .intro. The line still breaks two best practices (lowercase names, quoted values), which is why you write <p class="intro">.