Module 14: Introduction to CSS

Why each option is right or wrong

• “In a <style> block at the top of each page” (Incorrect): That works, but you'd have to make the same edit 20 times and keep them in step.
• “In a style attribute on every heading” (Incorrect): Inline styles mean editing every heading on every page.
• “In the hosting control panel's design settings for the site” (Incorrect): Hosting settings don't control page design; CSS does.
• “In the one external stylesheet every page links to” is correct.

  An external stylesheet is a single CSS file that every page links to. Change a rule there once and all 20 pages update. That's the main reason CSS lives in its own file.

  • One source of truth: no hunting through pages.
  • Cached once: the browser downloads the stylesheet once and reuses it on every page.

📖 Revise: Lesson 1: What CSS is

Why each option is right or wrong

• “Inline styles make the page insecure for visitors” (Incorrect): Inline styles aren't a security risk in themselves. The issue is maintenance.
• “Inline styles are ignored by modern browsers” (Incorrect): Browsers apply them, and give them high priority.
• “It's the approach recommended for quick fixes” (Incorrect): It's quick today and costly later. Stylesheets with classes are recommended.
• “Inline styles are scattered and hard to maintain” is correct.

  Inline styles apply only to the element they're written on, and they beat most stylesheet rules. Fifteen of them means fifteen places to find and change later, and they can silently override your stylesheet.

  • Ask instead: put the fix in the stylesheet using a class.
  • Debugging: inline styles are a common reason a stylesheet change 'does nothing'.

📖 Revise: Lesson 1: What CSS is

Why each option is right or wrong

• “Black, because the p rule applies to every paragraph” (Incorrect): It does apply, but the class rule is more specific and wins.
• “Black, because it was written first in the file” (Incorrect): Order only decides between equally specific rules.
• “Whichever rule the browser loaded last” (Incorrect): Specificity is checked before order. The class wins here.
• “Grey” is correct.

  When two rules disagree, the more specific selector wins. A class selector is more specific than an element selector, so .intro beats p, whatever order they're written in.

  • Specificity from low to high: element → class → id → inline style.
  • Only when equal does the later rule win.

📖 Revise: Lesson 2: Selectors and rules

Why each option is right or wrong

• “The server's error log” (Incorrect): The server doesn't know about CSS rules; the browser applies them.
• “The page's HTML source, under View Source” (Incorrect): View Source shows the HTML as sent, not which CSS rules won.
• “The CSS file itself, read from top to bottom” (Incorrect): Reading the file can't show which rule won for a specific element. DevTools can.
• “The browser's developer tools: Inspect → Styles” is correct.

  Inspect an element and the Styles panel lists every rule that targets it, which file each comes from, and which are crossed out because another rule overrides them.

  • Crossed out: overridden by a more specific or later rule.
  • Warning icon: a typo or invalid value.

📖 Revise: Lesson 2: Selectors and rules

Why each option is right or wrong

• “Grey text makes the page load more slowly on mobile data” (Incorrect): Colour has no effect on load time.
• “Some browsers can't display grey” (Incorrect): Every browser displays grey. Readability is the problem.
• “It only looks different on Windows computers” (Incorrect): Low contrast is hard to read on any system.
• “The contrast is too low for many people to read” is correct.

  Readable text needs enough difference between text and background colours. Light grey on white fails accessibility guidelines and is hard to read for people with weaker eyesight, or anyone on a phone in sunlight.

  • Guideline: a contrast ratio of at least 4.5:1 for normal text (WCAG).
  • Check: DevTools and online contrast checkers show the ratio.

📖 Revise: Lesson 3: Colours

Why each option is right or wrong

• “px doesn't work on phones” (Incorrect): px works everywhere; it just doesn't scale with user settings.
• “rem always makes text smaller” (Incorrect): rem is relative; it can be any size.
• “Browsers download fonts sized in rem faster than px” (Incorrect): Units don't affect loading speed.
• “rem grows with the visitor's browser text setting” is correct.

  rem is relative to the root font size, which follows the visitor's browser setting. People who set larger text get larger text on your site. Fixed pixel sizes can stop that from working well.

  • 1rem is usually 16px by default.
  • Accessibility: respecting user settings helps people with low vision.

📖 Revise: Lesson 4: Fonts and text

Why each option is right or wrong

• “Margin” (Incorrect): Margin adds space outside the button, between it and other elements, not inside.
• “Line-height” (Incorrect): Line-height changes spacing between lines of text, not the gap to the button's edge.
• “Border-width” (Incorrect): A thicker border makes the outline heavier, not the inner space bigger.
• “Padding” is correct.

  Padding is the space inside an element, between its content and its border. More padding makes the button itself bigger around the text.

  • Margin: space outside the border, pushing other elements away.
  • Bonus: bigger padding makes buttons easier to tap.

📖 Revise: Lesson 5: Spacing and borders

Why each option is right or wrong

• “Browsers won't submit a form unless focus styles are set” (Incorrect): Submission works regardless. Focus styles are for people.
• “It makes the form load faster” (Incorrect): Styles have no effect on load speed here.
• “It's only needed on touch screens, where fingers hide fields” (Incorrect): Touch users rarely see focus. Keyboard users need it most.
• “So keyboard users can see where they are” is correct.

  People who navigate with the Tab key rely on a visible focus style to know which field or button is active. Without it, they're typing blind.

  • Don't remove outlines without replacing them with a clear alternative.
  • :focus-visible lets you style focus for keyboard users.

📖 Revise: Lesson 5: Spacing and borders

Why each option is right or wrong

• “Variables make the colours look brighter on screen” (Incorrect): Variables store values; they don't change how colours look.
• “Browsers require variables for brand colours” (Incorrect): Plain colour values work; variables just make them easier to manage.
• “Variables stop visitors from copying your colours” (Incorrect): Anyone can see your CSS. Variables are about maintenance.
• “Each colour is defined once, so changing the palette is one edit” is correct.

  A CSS variable like --brand: #24594b; stores a value with a name. Every rule uses var(--brand). Change the variable once and every use updates.

  • Consistency: no near-miss shades scattered around.
  • Themes: dark mode can just swap the variables.

📖 Revise: Lesson 3: Colours

Why each option is right or wrong

• “Nothing, because web fonts are free to use on any site” (Incorrect): Free to use, but not free to download. Each costs loading time.
• “Text becomes unreadable on Windows” (Incorrect): Web fonts work on Windows. The cost is speed and clutter.
• “Search engines penalise pages with many fonts” (Incorrect): There's no direct penalty for fonts, though slower pages can rank lower.
• “Extra downloads slow the page, and the design looks busy” is correct.

  Each web font is a file the browser must download before showing text in it. Four fonts mean more waiting, especially on mobile, and mixing many typefaces usually looks unprofessional.

  • Rule of thumb: one or two fonts, using weights for variety.
  • System fonts load instantly and look clean.

📖 Revise: Lesson 4: Fonts and text