File Path System — Quick Revision

Compact HTML summary prepared for revision and interview prep — covers relative vs absolute paths, OS differences, and security.

1 — Core Principle

A website is a collection of files (HTML, CSS, JS, images, fonts, videos). These files live in folders and must be linked correctly. A file path is the address the browser uses to locate a file.

2 — Types of File Paths

Relative File Paths (use ~99%)

Relative paths start from the current file's location and are used for linking your project files together.

// Same folder
about.html


// Sub-folder (down)
images/logo.png


// Parent folder (up)
../images/logo.png

✅ Relative paths work anywhere — on your computer or after deployment.

Absolute File Paths

Absolute paths are full URLs that start with http:// or https://. Use them only for external resources like CDNs or Google Fonts.

// Example
https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap
https://example.com/assets/hero.jpg

🚫 Don't use local absolute paths like C:\Users\name\... — they break on servers and violate browser sandbox rules.

3 — Why Security Matters

Browsers run code inside a sandbox to prevent websites from accessing the user's file system. Without this, a malicious page could try to read private files.

4 — Absolute Paths by OS

Windows

Structure: Drive:\Folder\SubFolder\file.txt

C:\Users\JohnDoe\Documents\report.docx

macOS / Linux

Structure: /Folder/SubFolder/file.txt — starts from the single root /.

/Users/johndoe/Documents/report.docx

5 — Quick Interview Takeaways

Memory hook: Relative for your project, Absolute for the outside world.

Summary of Key Differences

Feature Windows macOS / Linux
Starting Point (Root) Drive Letter (e.g., C:\) A single forward slash (/)
Directory Separator Backslash (\) Forward Slash (/)
Example C:\Users\JohnDoe\Documents\report.docx /Users/johndoe/Documents/report.docx

HTML Boilerplate Code — Quick Summary

Step 1: The Fundamental Truth

A web browser needs specific, predictable instructions. It cannot guess your intentions. Boilerplate code provides the essential setup.

Step 2: The Core Problem

We need to tell the browser:

Step 3: The Solution — Boilerplate

Standard starting template for every HTML file.

1. <!DOCTYPE html>

Tells browser to use HTML5 (standard mode, not quirks mode). Must be first line.

2. <html lang="en"> ... </html>

Root element. Declares the language of the content (important for SEO & accessibility).

3. <head> ... </head>

Contains metadata (setup info for the browser, not visible to user).

4. <meta charset="UTF-8">

Specifies UTF-8 character encoding (prevents text encoding issues).

5. <meta name="viewport" ... >

Makes the page responsive:

6. <title> ... </title>

Defines the tab name, bookmark title, and search engine result title.

7. <body> ... </body>

Container for all visible content (headings, paragraphs, images, links, tables, etc.).

But Website Works Without Boilerplate?

Yes, because browsers are forgiving. They fix missing tags and guess setup info.

How Browsers Handle Bad HTML:

  1. No <!DOCTYPE html>? → Enter Quirks Mode.
  2. No <html> or <body>? → Browser generates them implicitly.
  3. No <meta charset>? → Browser guesses encoding (may fail with special characters).
  4. No <title>? → Browser uses the file name as the tab title.

Why Still Use Boilerplate?

Modern HTML5 Boilerplate Code:

HTML Boilerplate Code

Step 1: The First Principle (The Fundamental Truth)

The fundamental truth is that a web browser is a program that needs specific, predictable instructions to do its job. It cannot guess your intentions. You can't just give it a file with a <h1> tag and expect it to know what kind of document it is, what language it's in, or how to render it properly.

Step 2: The Core Problem

We need a way to give the browser essential "setup information" before it starts rendering our visible content (like paragraphs and images). This setup information needs to answer critical questions:

Step 3: The Logical Solution - The Boilerplate

The solution is to create a standard, universal starting template—a boilerplate. This is a block of code that you will start every single HTML file with. It's the "blueprint of the house".

1. <!DOCTYPE html>

The Problem: Browsers need to know which HTML version to use.
The Solution: This line tells the browser: "Use HTML5 standard mode".

2. <html lang="en">...</html>

The Problem: The web is global. How do browsers know the language?
The Solution: The lang attribute declares the primary language, useful for accessibility and SEO.

3. <head>...</head>

The <head> section stores metadata. It doesn’t display content, but tells the browser how to handle the page.

4. <meta charset="UTF-8">

This ensures proper text encoding so special characters like ©, €, ₹ display correctly.

5. <meta name="viewport" ...>

This enables responsive design:

6. <title>...</title>

This sets the browser tab name and bookmark title.

7. <body>...</body>

The body contains all the visible content: headings, paragraphs, images, links, etc.

But Websites Work Even Without Boilerplate

Browsers are built to be extremely forgiving. If you forget tags, the browser guesses. For example:

  1. No <!DOCTYPE html>? → Browser switches to quirks mode.
  2. No <html> or <body>? → Browser adds them automatically.
  3. No <meta charset="UTF-8">? → Browser guesses encoding (may break special characters).
  4. No <title>? → Browser uses filename in the tab.

So, Why Use a Boilerplate?

It ensures your site is professional, reliable, and future-proof. Without it, you risk unpredictable bugs and bad SEO/accessibility.

Multipage Website

The fundamental truth is that complex information is almost never presented on a single, infinitely long page. We naturally break information into distinct, self-contained topics. A book has chapters, a store has departments, and a company has different aspects (About, Services, Contact).

A multi-page website is the digital equivalent of this.

The Core Problem

We need a way to create these distinct topic pages and, most importantly, a way for a user to navigate between them seamlessly. How do we connect home.html to about.html and contact.html so that they feel like a single, cohesive "website" rather than three disconnected files?

The Logical Solution: A Shared Structure and a Navigation System

  1. A Consistent Structure: All pages share a common header (logo + navigation) and footer. This reassures the user they are still on the same website.
  2. A Linking System: Use the <a> (anchor) tag to create a navigation menu that appears on every page.

1. The <div> (The Generic Box)

First Principle

We need a way to group different elements (<h1>, <p>, <img>, etc.) together into a single unit.

The Core Problem

Example: A profile card with an image, a heading, and a bio.

<img src="avatar.png">
<h2>Arjun Kumar</h2>
<p>Loves to code and teach HTML.</p>

These are separate elements. To group them, wrap them in a <div>:

<div>
  <img src="avatar.png">
  <h2>Arjun Kumar</h2>
  <p>Loves to code and teach HTML.</p>
</div>

Now CSS can target the whole group at once.

2. class and id (Labels for the Box)

First Principle

Once we have boxes (<div>s), we need a way to identify them.

The Core Problem

A page may have many profile cards, a sidebar, a main area, and a gallery. How do we target one vs. many?

The Logical Solution

3. The <span> (The Inline Highlighter)

First Principle

Sometimes we need to highlight a piece of text inside a line, without breaking the sentence.

The Core Problem

If you use <div>, it breaks the line:

<p>This is very <div>important</div> information.</p>

Instead, use <span>:

<p>This is very <span class="highlight">important</span> information.</p>

Analogy: A <span> is like using a highlighter pen on a few words.

Semantic Tags