Our full learning roadmap

Phase 0 — Absolute basics

Before coding, you’ll understand:

 What a website is
 Internet vs web
 Browser, server, domain and hosting
 Front-end vs back-end development
 Static vs dynamic websites
 Code editors and browser developer tools
 Files, folders and file extensions
 How HTML, CSS and JavaScript work together

Phase 1 — HTML: Website structure

You’ll learn:

 HTML document structure

 Elements, tags and attributes
 Headings and paragraphs
 Text formatting
 Links
 Images
 Lists
 Tables
 Forms and input fields
 Buttons
 Audio and video
 Semantic HTML
 Accessibility basics
 Metadata
 Page structure
 HTML validation
 Building multi-page websites

HTML defines the content and meaning of a web page.

Modern HTML is maintained as a continuously updated Living
Standard, rather than being frozen as one old “HTML5 version.”

Phase 2 — CSS: Styling and layout

You’ll learn:

 CSS syntax
 Selectors
 Colours and backgrounds
 Units
 Typography
 Borders and shadows
 The box model
 Margin and padding
 Display properties
 Positioning
 Flexbox
 CSS Grid
 Responsive design
 Media queries
 Transitions
 Animations
 CSS variables
 Pseudo-classes
 Pseudo-elements
 Modern functions such as clamp(), min() and max()
 Container queries
 Modern responsive layouts

CSS is not really one giant “CSS3” specification anymore. It is

developed as separate modules, such as Grid, Flexbox, Display,
Values and Units. W3C’s CSS Snapshot collects the
specifications that represent the current state of CSS.

Phase 3 — JavaScript fundamentals

You’ll learn:

 What programming means

 Variables
 Data types
 Operators
 Conditions
 Loops
 Functions
 Arrays
  Objects
 Strings
 Numbers
 Scope
 Error handling
 Destructuring
 Spread and rest syntax
 Modules
 Debugging
 Problem-solving techniques

JavaScript is formally standardized as ECMAScript. We’ll use

modern, practical syntax that works in current browsers, while
avoiding experimental features that beginners do not need.

Phase 4 — JavaScript in websites

You’ll then connect JavaScript to HTML and CSS:

 The DOM
 Selecting HTML elements
 Changing text and styles
 Creating and removing elements
 Events
 Forms and validation
 Keyboard and mouse interactions
 Timers
 Local storage
 JSON
 Fetch API
 Async and await
 Working with public APIs
 Loading states
 Error states
 Interactive user interfaces

Phase 5 — Professional front-end skills

 Responsive design
 Mobile-first development
 Accessibility
 Search-engine-friendly HTML
  Web performance
 Clean code
 Naming conventions
 Folder organisation
 Browser compatibility
 Git and GitHub
 Deployment
 Portfolio building
 Basic UI and UX design
 Figma-to-code workflow
 Introduction to frameworks after fundamentals

My strong opinion: we will not jump directly into React or

another framework. Frameworks feel confusing when HTML,
CSS, JavaScript and the DOM are weak. Vanilla fundamentals
first; frameworks later.

Projects we’ll build

We’ll move from tiny exercises to complete websites:

1. Personal introduction page

2. Recipe page
3. School timetable
4. Portfolio website
5. Product landing page
6. Responsive restaurant website
7. Calculator
8. Digital clock
9. Quiz application
10. To-do application
11. Weather interface using an API
12. Expense tracker
13. Multi-page business website
14. Final responsive portfolio project
 Phase 0
Roadmap for Phase 0:
Lesso
Topic Result
n
Internet and World Wide Understand how websites
0.1
Web reach you
Websites, webpages and Identify different web
0.2
web applications products
Front end, back end and full
0.3 Understand developer roles
stack
Understand the three core
0.4 HTML, CSS and JavaScript
technologies
Organise website projects
0.5 Files, folders and paths
correctly
Code editor and browser Prepare your development
0.6
setup environment
Inspect and debug
0.7 Browser Developer Tools
webpages
Domains, hosting and Understand how websites
0.8
deployment go online
Web standards and Learn how professional
0.9
accessibility websites are built
Phase test and setup Confirm that your
0.10
practical foundation is solid

Lesson 0.1 — How the Internet and Web Work

Learning objectives

By the end of this lesson, you should be able to explain:

1. The difference between the internet and the web

2. What a client and server are
3. What happens after entering a website address
4. What DNS, IP addresses, URLs, HTTP, and HTTPS mean
5. The difference between a browser and search engine
6. How website files reach your screen
1. What is the internet?

The internet is a massive global network of connected

computers and other devices that communicate using agreed
technical rules called protocols.

The internet is the underlying infrastructure. The World Wide

Web is only one service that operates on it; email and other
communication services also use the internet.

Think of it like this:

Internet = the global system of roads connecting cities

The roads allow different services to travel:

 Webpages
 Emails
 Video calls
 Online games
 File transfers
 Messages

The internet is therefore not exactly the same thing as

websites.

A simplified internet connection

Your device
↓
Wi-Fi router or mobile network
↓
Internet service provider
↓
Other connected networks
↓
Destination server
Your internet service provider, or ISP, connects your home or
mobile device to the wider internet.

Common ISP examples in India include companies providing

fibre, broadband, or mobile-data connections. The exact
company does not change the fundamental process.

2. What is the World Wide Web?

The World Wide Web, usually called the web, is a system of

linked documents and resources that browsers access over the
internet.

These resources can include:

 HTML documents
 CSS stylesheets
 JavaScript files
 Images
 Videos
 Fonts
 Data

The internet provides the connection. The web uses that

connection to deliver webpages and related resources.

Internet v/s World Wide Web:

Internet World Wide Web
The global network
A service built on the internet
infrastructure
Connects devices and Connects webpages and
networks resources
Supports the web, email, Primarily accessed through
gaming and more browsers
Comparable to shops and
Comparable to roads
services beside the roads

Analogy

Imagine a pizza-delivery system:

 Internet: Roads connecting the restaurant and your house

  Web: The delivery service operating on those roads
 Website server: The restaurant
 Browser: You, the customer
 HTTP request: Your order
 HTTP response: The pizza delivery
 DNS: The contact system used to locate the restaurant
 Domain name: The restaurant’s memorable name
 IP address: Its exact location

This analogy is simplified, but it creates the correct mental

model.

3. What is a computer network?

A network is a group of connected devices that can

communicate and share information.

Your home may already contain a small network:

Laptop
Phone Wi-Fi router ─── Internet
Tablet
Smart TV

This local group of connected devices forms a local network.

The internet connects countless smaller networks together,

which is why the word can be understood as an “inter-network.”

4. What is a client?

A client is a device or program that requests something from

another computer.

When browsing the web, your browser normally acts as the

client.

Examples of web browsers include:

 Google Chrome
 Mozilla Firefox
 Microsoft Edge
 Safari
 Brave
Suppose you open a website. Your browser may request:

Please send me the homepage.

Please send me its stylesheet.
Please send me its JavaScript.
Please send me its logo.

The browser sends these requests to a server.

5. What is a server?

A server is a computer or software system that provides

resources or services to clients.

A web server stores or generates website resources and sends

them when requested. A web server can refer to the physical or
virtual computer, the server software running on it, or both.

A server may provide:

 HTML documents
 CSS files
 JavaScript files
 Images
 Videos
 User account information
 Product information
 Search results
 Database records

Client-server model

HTTP follows a client-server model: a client, usually a browser,

sends a request and waits for a response from a server.
CLIENT SERVER
Browser Web server
│ │
│──── Request: “Send homepage” ─────>│
│ │
│<──── Response: HTML, CSS, JS ──────│
│ │

The client requests. The server responds.

That is one of the most important ideas in web development.

6. What is an IP address?

Computers need addresses to find one another across networks.

An IP address, or Internet Protocol address, identifies a device

or destination on a network.

A simplified IPv4 address can look like this:

[Link]

A modern IPv6 address can look more like this:

2001:db8:85a3::8a2e:370:7334

Humans generally find names easier to remember than long

numeric addresses. That is one reason domain names and DNS
exist. ICANN explains that DNS lets people use familiar domain
names instead of remembering IP addresses.

Analogy

 Person’s name: Domain name

 Person’s phone number: IP address
 Contacts application: DNS

You remember the name, and the system finds the required
number.

7. What is a domain name?

A domain name is the human-readable name used to locate an

internet destination.

Examples:

[Link]
[Link]
[Link]

A domain usually contains sections separated by dots. ICANN

describes domain names as textual segments that identify a
particular internet address.
Consider:

[Link]

It can be broken into:

developer . mozilla . org

↑ ↑ ↑
subdomain main name top-level domain

Top-level domain

The final section is called the top-level domain, or TLD.

Examples:

.com
.org
.net
.in
.edu

In:

[Link]

 example is the main label or second-level portion

 .com is the top-level domain

In:

[Link]

 www is a subdomain
 example is the main domain label
 .com is the top-level domain

Note: A domain name is not the website itself. It is an address

used to reach the website.

8. What is DNS?

DNS stands for Domain Name System.

DNS converts a human-readable domain name into information
computers can use to locate the appropriate server.

Suppose you enter:

[Link]

A simplified process is:

1. Browser sees [Link]

2. DNS is asked where [Link] is located
3. DNS returns an IP address
4. Browser connects to that destination
5. Browser requests the webpage

ICANN describes DNS as an internet “address book” that helps

users reach the correct computer or device.

Important correction

DNS does not literally contain one magical global spreadsheet.

It is a distributed system involving many DNS servers and

layers. At beginner level, remembering “DNS translates names
into destination information” is enough.

9. What is a URL?

URL stands for Uniform Resource Locator.

A URL is the address of a particular resource on the web.

Example:

[Link]

Let’s break it down:

https:// [Link]/ products/[Link]

└─┬─┘ └────┬────┘└─────────┬─────────┘
scheme domain path
Scheme or protocol

https://

This indicates how the browser should communicate with the

server.

Domain

[Link]

This identifies the website’s domain.

Path

/products/[Link]

This identifies a particular location or resource on the website.

A more detailed URL

[Link]
category=shoes#reviews

Part Example Purpose

Scheme https Communication method
Subdomain shop A subsection of the domain
Domain [Link] Main human-readable address
Port 443 Communication endpoint
Path /products Requested location
?
Query string category=shoe Extra request information
s
A location within the returned
Fragment #reviews
page

You do not need to memorise every part today. Focus on:

Composition: scheme + domain + path

10. What are HTTP and HTTPS?

HTTP stands for Hypertext Transfer Protocol.

A protocol is a set of communication rules.

HTTP defines how clients and servers exchange web resources.

MDN describes HTTP as the foundation of web data exchange
and a protocol used to fetch resources such as HTML
documents.

A browser might effectively say:

GET /[Link]

The server might answer:

200 OK
Here is the requested HTML document.

HTTPS

HTTPS means HTTP communication protected using encryption

through TLS.

You normally see it at the beginning of a secure URL:

[Link]

Encryption helps prevent other parties on the network from

casually reading or modifying the information exchanged
between the browser and the server.

HTTPS does not automatically mean:

 The company is trustworthy

 Every statement on the website is true
 The website has no harmful content
 A product being sold is legitimate

It primarily means that the connection is encrypted and the

browser has verified the presented certificate according to its
trust system.
11. Request and response

The web operates through many requests and responses.

Request

A request is a message from the client asking for something.

Examples:

Send me the homepage.

Send me this image.
Submit this form.
Give me the latest product data.
Log this user in.

Response

A response is the server’s reply.

It may contain:

 HTML
 CSS
 JavaScript
 JSON data
 An image
 A video
 An error message
 A redirect

Simplified example

Browser:
GET /about

Server:
200 OK
[About-page HTML]

Opening one webpage may cause many requests rather than

only one.

For example:
Request 1 → HTML document
Request 2 → CSS stylesheet
Request 3 → JavaScript file
Request 4 → Logo
Request 5 → Background image
Request 6 → Font
Request 7 → Product data

A complete webpage is commonly assembled from multiple

resources, possibly delivered from different servers.

12. What happens when you open a website?

Suppose you enter:

[Link]

Here is the simplified journey.

Step 1: You enter the URL

The browser reads the address and identifies:

 The communication scheme: https

 The domain: [Link]
 The requested path

Step 2: The browser finds the server

The browser or operating system uses DNS to obtain the

destination’s address information.

[Link] → server address

Step 3: A connection is established

Your browser establishes a network connection to the

destination.

For HTTPS, a secure encrypted connection must also be

negotiated.

Step 4: The browser sends an HTTP request

Conceptually, it asks:
Please send me the resource located at /.

Step 5: The server processes the request

The server decides what to send back.

It might:

 Find an existing HTML file

 Run server-side code
 Read information from a database
 Check whether the user is logged in
 Generate a personalised response

Server-side code commonly handles tasks such as validating

requests, accessing databases, and sending the appropriate
data back to clients.

Step 6: The server sends a response

The response contains:

 A status code
 Response information called headers
 Usually some content called the body

Example:

Status: 200 OK
Content-Type: text/html

<!doctype html>
<html>
...
</html>

Step 7: The browser processes the HTML

The browser reads the HTML and turns it into an internal tree-
like representation called the DOM, or Document Object Model.

Step 8: More resources are requested

The HTML may refer to:

  Stylesheets
 JavaScript files
 Images
 Fonts
 Videos

The browser requests those resources separately.

Step 9: CSS is processed

The browser interprets CSS rules and builds an internal

representation of the page’s styles.

Step 10: JavaScript runs

JavaScript can:

 Change page content

 Respond to clicks
 Validate forms
 Request new data
 Create animations
 Update the interface

JavaScript is widely used as the scripting language of webpages,

though it can also run outside browsers.

Step 11: The page is rendered

The browser calculates the layout and paints the result onto the
screen.

The entire process can happen very quickly, but there is a lot
going on underneath.

13. Browser vs search engine

This confuses nearly every beginner, so lock it in now.

Web browser

A browser is software used to access and display web content.

Examples:
  Chrome
 Firefox
 Edge
 Safari

Search engine

A search engine is a website or online service that helps you

find webpages.

Examples include services that allow you to type a question or

keywords and receive search results.

The difference

Browser → The application you open

Search engine → A service you may visit inside the browser

Analogy:

Browser = Car
Search engine = Map/search service used inside the car
Internet = Road network
Website = Destination

Google Chrome and Google Search are not the same thing:

 Google Chrome is a browser

 Google Search is a search engine

14. Webpage vs website

Webpage

A webpage is one individual document or view available on the

web.

Examples:

Homepage
About page
Contact page
Product page
Login page

Website

A website is a collection of related webpages and resources

under a shared identity or domain.

Example structure:

[Link]/
├── Home page
├── About page
├── Contact page
├── Products page
└── Blog page

Analogy:

Website = Book
Webpage = One page or chapter in the book

15. Website vs web application

The boundary is not always perfectly sharp, but this beginner

distinction is useful.

Website

A traditional website mainly presents information.

Examples:

 School information site

 News publication
 Personal portfolio
 Restaurant site
 Documentation site

Web application

A web application provides richer functionality and lets users

perform tasks.
Examples:

 Online document editor

 Email application
 Learning dashboard
 Shopping platform
 Project-management tool

Modern products often combine both.

A shopping platform may contain:

 Informational pages
 Product pages
 User accounts
 Search
 Cart
 Payment workflow
 Order tracking

Calling it a web application is therefore usually more accurate.

16. Static and dynamic websites

Static website

A static website sends prepared files to visitors.

Browser requests page

↓
Server sends existing HTML file

The content generally stays the same until a developer changes

the files.

Static does not necessarily mean:

 Ugly
 Old-fashioned
 Completely motionless
 Unable to use JavaScript
A static site can still have modern styling, animations, forms,
and interactive JavaScript.

Dynamic website

A dynamic website can generate or customise content based on

data, users, or requests.

Browser sends request

↓
Server runs code
↓
Server reads database
↓
Server generates response

Examples:

 A user dashboard showing your information

 A shop displaying current inventory
 A social feed showing different posts
 A search page generating results
 An online classroom showing your progress

Comparison

Static Dynamic
Often generates content using
Often serves prepared files
code and data
Simpler architecture More complex architecture
Excellent for portfolios and Useful for accounts, dashboards
documentation and shops
Can be highly interactive in Often works with databases and
the browser authentication
17. Where HTML, CSS and JavaScript fit

The HTML standard describes HTML as the web’s core markup

language, and MDN defines it as the basic building block that
gives web content its structure and meaning.

HTML

HTML defines the content and semantic structure.

<h1>Welcome</h1>
<p>This is my website.</p>

CSS

CSS controls presentation and layout.

h1 {
font-size: 3rem;
}

JavaScript

JavaScript adds programming and behaviour.

[Link]("Page loaded");

The complete flow

SERVER SENDS FILES

↓
HTML → What exists
CSS → How it looks
JS → How it behaves
↓
BROWSER DISPLAYS THE RESULT

Modern HTML is maintained as a Living Standard, meaning the

standard continues to evolve instead of being treated only as a
frozen historical version.
18. Important vocabulary cheat sheet
Term Meaning
Global infrastructure connecting networks and
Internet
devices
A system of linked resources accessed over the
Web
internet
Client Program or device requesting a resource
Browser Client software used to access web content
Server System that provides resources or services
Domain name Human-readable internet address
IP address Network address used to identify a destination
System that helps map domain names to
DNS
destinations
URL Address of a particular web resource
HTTP Protocol used to exchange web resources
HTTP over an encrypted, authenticated
HTTPS
connection
Request Message asking a server for something
Response Server’s reply to a request
Webpage One page or document on the web
Website Collection of related webpages and resources
Web
Web product designed for performing tasks
application
HTML Structure and meaning
CSS Presentation and layout
JavaScript Programming and interactivity
19. Flashcards

Flashcard 1

Front: Is the internet the same as the web?

Back: No. The internet is the network infrastructure; the web is
a service built on it.

Flashcard 2

Front: What is a client?

Back: A program or device that requests a resource or service.

Flashcard 3

Front: What is a server?

Back: A system that responds to clients and provides resources
or services.

Flashcard 4

Front: What does DNS do?

Back: It helps translate human-readable domain names into
information needed to reach internet destinations.

Flashcard 5

Front: What is a URL?

Back: The address of a specific resource on the web.

Flashcard 6

Front: What is HTTP?

Back: A protocol used for communication between web clients
and servers.

Flashcard 7

Front: Browser or search engine: Chrome?

Back: Browser.

Flashcard 8
Front: What is the difference between a website and webpage?
Back: A webpage is one document or view; a website is a
related collection of pages and resources.

Flashcard 9

Front: What does HTML provide?

Back: Content structure and meaning.

Flashcard 10

Front: What does HTTPS add?

Back: Encryption and server-certificate verification for the
connection.

20. Common beginner mistakes

Mistake 1: “The internet is Google”

Google’s services operate through the internet, but Google is

not the internet itself.

Mistake 2: “Chrome is a search engine”

Chrome is a browser. A search engine is a service accessed

using a browser.

Mistake 3: “A domain name stores the website”

A domain name is an address. Website files are stored or

generated elsewhere, commonly on servers or hosting
infrastructure.

Mistake 4: “One webpage means one request”

A webpage frequently requires many separate requests for

HTML, CSS, JavaScript, images, fonts, and data.

Mistake 5: “HTTPS means the website is trustworthy”

HTTPS protects the connection. It does not prove every claim or

action on the website is safe or honest.
Mistake 6: “Static means there can be no interaction”

A static site can still run browser-side JavaScript and include

substantial interactivity.

21. Practical activity — Investigate a website

No coding is required yet.

Open a normal public website in Chrome or Edge.

Part A: Identify the address

Look at its URL and write down:

I chose [Link]/learn/responsive-web-design-
v9/workshop-cat-photo-app/step-24

Scheme: www
Domain: [Link]

Path:
/learn/responsive-web-design-v9/workshop-cat-photo-app/step-
24

Example:

URL: [Link]

Scheme: https
Domain: [Link]
Path: /products/shoes

Part B: Navigate through pages

Open two or three sections and observe how the URL changes.

Example:

/
/about
/contact
/products
Notice whether:

 The domain remains the same

 The path changes
 A query string appears
 A fragment beginning with # appears

Part C: Inspect page resources

On Windows:

Ctrl + Shift + I

Or:

F12

Then open the Network tab and reload the page.

You may see resource categories such as:

Document
Stylesheet
Script
Image
Font
Fetch/XHR

Do not worry about understanding every entry. The objective is

simply to observe that one webpage can load many resources.

22. Lesson test

Answer without checking the notes first.

Section A — Multiple choice

1. Which statement is correct?

A. The web and internet are exactly the same

B. The web is a service that uses the internet
C. The internet only contains webpages
D. A browser creates the global internet
2. Which program normally acts as a web client?

A. Browser
B. Domain name
C. IP address
D. HTML heading

3. What is DNS mainly used for?

A. Styling webpages
B. Writing JavaScript
C. Helping locate destinations using domain names
D. Creating passwords

4. Which is a browser?

A. HTML
B. Chrome
C. HTTP
D. DNS

5. Which is the most accurate description of HTTPS?

A. A programming language
B. An encrypted form of web communication
C. A search engine
D. A file extension

Section B — True or false

6. The internet supports services other than the web.

7. A domain name and IP address are exactly the same thing.
8. A browser may request multiple resources for one webpage.
9. CSS normally defines the semantic structure of a document.
10. HTTPS proves that every claim on a website is truthful.

Section C — Explain in your own words

11. What is the difference between the internet and web?

12. What is the difference between a client and server?
13. What happens after you enter a domain name?
14. What is the difference between a browser and search
engine?
 15. Explain HTML, CSS, and JavaScript using your own
analogy.

Section D — Trace the journey

Put these steps in the correct order:

A. The server sends a response

B. The browser displays the page
C. The user enters a URL
D. DNS helps locate the server
E. The browser sends an HTTP request
F. The browser processes HTML, CSS, and JavaScript

--------------------------------------X-----------------------------------------

Lesson 0.2

Webpages, Websites and Web Applications

This lesson answers a deceptively simple question:

What exactly are we building when we write web code?

People often use webpage, website, and web application as

though they mean the same thing. They are related, but not
identical.

Learning objectives

By the end of Lesson 0.2, you should be able to:

1. Explain what a webpage is

2. Explain what a website is
3. Explain what a web application is
4. Distinguish static and dynamic websites
5. Understand single-page and multi-page architectures
6. Recognise common categories of websites
7. Understand that these categories can overlap
8. Analyse a web product like a developer
1. What is a webpage?

A webpage is an individual document or view that can be

opened in a web browser.

Examples include:

 A homepage
 An About page
 A contact page
 A product page
 A news article
 A login page
 A user-profile page

A webpage is commonly built from HTML and may also use CSS,
JavaScript, images, fonts, video, and data from servers. The
browser retrieves these resources and assembles them into the
result displayed on your screen.

Simple webpage example

Suppose a school website has this address:

[Link]

The /about portion may represent one webpage: the school’s

About page.

Another address might be:

[Link]

That could represent a different webpage: the Contact page.

Book analogy

Think of a website as a book:

Website = Entire book

Webpage = One page or chapter
Links = Navigation between chapters
Domain = Book’s main identity
The analogy is not technically perfect, but it is useful for
beginners.

2. What is a website?

A website is a collection of related webpages and resources

usually connected through links and organised under a shared
identity or domain.

A website may contain:

Homepage
├── About
├── Services
├── Contact
├── Blog
│ ├── Article 1
│ ├── Article 2
│ └── Article 3
└── Login

The website is the complete collection. Each item within it

may be a separate webpage or view.

Example

Imagine this domain:

[Link]

It could contain:

[Link]
[Link]
[Link]
[Link]
[Link]

These addresses represent different locations within the same

overall website.

Important distinction
A domain name is not automatically the website itself.

Domain name = Human-readable address

Website = Content and functionality available through that
address
Hosting/server = Infrastructure delivering it

A single domain may even contain multiple related applications

using subdomains, such as [Link] and
[Link].

3. What is a web application?

A web application, or web app, is software built using web

technologies and accessed through a browser.

It is designed primarily to let users perform tasks, not merely

read information.

Examples of tasks include:

 Creating documents
 Sending messages
 Managing schoolwork
 Editing photos
 Tracking expenses
 Buying products
 Booking tickets
 Managing projects
 Watching personalised content
 Using an online calculator
 Updating a user profile

JavaScript and browser APIs are commonly used to change

webpage content, respond to user actions, store information,
and communicate with servers.

Website vs web application

A useful beginner distinction is:

Website → Mainly presents information

Web application → Mainly helps users perform tasks

However, this is not a strict scientific boundary.

Many modern web products are both.

For example, an online shopping platform can contain:

 Informational product pages

 Search tools
 User accounts
 Shopping carts
 Payments
 Order tracking
 Reviews
 Customer dashboards

The informational areas resemble a traditional website, while

the cart, account, checkout, and tracking areas behave like an
application.

Interaction comparison

Mostly informational webpage

User opens page

↓
User reads content
↓
User follows another link

Web application

User opens application

↓
User logs in
↓
User creates or changes data
↓
Application saves the data
↓
Interface updates
The second process involves more user input, application logic,
and state.

4. What does “state” mean?

In programming, state means the information describing the

application’s current situation.

For an online shopping application, state might include:

Logged-in user
Items in cart
Selected product size
Chosen delivery address
Current page
Applied coupon
Payment status

For a quiz application, state might include:

Current question
Selected answer
Current score
Remaining time
Completed questions

When something changes, the application’s state changes.

Example:

Cart before click:

0 items

User clicks “Add to cart”

Cart after click:

1 item

Later, JavaScript will help us manage state inside browser

interfaces.
5. Website and web-app spectrum

Instead of imagining two completely separate boxes, it is better

to imagine a spectrum:

Mostly informational Highly interactive

│ │
▼ ▼

Portfolio → Blog → News site → Shop → Dashboard → Online

editor

A portfolio may mostly display content.

A shop displays content but also includes search, accounts,

carts, and checkout.

An online editor behaves much more like traditional desktop

software.

This means asking “Is it a website or a web app?” sometimes

has no single perfect answer.

A better question is:

What information does it present, and what tasks can

users perform?

6. Static websites

A static website sends prepared resources to the browser.

For a particular URL, users generally receive the same prebuilt

content unless the website’s files are changed or rebuilt.

MDN describes a static site as one that returns the same hard-
coded content whenever a particular resource is requested.
Static websites can still contain HTML, CSS, and JavaScript;
“static” does not mean visually motionless.

Simplified static-site process

Browser requests /[Link]
↓
Server finds [Link]
↓
Server sends [Link]
↓
Browser displays it

Example project structure

portfolio/
├── [Link]
├── [Link]
├── [Link]
├── [Link]
├── css/
│ └── [Link]
├── js/
│ └── [Link]
└── images/
├── [Link]
└── [Link]

Each page may already exist as an HTML file.

Static does not mean boring

A static site can still have:

 Responsive layouts
 CSS animations
 Image galleries
 Dark mode
 JavaScript calculators
 Interactive menus
 Form validation
 Locally stored preferences
 Data loaded from external APIs

The term mainly describes how the site’s content is created and
delivered, not whether elements can move or respond to clicks.

Suitable uses
Static approaches are often suitable for:

 Portfolios
 Documentation
 Event pages
 Product landing pages
 Small business sites
 Personal profiles
 Simple school projects
 Campaign pages

7. Dynamic websites

A dynamic website generates or customises some content

when it is needed.

The server may:

1. Receive a request
2. Run application code
3. Read information from a database
4. Apply business rules
5. Generate or return the appropriate response

MDN defines dynamic sites as sites where some response

content is generated when required, often by combining
database information with page templates.

Simplified dynamic process

Browser requests /profile

↓
Server checks which user is logged in
↓
Server retrieves that user’s information
↓
Server generates or returns profile data
↓
Browser displays the personalised profile

Different users may receive different results from the same URL.
Example

Consider:

[Link]

User A may see:

Welcome, Aarav
Completed courses: 7
Pending assignments: 2

User B may see:

Welcome, Meera
Completed courses: 3
Pending assignments: 5

The URL is the same, but the response or data differs because
the users and stored information differ.

Common dynamic features

Dynamic sites often include:

 User accounts
 Personalised dashboards
 Search results
 Recommendations
 Comments
 Shopping carts
 Current inventory
 Order histories
 Notifications
 Messaging
 Database-backed content

Most large modern web products use databases and server-side

systems to store and retrieve changing information.
8. Static vs dynamic comparison
Feature Static site Dynamic site
Content Usually prepared Often generated
creation beforehand when requested
Database
Not necessarily Commonly used
required
Possible through external
User accounts Common
services, but not inherent
Limited without additional
Personalisation Common
services
Complexity Usually lower Usually higher
Depends on
Speed potential Often very fast
architecture
Updating Update data through
Edit or rebuild files
content an application
Example Basic portfolio Student dashboard

Important nuance

A modern project can mix both approaches.

For example:

Homepage → Prebuilt static content

Blog articles → Generated during deployment
Dashboard → Dynamically loaded user data
Checkout → Server-backed application

Real-world websites are often hybrid systems rather than purely

static or purely dynamic.

9. Client-side and server-side behaviour

To understand web applications, you need to separate two

locations where code can run.
Client side

Client-side code runs in the user’s browser.

Common client-side technologies include:

 HTML
 CSS
 JavaScript
 Browser APIs

Client-side JavaScript can:

 Respond to button clicks

 Open menus
 Change text
 Validate form fields
 Display popups
 Create animations
 Request data
 Update the page without a full reload

JavaScript is widely used as the scripting language of webpages,

and DOM APIs allow it to modify the document’s structure and
styling.

Server side

Server-side code runs on servers rather than in the visitor’s

browser.

It may:

 Verify login details

 Save information to a database
 Retrieve user records
 Process orders
 Apply permissions
 Generate pages
 Send emails
 Return API data

Dynamic server-side systems commonly combine a web server,

application code, and a database.
Example: Logging in

1. User enters username and password

2. Browser sends the information securely
3. Server checks the account
4. Server accepts or rejects the login
5. Browser displays the result

The browser handles the interface.

The server performs the trusted account check.

You should never rely only on browser-side JavaScript for

important security decisions because users control their own
browsers.

10. Multi-page applications

A multi-page application, or MPA, uses traditional page

navigation.

When the user moves to another route, the browser generally

requests a new page from the server.

Example navigation

User opens /
↓
Server sends homepage

User clicks /about

↓
Server sends About page

User clicks /contact

↓
Server sends Contact page

Each navigation may load a new HTML document.

Common qualities
An MPA may have:

 Separate pages or server routes

 Full document navigation
 Server-generated HTML
 Page-specific content
 Normal browser link behaviour

MPAs are common for:

 Blogs
 News platforms
 Documentation
 Business websites
 Content-heavy websites
 Online shops

An MPA does not have to be simple or static. It can be a massive

dynamic system.

11. Single-page applications

A single-page application, or SPA, loads an application shell

and then uses JavaScript to update views and manage
navigation without requesting a completely new HTML document
for every route.

In an SPA architecture, client-side JavaScript commonly handles

rendering, routing, and interface updates using data retrieved
by the application.

Simplified SPA flow

Browser loads application

↓
JavaScript starts
↓
User clicks Dashboard
↓
Application fetches required data
↓
JavaScript changes the visible interface

The screen may look like a different page, and the URL may
change, but the browser may not have performed a traditional
full-page navigation.

SPA analogy

Think of a stage play:

The theatre remains the same

Props and actors change
The audience sees a new scene

For an MPA, it is more like entering a different theatre room for

each scene.

Possible SPA benefits

 Smooth interface changes

 Desktop-app-like interactions
 Reuse of already loaded interface code
 Convenient stateful experiences
 Efficient updates after the initial load

Possible SPA challenges

 More JavaScript complexity

 Larger initial downloads
 Navigation must be implemented carefully
 Accessibility requires attention
 Search-engine visibility may require additional work
 Loading and error states must be designed properly
 Performance can suffer if too much code is sent

“SPA” does not automatically mean better or more modern. It is

an architectural choice.

My strong take: beginners should not start by building

everything as an SPA. First learn normal HTML pages, links,
forms, browser behaviour, CSS, JavaScript, and the DOM. Then
SPA frameworks become far less mysterious.
12. SPA vs MPA comparison
Feature SPA MPA
JavaScript often
Browser commonly
Navigation updates the current
loads another document
document
Initial Often easier to
Usually higher
complexity understand
JavaScript
Often heavy Can be light or optional
dependency
App-like
Common Also possible
interaction
Full page Usually avoided during Common during
reload internal navigation navigation
Blogs, stores,
Dashboards, editors,
Suitable for documentation, content
complex tools
sites

Neither is automatically superior.

Choose based on:

 Project requirements
 Performance
 Accessibility
 Content type
 Team knowledge
 Search requirements
 Maintenance cost
 User experience

13. Progressive Web Apps

A Progressive Web App, or PWA, is built using web-platform

technologies but provides experiences associated with installed
applications.
Depending on browser and platform support, a PWA may offer
features such as:

 Installation
 Its own application icon
 Standalone display
 Offline or unreliable-network support
 Background capabilities
 Notifications
 Integration with operating-system features

MDN defines a PWA as an application built using web

technologies that provides an experience similar to a platform-
specific application. A web app manifest supplies installation-
related information, while service workers are commonly
involved in offline and background behaviour.

Traditional website

Open browser
Enter address
Use website

Installable PWA experience

Visit web application

Install it
Launch from app icon
Use it in a more app-like window

A PWA is still made using web technology. It does not become a

traditional native Android, iOS, Windows, or macOS application.

14. Common types of websites

These categories describe a website’s purpose, not necessarily

its technical architecture.

A site can belong to several categories at once.

14.1 Portfolio website

A portfolio presents a person’s skills, work, projects, or

achievements.

Typical sections:

Home
About
Skills
Projects
Certificates
Contact

Common users:

 Students
 Designers
 Developers
 Photographers
 Writers
 Freelancers

Your future web-development portfolio will likely begin as a

static multi-page site and gradually become more interactive.

14.2 Blog

A blog publishes articles or posts, usually organised by date,

category, author, or topic.

Common features:

 Article pages
 Categories
 Tags
 Search
 Author profiles
 Comments
 Related posts
A small blog can be static. A larger blog may use a content-
management system and database.

14.3 News or magazine website

A news platform publishes frequently updated content.

Common features:

 Headlines
 Article categories
 Search
 Author information
 Publication dates
 Breaking-news sections
 Images and videos
 Recommendations

These sites are usually dynamic or generated through content-

management systems because content changes frequently.

14.4 Business or brochure website

A business website explains what an organisation offers.

Typical pages:

Home
About
Services
Pricing
Testimonials
Contact

Its primary purpose is often to build trust and generate

enquiries.

A brochure website may be mostly informational but can include

application-like features such as appointment booking.
14.5 Landing page

A landing page is designed around one focused goal.

Examples:

 Join a waiting list

 Download an application
 Register for an event
 Purchase a product
 Subscribe to a newsletter
 Start a free trial

A landing page usually contains:

Headline
Value proposition
Benefits
Images
Social proof
Call-to-action button
Frequently asked questions

A call to action, or CTA, asks the visitor to perform a specific

action.

Example:

Start Learning
Create Account
Download Guide
Register Now

14.6 E-commerce website

An e-commerce website allows users to browse and purchase

products or services.

Common features:

 Product catalogue
  Search
 Filters
 Product pages
 Cart
 Checkout
 Payments
 User accounts
 Order history
 Inventory
 Reviews

An e-commerce platform combines informational pages with

complex application functionality.

14.7 Educational website

An educational site delivers learning materials.

It might contain:

 Lessons
 Notes
 Videos
 Quizzes
 Worksheets
 Progress tracking
 Assignments
 Certificates
 Teacher dashboards

A simple tutorial website may be mainly informational. A

complete learning-management system is a web application.

14.8 Social or community platform

A community platform allows users to interact with one another.

Common features:

 User profiles
  Posts
 Comments
 Likes or reactions
 Following
 Groups
 Messaging
 Notifications
 Content moderation

These platforms are generally dynamic because user-generated

content constantly changes.

14.9 Dashboard

A dashboard presents data and controls in an organised

interface.

Examples:

 Student-progress dashboard
 Expense dashboard
 Website analytics dashboard
 Admin dashboard
 Inventory dashboard

Typical components:

Navigation sidebar
Summary cards
Charts
Tables
Filters
Forms
Notifications
Account settings

Dashboards are usually web applications because users view

personalised data and perform actions.
14.10 Portal

A portal acts as a central gateway to several services or

resources.

Examples include:

 Student portal
 Employee portal
 Government-service portal
 Customer-support portal

A student portal might provide:

Attendance
Marks
Assignments
Timetable
Notices
Fee records
Learning resources

14.11 Documentation website

A documentation website explains how a product, service, API,

or programming technology works.

Common features:

 Sidebar navigation
 Search
 Code examples
 Version information
 Tutorials
 Reference pages
 Previous and next links

Documentation sites prioritise readability, navigation,

accessibility, and search.

14.12 Search engine

A search engine helps users locate information or resources.

Its interface may appear simple:

Search box
Search button
Results page
Filters

Behind that simple interface can be highly complex systems for:

 Collecting information
 Creating indexes
 Understanding queries
 Ranking results
 Filtering unwanted content
 Returning results quickly

Simple-looking interfaces are not always simple systems.

14.13 Software as a Service

Software as a Service, commonly called SaaS, is software

delivered through an online service, often through a browser.

Examples of SaaS categories include:

 Project management
 Online design tools
 Accounting systems
 School-management systems
 Customer-support platforms
 Document editors

Common SaaS features include:

 Accounts
 Subscription plans
 Dashboards
 Data storage
 Team collaboration
 Permissions
  Settings
 Billing

SaaS describes the business and delivery model more than one
specific programming technique.

15. Categories can overlap

Consider an online learning platform.

It may simultaneously be:

Educational website
Web application
Dynamic website
SaaS platform
Multi-page application or SPA
Installable PWA

These labels answer different questions:

Label Question answered

Educational
What is its purpose?
website
Web application How interactive is it?
Dynamic website How is changing content produced?
SaaS How is the software delivered?
SPA or MPA How is navigation structured?
Does it provide installable/app-like web
PWA
capabilities?

Do not force every website into one box.

16. Anatomy of a typical modern website

Consider a school-learning platform.

Public area

Homepage
About
Available courses
Pricing
Contact
Help

These areas mostly present information.

Authentication area

Create account
Log in
Reset password
Verify email

These pages handle user identity.

Student application

Dashboard
Lessons
Quizzes
Assignments
Progress
Certificates
Settings

These areas behave like a web application.

Teacher application

Create course
Upload lesson
Review assignment
View student progress
Publish announcement
Administrator area

Manage users
Manage permissions
View reports
Configure platform
Moderate content

One “website” can contain several connected applications and

user experiences.

17. Common beginner misconceptions

Misconception 1: Every URL is a separate HTML file

Not necessarily.

This URL:

[Link]

could be:

 A physical HTML file

 A server-generated page
 A client-side route in an SPA
 A prebuilt static page
 A dynamically rendered hybrid page

The visible URL does not reveal the entire architecture.

Misconception 2: Dynamic means animated

These are different ideas.

Dynamic content → Content changes based on data or

conditions
Animation → Visual movement over time

A static website can have animations.

A dynamic website can have no animations at all.

Misconception 3: A web app must be downloaded

A web application can run directly in a browser.

Some web applications can additionally be installed as PWAs,

but installation is not required for something to be a web app.

Misconception 4: SPAs are always faster

An SPA can feel fast after it loads, but it may also send large
amounts of JavaScript or perform inefficient rendering.

Performance depends on implementation, architecture, network

conditions, caching, devices, and many other factors.

Misconception 5: More JavaScript means a better website

Nope. That idea has caused a lot of unnecessarily heavy

websites.

JavaScript should be used when it meaningfully improves

functionality.

A page containing headings, paragraphs, links, and images does

not need a giant JavaScript framework merely to exist.

Misconception 6: Static sites are outdated

Static architecture remains useful for portfolios, documentation,

landing pages, blogs, and performance-focused content.

Modern static-site generators can create large websites during a

build process and distribute the finished files efficiently.
18. Developer analysis framework

Whenever you visit a web product, analyse it using these

questions.

Purpose

Why does this website exist?

What problem does it solve?
Who is it for?

Content

What information does it present?

How is that information organised?

User actions

What can users click, create, edit, upload, buy, or submit?

Navigation

How do users move between sections?

Does the page fully reload?
Does the interface update instantly?

Personalisation

Does everyone see the same content?

Does it change after login?

Data

What information might be stored?

Does the website probably use a database?

Architecture guess

Mostly static or dynamic?

Likely SPA, MPA, or hybrid?
Website, application, or both?

You will not always know the exact internal architecture—and

that is okay. Developers frequently begin with evidence and
make careful hypotheses.
19. Practical activity — Website detective

Choose three safe, normal websites:

1. An informational website
2. An online shop or learning platform
3. A highly interactive web application

Create a table like this:

Site Site Site

Question
1 2 3
Main purpose
Target user
Mostly website or web
app?
Static or dynamic clues
Main user actions
Login required?
Personalised content?
Possible stored data
SPA, MPA, or uncertain?

What counts as evidence?

Possible evidence includes:

The cart updates after clicking

A dashboard changes after login
Search results depend on the query
The URL changes during navigation
The page visibly reloads
Content is personalised
New posts appear frequently
Forms save information
Do not worry if your SPA or MPA guess is uncertain. Write:

Uncertain — more investigation needed

That is better than pretending.

20. Mini practical — Design a school website concept

Imagine you are planning a school website.

Divide its features into two groups.

Informational website section

Possible pages:

Homepage
About the school
Admissions
Facilities
School rules
Contact information
News
Events

Web application section

Possible features:

Student login
Attendance
Marks
Assignments
Timetable
Fee information
Teacher dashboard
Announcements
Profile settings

Now answer:

1. Which pages should everyone access?

2. Which pages require login?
3. What data would need to be stored?
4. Which features would be personalised?
5. Which areas are mostly informational?
6. Which areas behave like an application?

This is an early form of requirements analysis—figuring out

what a system needs before writing code.

21. Lesson 0.2 cheat sheet

WEBPAGE
One individual document or view.

WEBSITE
A related collection of webpages and resources.

WEB APPLICATION
Browser-based software designed for performing tasks.

STATIC WEBSITE
Prepared content is delivered without generating it separately
for every request.

DYNAMIC WEBSITE
Content can be generated or customised using code and data.

CLIENT SIDE
Code running in the visitor’s browser.

SERVER SIDE
Code running on servers.

MPA
Navigation commonly loads new HTML documents.

SPA
JavaScript commonly updates views inside the current
document.
PWA
A web app enhanced with app-like and potentially installable
capabilities.

SAAS
Software delivered as an online service.

22. Flashcards

Flashcard 1

Front: What is a webpage?

Back: One individual web document or view accessed through a
browser.

Flashcard 2

Front: What is a website?

Back: A collection of related webpages and resources.

Flashcard 3

Front: What is a web application?

Back: Software built with web technology that allows users to
perform tasks through a browser.

Flashcard 4

Front: Are website and web app completely separate

categories?
Back: No. Many modern products are both informational
websites and interactive applications.

Flashcard 5

Front: What is a static website?

Back: A site that generally delivers prepared content for each
URL.

Flashcard 6
Front: Does static mean no animations?
Back: No. Static describes content generation and delivery, not
visual movement.

Flashcard 7

Front: What is a dynamic website?

Back: A site where some content is generated or customised
using code and data.

Flashcard 8

Front: What is client-side code?

Back: Code that runs in the user’s browser.

Flashcard 9

Front: What is server-side code?

Back: Code that runs on a server and may process requests,
permissions, or database information.

Flashcard 10

Front: What is an MPA?

Back: A multi-page application where navigation commonly
requests another HTML document.

Flashcard 11

Front: What is an SPA?

Back: A single-page application where JavaScript updates the
interface and commonly manages navigation.

Flashcard 12

Front: What is a PWA?

Back: A web application enhanced to provide platform-app-like
capabilities.

Flashcard 13

Front: What is state?

Back: Information describing the application’s current situation.

Flashcard 14
Front: Is an SPA always better than an MPA?
Back: No. The correct architecture depends on project
requirements.

23. Lesson test

Try answering without checking the notes.

Section A — Multiple choice

1. What is a webpage?

A. The entire internet

B. One web document or view
C. A Wi-Fi connection
D. A server’s IP address

2. What is a website?

A. Only the homepage

B. A browser
C. A collection of related webpages and resources
D. A programming language

3. Which best describes a web application?

A. A printed document
B. Browser-based software that helps users perform tasks
C. A computer network cable
D. Only a static image

4. What does “static website” primarily describe?

A. A page with no colours

B. A page with no movement
C. How content is prepared and delivered
D. A broken website

5. Which feature most strongly suggests a dynamic

application?
A. A fixed heading
B. A personalised student dashboard
C. A background colour
D. A logo image

6. Where does client-side JavaScript normally run?

A. In the user’s browser

B. Inside the keyboard
C. In the domain name
D. In the Wi-Fi password

7. Which is generally associated with an SPA?

A. JavaScript updates views in the current document

B. Every button turns off the internet
C. HTML cannot be used
D. The application has exactly one feature

8. What does PWA stand for?

A. Personal Website Address

B. Progressive Web App
C. Public Web Algorithm
D. Program Without Access

Section B — True or false

9. A website can contain many webpages.

10. A web application must always be installed.
11. Static websites cannot use JavaScript.
12. Dynamic content may be created using database
information.
13. An e-commerce platform can be both a website and
web application.
14. Every URL must correspond to a physical HTML file.
15. An SPA is automatically better than an MPA.
16. Client-side and server-side code run in different
environments.
Section C — Explain

17. Explain the difference between a webpage and website.

18. Explain the difference between a website and web
application.
19. Explain static and dynamic websites using your own
analogy.
20. What is application state? Give two examples.
21. Explain the difference between client-side and server-
side code.
22. Explain SPA and MPA navigation.
23. Why can a shopping platform be called both a website
and web application?
24. Why is “dynamic” not the same as “animated”?

Section D — Classification

Classify each as primarily informational, application-like, or

mixed.

25. A one-page student portfolio

26. An online document editor
27. A restaurant site containing menus and table booking
28. A student dashboard showing marks and attendance
29. A technology blog with comments and user accounts
30. A product landing page

Section E — Architecture thinking

Consider a quiz platform with:

User accounts
Questions loaded from a database
Timer
Score calculation
Saved progress
Teacher dashboard
Certificates
Answer:

31. Is it mainly a website, web application, or both?

32. Is it likely static or dynamic?
33. What application state might it contain?
34. Which features probably require server-side code?
35. Which features could run client-side?
36. What information might be stored in a database?

24. Practical challenge

Sketch this structure on paper or in a text file:

My Future Learning Platform

├── Public Website
│ ├── Home
│ ├── About
│ ├── Courses
│ └── Contact
│
├── Student Application
│ ├── Dashboard
│ ├── Lessons
│ ├── Quizzes
│ └── Progress
│
└── Admin Application
├── Manage Students
├── Create Lessons
├── Create Tests
└── View Reports

For each section, mark it as:

I = Mainly informational
A = Mainly application functionality
M = Mixed

Main takeaway

Do not memorise website categories as rigid boxes.

Think in layers:

Purpose:
What is it for?

Content:
What does it show?

Functionality:
What can users do?

Data:
What information changes or gets stored?

Architecture:
How are pages generated and navigated?

Experience:
Does it behave more like a document or software?

----------------------------------------
x--------------------------------------------

Lesson 0.3

Front-End, Back-End, Full-Stack and the Web Development

Ecosystem

Welcome back, bro. 😎

Now we're getting to one of the most important mental

models in web development.

You've learned:

 Lesson 0.1: How the internet and web work

 Lesson 0.2: Webpages, websites, web applications,
static/dynamic sites, SPA/MPA

Now we're going to answer:

Who builds all this stuff, and what exactly does each
developer work on?

By the end of this lesson, you should understand the difference

between:

Front-end
Back-end
Full-stack
Database
API
Web server
DevOps / Cloud
UI/UX
Web designer
Web developer

We'll also connect everything into one complete picture.

Lesson 0.3 — The Big Picture

Imagine we're building a modern online learning platform.

A student opens:

[Link]

They see:
┌─────────────────────────────────────┐
│ LEARN PLATFORM │
├─────────────────────────────────────┤
│ Home Courses Dashboard Profile │
├─────────────────────────────────────┤
│ │
│ Welcome, Bro! │
│ │
│ Your Progress: 72% │
│ │
│ [ Continue Learning ] │
│ │
└─────────────────────────────────────┘

What happens behind the scenes?

The complete system might involve:

USER
│
▼
 WEB BROWSER
│
┌────────┴────────┐
│ │
▼ ▼
FRONT END INTERNET
│ │
└────────┬────────┘
│
▼
BACK END
│
┌──────┴──────┐
│ │
▼ ▼
DATABASE API
│ │
└──────┬──────┘
│
▼
SERVER / CLOUD

And there may also be people responsible for:

UI/UX Design
Security
Testing
Deployment
Monitoring
Performance
Accessibility

So a real web product is rarely "just HTML."

It is an entire ecosystem.

1. Front-End Development

Let's start with the part you are going to learn first.

What is the front end?

The front end is the part of a web product that runs in the
user's browser and that the user directly interacts with.

You can think of it as:

Everything the user experiences through the interface.

Examples:

 Navigation bars
  Buttons
 Text
 Images
 Forms
 Cards
 Menus
 Animations
 Tables
 Dashboards
 Error messages
 Loading indicators

The core technologies you are learning—HTML, CSS, and

JavaScript—are fundamental front-end technologies. HTML
structures content, CSS styles it, and JavaScript adds
programming and interactivity.

Front-end example

Suppose you have:

<button>Start Course</button>

HTML gives the button its structure.

CSS:

button {
background-color: blue;
color: white;
padding: 12px 20px;
}

CSS controls how it looks.

JavaScript:

[Link]("click", () => {
[Link]("Course started");
});

JavaScript controls what happens when the user interacts with it.
So:

HTML
↓
Structure

CSS
↓
Presentation

JavaScript
↓
Behaviour

That is the basic front-end triangle.

2. What Does a Front-End Developer Do?

A front-end developer builds the browser-facing part of a

website or web application.

Their work may include:

HTML
CSS
JavaScript
Responsive design
Accessibility
Browser APIs
Performance
Forms
Animations
UI interactions
Data fetching
Error handling

Modern front-end development can also involve frameworks and

libraries, but those sit on top of core web technologies rather
than replacing the need to understand them. MDN's current
learning curriculum still treats HTML, CSS, and JavaScript as
foundational skills before moving into broader tooling and
frameworks.

Later, you may encounter technologies such as:

React
Vue
Angular
Svelte

These are tools used to build complex user interfaces and

applications.

But our learning order will be:

HTML
↓
CSS
↓
JavaScript
↓
DOM
↓
APIs
↓
Tooling
↓
Frameworks

That order is intentional.

You don't want to learn:

React
↓
"What is this <div> thing?"

You want:

HTML knowledge
↓
CSS knowledge
 ↓
JavaScript knowledge
↓
DOM knowledge
↓
Framework knowledge

That foundation makes frameworks much easier.

3. Back-End Development

Now imagine a student clicks:

[ View My Progress ]

The browser needs actual data.

For example:

Student name: Aarav

Courses completed: 7
Quiz score: 88%
Current course: JavaScript

Where does that information come from?

The answer usually involves the back end.

The back end consists of server-side systems that handle tasks

such as processing requests, applying business rules, accessing
stored data, managing authentication, and generating or
returning responses. MDN describes server-side programming as
a way to store information in databases and dynamically
construct responses such as HTML or data formats like JSON.

A simplified system might look like:

Browser
│
│ "Give me my progress"
▼
Server
 │
│ "Find this user's data"
▼
Database
│
│ "Here it is"
▼
Server
│
│ "Return the data"
▼
Browser

The browser then displays:

Your Progress: 72%

4. What Does a Back-End Developer Do?

A back-end developer often works on things such as:

 Server-side programming
 Databases
 Authentication
 Authorisation
 Business logic
 APIs
 Data processing
 Security
 Server architecture
 Performance
 Error handling

For example, imagine an online store.

A user clicks:

Buy Now

The back end may need to:

1. Identify the user

 2. Check whether the product exists
3. Check inventory
4. Calculate the price
5. Apply discounts
6. Create an order
7. Store the order
8. Process payment through an appropriate payment system
9. Update inventory
10. Return the result

The front end might show:

Order confirmed!

But an enormous amount of work can happen behind that

simple message.

5. Front End vs Back End

Here's the simplest comparison.

Front End Back End

Runs primarily in the browser Runs primarily on servers
Usually behind the
User-facing
scenes
HTML Server-side languages
CSS Server-side frameworks
JavaScript Databases
UI Business logic
Browser interactions Authentication
Forms and interface Data processing
Visual presentation APIs

A very simplified mental model:

FRONT END
"What the user sees and interacts with"

BACK END
"What powers the application behind the scenes"

But there is an important nuance.

The boundary is not always absolute.

Modern systems can render content on the server, in the

browser, or through a mixture of both. Architectures such as
server-side rendering and client-side rendering distribute work
differently between the server and client.

So don't think:

Browser = 100% front end

Server = 100% back end

as an unbreakable law.

Think:

Front end generally refers to the user-facing experience,

while back end generally refers to server-side systems
and application logic.

That's the useful distinction.

6. What is a Full-Stack Developer?

A full-stack developer works across both the front-end and

back-end portions of a web application.

For example:

HTML
CSS
JavaScript
 +
Server-side programming
+
Databases
+
APIs

A full-stack developer might build:

Frontend
↓
Login page

Backend
↓
Authentication system

Database
↓
Store user account

API
↓
Connect frontend and backend

The exact meaning of "full-stack" varies between companies and

individuals. One developer might be comfortable across the
whole application while another may specialise in particular
areas but still work across the stack.

So:

Front-end developer
↓
Specialises mainly in user-facing web development

Back-end developer
↓
Specialises mainly in server-side systems

Full-stack developer
↓
Works across both

Being full-stack doesn't necessarily mean being an expert in

every technology.

Nobody knows every framework, database, cloud platform,

programming language, and infrastructure system.

That's not realistic.

7. The Stack

You've probably heard people say:

"What's your tech stack?"

A tech stack is simply the collection of technologies used to

build and run a software product.

Imagine a web application using:

Front End
HTML
CSS
JavaScript
React

Back End
[Link]
Express

Database
PostgreSQL

Deployment
Cloud hosting

Version Control
Git
You could describe this as part of the application's technology
stack.

8. Example: MERN Stack

You may eventually encounter the term MERN.

It stands for:

M → MongoDB
E → Express
R → React
N → [Link]

Roughly:

React
↓
Front End

[Link] + Express
↓
Back End

MongoDB
↓
Database

Notice something interesting:

JavaScript

can be used across much of the stack.

That is possible because JavaScript runs in browsers and can

also run outside browsers through environments such as
[Link]. MDN describes [Link] as a JavaScript runtime that
allows JavaScript to be used for server-side tools and
applications outside the browser.

But MERN is only one possible stack.

There are many others.

Examples:

HTML/CSS/JS + Python + PostgreSQL

HTML/CSS/JS + Java + MySQL

React + [Link] + PostgreSQL

Vue + Go + PostgreSQL

Angular + .NET + SQL Server

Don't worry about choosing one right now.

You are still at Phase 0.

First:

Learn the web

↓
Learn HTML
↓
Learn CSS
↓
Learn JavaScript
↓
Understand APIs
↓
Then choose a stack

That is our route.

9. What is a database?

A database is a system used to store, organise, retrieve, and

manage data.

Imagine our learning platform.

The database might contain:

USERS
────────────────────
id
name
email
password_hash

COURSES
────────────────────
id
title
description

ENROLLMENTS
────────────────────
user_id
course_id
progress

QUIZZES
────────────────────
id
course_id
title

RESULTS
────────────────────
user_id
quiz_id
score

When you log in, the application might retrieve your user record.

When you complete a quiz, the system might store your result.

When you return tomorrow, your progress is still there.

That's because the application has persistent data storage.

Server-side programming is particularly useful for applications
that need to store and dynamically retrieve large or changing
amounts of information from databases.

10. Types of Databases

You don't need to learn databases yet, but you should know the
broad categories.

Relational databases

These organise data into tables with defined relationships.

Examples include:

PostgreSQL
MySQL
SQLite
Microsoft SQL Server
Oracle Database

Imagine:

STUDENTS
┌────┬────────┐
│ ID │ NAME │
├────┼────────┤
│ 1 │ Aarav │
│ 2 │ Meera │
└────┴────────┘

And:

COURSES
┌────┬─────────────┐
│ ID │ COURSE │
├────┼─────────────┤
│ 1 │ HTML │
│ 2 │ JavaScript │
└────┴─────────────┘

Relationships connect the data.

You'll eventually learn SQL separately.

NoSQL databases

"NoSQL" is a broad category that includes database systems

with models other than the traditional relational table model.

One common model stores data in document-like structures.

For example:

{
"name": "Aarav",
"course": "JavaScript",
"progress": 72
}

MongoDB is a well-known document-oriented database.

Again, don't worry about implementation details yet.

The key idea is:

Database
↓
Persistent data storage

11. What is an API?

An API, or Application Programming Interface, is a defined

way for software components to communicate.

In web development, APIs are often used to allow a front end to

communicate with back-end services or external services.

Imagine your weather application.

The front end says:

"Give me today's weather for Delhi."

The API might return structured data:

{
"city": "Delhi",
"temperature": 32,
"condition": "Sunny"
}

JavaScript can then take that data and display:

Delhi
32°C
Sunny

HTTP is commonly used for client-server communication, and

web APIs frequently exchange structured data between systems.

12. API Analogy

Imagine a restaurant.

YOU
↓
Customer

MENU
↓
Available options

WAITER
↓
API

KITCHEN
↓
Back end

STORAGE / INGREDIENTS
↓
Database

You don't walk into the kitchen and start grabbing ingredients.
Instead:

You place an order

↓
Waiter communicates the request
↓
Kitchen processes it
↓
Waiter brings the result

In this analogy:

Browser
↓
API request
↓
Server
↓
Database
↓
Server
↓
API response
↓
Browser

This is simplified but extremely useful.

13. What is a web server?

A web server is responsible for receiving HTTP requests and

returning HTTP responses.

It can refer to the computer or infrastructure hosting the

software, and also to server software that handles web requests.

A web server may deliver resources such as:

 HTML
 CSS
 JavaScript
  Images
 Fonts
 Video

It can also participate in dynamic application processing.

The simplified flow is:

Browser
│
│ HTTP Request
▼
Web Server
│
│ HTTP Response
▼
Browser

A response might have a status code like:

200 OK
404 Not Found
403 Forbidden
500 Internal Server Error

These status codes communicate the result of the request.

14. Front-End Developer vs Web Designer

These roles can overlap, especially in smaller teams, but there is

a useful distinction.

Web designer

A web designer generally focuses more on:

 Visual design
 Layout
 Colour
 Typography
 Branding
 User experience
  Interface structure

They may use tools such as design software or design systems.

Their question might be:

"How should this page look and feel?"

Front-end developer

A front-end developer focuses more on:

 Turning designs into working interfaces

 HTML
 CSS
 JavaScript
 Responsiveness
 Accessibility
 Browser behaviour
 Interactions
 Performance

Their question might be:

"How do I make this design work correctly in the browser?"

The overlap

Modern front-end developers benefit massively from

understanding design principles.

And designers benefit from understanding technical limitations.

You don't have to be a professional UI/UX designer to become a

good front-end developer, but we'll learn enough design thinking
to help you build interfaces that don't look like they were
assembled by a toaster. 😭
15. UI and UX

You will hear these terms constantly.

UI

UI = User Interface

It refers to the interface users interact with.

Examples:

Buttons
Menus
Cards
Forms
Icons
Colours
Typography

UX

UX = User Experience

It is broader.

It considers:

 How easy something is to use

 How users move through the product
 Whether tasks are intuitive
 How errors are handled
 How the product feels to use
 Whether the experience is accessible

Example:

Imagine a beautiful login page.

The button looks amazing.

But when you click it:

Nothing happens.
That's bad UX.

A pretty interface is not enough.

A good product must also work properly.

16. What is DevOps?

You may eventually hear:

"Developer + Operations = DevOps"

The idea is broader than the name suggests.

DevOps involves practices that help teams build, test, deploy,

operate, and monitor software.

This can include:

 Automation
 Continuous integration
 Continuous delivery/deployment
 Infrastructure
 Monitoring
 Deployment processes
 Reliability

Imagine you build a website on your laptop.

That's great.

But how does it become accessible to users?

Your laptop
↓
Code repository
↓
Build process
↓
Deployment
↓
Cloud/server infrastructure
 ↓
Users

DevOps practices help teams manage that journey efficiently

and reliably.

You don't need to become a DevOps engineer to be a front-end

developer, but understanding deployment and basic
infrastructure is extremely valuable.

We'll learn the basics later.

17. What is Cloud?

When developers say:

"It's hosted in the cloud."

They don't mean the website is literally floating in the sky. 😭

Cloud platforms provide computing resources over networks.

These resources may include:

 Servers
 Storage
 Databases
 Networking
 Monitoring
 Content delivery
 Compute services

For a beginner, the simplest mental model is:

Your computer
↓
You write code

Cloud infrastructure
↓
Your application runs online
Users
↓
Access your application

Later, you may encounter cloud platforms and hosting services

such as:

AWS
Microsoft Azure
Google Cloud
Cloudflare
Vercel
Netlify

These platforms have different purposes and architectures, so

don't treat them as interchangeable. We'll explore hosting
separately when we reach deployment.

18. The complete web application

Let's put everything together.

Suppose you're building:

StudyHub

A student opens the application.

Step 1 — Browser

The user visits:

[Link]

The browser loads the front end.

HTML
CSS
JavaScript

Step 2 — Front end

The user sees:

Welcome back, Bro!

Continue learning

HTML 90%
CSS 62%
JavaScript 20%

The front end handles:

 Layout
 Colours
 Buttons
 Navigation
 Interactions

Step 3 — API request

JavaScript asks the server:

GET /api/progress

Step 4 — Back end

The server receives the request.

It checks:

Who is this user?

Is the user authenticated?
What data should this user be allowed to access?

Step 5 — Database

The server requests:

Give me the student's progress.

The database returns data.

HTML → 90
CSS → 62
JS → 20

Step 6 — API response

The back end sends data:

{
"html": 90,
"css": 62,
"javascript": 20
}

Step 7 — Front end updates

JavaScript receives the data.

The page displays:

HTML 90%
CSS 62%
JavaScript 20%

19. The complete architecture

Here is the mental model I want you to remember:

USER
│
▼
WEB BROWSER
│
│
FRONT END
HTML + CSS + JavaScript
│
│ HTTP/API request
▼
BACK END
Server + Application Logic
│
┌────────────┴────────────┐
│ │
▼ ▼
 DATABASE APIs
│ │
└────────────┬────────────┘
│
▼
SERVER / CLOUD
│
▼
USER

This is simplified, but this mental map will be incredibly useful

throughout the course.

20. A real-world example: YouTube-like platform

Imagine a video platform.

Front end

Homepage
Video player
Search bar
Subscribe button
Comments
Recommended videos

Technologies might include:

HTML
CSS
JavaScript

possibly with a JavaScript framework.

Back end

Handles:

Accounts
Authentication
Subscriptions
Comments
Recommendations
Video metadata
Permissions

Database

Stores:

Users
Videos
Comments
Subscriptions
Playlists
Watch history

APIs

Allow the front end to request:

Video information
User profile
Comments
Recommendations
Search results

Infrastructure

Handles:

Servers
Storage
Traffic
Deployment
Monitoring
Scaling

Developer roles

A large organisation might have:

UI/UX Designers
Front-End Developers
Back-End Developers
Full-Stack Developers
Database Engineers
Cloud Engineers
DevOps Engineers
Security Engineers
QA/Test Engineers
Accessibility Specialists

At a small company, one person might handle several of these

responsibilities.

At a huge company, they might be separate specialised teams.

21. Where you fit into this course

Right now, you're starting here:

YOU
│
▼
WEB FUNDAMENTALS
│
▼
HTML
│
▼
CSS
│
▼
JavaScript
│
▼
DOM + APIs
│
▼
Responsive Design
│
 ▼
Accessibility
│
▼
Git + GitHub
│
▼
Deployment
│
▼
Backend Concepts
│
▼
Full-Stack Basics
│
▼
Frameworks

Our initial target is front-end development.

Once you become strong there, we can branch into:

Front-end
│
├── React
│
├── TypeScript
│
├── Advanced Web APIs
│
└── Performance

Back-end
│
├── [Link]
├── Express
├── APIs
├── Databases
└── Authentication

That will give you a path toward full-stack development.

22. One very important concept: "The browser is not the whole
application"

Suppose you build:

<h1>Hello World</h1>

That's a front-end page.

Now suppose you build:

Login
↓
Database
↓
Personal dashboard
↓
Save progress
↓
Upload assignment
↓
Teacher review

You've moved into a much larger system.

This is why we are learning Phase 0.

You should be able to look at any web product and mentally ask:

What runs in the browser?

What runs on the server?

Where is the data stored?

How does the browser communicate with the server?

How does the application know who the user is?

How does the application protect the data?

How does the application get deployed?

You don't need to know all the answers yet.

But you should know which questions to ask.

That's developer thinking.

23. The most important comparison

Memorise this mental model:

FRONT END
"What the user sees and interacts with"

BACK END
"What processes requests and runs application logic"

DATABASE
"Where persistent application data is stored"

API
"How software components communicate"

SERVER
"Where server-side software runs and responds to requests"

CLOUD / INFRASTRUCTURE
"Systems that host, deliver, scale and operate applications"

FULL STACK
"Working across the front end and back end"

24. Cheat Sheet

Developer types

Role Primary focus

Web Designer Visual design and user experience
 Role Primary focus
UI Designer Interface appearance and interaction design
UX Designer User experience and usability
Front-End
Browser-facing implementation
Developer
Back-End
Server-side systems and application logic
Developer
Full-Stack
Front end + back end
Developer
Database Engineer Data storage and database systems
Delivery, automation, infrastructure and
DevOps Engineer
operations
Cloud Engineer Cloud infrastructure and services
QA/Test Engineer Software quality and testing
Security Engineer Application and infrastructure security

These aren't perfectly standardised job definitions; companies

often combine or split responsibilities differently.

25. Technology map

WEB DEVELOPMENT
│
┌────────────────┴────────────────┐
│ │
▼ ▼
FRONT END BACK END
│ │
HTML + CSS Server-side code
JavaScript Application logic
DOM APIs
Browser APIs Authentication
Accessibility Database access
Responsive UI Business rules
│ │
└──────────────┬──────────────────┘
│
▼
FULL STACK

And around the system:

Database
+
Cloud
+
DevOps
+
Security
+
Testing
+
Monitoring

26. Flashcards

Flashcard 1

Front: What is front-end development?

Back: Development of the user-facing parts of a web product,
primarily experienced in the browser.

Flashcard 2

Front: What are the three foundational front-end technologies?

Back: HTML, CSS, and JavaScript.

Flashcard 3

Front: What does HTML do?

Back: Structures and gives meaning to web content.

Flashcard 4

Front: What does CSS do?

Back: Controls presentation, styling, and layout.

Flashcard 5

Front: What does JavaScript do?

Back: Adds programming logic and interactivity to web
experiences.

Flashcard 6
Front: What is back-end development?
Back: Development of server-side systems and application logic
that support the web application.

Flashcard 7

Front: What does a database do?

Back: Stores and manages persistent data.

Flashcard 8

Front: What is an API?

Back: A defined interface that allows software components to
communicate.

Flashcard 9

Front: What is a full-stack developer?

Back: A developer who works across both front-end and back-
end parts of an application.

Flashcard 10

Front: What is a tech stack?

Back: The collection of technologies used to build and operate a
software product.

Flashcard 11

Front: What is UI?

Back: User Interface—the elements users interact with.

Flashcard 12

Front: What is UX?

Back: User Experience—the overall quality, usability, and
experience of using a product.

Flashcard 13

Front: Where does front-end code primarily run?

Back: In the user's browser.

Flashcard 14
Front: Where does back-end code primarily run?
Back: On servers or server-side runtimes.

Flashcard 15

Front: What does DevOps broadly concern itself with?

Back: Practices and tooling for building, delivering, deploying,
operating, and monitoring software.

27. Lesson Test

No peeking. 😎

Section A — Multiple choice

1. Which technology is primarily used to structure

webpage content?

A. CSS
B. HTML
C. SQL
D. DNS

2. Which is most associated with front-end development?

A. Browser interface
B. Database indexing
C. Server infrastructure
D. Database backups

3. Which is most associated with back-end development?

A. Button colour
B. Page typography
C. Authentication logic
D. Font size

4. What does a database primarily provide?

A. Persistent data storage

B. Website colours
C. Browser tabs
D. Network cables

5. What does an API commonly provide?

A. A way for software components to communicate

B. A replacement for HTML
C. A type of monitor
D. A CSS selector

6. What does full-stack generally mean?

A. Only CSS development

B. Working across front-end and back-end development
C. Only database design
D. Only cloud hosting

7. Which technology can run in the browser and, through

environments like [Link], outside the browser?

A. HTML
B. CSS
C. JavaScript
D. SQL

Section B — True or false

8. Front-end development is only about making websites look

pretty.
9. Back-end code can interact with databases.
10. A full-stack developer must know every programming
language.
11. A web application can use an API to obtain data.
12. The database normally handles the visual layout of the
website.
13. HTML, CSS, and JavaScript are foundational web
technologies.
14. The front end and back end can communicate through
HTTP-based APIs.
15. A developer can specialise in one part of the stack.
Section C — Explain

16. Explain front-end development in your own words.

17. Explain back-end development in your own words.
18. What is the difference between front-end and back-
end?
19. What is the job of a database?
20. What is an API?
21. What is the difference between a web designer and
front-end developer?
22. What is the difference between UI and UX?
23. What does "full-stack" mean?

28. Scenario challenge

Imagine you are building:

STUDY PROGRESS APP

The application allows a student to:

Create account
Log in
See courses
Track progress
Take quizzes
View scores

Now classify each responsibility:

A.

Designing the "Log In" button.

Front end / Back end / Database / API

B.

Checking whether a username and password are valid.

Front end / Back end / Database / API

C.

Storing the student's quiz score.

Front end / Back end / Database / API

D.

Sending quiz-score data from server to browser.

Front end / Back end / Database / API

E.

Changing the score display from 80% to 85% after receiving new
data.

Front end / Back end / Database / API

F.

Creating the layout and colours of the dashboard.

Front end / Back end / Database / API

29. Final Practical — Draw Your First Architecture

Create a simple diagram for an imaginary:

Online School Management System

Include:

Student
Teacher
Browser
Front End
Back End
API
Database

Your diagram should show the direction of communication.

For example:

Student
↓
Browser
↓
Front End
↓
API
↓
Back End
↓
Database

Then add the reverse flow:

Database
↓
Back End
↓
API
↓
Front End
↓
Browser
↓
Student

Finally, add one example of data moving through the system:

Student clicks "View Marks"

↓
Browser sends request
↓
Back end receives request
↓
Database returns marks
↓
Back end sends response
↓
Front end displays marks
This exercise is very important because it combines
everything we've learned in Lessons 0.1–0.3.

Your Phase 0 mental map so far

You should now be able to think like this:

INTERNET
│
▼
WEBSITE
│
┌──────────┴──────────┐
│ │
▼ ▼
FRONT END BACK END
│ │
HTML/CSS/JS Server-side code
│ │
▼ ▼
BROWSER APIs + Logic
│
▼
DATABASE

And the biggest thing I want you to understand is this:

HTML, CSS, and JavaScript are not "the entire internet"

or even "the entire web-development world." They are
the foundation of the browser-facing part of web
development.

Once you master them, you'll have the foundation needed to

understand everything that comes later.

MDN's current learning path similarly treats front-end

fundamentals as a structured foundation before learners move
into extensions such as client-side APIs, tooling, and server-side
development.

-------------------------------------X------------------------------------------

Lesson 0.4

The HTML + CSS + JavaScript Triangle

Bro, this is a big one. This is the lesson where the three
technologies stop feeling like three random things and start
becoming one system.
You've already learned:

 0.1: How the internet and web work

 0.2: Webpages, websites, web apps, static/dynamic sites
 0.3: Front end, back end, databases, APIs, full stack

Now we're going to understand:

How HTML, CSS, and JavaScript actually cooperate inside

the browser.

We will cover:

1. What HTML really does

2. What CSS really does
3. What JavaScript really does
4. Why we separate them
5. What the browser does with your files
6. What the DOM is
7. What CSSOM is
8. How a browser turns code into pixels
9. How JavaScript interacts with the DOM
10. The difference between source code and the DOM
11. Inline, internal, and external CSS
12. Inline, internal, and external JavaScript
13. Modern best practices
14. Your first proper three-file website
15. Practical exercises
16. Cheat sheet
17. Flashcards
18. Test

1. The HTML + CSS + JavaScript Triangle

Let's start with the most important diagram in our entire course:

WEB PAGE
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
 HTML CSS JavaScript
│ │ │
▼ ▼ ▼
Structure Style Behaviour
Meaning Layout Interaction
│ │ │
└─────────────┼─────────────┘
│
▼
BROWSER
│
▼
USER

A useful beginner mental model is:

HTML → What exists?

CSS → How does it look?
JavaScript → What does it do?

MDN's current web-standards curriculum describes the same

separation at a high level: HTML provides structure and
semantics, CSS handles styling and layout, and JavaScript
controls dynamic behaviour. HTML itself is the web's core
markup language, while CSS is a stylesheet language for
describing presentation.

2. HTML — The Structure and Meaning

HTML stands for:

HyperText Markup Language

HTML is a markup language, not a general-purpose

programming language.

Its main job is to describe:

 Headings
 Paragraphs
 Links
  Images
 Lists
 Forms
 Tables
 Articles
 Navigation
 Sections
 Buttons
 Other document content

For example:

<h1>My Website</h1>

<p>Welcome to my website.</p>

<a href="[Link] Example</a>

HTML tells the browser:

This is a heading.
This is a paragraph.
This is a link.

It gives content structure and meaning.

That "meaning" part is incredibly important.

Compare:

<div>Click here</div>

with:

<button>Click here</button>

They might be visually styled to look identical.

But semantically, they are different.

The second one tells the browser:

This is a button.

That matters for:

  Accessibility
 Keyboard interaction
 Assistive technologies
 Browser behaviour
 Maintainability
 Search engines and document structure

The HTML Living Standard continues to define HTML as the core

markup language of the web, with semantics, document
structure, elements, and web APIs all covered by the standard.

So our first rule is:

Use HTML to describe what something is, not merely

what it looks like.

3. CSS — The Presentation and Layout

CSS stands for:

Cascading Style Sheets

CSS describes how HTML elements should be presented.

For example:

h1 {
color: blue;
font-size: 40px;
}

HTML:

<h1>Hello</h1>

CSS:

h1 {
color: blue;
}

The result:
Hello

The HTML says:

"This is a heading."

The CSS says:

"Display that heading with this appearance."

CSS controls things such as:

 Colours
 Fonts
 Text size
 Spacing
 Borders
 Shadows
 Layout
 Flexbox
 Grid
 Responsive design
 Transitions
 Animations

MDN describes CSS as a language for styling and laying out web
pages, including properties such as fonts, colours, sizes,
spacing, columns, and animations. CSS is now developed as a
collection of modules rather than a single monolithic "CSS3"
version.

Think of it like this:

HTML
↓
"Here is a button."

CSS
↓
"Make it blue, rounded, and 200px wide."
4. JavaScript — Behaviour and Logic

JavaScript is a programming language widely used to make web

pages interactive.

It can respond to:

 Clicks
 Keyboard input
 Mouse actions
 Form submissions
 Timers
 Network responses
 Other browser events

It can also modify the document and communicate with web

APIs. JavaScript is also used outside the browser in environments
such as [Link].

Imagine this HTML:

<button id="helloButton">Click me</button>

Without JavaScript, the button exists.

With JavaScript:

const button = [Link]("#helloButton");

[Link]("click", () => {
alert("Hello!");
});

Now the button does something.

The flow is:

User clicks button

↓
Browser detects click
↓
JavaScript event handler runs
↓
alert() executes
 ↓
User sees message

So:

HTML → Button exists

CSS → Button looks good
JavaScript → Button responds

5. The Three-Layer Architecture

A common conceptual model is to think of a webpage as three

layers.

┌───────────────────────────────┐
│ HTML │
│ Structure + Semantics │
├───────────────────────────────┤
│ CSS │
│ Presentation + Layout │
├───────────────────────────────┤
│ JavaScript │
│ Behaviour + Interaction │
└───────────────────────────────┘

Let's build a simple card.

HTML

<article class="card">
<h2>Learn Web Development</h2>
<p>Start learning HTML, CSS, and JavaScript.</p>
<button>Start Learning</button>
</article>

HTML defines:

Article
├── Heading
├── Paragraph
└── Button
CSS

.card {
padding: 24px;
border-radius: 16px;
box-shadow: 0 8px 24px rgb(0 0 0 / 10%);
}

CSS defines the presentation.

JavaScript

const button = [Link]("button");

[Link]("click", () => {
alert("Let's start learning!");
});

JavaScript defines the interaction.

6. Why Separate HTML, CSS and JavaScript?

You can write everything in one file.

But large projects become difficult to maintain when structure,

styling, and behaviour are mixed unnecessarily.

Imagine this:

<button
style="background: blue; color: white; padding: 10px;"
onclick="alert('Hello')"
>
Click me
</button>

This works.

But now imagine:

500 buttons
50 pages
20 different interactions

You'd quickly end up with a maintenance nightmare.

Instead:

HTML
↓
Structure

CSS
↓
Styling

JavaScript
↓
Behaviour

This separation creates a cleaner mental and technical

architecture.

It also lets you:

 Change the design without rewriting HTML

 Change behaviour without rewriting styles
 Reuse CSS
 Reuse JavaScript
 Debug more easily
 Keep projects organised

The separation is not absolute—modern applications sometimes

generate markup or styles through JavaScript—but
understanding the separation is foundational and useful. MDN's
curriculum explicitly teaches the three technologies as distinct
core layers.

7. The Browser Is the Interpreter of Your Web Technologies

Here's a key concept.

You write:
HTML
CSS
JavaScript

The browser takes those resources and processes them to

create the webpage the user sees.

Simplified:

Your Files
│
├── HTML
├── CSS
└── JavaScript
│
▼
Browser
│
├── Parse HTML
├── Build DOM
├── Parse CSS
├── Build CSSOM
├── Run JavaScript
├── Calculate layout
├── Paint
└── Composite
│
▼
Pixels on Screen

The browser's rendering pipeline is more complicated than this

diagram, but the core idea is correct. MDN describes the critical
rendering path as the sequence used to turn HTML, CSS, and
JavaScript into pixels, involving structures such as the DOM,
CSSOM, render tree, and layout.

Now let's understand each part.

8. What Happens When the Browser Loads HTML?

Suppose your HTML is:

<!doctype html>

<html>
<body>
<h1>Hello</h1>
<p>Welcome!</p>
</body>
</html>

The browser reads and parses the HTML.

It creates a tree-like representation called the:

DOM — Document Object Model

A simplified DOM might look like:

Document
└── html
└── body
├── h1
│ └── "Hello"
│
└── p
└── "Welcome!"

This is a tree structure.

Each element can have:

 A parent
 Children
 Siblings
 Descendants
 Attributes

The browser's DOM represents the HTML document as a

hierarchy of nodes. The DOM API then provides ways to access
and manipulate that document programmatically.
9. Understanding the DOM

Let's take:

<body>
<h1>Hello</h1>

<p>Welcome</p>
</body>

The DOM relationship is:

body
├── h1
│ └── "Hello"
│
└── p
└── "Welcome"

Here:

body

is the parent of:

h1
p

And:

h1
p

are siblings.

The text:

"Hello"

is a child node associated with the <h1> element.

You don't need to memorise every DOM node type right now.

Just understand this:

The DOM is the browser's structured representation of
the document that JavaScript can interact with.

10. Source HTML vs DOM

This is a subtle but important concept.

Your original HTML source might be:

<p>Hello</p>

But JavaScript can change the document:

[Link]("p").textContent = "Goodbye";

Now the browser's current DOM represents:

<p>Goodbye</p>

Your original source file may still contain:

<p>Hello</p>

So:

HTML source
↓
Starting point

DOM
↓
Current document representation

This distinction becomes very useful when debugging.

When you inspect a page using browser developer tools, you are
often looking at the current DOM, which may have been
modified after the original HTML loaded.
11. CSSOM — The CSS Object Model

The browser also needs to understand CSS.

Suppose you have:

h1 {
color: blue;
font-size: 40px;
}

The browser parses the CSS and creates an internal

representation commonly referred to as the CSSOM, or CSS
Object Model.

At a high level:

HTML
↓
DOM

CSS
↓
CSSOM

The browser uses these structures together to determine how

content should be rendered.

The critical rendering process includes the DOM and CSSOM as

inputs to later rendering stages.

You do not need to become an expert in CSSOM today.

Just remember:

DOM → Structure of document

CSSOM → Representation of CSS rules

12. DOM + CSSOM

Imagine:

HTML:
<h1>Hello</h1>

CSS:

h1 {
color: blue;
}

Conceptually:

HTML
↓
DOM
↓

h1
└── "Hello"

CSS
↓
CSSOM
↓

h1
└── color: blue

The browser combines information from the document and

styles to determine how things should appear.

13. The Rendering Pipeline

Let's simplify what happens next.

HTML
↓
DOM
↓
CSS
↓
CSSOM
 ↓
Render information
↓
Layout
↓
Paint
↓
Composite
↓
Screen

Let's understand these terms.

Step 1 — DOM construction

The browser processes HTML and creates the DOM.

HTML
↓
DOM

Step 2 — CSS processing

The browser processes CSS.

CSS
↓
CSSOM

Step 3 — Determine what to render

The browser combines the document structure and applicable

styles.

Not every DOM node necessarily becomes something visually

painted in the same way. For example, some elements or nodes
may not produce visible pixels.
Step 4 — Layout

The browser calculates:

 Positions
 Widths
 Heights
 Relationships between elements

Imagine:

Header
↓
Main content
↓
Footer

The browser figures out where each piece goes.

Step 5 — Paint

The browser determines which visual elements need to be

drawn:

 Text
 Backgrounds
 Borders
 Shadows
 Images

Step 6 — Composite

The browser combines rendered pieces into the final visual

output.

The exact internals vary across browsers and rendering engines,

so don't treat this simplified pipeline as a literal one-to-one
implementation diagram. But the DOM/layout/paint model is a
useful foundation for understanding rendering and performance.
14. Where Does JavaScript Fit?

JavaScript can interact with the DOM.

Example:

<h1 id="title">Hello</h1>

JavaScript:

const title = [Link]("#title");

[Link] = "Welcome!";

Before:

Hello

After:

Welcome!

The JavaScript changed the DOM.

The browser can then update what the user sees.

This is the basic idea behind dynamic interfaces.

MDN's DOM scripting material specifically covers selecting DOM

nodes, creating/removing nodes, modifying attributes, and
manipulating styles with JavaScript.

15. The Real Power of JavaScript

JavaScript can do much more than change text.

Imagine:

<button id="countButton">
Clicked: 0
</button>
JavaScript:

let count = 0;

const button = [Link]("#countButton");

[Link]("click", () => {
count++;
[Link] = `Clicked: ${count}`;
});

Now:

Initial:
Clicked: 0

Click

Clicked: 1

Click

Clicked: 2

Click

Clicked: 3

The interaction cycle is:

User action
↓
Browser event
↓
JavaScript runs
↓
JavaScript changes state
↓
JavaScript updates DOM
↓
Browser updates visual output
This cycle appears everywhere in modern web applications.

16. What is an Event?

An event is something that happens in the browser that code

can respond to.

Examples include:

click
input
submit
keydown
keyup
pointerover
focus
blur
change

For example:

[Link]("click", () => {
[Link]("Button clicked!");
});

The code says:

"When this button receives a click event, execute this function."

This is called an event listener.

We'll study events deeply later.

For now:

Event
↓
Something happened

Event listener
↓
Code that reacts to it
17. The Three Technologies Working Together

Let's make a mini application.

HTML

<h1 id="message">Hello</h1>

<button id="changeButton">
Change Message
</button>

CSS

h1 {
color: darkblue;
}

button {
padding: 10px 16px;
}

JavaScript

const message = [Link]("#message");

const button = [Link]("#changeButton");

[Link]("click", () => {
[Link] = "You clicked the button!";
});

The architecture:

HTML
↓
Creates heading + button

CSS
↓
Styles heading + button
JavaScript
↓
Finds heading + button
↓
Waits for click
↓
Changes heading

That is the web-development triangle in action.

18. Inline, Internal and External CSS

There are three common ways to add CSS.

Method 1 — Inline CSS

<h1 style="color: red;">

Hello
</h1>

The style is directly on the element.

Advantages

Simple for tiny experiments.

Disadvantages

Hard to maintain.

Not reusable.

Can make HTML messy.

We generally avoid using inline styles for normal project styling.

Method 2 — Internal CSS

<!doctype html>
<html>
<head>
<style>
h1 {
color: red;
}
</style>
</head>

<body>
<h1>Hello</h1>
</body>
</html>

CSS is written inside <style>.

This can be useful for small, single-document examples.

Method 3 — External CSS

HTML:

<link rel="stylesheet" href="[Link]">

CSS:

h1 {
color: red;
}

This is generally the cleanest approach for multi-file projects

because the stylesheet can be reused across multiple pages.

For our projects, we'll primarily use:

HTML
+
External CSS
+
External JavaScript
19. Inline, Internal and External JavaScript

Similar concept.

Inline JavaScript

<button onclick="alert('Hello')">
Click
</button>

This works but mixes HTML and JavaScript.

We generally avoid this approach for larger projects.

Internal JavaScript

<script>
[Link]("Hello");
</script>

Useful for small examples.

External JavaScript

<script src="[Link]"></script>

Then:

[Link]("Hello");

We will primarily use external JavaScript files.

20. Your First Proper Three-File Project

Now we're moving from theory to reality.

Create a folder:

my-first-site
Inside it:

my-first-site/
│
├── [Link]
├── [Link]
└── [Link]

This is your first proper front-end project structure.

21. Step 1 — [Link]

Create:

[Link]

Add:

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">

<meta
name="viewport"
content="width=device-width, initial-scale=1.0"
>

<title>My First Website</title>

<link rel="stylesheet" href="[Link]">

<script src="[Link]" defer></script>

</head>

<body>
<main class="container">
<h1 id="title">Welcome to My Website</h1>

<p id="message">
I am learning HTML, CSS, and JavaScript.
 </p>

<button id="changeButton" type="button">

Change Message
</button>
</main>
</body>
</html>

Let's understand the important parts.

The CSS connection

<link rel="stylesheet" href="[Link]">

This tells the browser to load the external stylesheet:

[Link]

The browser now has:

[Link]
+
[Link]

The JavaScript connection

<script src="[Link]" defer></script>

This loads the external JavaScript file.

The defer attribute tells the browser to defer script execution

until the HTML document has been parsed; deferred external
scripts execute in document order and before
DOMContentLoaded. This is a common modern approach for
scripts that need to interact with the document.

So:

<script src="[Link]" defer></script>

is often preferable for beginner projects over immediately
placing a normal script in the <head> and then wondering why
elements don't exist yet when the script runs.

22. Step 2 — [Link]

Create:

[Link]

Add:

*{
box-sizing: border-box;
}

body {
margin: 0;
min-height: 100vh;
display: grid;
place-items: center;
font-family: system-ui, sans-serif;
background: #f5f7fb;
}

.container {
width: min(90%, 600px);
padding: 32px;
text-align: center;
background: white;
border-radius: 16px;
box-shadow: 0 10px 30px rgb(0 0 0 / 10%);
}

h1 {
margin-top: 0;
}

button {
padding: 12px 20px;
 border: 0;
border-radius: 8px;
font: inherit;
cursor: pointer;
}

button:hover {
opacity: 0.85;
}

Boom.

Your page now has styling.

Let's break down a few things.

box-sizing

*{
box-sizing: border-box;
}

We'll learn the box model properly during our CSS phase.

For now, this is a commonly useful baseline.

min-height

min-height: 100vh;

The vh unit represents a viewport-related length. Here we're

making the body at least as tall as the viewport.

display: grid

display: grid;

This enables CSS Grid layout.

We will study Grid deeply later.

place-items

place-items: center;
This centers the content in both relevant directions for the grid
container.

width: min(...)

width: min(90%, 600px);

This uses CSS's min() function.

The container will use the smaller of:

90% of available width

600px

This is a nice example of modern CSS functionality without

needing complicated media queries.

23. Step 3 — [Link]

Create:

[Link]

Add:

const title = [Link]("#title");

const message = [Link]("#message");
const button = [Link]("#changeButton");

[Link]("click", () => {
[Link] = "Great job! 🎉";

[Link] =
"You just connected HTML, CSS, and JavaScript!";
});

Let's break this down.

Selecting an element

const title = [Link]("#title");

The HTML is:

<h1 id="title">

The CSS selector:

#title

means:

Find the element whose id is title.

The browser returns a reference to that element.

We store it in:

title

Selecting the message

const message = [Link]("#message");

This finds:

<p id="message">

Selecting the button

const button = [Link]("#changeButton");

This finds:

<button id="changeButton">

Adding an event listener

[Link]("click", () => {

This says:

When button receives a click event, execute the function.

The function is:

() => {
[Link] = "Great job! 🎉";

[Link] =
"You just connected HTML, CSS, and JavaScript!";
}

24. The Complete Flow

When you open:

[Link]

the browser loads:

[Link]
│
├──────────────┐
│ │
▼ ▼
[Link] [Link]
│ │
│ ▼
│ JavaScript
│ │
│ ▼
│ DOM
│ │
└───────┬──────┘
│
▼
Rendered Page

You see:

Welcome to My Website

I am learning HTML, CSS, and JavaScript.

[ Change Message ]

You click:
[ Change Message ]

JavaScript runs:

[Link] = "Great job! 🎉";

and:

[Link] =
"You just connected HTML, CSS, and JavaScript!";

The page changes.

No full page reload is necessary for this DOM update.

That's the magic of client-side JavaScript.

25. What Exactly Did We Build?

We built a tiny interactive web application.

HTML
↓
Created the interface

CSS
↓
Styled the interface

JavaScript
↓
Added behaviour

And more specifically:

User
↓
Clicks button
↓
Browser generates click event
↓
JavaScript event listener runs
 ↓
JavaScript modifies DOM
↓
Browser updates rendering

This is one of the most fundamental patterns in front-end

development.

26. The Separation of Responsibilities

Our project now looks like this:

[Link]
│
├── Content
├── Structure
├── Semantics
└── References external resources

[Link]
│
├── Colours
├── Typography
├── Spacing
├── Layout
└── Visual appearance

[Link]
│
├── Select elements
├── Listen for events
├── Change content
└── Control behaviour

That's clean.

Imagine the website has 50 pages.

You could potentially reuse:

[Link]

across many of them.

You could also reuse JavaScript modules where appropriate.

That's the power of separating concerns.

27. One Big Warning: JavaScript Is Not "Magic"

When beginners see:

[Link]("#message")

they sometimes think:

"JavaScript somehow knows my HTML."

Nope.

There's a whole chain:

HTML file
↓
Browser parses HTML
↓
DOM is created
↓
JavaScript accesses DOM
↓
JavaScript finds #message

So when you write:

[Link]("#message")

you're effectively saying:

"Browser, please give me the element in the document that

matches this CSS selector."

That's why understanding the DOM matters.

28. CSS Selectors and JavaScript Selectors

This is a cool connection.

CSS:

#message {
color: blue;
}

JavaScript:

[Link]("#message");

Both use the selector:

#message

You can also select classes.

HTML:

<p class="text">Hello</p>

CSS:

.text {
color: green;
}

JavaScript:

[Link](".text");

This means your HTML, CSS, and JavaScript can communicate

using common identifiers and selectors.

We'll study selectors properly in the CSS phase.

29. The DOM Is Live

Suppose you have:

<p id="message">Hello</p>

JavaScript:

const message = [Link]("#message");

[Link] = "Goodbye";

The browser's document is now:

<p id="message">Goodbye</p>

The JavaScript changed the current document representation.

This is the foundation for things like:

 Modal windows
 Dropdown menus
 Tabs
 Accordions
 Interactive forms
 Shopping carts
 Dashboards
 Live counters
 Interactive games

The DOM API exists specifically to represent and manipulate

document structure and related browser features.

30. What Happens If CSS Is Disabled?

Imagine:

HTML ✅
CSS ❌
JavaScript ✅

The page may still have:

 Headings
 Paragraphs
 Links
  Buttons
 Forms

But the visual presentation will be much more basic.

This demonstrates an important principle:

HTML should provide meaningful content and structure

independent of visual decoration.

31. What Happens If JavaScript Is Disabled?

Imagine:

HTML ✅
CSS ✅
JavaScript ❌

Some pages will still work perfectly.

Others may lose:

 Menus
 Dynamic interactions
 Client-side validation
 Data loading
 Application functionality

This leads to a broader concept we'll study later:

Build the fundamental document correctly, then enhance it with

CSS and JavaScript.

This approach is often described as progressive

enhancement.

It is particularly valuable for accessibility, resilience,

performance, and graceful handling of different browsing
environments.
32. Progressive Enhancement

Imagine building a form.

Layer 1 — HTML

<form>
<label for="email">Email</label>
<input id="email" type="email">
<button type="submit">Subscribe</button>
</form>

The basic structure exists.

Layer 2 — CSS

You make it beautiful.

HTML
+
CSS

Layer 3 — JavaScript

You add:

Instant validation
Loading state
Success message
Animation
API submission

The model becomes:

HTML
↓
Basic functionality
↓
CSS
↓
Better presentation
↓
JavaScript
↓
Enhanced interaction

That's a powerful way to think.

33. Why We Use Semantic HTML

Imagine two versions.

Version A

<div onclick="openMenu()">
Menu
</div>

Version B

<button type="button">
Menu
</button>

Version B communicates its purpose more clearly.

HTML provides semantic meaning, and the standard includes

elements designed for different structural and interactive roles.
Good semantics support accessibility and help browsers and
other technologies interpret the document.

As we progress, you'll learn to ask:

"What is this element?"

rather than:

"How do I make this element look like this?"

That's the mindset of good HTML.

34. A Website as a Restaurant

Here's another analogy that actually works quite well.

Imagine:

HTML
↓
The restaurant's structure
Tables
Kitchen
Menu
Entrance

CSS
↓
Interior design
Colours
Lighting
Furniture
Spacing

JavaScript
↓
The behaviour
Ordering
Interactions
Notifications
Dynamic menu updates

The customer sees the final restaurant.

But the structure, appearance, and behaviour are separate

concepts.

The same thing happens in web development.

35. A Website as a Human

Another classic analogy:

HTML
↓
Skeleton

CSS
↓
Appearance / clothing

JavaScript
↓
Behaviour / actions

It's not technically perfect, but it's excellent for remembering

the roles.

I prefer the restaurant analogy for architecture and the

human-body analogy for memory.

36. Modern Best Practices We're Already Starting With

For this course, we'll generally follow these principles.

Use semantic HTML

Prefer:

<header>
<nav>
<main>
<section>
<article>
<footer>

when they accurately represent the content.

Keep styling in CSS

Prefer:

.card {
padding: 20px;
}

instead of spreading styles throughout HTML.

Keep behaviour in JavaScript

Prefer:

[Link]("click", handleClick);

rather than putting large chunks of behaviour into HTML

attributes.

Use external files for larger projects

[Link]
[Link]
[Link]

Use defer for simple external scripts

<script src="[Link]" defer></script>

when the script is intended to run after HTML parsing.

Write accessible HTML from the beginning

Use:

 Proper headings
 Labels for form fields
 Semantic buttons
 Meaningful link text
 Keyboard-friendly interactions

We'll explore accessibility properly later.

37. Your First Debugging Exercise

Open your project.

Open Developer Tools:

F12

or:
Ctrl + Shift + I

Go to:

Elements

Find:

<h1 id="title">

Now change the text directly in Developer Tools.

For example:

Welcome to My Website

to:

Hello, Browser!

Notice what happens.

Your actual [Link] file has not necessarily changed.

You have changed the current DOM inside the browser's page.

Now refresh the page.

What happens?

The change disappears.

Why?

Because:

Original file
↓
Browser loads it again
↓
Original DOM reconstructed

This is a perfect demonstration of:

Source file ≠ Current DOM

38. Your First JavaScript Console Experiment

Open Developer Tools.

Go to:

Console

Type:

[Link]("#title")

You should get a reference to the heading element.

Now try:

[Link]("#title").textContent

You should get the heading's current text.

Now try:

[Link]("#title").textContent = "I changed the

page!";

Your webpage should change immediately.

You just manually used JavaScript to manipulate the DOM.

No framework.

No React.

No Vue.

No Angular.

Just the web platform itself.

That foundation is extremely important.

39. Your First Challenge

Modify the project so the button cycles through three messages.

Start:

I am learning web development.

First click:

HTML gives pages structure.

Second click:

CSS makes pages beautiful.

Third click:

JavaScript makes pages interactive.

Then repeat from the first message.

Hint

You will need:

let index = 0;

An array:

const messages = [
"I am learning web development.",
"HTML gives pages structure.",
"CSS makes pages beautiful.",
"JavaScript makes pages interactive."
];

Then use:

index++;

and:

index = index % [Link];

We'll explain arrays and variables properly during the JavaScript

phase, so it's perfectly okay if this doesn't make complete sense
yet.

For now, treat it as a guided preview of things you'll learn.

40. Bonus Challenge — Change the Page Theme

Add a second button:

<button id="themeButton" type="button">

Toggle Theme
</button>

When clicked, the page should switch between:

Light mode

and:

Dark mode

One beginner-friendly approach will eventually involve

JavaScript adding/removing a CSS class.

For example:

[Link]("dark");

and CSS:

[Link] {
background: #111;
color: white;
}

Don't worry if [Link]() is new.

This is a preview of the DOM and CSS interaction we'll study

deeply later.

41. Cheat Sheet

HTML

Purpose:
Structure + semantics
Common file:
.html

Examples:
<h1>
<p>
<a>
<img>
<button>
<form>
<header>
<main>
<footer>

CSS

Purpose:
Styling + layout

Common file:
.css

Examples:
color
background
margin
padding
font-size
display
flex
grid
position

JavaScript

Purpose:
Logic + behaviour + interaction

Common file:
.js

Examples:
variables
functions
events
DOM manipulation
fetch()
arrays
objects
conditions
loops

DOM

Full name:
Document Object Model

Purpose:
Browser representation of document structure

Used by:
JavaScript

CSSOM

Full name:
CSS Object Model

Purpose:
Browser's representation of CSS information

Basic relationship

HTML
↓
DOM

CSS
↓
CSSOM

JavaScript
↓
Can interact with DOM and browser APIs

DOM + CSSOM + rendering process

↓
Visual output

42. The One Diagram to Memorise

USER
│
▼
WEB BROWSER
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
HTML CSS JavaScript
│ │ │
▼ ▼ ▼
DOM CSSOM Events
│ │ │
└───────────┼───────────┘
│
▼
Rendering Process
│
▼
Pixels on Screen
│
▼
USER

And interaction:

User action
↓
Browser event
↓
JavaScript
↓
DOM changes
↓
Browser renders updated state
↓
User sees result

That second diagram is basically the foundation of interactive

front-end development.

43. Flashcards

Flashcard 1

Front: What is HTML used for?

Back: Structure and semantic meaning of web content.

Flashcard 2

Front: What is CSS used for?

Back: Styling and layout.

Flashcard 3

Front: What is JavaScript used for?

Back: Programming logic, dynamic behaviour, and interactivity.

Flashcard 4

Front: What is DOM?

Back: The browser's object-based representation of the
document structure.

Flashcard 5

Front: What is CSSOM?

Back: A representation of CSS information used by the browser.

Flashcard 6
Front: What does querySelector() do?
Back: Finds the first element matching a CSS selector.

Flashcard 7

Front: What does addEventListener() do?

Back: Registers code to run when a specified event occurs.

Flashcard 8

Front: What is an event?

Back: Something that happens in the browser that JavaScript
can respond to.

Flashcard 9

Front: What does textContent do?

Back: Gets or sets the text content of a DOM node.

Flashcard 10

Front: What is external CSS?

Back: CSS stored in a separate .css file and linked to HTML.

Flashcard 11

Front: What is external JavaScript?

Back: JavaScript stored in a separate .js file and loaded by the
HTML document.

Flashcard 12

Front: What does defer do on a script?

Back: Defers execution of a classic external script until HTML
parsing is complete.

Flashcard 13

Front: What is progressive enhancement?

Back: Building a functional foundation first and then enhancing
it with styling and richer behaviour.

Flashcard 14
Front: What is the browser rendering process?
Back: The series of steps through which browser resources are
processed into visual output.

44. Lesson Test

Try this without looking back.

Section A — Multiple Choice

1. Which technology primarily defines webpage

structure?

A. CSS
B. HTML
C. JavaScript
D. SQL

2. Which technology primarily controls presentation?

A. HTML
B. CSS
C. JavaScript
D. HTTP

3. Which technology primarily controls browser-side

behaviour?

A. HTML
B. CSS
C. JavaScript
D. DNS

4. What does DOM stand for?

A. Data Object Module

B. Document Object Model
C. Dynamic Object Method
D. Document Operation Machine

5. What does [Link]() work with?

A. CSS selectors
B. SQL queries
C. DNS records
D. File paths only

6. What does addEventListener() allow JavaScript to do?

A. Create a database
B. Respond to events
C. Write CSS automatically
D. Change the domain name

7. What does defer generally do for a classic external

script?

A. Deletes the script

B. Prevents execution forever
C. Delays execution until HTML parsing has completed
D. Converts JavaScript into CSS

45. Section B — True or False

8. HTML is a markup language.

9. CSS can control layout.
10. JavaScript cannot change the DOM.
11. The DOM is a tree-like representation of document
structure.
12. CSS and JavaScript must always be written inline.
13. An external stylesheet can be reused across multiple
HTML documents.
14. JavaScript can respond to user events.
15. The browser can process HTML, CSS, and JavaScript to
produce a rendered page.
16. The original HTML source and the current DOM are
always guaranteed to be identical.
46. Section C — Explain in Your Own Words

17. Explain HTML, CSS, and JavaScript using the restaurant

analogy.
18. What is the difference between HTML structure and CSS
styling?
19. Why is the DOM important?
20. What happens when JavaScript changes textContent?
21. What is an event listener?
22. Why might we separate HTML, CSS, and JavaScript into
different files?
23. What is the difference between source HTML and the
current DOM?
24. Explain the basic path from HTML source to pixels on
the screen.

47. Section D — Code Reading

What will happen when this button is clicked?

<p id="message">Original message</p>

<button id="button">
Click me
</button>

<script>
const message = [Link]("#message");
const button = [Link]("#button");

[Link]("click", () => {
[Link] = "New message!";
});
</script>

Answer:

Before click:
?
After click:
?

What DOM element changes?

?

Which JavaScript property is used?

?

48. Section E — Debugging Challenge

The following code doesn't work correctly:

<h1 id="title">Hello</h1>

<script>
const heading = [Link]("#heading");

[Link] = "Welcome";
</script>

Find the problem.

Hint

Compare:

id="title"

with:

"#heading"

What selector is JavaScript searching for?

49. Section F — Practical Project

Build a mini page called:

My Learning Dashboard
Your page must contain:

Title:
My Web Development Journey

Paragraph:
I am learning HTML, CSS, and JavaScript.

Button:
Show My Goal

When the button is clicked, JavaScript should change the

paragraph to:

My goal is to become a skilled web developer.

Your project should have exactly:

my-learning-dashboard/
├── [Link]
├── [Link]
└── [Link]

Requirements

HTML must contain:

A semantic main element

A heading
A paragraph
A button

CSS must contain:

Background styling
Text styling
Button styling
Some spacing

JavaScript must:

Select the paragraph

Select the button
Listen for click
Change paragraph text

50. Your Phase 0 Progress

You've now built the conceptual foundation:

0.1 ✅ Internet and Web

↓
0.2 ✅ Websites and Web Applications
↓
0.3 ✅ Front End / Back End / Full Stack
↓
0.4 ✅ HTML + CSS + JavaScript Triangle

Your mental model should now be:

WEB
│
▼
BROWSER
│
┌─────────┼─────────┐
│ │ │
▼ ▼ ▼
HTML CSS JavaScript
│ │ │
▼ ▼ ▼
Structure Style Behaviour
│ │ │
└─────────┼─────────┘
│
▼
DOM
│
▼
Browser Rendering
│
▼
Screen Output
│
▼
 User

And one of the most important principles from today's lesson:

HTML describes the content and its meaning. CSS

controls presentation and layout. JavaScript adds
programming logic and dynamic behaviour.

That's our foundation.

----------------------------------X---------------------------------------------

Lesson 0.5

Files, Folders, File Extensions, Paths, and Project Structure

Welcome to Lesson 0.5, bro. 🔥

This is one of those lessons that seems boring at first but will
save you from an insane amount of confusion later.

Soon you'll write code like:

<link rel="stylesheet" href="css/[Link]">

and:

<script src="js/[Link]" defer></script>

and:

<img src="images/[Link]" alt="My profile photo">

And you'll eventually wonder:

"Why isn't my CSS working?"

"Why is my image broken?"

"Why does ../ exist?"

"Why does ./[Link] work but /[Link] doesn't?"

"Why does my file work on my laptop but not after uploading it?"
This entire lesson is designed to answer those questions before
they become headaches.

What you'll learn

By the end of this lesson, you'll understand:

1. What files and folders are

2. What file extensions are
3. How websites are organised on your computer
4. What a project root is
5. What file paths are
6. Relative paths
7. Absolute URLs
8. ./
9. ../
10. /
11. href
12. src
13. How HTML connects to CSS and JavaScript
14. How images are connected to HTML
15. Why file naming matters
16. Windows-specific beginner issues
17. How to create a professional beginner project structure
18. How to debug missing files
19. How browser paths differ from Windows file paths

1. What is a file?

A file is a collection of information stored on your computer.

Examples:

[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
Each file usually has:

filename + extension

For example:

[Link]

Break it down:

index . html
↑ ↑
name extension

The extension helps identify the file type.

A website project might contain:

[Link]
[Link]
[Link]
[Link]
[Link]

Each file serves a different purpose.

2. What is a folder?

A folder is a container used to organise files and other folders.

For example:

my-website/
├── [Link]
├── [Link]
├── [Link]
└── [Link]

Here:

my-website

is the folder.
Inside it are four files.

A website project can become much larger:

my-website/
├── [Link]
├── [Link]
├── [Link]
│
├── css/
│ └── [Link]
│
├── js/
│ └── [Link]
│
├── images/
│ ├── [Link]
│ ├── [Link]
│ └── [Link]
│
└── pages/
├── [Link]
└── [Link]

A sensible folder structure makes it easier to find, connect, and

maintain your files. MDN's current beginner material explicitly
teaches file and folder organisation, naming practices, website
structure, file paths, and extensions as part of the initial web-
development environment setup.

3. What is a file extension?

A file extension is generally the portion at the end of a

filename that indicates its format or type.

Examples:

.html → HTML
.css → CSS
.js → JavaScript
.jpg → JPEG image
.png → PNG image
.svg → SVG image
.gif → GIF image
.webp → WebP image
.pdf → PDF document

Examples:

[Link]
[Link]
[Link]
[Link]
[Link]

The browser uses these files differently depending on what they

represent and how they're referenced.

4. Important Windows issue: Hidden file extensions

Since you're likely working on Windows, pay attention to this.

Windows File Explorer can hide known file extensions.

That can cause a beginner to accidentally create:

[Link]

while thinking they created:

[Link]

That is a completely different filename.

You might see:

[Link]

in Explorer while the actual filename is:

[Link]

This can cause your browser or editor to behave unexpectedly.

Best practice

Turn on File name extensions in Windows File Explorer so you

can see the actual extensions.

Then make sure you see:

[Link]
[Link]
[Link]

and not:

[Link]
[Link]
[Link]

This is one of the most common beginner problems.

5. What is a project?

A project is a collection of files and folders that together make

up something you're building.

For example:

my-portfolio/

could be your project.

Inside:

my-portfolio/
├── [Link]
├── [Link]
├── [Link]
├── [Link]
├── css/
├── js/
├── images/
└── fonts/
The entire folder represents your project.

Think:

Project
│
├── Documents
├── Styles
├── JavaScript
├── Images
└── Other resources

As your projects grow, organisation becomes increasingly

important.

6. What is the project root?

The project root is the main directory from which the project is
organised.

Imagine:

my-website/
├── [Link]
├── css/
├── js/
└── images/

Here:

my-website/

is the project root in our simplified structure.

It is the top-level directory containing your project's main files

and folders.

You can think of it as:

The front door of your project.

Everything else is organised underneath it.

7. The file system tree

Let's look at a more realistic project:

my-portfolio/
│
├── [Link]
│
├── pages/
│ ├── [Link]
│ ├── [Link]
│ └── [Link]
│
├── css/
│ ├── [Link]
│ └── [Link]
│
├── js/
│ └── [Link]
│
├── images/
│ ├── [Link]
│ ├── [Link]
│ └── [Link]
│
└── assets/
└── [Link]

Let's understand the tree.

Root

my-portfolio/

HTML pages

[Link]
pages/

CSS
css/

JavaScript

js/

Images

images/

Other assets

assets/

You don't have to use this exact structure for every project.
There is no single universal folder structure that every developer
follows.

But having a predictable structure is incredibly helpful.

8. What is a path?

A path tells the browser where a resource can be found.

Imagine this:

my-website/
├── [Link]
└── [Link]

From [Link], the CSS file is:

[Link]

So you can write:

<link rel="stylesheet" href="[Link]">

The browser uses that path to locate the stylesheet.

Paths are essential because webpages often reference resources

stored in different locations. MDN's file-handling guidance treats
understanding file paths as a fundamental part of building
websites.

9. A path is like an address

Think about your computer.

You may have:

C:\
└── Users
└── YourName
└── Documents
└── Websites
└── my-website

You can think of a path as a way of saying:

"Go here, then here, then here."

Similarly, inside a website:

my-website/
├── [Link]
└── images/
└── [Link]

From [Link]:

images/[Link]

means:

Start here
↓
Go into images
↓
Find [Link]
10. Paths vs URLs

This is important.

A file-system path and a URL are related concepts, but they

are not identical.

For example, Windows might have a local file path like:

C:\Users\Aarav\Documents\my-website\[Link]

A webpage might reference a resource using:

images/[Link]

And an internet resource might have:

[Link]

These are different address systems.

For web development, you'll commonly work with URL

references inside HTML and CSS.

11. Absolute URLs

An absolute URL provides the complete address of a resource.

Example:

<a href="[Link]
MDN
</a>

The browser already has everything it needs to locate that

resource.

The full URL contains the necessary location information.

For example:

[Link]

This includes:
https://
[Link]
/images/[Link]

An absolute URL is generally self-contained.

MDN distinguishes absolute URLs from relative references and

explains that relative references can be resolved using the
current document's URL as context.

12. Relative paths

A relative path doesn't provide the full domain.

For example:

<img src="images/[Link]" alt="Website logo">

The browser determines where this refers based on the current

document's location and the path provided.

Imagine:

my-website/
├── [Link]
└── images/
└── [Link]

From:

[Link]

you write:

<img src="images/[Link]" alt="Website logo">

Meaning:

Current location
↓
Go into images/
↓
Find [Link]
Relative references are resolved using the current document's
base URL.

13. ./ — Current directory

Let's say:

my-website/
├── [Link]
└── [Link]

You can write:

<link rel="stylesheet" href="./[Link]">

The ./ means, conceptually:

Start from the current directory.

So:

./[Link]

means:

Current directory
↓
[Link]

In many situations:

[Link]

and:

./[Link]

resolve to the same resource.

So these are commonly equivalent in this situation:

<link rel="stylesheet" href="[Link]">

and:
<link rel="stylesheet" href="./[Link]">

The explicit ./ can sometimes make your intention clearer to a

beginner.

14. ../ — Parent directory

Now let's make things slightly more interesting.

Imagine:

my-website/
│
├── [Link]
│
├── pages/
│ └── [Link]
│
└── css/
└── [Link]

The file:

[Link]

is inside:

pages/

But:

[Link]

is in:

css/

How does [Link] reach [Link]?

Let's trace the path.

Start here:
pages/

Go up one folder:

../

Now you're at:

my-website/

Then go into:

css/

Then find:

[Link]

So:

<link rel="stylesheet" href="../css/[Link]">

means:

Start in pages/
↓
Go up one level
↓
Go into css/
↓
Find [Link]

This is what ../ is for.

MDN describes ../ as a parent-directory relative reference, with

each ../ moving one level upward in the directory tree.

15. Multiple ../

Suppose:

my-website/
│
├── css/
│ └── [Link]
│
└── pages/
└── admin/
└── settings/
└── [Link]

We are here:

pages/admin/settings/[Link]

We want:

css/[Link]

Let's move upward.

[Link]
↑ ../
settings/
↑ ../
admin/
↑ ../
pages/
↑ ../
my-website/

Then:

css/[Link]

So:

<link rel="stylesheet" href="../../../css/[Link]">

Let's count:

../../../css/[Link]

Three ../ segments move up three directory levels from

settings/:

settings/
 ↑
admin/
↑
pages/
↑
my-website/

Then:

css/[Link]

The exact number of ../ segments depends on where the

current document is located.

This is why folder organisation matters.

16. Root-relative paths

You may also see:

/css/[Link]

The leading / indicates a path relative to the site root when

used as a URL reference in a web context.

Suppose the site is:

[Link]

Then:

/css/[Link]

resolves to:

[Link]

It does not mean:

[Link]

Instead, it starts from the site's root.

MDN's URL documentation describes /path as a root-relative
reference, while ./ or no prefix is relative to the current directory
and ../ moves upward to a parent directory.

Important beginner warning

A root-relative path can behave differently when you are simply

opening local files directly with a file:// URL rather than running
them through a web server.

For beginners, I recommend getting comfortable first with:

[Link]
./[Link]
../css/[Link]

Then we'll properly explore root-relative paths once we start

using a local development server.

17. The four path patterns you must know

Path Meaning
Look relative to current document
[Link]
location
./[Link] Explicitly current directory
../[Link] Go up one directory, then find file
Start from site root in a web URL
/[Link]
context
[Link] Full absolute URL

The first four are relative/root-relative forms depending on

context; the last one is a fully qualified absolute URL.

18. href vs src

This is a very important distinction.

You'll frequently see:

<link rel="stylesheet" href="[Link]">

and:

<script src="[Link]" defer></script>

and:

<img src="images/[Link]" alt="Logo">

What are href and src?

href

href generally specifies a referenced location or destination.

Example:

<a href="[Link]">About</a>

The link points to:

[Link]

Another example:

<link rel="stylesheet" href="[Link]">

The link element references an external stylesheet.

The <link> element is specifically designed to establish

relationships between a document and external resources,
including stylesheets.

src

src generally identifies a resource that the element is going to

load or use as its source.

Example:
<img src="images/[Link]" alt="Logo">

The image source is:

images/[Link]

Another:

<script src="[Link]"></script>

The JavaScript source is:

[Link]

MDN documents the src attribute of <script> as the URL of an

external script, while <img> uses src to identify the image
resource to load.

A useful beginner mental shortcut:

href → "Where does this link/reference point?"

src → "Where does this resource come from?"

This is simplified but useful.

19. Linking HTML and CSS

Imagine:

my-website/
├── [Link]
└── [Link]

Your HTML:

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">

<title>My Website</title>
 <link rel="stylesheet" href="[Link]">
</head>

<body>
<h1>Hello!</h1>
</body>
</html>

The relationship is:

[Link]
│
│ href="[Link]"
▼
[Link]

The browser loads the HTML document and follows the

stylesheet reference.

20. Linking HTML and JavaScript

Imagine:

my-website/
├── [Link]
└── [Link]

HTML:

<script src="[Link]" defer></script>

The relationship:

[Link]
│
│ src="[Link]"
▼
[Link]

Now JavaScript can interact with the page.

21. Linking HTML and Images

Imagine:

my-website/
├── [Link]
└── images/
└── [Link]

HTML:

<img
src="images/[Link]"
alt="A profile photograph"
>

The path means:

[Link]
↓
images/
↓
[Link]

The alt attribute is also important because it provides

alternative text describing the image for situations where the
image cannot be seen or loaded and for assistive technology.
MDN's HTML image guidance treats src and alt as important
attributes for useful <img> elements.

22. A Complete Project

Let's build this:

my-portfolio/
│
├── [Link]
│
├── css/
│ └── [Link]
│
├── js/
│ └── [Link]
│
└── images/
└── [Link]

Now let's connect everything.

[Link]

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">

<meta
name="viewport"
content="width=device-width, initial-scale=1.0"
>

<title>My Portfolio</title>

<link
rel="stylesheet"
href="css/[Link]"
>

<script
src="js/[Link]"
defer
></script>
</head>

<body>
<main>
<h1>My Portfolio</h1>

<img
src="images/[Link]"
alt="My profile photograph"
 >

<p>
I am learning web development.
</p>

<button type="button" id="helloButton">

Say Hello
</button>
</main>
</body>
</html>

css/[Link]

body {
font-family: system-ui, sans-serif;
}

main {
max-width: 600px;
margin: 0 auto;
padding: 32px;
}

img {
width: 200px;
height: 200px;
object-fit: cover;
}

Notice something important:

The CSS file is inside:

css/

But the HTML file is in:

my-portfolio/

Therefore:
href="css/[Link]"

is correct.

js/[Link]

const button = [Link]("#helloButton");

[Link]("click", () => {
alert("Hello from JavaScript!");
});

The JavaScript is inside:

js/

So:

src="js/[Link]"

is correct.

23. The Complete File Map

my-portfolio/
│
├── [Link]
│
│ ├── href="css/[Link]"
│ │ ↓
│ │ css/[Link]
│ │
│ ├── src="js/[Link]"
│ │ ↓
│ │ js/[Link]
│ │
│ └── src="images/[Link]"
│ ↓
│ images/[Link]
│
├── css/
│ └── [Link]
│
├── js/
│ └── [Link]
│
└── images/
└── [Link]

Your brain should start seeing paths as navigation through

the project tree.

24. Nested HTML Pages

Let's make the project slightly more complex.

my-portfolio/
│
├── [Link]
│
├── pages/
│ ├── [Link]
│ └── [Link]
│
├── css/
│ └── [Link]
│
└── js/
└── [Link]

Now [Link] is at:

my-portfolio/

and [Link] is at:

my-portfolio/pages/

If [Link] links to [Link]:

<a href="pages/[Link]">
 About
</a>

Path:

[Link]
↓
pages/
↓
[Link]

25. Going Back Up With ../

Now suppose [Link] needs the same CSS file.

Current location:

pages/[Link]

CSS location:

css/[Link]

From pages/[Link]:

pages/
↑ ../
my-portfolio/
↓
css/
↓
[Link]

So:

<link rel="stylesheet" href="../css/[Link]">

This is the pattern:

../

Go up.

Then:
css/

Go down into CSS.

Then:

[Link]

Select the file.

26. A Path Exercise

Consider:

website/
│
├── [Link]
│
├── css/
│ └── [Link]
│
├── images/
│ └── [Link]
│
└── pages/
├── [Link]
└── projects/
└── [Link]

Let's answer some questions.

Question 1

How does [Link] reach [Link]?

Answer:

css/[Link]
Question 2

How does [Link] reach the logo?

Answer:

images/[Link]

Question 3

How does [Link] reach [Link]?

Answer:

../css/[Link]

Question 4

How does [Link] reach [Link]?

Current location:

pages/projects/

Go up:

../

You reach:

pages/

Go up again:

../

You reach:

website/
Then:

css/[Link]

So:

../../css/[Link]

Question 5

How does [Link] reach the logo?

The logo is:

images/[Link]

From:

pages/projects/

go up twice:

../../

then:

images/[Link]

Answer:

../../images/[Link]

27. File Names Matter

Consider:

[Link]

and:

[Link]

Depending on your environment and hosting system, differences

in letter case may cause problems.
A robust habit is to use consistent, predictable lowercase
filenames.

I recommend:

[Link]
[Link]
[Link]
[Link]
[Link]

Avoid names like:

My Final Website!!!.html
[Link]
JavaScript [Link]

Instead:

[Link]
[Link]
[Link]

You can use:

kebab-case

for filenames:

[Link]
[Link]
[Link]

Consistency is more important than obsessing over one naming

style.

28. Spaces in File Names

Technically, filenames containing spaces can work in many

contexts.

For beginners, however, I recommend avoiding them.

Instead of:

my profile [Link]

use:

[Link]

Why?

Because spaces can make URLs and command-line work more

awkward, and consistent naming makes projects easier to
manage.

29. Special Characters

Avoid unnecessarily complicated filenames such as:

my@website#final!.html

Prefer:

[Link]

Simple filenames are easier to read, reference, and debug.

30. Case Sensitivity

This one can surprise beginners.

Imagine your file is:

[Link]

But your HTML says:

<link rel="stylesheet" href="[Link]">

On some systems, those may be treated as different filenames.

Then you get:

CSS does not load ❌

Even though the names look almost identical.

So make sure the exact filename matches.

[Link]

must be referenced consistently.

31. The Classic "My CSS Isn't Working" Problem

Let's say:

website/
├── [Link]
└── css/
└── [Link]

But your HTML says:

<link rel="stylesheet" href="[Link]">

The browser searches for:

website/[Link]

But the actual file is:

website/css/[Link]

So the correct path is:

<link rel="stylesheet" href="css/[Link]">

The problem isn't CSS.

The problem is:

The browser can't find the CSS file at the location you
specified.

This distinction is huge.

When something doesn't load, ask:

Is my code wrong?
OR
Is my path wrong?

32. The Classic "My Image Is Broken" Problem

Suppose:

website/
├── [Link]
└── images/
└── [Link]

You write:

<img src="[Link]" alt="Logo">

This tells the browser:

Look next to [Link]

Find [Link]

But [Link] isn't next to [Link].

It's inside:

images/

So you need:

<img src="images/[Link]" alt="Logo">

The browser isn't psychic. 😭

The path must describe where the resource is.

33. The Classic ../ Mistake

Suppose:
website/
├── css/
│ └── [Link]
└── pages/
└── [Link]

You write:

<link rel="stylesheet" href="css/[Link]">

But you're inside:

pages/[Link]

The browser looks for:

pages/css/[Link]

That's not where the file is.

You need:

<link rel="stylesheet" href="../css/[Link]">

Because:

pages/
↑
../
↓
website/

Then:

css/[Link]

34. File Path vs URL Path

Here is a subtle but important point.

On Windows, you might see:

C:\Projects\Website\images\[Link]
But web URLs generally use forward slashes:

images/[Link]

And URL paths look like:

/images/[Link]

So for web development, you'll usually write:

rather than:

You may have seen Windows file paths like:

C:\Users\...

but HTML URL references commonly use:

images/[Link]

Keep these concepts separate.

35. Why [Link] Is Special

You will frequently see:

[Link]

used as the main page of a simple website.

For example:

my-website/
└── [Link]

This convention is extremely common.

When websites are served by a web server, a directory URL

often maps to a default document such as [Link],
depending on server configuration.
For beginners, think:

[Link]
↓
Main entry page

This isn't a universal law that every web server must follow, but
it is a very common convention.

We'll understand this much better when we get to hosting and

deployment.

36. A Good Beginner Project Structure

For your first few projects, I recommend something like:

project-name/
│
├── [Link]
│
├── css/
│ └── [Link]
│
├── js/
│ └── [Link]
│
└── images/

For a larger multi-page project:

project-name/
│
├── [Link]
│
├── pages/
│ ├── [Link]
│ ├── [Link]
│ └── [Link]
│
├── css/
│ ├── [Link]
│ └── [Link]
│
├── js/
│ ├── [Link]
│ └── [Link]
│
├── images/
│ ├── [Link]
│ └── [Link]
│
└── assets/
└── [Link]

Again, this is our recommended learning structure, not a

mandatory universal standard.

As projects become larger, you may use different conventions.

37. A More Professional Structure Later

When you move into modern tooling and frameworks, you might
see structures such as:

my-app/
├── src/
├── public/
├── [Link]
├── [Link]
└── node_modules/

Or:

src/
├── components/
├── pages/
├── styles/
├── assets/
└── utils/

Don't worry about these yet.

Right now, I want you to master:

HTML
CSS
JS
Images
Folders
Paths

Once those are solid, complicated project structures become

much easier.

38. A Critical Concept: The Path Is Relative to Something

This is one of the most important ideas in today's lesson.

A relative path only makes sense when you know:

Relative to what?

For example:

images/[Link]

Where does it start?

Usually, relative URL references are resolved against the

document's base URL.

So if:

[Link]

is at:

website/

then:

images/[Link]

means:
website/images/[Link]

But if:

[Link]

is at:

website/pages/

then:

images/[Link]

would mean:

website/pages/images/[Link]

not:

website/images/[Link]

That's why you may need:

../images/[Link]

This single concept will make paths much easier.

39. href and src — Quick Reference

Link to another page

<a href="[Link]">About</a>

Link to an external website

<a href="[Link]

Load CSS

<link rel="stylesheet" href="css/[Link]">

Load JavaScript
<script src="js/[Link]" defer></script>

Load image

<img src="images/[Link]" alt="Website logo">

Link to a PDF

<a href="assets/[Link]">
Download Resume
</a>

The anchor element's href can point to webpages, files, email

addresses, page fragments, and other URL-addressable
destinations.

40. Building a Multi-Page Website

Let's create:

my-school-site/
│
├── [Link]
│
├── pages/
│ ├── [Link]
│ └── [Link]
│
├── css/
│ └── [Link]
│
└── js/
└── [Link]

From [Link]

To About:

<a href="pages/[Link]">
About
</a>
To Contact:

<a href="pages/[Link]">
Contact
</a>

From [Link]

Back to Home:

<a href="../[Link]">
Home
</a>

Why?

Because:

[Link]
↓
../
↓
my-school-site/
↓
[Link]

From [Link]

Back to Home:

<a href="../[Link]">
Home
</a>

The same logic applies.

41. Navigation Diagram

my-school-site/
│
├── [Link]
│ │
│ ├── pages/[Link]
│ │
│ └── pages/[Link]
│
└── pages/
│
├── [Link]
│ │
│ └── ../[Link]
│
└── [Link]
│
└── ../[Link]

Thinking visually like this is extremely helpful.

42. Practical Exercise — Build This Project

Create:

web-fundamentals/
│
├── [Link]
│
├── pages/
│ ├── [Link]
│ └── [Link]
│
├── css/
│ └── [Link]
│
├── js/
│ └── [Link]
│
└── images/
└── [Link]

You don't need a real profile image. You can add one later.
43. [Link]
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">

<meta
name="viewport"
content="width=device-width, initial-scale=1.0"
>

<title>Web Fundamentals</title>

<link rel="stylesheet" href="css/[Link]">

<script src="js/[Link]" defer></script>

</head>

<body>
<header>
<nav>
<a href="[Link]">Home</a>
<a href="pages/[Link]">About</a>
<a href="pages/[Link]">Contact</a>
</nav>
</header>

<main>
<h1>My Web Development Journey</h1>

<p>
I am learning how websites work.
</p>

<button id="helloButton" type="button">

Say Hello
</button>
</main>
</body>
</html>
44. pages/[Link]

Notice the paths.

This file is inside:

pages/

So CSS requires:

../css/[Link]

JavaScript requires:

../js/[Link]

Home requires:

../[Link]

Code:

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">

<meta
name="viewport"
content="width=device-width, initial-scale=1.0"
>

<title>About Me</title>

<link
rel="stylesheet"
href="../css/[Link]"
>

<script
src="../js/[Link]"
defer
></script>
 </head>

<body>
<header>
<nav>
<a href="../[Link]">Home</a>
<a href="[Link]">About</a>
<a href="[Link]">Contact</a>
</nav>
</header>

<main>
<h1>About Me</h1>

<p>
I am a beginner learning HTML, CSS, and JavaScript.
</p>
</main>
</body>
</html>

Notice:

<a href="[Link]">About</a>

Why not:

<a href="pages/[Link]">About</a>

Because we're already inside the pages folder.

The current file is:

pages/[Link]

So:

[Link]

is enough to refer to itself.

45. pages/[Link]
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">

<meta
name="viewport"
content="width=device-width, initial-scale=1.0"
>

<title>Contact</title>

<link
rel="stylesheet"
href="../css/[Link]"
>

<script
src="../js/[Link]"
defer
></script>
</head>

<body>
<header>
<nav>
<a href="../[Link]">Home</a>
<a href="[Link]">About</a>
<a href="[Link]">Contact</a>
</nav>
</header>

<main>
<h1>Contact</h1>

<p>
This is my contact page.
</p>
</main>
</body>
</html>

46. css/[Link]
body {
margin: 0;
font-family: system-ui, sans-serif;
line-height: 1.6;
}

header {
padding: 16px 24px;
border-bottom: 1px solid #ddd;
}

nav {
display: flex;
gap: 16px;
}

main {
max-width: 700px;
margin: 0 auto;
padding: 40px 24px;
}

button {
padding: 10px 16px;
font: inherit;
cursor: pointer;
}

47. js/[Link]
const button = [Link]("#helloButton");

if (button) {
[Link]("click", () => {
alert("Hello from my website!");
});
}
Now you're seeing an important idea.

The JavaScript file is loaded on multiple pages.

But only the home page has:

<button id="helloButton">

So this:

if (button) {

checks whether the button exists before trying to attach an

event listener.

That prevents an error on pages where the button isn't present.

This is a small preview of real-world JavaScript defensive coding.

We'll study it properly later.

48. Your Folder-Path Challenge

Without looking at the answer, calculate these.

Given:

website/
│
├── [Link]
│
├── css/
│ └── [Link]
│
├── js/
│ └── [Link]
│
├── images/
│ └── [Link]
│
└── pages/
├── [Link]
 └── projects/
└── [Link]

Question 1

From [Link] to [Link]:

Question 2

From [Link] to [Link]:

Question 3

From [Link] to [Link]:

Question 4

From [Link] to [Link]:

Question 5

From [Link] to [Link]:

Question 6

From [Link] to [Link]:

Question 7

From [Link] to [Link]:

Try these before checking the answers below.

49. Answers

1. [Link] → [Link]

css/[Link]

2. [Link] → [Link]

images/[Link]

3. [Link] → [Link]

../js/[Link]

4. [Link] → [Link]

../images/[Link]

5. [Link] → [Link]

Current:

pages/projects/

Up:

../

Now:

pages/

Up:

../

Now:

website/

Then:

css/[Link]
Answer:

../../css/[Link]

6. [Link] → [Link]

../../[Link]

7. [Link] → [Link]

pages/projects/[Link]

50. Debugging Checklist

When a resource isn't loading, check these in order.

Step 1 — Does the file actually exist?

Look at your folder.

Is it really:

[Link]

or is it:

[Link]

Step 2 — Is the folder correct?

Is the file here?

css/[Link]

or here?

[Link]

Step 3 — Is the path correct?

HTML:

<link rel="stylesheet" href="css/[Link]">

Folder:

css/
└── [Link]

Correct.

Step 4 — Is the capitalization identical?

[Link]

vs:

[Link]

Check carefully.

Step 5 — Are you starting from the correct directory?

If your HTML is inside:

pages/

you may need:

../

Step 6 — Did you accidentally add the wrong extension?

Check for:

[Link]

or:

[Link]
Step 7 — Check Developer Tools

Open:

F12

Look at:

Console
Network

A missing resource may show an error such as a 404 response.

A 404 generally means the requested resource wasn't found at

that location.

This is a very useful clue:

Your HTML may be fine. Your path may simply be wrong.

51. Browser Mental Model

Imagine the browser is standing at:

website/pages/[Link]

You say:

css/[Link]

The browser thinks:

website/pages/css/[Link]

You say:

../css/[Link]

The browser thinks:

website/pages/
↑
../
↓
website/
↓
css/
↓
[Link]

This is exactly the mental model I want you to develop.

52. Cheat Sheet

File structure

project/
├── [Link]
├── css/
├── js/
└── images/

Current directory

./

Example:

./[Link]

Relative path

[Link]

Parent directory

../

Example:

../[Link]

Two levels up

../../

Root-relative path
/[Link]

Starts at the site root in a web URL context.

Absolute URL

[Link]

Complete URL.

CSS

<link rel="stylesheet" href="css/[Link]">

JavaScript

<script src="js/[Link]" defer></script>

Image

<img src="images/[Link]" alt="Logo">

Link

<a href="pages/[Link]">
About
</a>

53. Flashcards

Flashcard 1

Front: What is a file?

Back: A stored collection of information identified by a filename.

Flashcard 2

Front: What is a folder?

Back: A container used to organise files and other folders.

Flashcard 3
Front: What is a file extension?
Back: The ending of a filename that commonly indicates its file
type or format.

Flashcard 4

Front: What is the project root?

Back: The top-level directory from which a project is organised.

Flashcard 5

Front: What does ./ represent?

Back: The current directory in a relative path.

Flashcard 6

Front: What does ../ represent?

Back: The parent directory.

Flashcard 7

Front: What does / at the beginning of a URL path generally

represent?
Back: The site root in a web URL context.

Flashcard 8

Front: What does href commonly specify?

Back: A referenced destination or resource location, such as a
link or stylesheet.

Flashcard 9

Front: What does src commonly specify?

Back: The source URL of a resource loaded or used by an
element.

Flashcard 10

Front: How do you link a CSS file?

Back: <link rel="stylesheet" href="[Link]">

Flashcard 11
Front: How do you load external JavaScript?
Back: <script src="[Link]" defer></script>

Flashcard 12

Front: How do you load an image from an images folder?

Back: <img src="images/[Link]" alt="Description">

Flashcard 13

Front: Why might [Link] fail to load?

Back: The path, filename, folder, extension, or capitalization
may be incorrect.

Flashcard 14

Front: What is the difference between [Link] and ../[Link]?

Back: The first looks relative to the current directory; the
second goes up one directory first.

Flashcard 15

Front: What is an absolute URL?

Back: A URL that contains the complete address needed to
identify a resource.

54. Lesson Test

Section A — Multiple Choice

1. Which file extension is used for HTML?

A. .css
B. .js
C. .html
D. .web

2. What does ../ mean?

A. Current directory
B. Parent directory
C. Site root
D. Internet

3. Which path points into an images folder?

A. ../images
B. images/[Link]
C. /../images
D. https/images

4. Which attribute is commonly used by <link> to

identify a referenced stylesheet?

A. src
B. href
C. path
D. file

5. Which attribute identifies the source of an image?

A. href
B. src
C. link
D. url

6. Which is a complete absolute URL?

A. images/[Link]
B. ../images/[Link]
C. [Link]
D. ./[Link]

7. Where is [Link] if this path is used?

css/[Link]

A. In the current directory

B. In the css subdirectory
C. In the parent directory
D. On another website
55. Section B — True or False

8. ./[Link] generally refers to [Link] in the current

directory.
9. ../[Link] means go up one directory before finding
[Link].
10. A relative path always contains a complete domain
name.
11. href can be used to link to another HTML page.
12. src can be used to load an external JavaScript file.
13. A file named [Link] is the same as [Link].
14. File and folder organisation is important in web
development.
15. A relative URL reference is resolved using contextual
information such as the document's base URL.

56. Section C — Path Problems

Given:

website/
│
├── [Link]
├── css/
│ └── [Link]
├── js/
│ └── [Link]
├── images/
│ └── [Link]
└── pages/
├── [Link]
└── projects/
└── [Link]

Write the correct path from:

16. [Link] → [Link]

17. [Link] → [Link]

18. [Link] → [Link]

19. [Link] → [Link]

20. [Link] → [Link]

21. [Link] → [Link]

22. [Link] → [Link]

23. [Link] → [Link]

57. Section D — Debugging

You have:

website/
├── [Link]
└── css/
└── [Link]

But your HTML contains:

<link rel="stylesheet" href="[Link]">

Question 24

Why doesn't the CSS load?

Question 25

What should the correct code be?

Now imagine:

website/
├── [Link]
└── images/
└── [Link]

Your code is:

<img src="[Link]" alt="Logo">

Question 26

Identify the problem.

Question 27

What should the corrected code be?

Now imagine:

website/
├── [Link]
└── pages/
└── [Link]

Your About page contains:

<a href="[Link]">Home</a>

Question 28

Why might the link fail?

Question 29

What should the corrected path be?

58. Final Practical — Build Your First Multi-Page Site

Create this exact structure:

my-first-multipage-site/
│
├── [Link]
│
├── pages/
│ ├── [Link]
│ └── [Link]
│
├── css/
│ └── [Link]
│
├── js/
│ └── [Link]
│
└── images/
└── [Link]

Your website should have:

Home

My First Website

About

About Me
I am learning web development.

Contact

Contact Me
This is my contact page.

Every page must:

 Load the same CSS file

 Load the same JavaScript file
 Have working navigation
 Have a Home link
 Use correct relative paths

Your navigation should work like this:

Home
│
├──→ About
│ │
│ └──→ Home
│
└──→ Contact
│
└──→ Home

And your file relationships should look like:

[Link]
│
├── css/[Link]
├── js/[Link]
└── pages/[Link]
│
├── ../css/[Link]
├── ../js/[Link]
└── ../[Link]

The Big Lesson From 0.5

The most important thing today isn't memorising:

./
../
/

The real skill is this:

Look at where your current file is. Look at where the

resource you want is. Then calculate the path between
them.

For example:

Current file:
website/pages/[Link]

Target:
website/css/[Link]

Think:

[Link]
↓
I'm inside pages/
↓
Go up one level: ../
↓
I'm at website/
↓
Go into css/
↓
Find [Link]

Therefore:

../css/[Link]

That's the skill.

Phase 0 Progress
0.1 ✅ Internet and Web
↓
0.2 ✅ Webpages, Websites, Web Apps
↓
0.3 ✅ Front-End / Back-End / Full Stack
↓
0.4 ✅ HTML + CSS + JavaScript
↓
0.5 ✅ Files, Folders, Paths, Project Structure

At this point, you've built a pretty solid mental model of what

web development is and how the pieces fit together.

-----------------------------------X--------------------------------------------

Lesson 0.6

Your Web Development Environment

Welcome to Lesson 0.6, bro. 🧑‍💻🔥

Until now, we've been building the mental model of web

development.

Now we're going to build the actual workspace where you'll

learn and practice.

By the end of this lesson, your workflow should look like:

Create project folder

↓
Open folder in VS Code
↓
Create HTML/CSS/JS files
↓
Write code
↓
Open in browser
↓
Test
↓
Inspect with DevTools
↓
Find errors
↓
Fix code
↓
Repeat

This is the basic loop you'll follow for a huge part of your front-
end journey.

MDN's current beginner curriculum includes environment setup

before the core HTML/CSS/JavaScript modules, and its setup
material covers code editors, browsers, file systems, and local
testing. MDN currently recommends Visual Studio Code as its
main code editor example for learners.

What you'll learn

By the end of Lesson 0.6, you'll understand:

1. What a code editor is

2. Why we use VS Code
3. How to install and configure VS Code
4. How to open a project folder
5. What the VS Code interface contains
6. How to create files
7. How to use the integrated terminal
8. What a browser is doing during development
9. How to open DevTools
 10. What the Elements, Console, Network, and Sources
panels are
11. How to test HTML, CSS, and JavaScript
12. How to refresh a webpage
13. How to inspect and temporarily modify a page
14. How to diagnose basic errors
15. What extensions are
16. Which tools you actually need right now
17. How to create your standard beginner workflow

1. Your Development Toolkit

For our initial HTML, CSS, and JavaScript learning, your setup
can be surprisingly simple.

You need:

1. A computer
+
2. A code editor
+
3. A modern web browser
+
4. Your project folders
+
5. Developer Tools

That's it.

Our starting toolkit will be:

VS Code
+
Google Chrome
+
File Explorer
+
Chrome DevTools

You do not need to install a gigantic collection of programming

software just to learn HTML and CSS.
You also do not need a JavaScript framework yet.

And for our initial plain HTML/CSS/JavaScript work, you don't

need [Link] or npm just to create and open simple webpages.
We'll introduce additional tooling when it becomes useful rather
than installing everything upfront.

2. What Is a Code Editor?

A code editor is software designed for writing and editing

source code.

You could technically write HTML in:

Notepad

But a proper code editor gives you features designed for

programming.

For example:

 Syntax highlighting
 Auto-completion
 Error indicators
 Search and replace
 File navigation
 Code formatting support
 Extensions
 Integrated terminal
 Source control integration

Think of it this way:

Microsoft Word
↓
Designed primarily for documents

VS Code
↓
Designed primarily for code and text-based projects
MDN's current setup guidance recommends a full code editor
such as VS Code for learning web development rather than
relying on a basic text editor.

3. Why We're Using VS Code

For this course, we'll use:

Visual Studio Code (VS Code)

Important:

Visual Studio Code

is not the same product as:

Visual Studio

They are different tools.

For our beginner front-end work, VS Code is a great choice

because it provides:

 A project Explorer
 Syntax highlighting
 Built-in editing features
 Integrated terminal
 Extensions
 Search across files
 Git/source-control integration
 Debugging capabilities

The current official VS Code documentation provides dedicated

setup and beginner guides for opening folders, editing files,
using source control, and running/debugging projects.

4. Installing VS Code on Windows

Because you're using Windows, we'll use the Windows

installation path.
Microsoft's current VS Code documentation says the User
Setup installation is recommended for most Windows users
because it installs for your user account and doesn't require
administrator permissions.

Step 1

Open the official Visual Studio Code website.

Download the Windows installer.

Look for the User Setup option.

Step 2

Run the installer.

Follow the installation prompts.

Step 3

After installation, open:

Visual Studio Code

You should see the VS Code interface.

Step 4

Do not install 50 extensions immediately.

Seriously.

You don't need a circus on day one. 😂

We'll add only what is useful.

5. Your First Look at VS Code

When you open VS Code, you'll see several important areas.

A simplified layout:
┌─────────────────────────────────────────────────────
───┐
│ Title / Menu │
├───────┬─────────────────────────────────────────────
───┤
│ │ │
│A │ │
│c │ │
│t │ EDITOR AREA │
│i │ │
│v │ [Link] │
│i │ [Link] │
│t │ [Link] │
│y │ │
│ │ │
│B │ │
│a │ │
│r │ │
├───────┴─────────────────────────────────────────────
───┤
│ STATUS BAR │
└─────────────────────────────────────────────────────
───┘

Let's understand the major sections.

6. Activity Bar

The vertical bar on the left gives access to different VS Code

views.

You'll commonly use:

Explorer
Search
Source Control
Run and Debug
Extensions

You don't need to master everything yet.

Our first priorities are:

Explorer
Search
Extensions

Later:

Source Control
Run and Debug
Terminal

will become more important.

7. Explorer

The Explorer shows your project's files and folders.

Suppose you open:

my-first-site/

You might see:

my-first-site
│
├── [Link]
├── css
│ └── [Link]
├── js
│ └── [Link]
└── images

You can click files to open them.

You can expand and collapse folders.

This becomes your main navigation system inside a coding

project.
8. Editor Area

The large central area is where you write code.

For example:

<h1>Hello, bro!</h1>

You can have multiple files open as tabs:

┌────────────┬────────────┬────────────┐
│ [Link] │ [Link] │ [Link] │
└────────────┴────────────┴────────────┘

Clicking a tab switches between files.

9. Status Bar

At the bottom, VS Code displays information about the current

file and workspace.

Depending on your file, it may show information related to:

 Language mode
 Encoding
 Line/column position
 Indentation
 Source control status

For now, the most important thing to notice is the language

mode.

If you open:

[Link]

VS Code should recognise it as HTML.

Similarly:

[Link]

should be recognised as CSS.

And:

[Link]

as JavaScript.

That helps VS Code provide appropriate syntax highlighting and

editing assistance.

10. Your First Project Workspace

Now let's create a proper practice area.

Open File Explorer.

Create a folder called:

web-development-course

Inside it, create:

web-development-course/

Eventually we'll have:

web-development-course/
│
├── 01-phase-0/
│
├── 02-html/
│
├── 03-css/
│
├── 04-javascript/
│
└── projects/

But don't create everything yet.

For now, create:

web-development-course/
└── 01-phase-0/
Inside 01-phase-0, create:

lesson-06-environment/

So:

web-development-course/
└── 01-phase-0/
└── lesson-06-environment/

This will be our practice project.

11. Open Your Project in VS Code

In VS Code:

File
↓
Open Folder
↓
Select:
web-development-course

You can also open a particular project folder.

The important concept is:

Open the folder, not just one individual file.

Why?

Because VS Code can then understand the project as a

workspace.

You can see:

HTML
CSS
JavaScript
Images
Other files

all together.
VS Code's official beginner guide explicitly uses the concept of
opening a folder as a workspace for project development.

12. Workspace

You will hear the word:

Workspace

A workspace is essentially the project context you're working in.

For our purposes, imagine:

Workspace
↓
Your project folder
↓
All the files and folders belonging to the project

Example:

my-website/
├── [Link]
├── css/
├── js/
└── images/

When you open my-website as a workspace, VS Code shows the

entire project structure.

This is much better than constantly opening individual files from

File Explorer.

13. Create Your First Files

Inside:

lesson-06-environment/

create:
[Link]
[Link]
[Link]

Your structure:

lesson-06-environment/
├── [Link]
├── [Link]
└── [Link]

Now let's connect them.

14. [Link]

Write:

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">

<meta
name="viewport"
content="width=device-width, initial-scale=1.0"
>

<title>My Development Environment</title>

<link rel="stylesheet" href="[Link]">

<script src="[Link]" defer></script>

</head>

<body>
<main>
<h1>My Development Environment</h1>

<p id="message">
I am learning web development.
 </p>

<button id="testButton" type="button">

Test JavaScript
</button>
</main>
</body>
</html>

15. [Link]

Write:

body {
margin: 0;
min-height: 100vh;
display: grid;
place-items: center;
font-family: system-ui, sans-serif;
background: #f4f4f5;
}

main {
width: min(90%, 600px);
padding: 32px;
text-align: center;
background: white;
border-radius: 16px;
box-shadow: 0 10px 30px rgb(0 0 0 / 10%);
}

button {
padding: 10px 16px;
font: inherit;
cursor: pointer;
}

16. [Link]

Write:
const button = [Link]("#testButton");
const message = [Link]("#message");

[Link]("click", () => {
[Link] = "JavaScript is working! 🎉";
});

Now your three technologies are connected:

[Link]
│
├── [Link]
│
└── [Link]

17. Opening Your Website

Now go to your project folder in File Explorer.

Double-click:

[Link]

Your default browser should open the page.

You should see:

My Development Environment

I am learning web development.

[ Test JavaScript ]

Click the button.

The text should change to:

JavaScript is working! 🎉

Congratulations.

You've now created and tested a complete tiny web project.

18. The Development Loop

This is the workflow I want you to develop as a habit:

1. Write code
↓
2. Save
↓
3. Open/reload browser
↓
4. Test
↓
5. Inspect
↓
6. Find problems
↓
7. Edit code
↓
8. Save
↓
9. Reload
↓
10. Repeat

This is normal.

Real developers don't write perfect code in one shot.

They:

Write
↓
Run
↓
Break
↓
Debug
↓
Fix
↓
Repeat

That's literally part of programming.

19. Saving Your Files

This sounds basic, but beginners often forget it.

When you modify:

[Link]

you need to save it before expecting the browser to see the

change.

Keyboard shortcut on Windows:

Ctrl + S

Then refresh your browser:

Ctrl + R

or:

F5

A useful loop:

Edit
↓
Ctrl + S
↓
Browser
↓
Ctrl + R

Later, we'll use tooling that can automatically reload the

browser when files change.

For now, manual reload is totally fine.

20. The Browser Is Your Testing Environment

Your browser is not merely for browsing social media and

watching videos.

For a front-end developer, it's also a development tool.

Your browser can:

Load HTML
Apply CSS
Run JavaScript
Inspect the DOM
Show errors
Show network requests
Measure performance
Debug JavaScript

Chrome DevTools is built directly into Chrome and is specifically

designed to inspect, diagnose, and edit webpages during
development.

So our core loop becomes:

VS Code
↓
Write code

Browser
↓
Run code

DevTools
↓
Inspect + Debug

21. What Are Developer Tools?

Developer Tools, often called:

DevTools
are tools built into modern browsers that help developers
understand what a webpage is doing.

MDN describes browser DevTools as tools for inspecting loaded

HTML, CSS, and JavaScript, examining requested assets, and
diagnosing webpage problems.

In Chrome, you can open DevTools from:

Three dots
↓
More tools
↓
Developer Tools

You can also use the keyboard shortcut:

Ctrl + Shift + I

Chrome's official documentation lists opening DevTools through

the browser menu and keyboard shortcut options.

22. The DevTools Panels You Need First

Don't worry about everything.

We will focus on:

Elements
Console
Network
Sources

Later:

Application
Performance
Lighthouse
Memory
Security

will become useful.

23. Elements Panel

The Elements panel lets you inspect the current HTML/DOM and
associated styles.

Open your project.

Press:

Ctrl + Shift + I

Then select:

Elements

You should see something similar to:

<html>
<head>
...
</head>

<body>
<main>
<h1>My Development Environment</h1>

<p id="message">
I am learning web development.
</p>

<button id="testButton">
Test JavaScript
</button>
</main>
</body>
</html>

This is your page's current DOM representation.

Remember our previous lesson?

HTML source
 ↓
Browser parses it
↓
DOM

DevTools lets you inspect that current DOM.

24. Temporarily Editing HTML

In the Elements panel, find:

<h1>My Development Environment</h1>

Double-click the text.

Change:

My Development Environment

to:

Hello from DevTools!

You should see the page change immediately.

Notice something important.

You didn't modify:

[Link]

You changed the current page inside the browser.

Refresh.

The change disappears.

Why?

Because:

Your source file

↓
Browser loads it
 ↓
Current DOM
↓
You temporarily edit DOM
↓
Refresh
↓
Original source loaded again

This is an incredibly useful debugging concept.

25. Editing CSS in DevTools

In Elements, click an HTML element.

You may see a Styles section.

You can temporarily change CSS.

For example:

font-size: 50px;

or:

background: yellow;

The browser updates immediately.

This is fantastic for testing ideas.

For example:

"What if I make this button bigger?"

Try it in DevTools first.

If you like it, put the final change into:

[Link]

This gives you a fast design workflow.

26. The Console

The Console is one of your best friends.

Open:

Console

You can write JavaScript directly.

Try:

2+2

You should get:

Try:

[Link]

You might see:

"My Development Environment"

Try:

[Link]("#message")

You should get a reference to the paragraph.

Try:

[Link]("#message").textContent

You should see:

"I am learning web development."

Now try:

[Link]("#message").textContent =
"I changed this from DevTools!";
The page should change immediately.

This is you using JavaScript to manipulate the DOM.

27. Console as a Scratchpad

The Console is useful for:

Testing JavaScript
Inspecting values
Checking elements
Debugging
Reading errors
Running small experiments

Think of it as:

A live JavaScript playground attached to the current

webpage.

Later, you'll frequently use:

[Link]()

For example:

const message = "Hello";

[Link](message);

The Console displays:

Hello

This is one of the simplest debugging techniques in JavaScript.

28. The Network Panel

The Network panel shows resources requested by the

webpage.
Open:

Network

Then refresh the page.

You may see requests for:

Document
Stylesheet
Script
Image
Font

Remember Lesson 0.1?

One webpage can involve multiple resources.

Now you're seeing that concept in practice.

For our page:

[Link]
↓
[Link]
↓
[Link]

The Network panel lets you observe those requests.

29. Network Status Codes

You may eventually see:

200
404
500

For example:

200 OK

generally indicates a successful request.

404 Not Found

indicates the requested resource wasn't found.

Imagine:

[Link] ✅
[Link] ❌

You might see a failed request for the stylesheet.

This tells you:

"The browser tried to get the file, but it couldn't find it at that
address."

Then you inspect your path.

For example:

<link rel="stylesheet" href="[Link]">

But your actual file is:

[Link]

The mismatch is:

[Link]
≠
[Link]

DevTools helps you find this.

30. Sources Panel

The Sources panel allows you to inspect loaded source files

and, later, debug JavaScript using breakpoints.

For example, you may see:

[Link]
[Link]
[Link]

As we move deeper into JavaScript, you'll use it to:

 Set breakpoints
 Pause JavaScript
 Inspect variables
 Step through code
 Understand execution

For now, just know it exists.

31. Console Errors

Let's intentionally create a bug.

Change your JavaScript:

const button = [Link]("#testButton");

const message = [Link]("#message");

[Link]("click", () => {
[Link] = "JavaScript is working! 🎉";
});

to:

const button = [Link]("#doesNotExist");

[Link]("click", () => {
[Link]("Hello");
});

Save.

Reload.

Open Console.

You'll likely see an error because:

[Link]("#doesNotExist")
returns:

null

There is no element with that ID.

Then you're doing:

[Link](...)

which doesn't work.

This is one of the earliest JavaScript debugging lessons:

Read the error.

Do not immediately panic.

32. The Three Places to Look When Something Breaks

Whenever your website isn't working, check:

1. VS Code
↓
Is my source code correct?

2. Browser
↓
Does the page visually look correct?

3. DevTools
↓
Are there errors or failed requests?

This becomes:

Code
↓
Browser
↓
DevTools

Your debugging workflow.

33. Three Categories of Errors

You'll encounter three broad types of problems.

1. Syntax errors

You wrote code incorrectly.

Example:

const message =

This is incomplete.

2. Logic errors

Your code runs but doesn't do what you intended.

Example:

if (age > 18) {

[Link]("Minor");
}

The syntax may be valid.

The logic is wrong.

3. Runtime errors

Something goes wrong while the code runs.

Example:

const button = null;

[Link]("click", handleClick);

The program tries to call a method on null.

We'll study errors much more deeply during JavaScript.

34. The Browser + Editor Relationship

Let's make this crystal clear.

YOU
│
▼
VS CODE
│
Write code
│
▼
FILES
│
▼
BROWSER
│
Run/render webpage
│
▼
DEVTOOLS
│
Inspect + diagnose
│
▼
YOU
│
└────── Fix code

This is your basic development ecosystem.

35. Do You Need Extensions?

VS Code has an extension system.

Extensions can add:

 Language support
 Formatting
 Debugging
 Themes
 Tools
 Framework support

But here's my advice:

Don't install extensions just because someone on

YouTube has a giant list.

For now, learn the actual web platform.

Our initial setup can be:

VS Code
+
Chrome
+
DevTools

That's enough to start learning.

Later, we can introduce tools such as:

 Prettier
 Live Server or another local development server
 Git integrations
 Framework-specific extensions

We'll add them when they solve a real problem.

36. VS Code Extensions Panel

You can open Extensions using:

Ctrl + Shift + X

You'll see the extension marketplace.

This is where extensions are searched and installed.

For now, I recommend not making extension hunting part of

your daily routine.

Your first objective is:

Learn HTML
Learn CSS
Learn JavaScript

not:

Collect 73 extensions

37. What About Live Server?

You've probably heard beginners talk about Live Server.

A local development server can be useful because it serves your

files through HTTP and can make the development experience
more convenient.

However, I don't want you to become dependent on it before

understanding how normal HTML files work.

For our course:

First

We'll learn:

Open [Link] directly

Then

We'll learn:
Run a local development server

Later

We'll learn:

Build tools
Package managers
Framework tooling

This progression is intentional.

You should understand the underlying web before relying on

development tooling.

38. Do You Need [Link]?

Not for our first basic HTML/CSS/JavaScript projects.

You can create:

[Link]
[Link]
[Link]

and open the HTML file in your browser.

Later, [Link] becomes useful for development tooling and

server-side JavaScript environments. VS Code's current broader
beginner tooling guides introduce [Link] when running and
debugging JavaScript applications, while MDN's initial
environment setup focuses first on the basic tools needed for
simple web development.

So our progression is:

Phase 0
↓
HTML/CSS/JS basics
↓
Browser + DevTools
↓
JavaScript fundamentals
↓
Git
↓
[Link]/npm
↓
Tooling
↓
Frameworks

You don't need to rush.

39. Your First Development Workflow

From now on, every project should roughly follow this process.

Step 1 — Create project folder

my-project/

Step 2 — Open folder in VS Code

File
↓
Open Folder

Step 3 — Create files

[Link]
[Link]
[Link]

Step 4 — Connect them

<link rel="stylesheet" href="[Link]">

<script src="[Link]" defer></script>

Step 5 — Write code

HTML
CSS
JavaScript
Step 6 — Save

Ctrl + S

Step 7 — Open browser

Open:

[Link]

Step 8 — Test

Click buttons.

Resize the browser.

Try interactions.

Step 9 — Open DevTools

Ctrl + Shift + I

Step 10 — Inspect

Check:

Elements
Console
Network

Step 11 — Fix

Go back to VS Code.

Repeat.

Code
↓
Browser
↓
DevTools
↓
Fix
↓
Repeat
This is your new habit.

40. Your First Debugging Lab

Now let's deliberately create problems.

This is not optional busywork.

Learning to debug early is one of the best things you can do.

Bug 1 — Broken CSS path

Change:

<link rel="stylesheet" href="[Link]">

to:

<link rel="stylesheet" href="[Link]">

But keep the actual file:

[Link]

Reload.

What happens?

Your styling disappears.

Now open:

DevTools
↓
Network

Look for the failed stylesheet.

Then fix:

<link rel="stylesheet" href="[Link]">

Bug 2 — Wrong JavaScript selector

Change:

const button = [Link]("#testButton");

to:

const button = [Link]("#wrongButton");

Reload.

Open Console.

You should encounter an error when the code tries to use the
missing element.

Fix:

const button = [Link]("#testButton");

Bug 3 — Wrong HTML ID

Change:

<p id="message">

to:

<p id="text">

But leave JavaScript as:

const message = [Link]("#message");

Now the selector can't find the element.

Fix either:

<p id="message">

or:

const message = [Link]("#text");

The IDs must match.

41. The Debugging Mindset

When something breaks, don't say:

"My website doesn't work."

That's too vague.

Instead ask:

What exactly is broken?

For example:

CSS doesn't appear.

Then:

Is the CSS file loaded?

If not:

Check Network.

Or:

Button does nothing.

Then:

Does the JavaScript run?

Check Console.

Then:

Does the button exist?

Check Elements.

Then:
Is the selector correct?

Check your JavaScript.

This turns:

😵 "Everything is broken!"

into:

🔍 "The script loaded, but the selector returns null."

Much better.

42. Browser Testing

Your website should be tested at different sizes.

Try:

Maximised browser
↓
Half-width browser
↓
Narrow browser

Later you'll learn responsive design properly.

For now, simply observe:

Does the layout still behave reasonably?

You can also use DevTools' device emulation features later to

test different viewport sizes.

This will become extremely important when we study responsive

CSS.

43. Your Tool Stack

Our beginning stack:

OPERATING SYSTEM
Windows

CODE EDITOR
VS Code

BROWSER
Google Chrome

DEVTOOLS
Chrome DevTools

FILES
HTML + CSS + JavaScript

DEBUGGING
Console + Elements + Network

Later:

VERSION CONTROL
Git

REMOTE REPOSITORY
GitHub

RUNTIME / TOOLING
[Link] + npm

LOCAL SERVER
Development server

FRAMEWORK
React or another modern framework

DEPLOYMENT
Hosting platform

We're adding complexity gradually.

44. Keyboard Shortcuts You Should Know

You don't need to memorise 50 shortcuts.

Start with these.

Save

Ctrl + S

Open folder

Ctrl + K
Ctrl + O

VS Code also provides the File → Open Folder workflow, which

is perfectly fine for beginners.

Search in file

Ctrl + F

Search across project

Ctrl + Shift + F

Command Palette

Ctrl + Shift + P

This is a powerful one.

It lets you search for VS Code commands instead of trying to

remember every menu location.

Open Extensions

Ctrl + Shift + X

Open terminal

Ctrl + `

The backtick key is usually located near the top-left of the

keyboard.
Open DevTools in Chrome

Ctrl + Shift + I

Chrome's official DevTools documentation supports opening

DevTools through the browser UI and keyboard shortcuts.

45. The Integrated Terminal

VS Code has a built-in terminal.

You can open it using:

Ctrl + `

You'll see something like:

PS C:\Users\YourName\Documents\web-development-course>

or another shell prompt depending on your configuration.

Don't panic.

This is simply a command-line interface.

We'll learn the command line gradually.

For now, one useful command is:

cd

which means:

change directory

For example:

cd web-development-course

You can also use:

dir
in Windows Command Prompt/PowerShell contexts to list files
and directories.

If you're using PowerShell, common commands may differ

slightly in behaviour, but basic navigation is straightforward.

We'll have a dedicated command-line lesson later.

46. Why Learn the Terminal?

You might wonder:

"Why not just click everything?"

You absolutely can at first.

But eventually, the terminal helps with:

 Running development servers

 Installing packages
 Using Git
 Running build commands
 Managing projects
 Automating tasks
 Working with frameworks

The terminal is not an evil hacker screen.

It's simply another interface for interacting with your computer.

GUI
↓
Click buttons

CLI
↓
Type commands

Both accomplish tasks.

We'll learn the basics later without rushing.

47. Workspace Trust

When opening an unfamiliar project, VS Code may ask whether

you trust the folder.

This matters because a project can contain code or configuration

that may execute commands through development tooling.

For your own folders that you created yourself, you generally
know what you're opening.

For code downloaded from the internet, it's wise to inspect it

before trusting or running project tooling. VS Code's
documentation specifically explains Workspace Trust as a
security mechanism for deciding whether project code should be
allowed to run with full workspace capabilities.

For now:

Your own project

↓
You know what's inside
↓
Safe learning environment

Still, develop the habit of being cautious with unfamiliar code.

48. Your Recommended Beginner Setup

I recommend:

Browser
Google Chrome

Editor
VS Code

Project folders
Documents/web-development-course/
DevTools
Chrome DevTools

Extensions
Minimal at first

[Link]
Not yet required

Git
Coming later

Frameworks
Much later

The goal is to avoid tool overload.

You are learning web development—not competing in the "who

has the most VS Code extensions" Olympics. 😂

49. Your First Complete Environment Diagram

Here's your development environment:

YOU
│
│ write code
▼
VS CODE
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
HTML CSS JavaScript
│ │ │
└──────────┼──────────┘
│
▼
FILE SYSTEM
│
 ▼
BROWSER
│
▼
RENDERED WEBSITE
│
▼
DEVTOOLS
┌──────┼──────┐
│ │ │
▼ ▼ ▼
Elements Console Network
│ │ │
└──────┼──────┘
│
▼
DEBUGGING
│
└────────→ Back to VS Code

This is your day-to-day loop.

50. Practical — Create Your Development Workspace

Now create this exact structure:

web-development-course/
│
├── 01-phase-0/
│ │
│ └── lesson-06-environment/
│ │
│ ├── [Link]
│ ├── [Link]
│ └── [Link]
│
└── projects/

Open:
web-development-course

in VS Code.

Then open:

lesson-06-environment/[Link]

in Chrome.

Test:

HTML ✅
CSS ✅
JavaScript ✅

Then open:

Ctrl + Shift + I

Test:

Elements ✅
Console ✅
Network ✅

51. Practical — Your First DevTools Investigation

Open your webpage.

Investigation 1

In Elements, find:

<h1>

Change the text temporarily.

Refresh.

Observe what happens.

Investigation 2
In Styles, change the background colour temporarily.

Refresh.

Observe what happens.

Investigation 3

Open Console.

Run:

[Link]("h1")

Then:

[Link]("h1").textContent

Then:

[Link]("h1").textContent = "DevTools Rocks!";

Observe each result.

Investigation 4

Open Network.

Reload.

Find:

[Link]
[Link]
[Link]

Observe their requests.

52. Practical — Build a Debugging Habit

Write this somewhere:

MY DEBUGGING CHECKLIST

1. What exactly is broken?

2. Does my HTML exist?
3. Does my CSS load?
4. Does my JavaScript load?
5. Is there a Console error?
6. Is there a Network error?
7. Does my selector match the HTML?
8. Is my filename correct?
9. Is my path correct?
10. Did I save the file?

You'll use this constantly.

53. Cheat Sheet

Core tools

VS Code
→ Write and manage code

Chrome
→ Run and view websites

DevTools
→ Inspect and debug websites

File Explorer
→ Manage files and folders

VS Code

Explorer
→ Files and folders
Editor
→ Write code

Terminal
→ Run commands

Extensions
→ Add functionality

Source Control
→ Git integration

Chrome DevTools

Elements
→ Inspect DOM and styles

Console
→ Run JavaScript and view errors

Network
→ Inspect resource requests

Sources
→ Inspect source and debug JavaScript

Basic workflow

Create folder
↓
Open in VS Code
↓
Create files
↓
Write code
↓
Save
↓
Open browser
↓
Test
↓
Open DevTools
↓
Debug
↓
Fix
↓
Repeat

54. Flashcards

Flashcard 1

Front: What is a code editor?

Back: Software designed to write and manage source code.

Flashcard 2

Front: What editor are we using?

Back: Visual Studio Code (VS Code).

Flashcard 3

Front: What is a workspace?

Back: The project context, commonly represented by an opened
project folder in VS Code.

Flashcard 4

Front: What is the Explorer in VS Code?

Back: The interface for viewing and managing files and folders
in a workspace.

Flashcard 5

Front: What are browser DevTools?

Back: Built-in browser tools for inspecting, debugging, and
analysing webpages.

Flashcard 6
Front: What does the Elements panel show?
Back: The current DOM and associated CSS rules.

Flashcard 7

Front: What is the Console used for?

Back: Running JavaScript experiments and viewing logs and
errors.

Flashcard 8

Front: What does the Network panel show?

Back: Requests and responses for resources loaded by the
webpage.

Flashcard 9

Front: What is the Sources panel useful for?

Back: Inspecting source files and debugging JavaScript.

Flashcard 10

Front: What is the basic development loop?

Back: Write → Save → Run → Test → Inspect → Debug → Fix →
Repeat.

55. Lesson Test

Section A — Multiple Choice

1. What is VS Code?

A. A web browser
B. A code editor
C. A database
D. A search engine

2. What is Chrome DevTools?

A. A database server
B. A browser development and debugging toolkit
C. A programming language
D. A hosting provider

3. Which panel is best for viewing the current DOM?

A. Network
B. Elements
C. Console
D. Sources

4. Which panel is commonly used to view JavaScript

errors?

A. Console
B. Network
C. Explorer
D. Elements only

5. Which panel helps you investigate a missing CSS file?

A. Network
B. Extensions
C. Settings
D. Terminal only

6. What should you generally do after modifying a source

file?

A. Turn off the computer

B. Save it and reload/test the page
C. Delete the project
D. Reinstall VS Code

7. What does the VS Code Explorer primarily show?

A. Search-engine results
B. Project files and folders
C. Browser cookies
D. CPU temperature
56. Section B — True or False

8. You need a JavaScript framework to write your first HTML

page.
9. Chrome DevTools can inspect a webpage's DOM.
10. The Console can display JavaScript errors.
11. The Network panel can help identify failed resource
requests.
12. You should immediately install dozens of VS Code
extensions.
13. The browser can be used as a development and
debugging tool.
14. VS Code can open a project folder as a workspace.
15. Refreshing the page can restore the original source
state after a temporary DevTools DOM edit.

57. Section C — Explain

16. What is the purpose of a code editor?

17. Why are we using VS Code?
18. Explain the relationship between VS Code and Chrome.
19. What is the purpose of Chrome DevTools?
20. Explain the difference between the Elements and
Console panels.
21. What is the Network panel useful for?
22. Why is debugging part of normal programming?
23. Explain your development workflow from writing code
to fixing a bug.

58. Section D — Debugging Scenarios

Scenario 1

Your page loads, but there is no styling.

You check:

[Link] ✅
[Link] ✅
[Link] ✅

What should you investigate?

Scenario 2

Your button doesn't work.

The page looks correct.

What should you check first?

Scenario 3

Your JavaScript gives:

Cannot read properties of null

What might this suggest?

Scenario 4

A file returns:

404 Not Found

What should you investigate?

59. Section E — Practical Challenge

Build a page called:

My Developer Workspace

Your page should contain:

Heading:
My Developer Workspace
Paragraph:
I am learning how to build websites.

Button:
Test My Setup

When the button is clicked:

The paragraph changes to:

"My HTML, CSS, and JavaScript are connected!"

Your project must contain:

my-developer-workspace/
├── [Link]
├── [Link]
└── [Link]

Then perform these tasks:

✅ Open the project in VS Code

✅ Open [Link] in Chrome
✅ Open DevTools
✅ Inspect the heading in Elements
✅ Change the heading temporarily
✅ Run JavaScript in Console
✅ Check Network for CSS and JS
✅ Create one deliberate bug
✅ Find the bug using DevTools
✅ Fix the bug

60. Your Phase 0 Progress

Look at how far you've come:

0.1 ✅ Internet and Web

↓
0.2 ✅ Websites and Web Applications
↓
0.3 ✅ Front End / Back End / Full Stack
 ↓
0.4 ✅ HTML + CSS + JavaScript
↓
0.5 ✅ Files, Folders, Paths
↓
0.6 ✅ Development Environment

You now understand not only what web development is, but
also where and how you actually do it.

Your full mental model is becoming:

WEB DEVELOPMENT
│
▼
BROWSER
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
HTML CSS JavaScript
│ │ │
▼ ▼ ▼
DOM Styles Events
│ │ │
└────────────────┼────────────────┘
│
▼
RENDERED PAGE
│
▼

↙ ↘
DEVTOOLS
↓

↘ ↙
Elements Console Network
↓
DEBUGGING
│
▼
VS CODE
│
└──────→ Repeat
The big takeaway

Your job as a beginner is not to memorise every feature inside

VS Code or Chrome DevTools.

Your goal is to develop this habit:

Write code → run it → observe the result → inspect what

happened → fix what's wrong.

That habit is more valuable than memorising a hundred

shortcuts.

-------------------------------------X------------------------------------------

Lesson 0.7

Browser Developer Tools — Your First Real Debugging Lab

Alright, bro. This is a big milestone.
Up to now, you've learned what the web is, how websites are
structured, how HTML/CSS/JavaScript work together, how files
and paths work, and how to set up your coding environment.
Now we're going to learn one of the most important tools a
front-end developer uses every single day:
Browser Developer Tools, usually called DevTools.
Chrome DevTools is a set of web-development tools built
directly into Chrome. It lets you inspect and edit the current
page, examine network activity, run and debug JavaScript, and
investigate problems. MDN also describes browser developer
tools as a core way to inspect HTML, CSS, JavaScript, and the
resources a page loads.
This lesson is going to be very practical.
By the end, you should be able to look at a broken webpage and
start thinking:
What exactly is broken?
↓
Is it HTML?
 ↓
Is it CSS?
↓
Is JavaScript running?
↓
Is the browser finding my files?
↓
Is the DOM what I expect?
↓
What does the Console say?
↓
What does Network say?
↓
What can I inspect in Sources?
That is the beginning of real debugging.

What you'll learn

Today we'll cover:

1. What DevTools are

2. How to open DevTools
3. How to dock and undock DevTools
4. The Elements panel
5. The DOM tree
6. Inspecting elements
7. Editing HTML live
8. Editing CSS live
9. Understanding the Styles panel
10. Understanding the Computed panel
11. Understanding the Box Model
12. The Console
13. [Link]()
14. Reading errors
 15. Running JavaScript manually
16. The Network panel
17. Understanding request types
18. Status codes
19. The Sources panel
20. Finding source files
21. Breakpoints — introduction
22. Your first complete debugging workflow
23. Three deliberate bugs
24. A full debugging practical
25. Cheat sheet
26. Flashcards
27. Test

1. What Exactly Are DevTools?

Imagine your webpage is a car.
A normal user sees:
🚗
They can drive it.
But a mechanic needs to see:
Engine
Fuel
Battery
Sensors
Computer diagnostics
DevTools are kind of like the mechanic's toolkit for your
webpage.
The visitor sees:
Website
You, the developer, can inspect:
HTML
CSS
JavaScript
DOM
Network requests
Console messages
Source files
Performance information
Chrome DevTools provides tools for inspecting the page and
diagnosing problems, while the browser itself remains the
environment running your HTML, CSS, and JavaScript.

2. The DevTools Mental Model

Think of your development setup as:
YOU
│
▼
VS CODE
│
Write code
│
▼
FILES
│
▼
BROWSER
│
┌────────┼────────┐
│ │ │
▼ ▼ ▼
 HTML CSS JS
│ │ │
└────────┼────────┘
│
▼
WEBPAGE
│
▼
DEVTOOLS
┌──────┼──────┐
│ │ │
▼ ▼ ▼
Elements Console Network
│ │ │
└──────┼──────┘
│
▼
DEBUG
│
▼
VS CODE
Your workflow becomes:
Write
↓
Run
↓
Observe
↓
Inspect
↓
Diagnose
↓
Fix
↓
Verify
That's the cycle.

3. Opening Chrome DevTools

Open your project from Lesson 0.6.
You should have something like:
lesson-06-environment/
├── [Link]
├── [Link]
└── [Link]
Open [Link] in Chrome.
To open DevTools, you can use:
Ctrl + Shift + I
You can also open the Chrome menu and choose the Developer
Tools option from the relevant tools menu. Chrome's official
documentation lists both menu-based and keyboard-based ways
to open DevTools.
You should see something like:
┌─────────────────────────────────────────┐
│ YOUR WEBPAGE │
│ │
│ Hello, Developer! │
│ │
├─────────────────────────────────────────┤
│ DEVTOOLS │
│ Elements Console Network Sources ... │
│ │
│ Inspection area │
│ │
└─────────────────────────────────────────┘
The exact layout can vary depending on your browser version,
screen size, and DevTools docking settings.

4. The Four Panels You Need First

For now, focus on:
Elements
Console
Network
Sources
Their basic jobs are:
Elements
↓
Inspect page structure and CSS

Console
↓
Run JavaScript and read messages/errors

Network
↓
Inspect resource requests

Sources
↓
Inspect source files and debug JavaScript
Chrome's official documentation describes Elements as the
place to inspect and edit the DOM, Console as a place to view
messages and run JavaScript, Network as a tool for inspecting
resource activity, and Sources as a place to inspect resources
and debug JavaScript.

5. The Elements Panel

Click:
Elements
This is where you'll spend a lot of time as a front-end developer.
The Elements panel gives you an interactive view of the current
DOM and lets you inspect and temporarily manipulate elements
and their styles. Chrome's documentation also exposes CSS
rules, computed styles, layout information, event listeners, and
DOM breakpoints from this area.
You may see:
<html>
<head>
...
</head>

<body>
<main>
<h1>My Development Environment</h1>
 <p id="message">
I am learning web development.
</p>

<button id="testButton">
Test JavaScript
</button>
</main>
</body>
</html>
Notice how this resembles your HTML.
But remember:
This is the current DOM representation, not simply a text editor
showing your original source file.
JavaScript may have changed the DOM after the page loaded.

6. Your First DOM Inspection

Find:
<h1>My Development Environment</h1>
Click the <h1> element.
You may see the selected element highlighted in the webpage.
This gives you a direct connection:
DOM element
↕
Visible element
You can see:
What element is this?
What classes does it have?
What IDs does it have?
What CSS rules affect it?
That's enormously useful.

7. Selecting an Element From the Page

DevTools includes an element-selection tool.
Look for an icon resembling:
↖
or an inspection pointer.
Click it.
Then move your mouse over the page.
You should see different elements highlighted.
For example:
<h1>
<p>
<button>
<main>
Click the heading.
DevTools should jump to that element in the Elements panel.
This creates a very useful loop:
See something on page
↓
Inspect it
↓
Find its DOM element
↓
See its CSS
↓
Understand why it looks that way
This is one of the quickest ways to explore an unfamiliar
website.

8. Editing HTML Live

Find:
<h1>My Development Environment</h1>
Double-click the text.
Change it to:
Welcome to DevTools!
You should immediately see:
Welcome to DevTools!
on the page.
That is a live temporary change.
Now refresh:
Ctrl + R
What happens?
Your original heading returns.
Why?
Because you modified the current DOM inside the browser, not
the source file saved on your computer.
The conceptual flow is:
[Link]
↓
Browser loads it
↓
DOM created
↓
DevTools changes DOM
↓
Page changes
↓
Refresh
↓
[Link] loaded again
↓
Original content returns
Chrome's Elements panel is specifically intended for inspecting
and editing the current DOM, making this kind of temporary
experimentation a normal part of the tool.

9. Why Temporary Editing Is Useful

You might ask:
"If the change disappears, why bother?"
Because it is incredibly useful for experimentation.
Imagine you want to test:
Should this heading be larger?
Should this button be blue?
Should this section have more spacing?
Should this element be hidden?
Instead of changing your actual code immediately, you can test
the idea in DevTools.
For example:
Idea
↓
Temporary DevTools change
↓
Looks good?
↓
Copy final change into VS Code
This is much faster than constantly editing your source file just
to test tiny design ideas.

10. Editing CSS Live

In the Elements panel, select your:
<h1>
Look at the Styles area.
You may see rules such as:
h1 {
margin-top: 0;
}
Now try adding:
color: purple;
You should immediately see the heading change colour.
Try:
font-size: 50px;
Try:
letter-spacing: 2px;
Try:
text-transform: uppercase;
You are now experimenting with CSS without opening your
actual CSS file.
11. CSS Declarations
Remember:
h1 {
color: purple;
font-size: 50px;
}
The individual lines:
color: purple;
and:
font-size: 50px;
are CSS declarations.
You can temporarily:

 Add them
 Remove them
 Change their values
 Disable them

This lets you investigate exactly which CSS rule is producing a

visual result.

12. Disabling a CSS Rule

Suppose you have:
button {
padding: 10px 16px;
}
In DevTools, you can temporarily uncheck the declaration.
The padding disappears.
Check it again.
The padding returns.
This teaches you something powerful:
You can experimentally isolate which CSS rules affect an
element.
Chrome's Styles interface also helps identify overridden, invalid,
and inactive CSS rules.

13. CSS Rules Can Be Overridden

Consider:
button {
color: red;
}

button {
color: blue;
}
Depending on the cascade and other factors, one rule may win
over another.
DevTools will often show the overridden rule crossed out.
You might see:
color: red; /* crossed out */
and:
color: blue; /* active */
This is your first real glimpse of the:
Cascading in Cascading Style Sheets.
The browser is applying rules and resolving conflicts.
We'll study the CSS cascade deeply during Phase 2.
For now:
Rule exists
↓
Browser compares competing rules
↓
Winning rule is applied
↓
Other rule may be overridden
DevTools is one of the easiest ways to see this process
happening.

14. The Computed Panel

Select an element.
Find:
Computed
The Computed panel shows the final resolved CSS property
values as rendered by Chrome.
For example, a button might have:
color: rgb(...)
display: inline-block
font-size: 16px
margin-top: 10px
padding-left: 16px
width: ...
height: ...
This answers a very useful question:
What value is actually being applied right now?
Chrome's Elements documentation describes Computed as a list
of resolved properties applied to an element as rendered.
15. Styles vs Computed
Think of it like this.

Styles

"What CSS rules are contributing?"

Computed

"What final values did the browser resolve?"

This distinction becomes extremely useful when your CSS
behaves unexpectedly.
Suppose you think:
font-size: 32px;
is active.
But Computed says:
font-size: 16px
Then something else is affecting the final result.
You investigate.
Maybe:

 Your selector didn't match

 Another rule won
 A media query changed it
 Inheritance affected it
 The declaration was invalid

DevTools helps you trace that.

16. The Box Model

Now inspect an element.
Look for the box-model visualization.
You'll typically see:
 margin
┌─────────────────┐
│ │
│ border │
│ ┌───────────┐ │
│ │ padding │ │
│ │ ┌───────┐ │ │
│ │ │content│ │ │
│ │ └───────┘ │ │
│ └───────────┘ │
│ │
└─────────────────┘
This is the CSS box model.
The major layers are:
Content
Padding
Border
Margin
For example:
button {
margin: 20px;
padding: 10px;
border: 2px solid;
}
The browser calculates how all of these contribute to the
element's final dimensions and spacing.
Chrome DevTools exposes box-model inspection directly in the
Elements panel.
We'll study the CSS box model properly in our CSS phase.
For now, remember:
Content
↓
Padding
↓
Border
↓
Margin

17. The box-sizing Connection

Earlier we used:
*{
box-sizing: border-box;
}
The box model helps you understand why developers often care
about this property.
Imagine:
width: 200px;
padding: 20px;
border: 5px solid;
Depending on box-sizing, the relationship between the declared
width and final rendered dimensions changes.
Don't worry about calculating this yet.
The important point is:
DevTools lets you inspect the result instead of guessing.
That is the beginning of developer-level debugging.
18. Event Listeners
In the Elements panel, you may find an:
Event Listeners
section.
This can help you inspect event handlers associated with an
element.
For example:
button
↓
click listener
↓
[Link]
This becomes useful when:
"I clicked the button. Why didn't anything happen?"
You may investigate:
Does the button exist?
↓
Does it have a click listener?
↓
Where is the listener defined?
↓
Does the listener execute?
Chrome's Elements panel documentation includes an Event
listeners view that can show associated listeners and help reveal
their source.
We'll go deeper into events during JavaScript.

19. The Console

Now open:
Console
The Console has two major uses:
1. View messages and errors
2. Run JavaScript
Chrome's official documentation explicitly describes these as the
Console's two primary uses.
This makes the Console incredibly important.

20. Your First Console Experiments

Type:
2+2
Expected result:
4
Now:
"Hello" + " " + "Bro"
Expected:
"Hello Bro"
Try:
[Link]
You should get the current page title.
Try:
[Link]
You should get a reference to the document's <body> element.
Try:
[Link]("h1")
You should get your <h1> element.
This is the DOM in action.
MDN describes the DOM as the browser-facing object model for
document structure and related browser functionality, while the
Console provides a way to execute JavaScript in the page's
environment.

21. Change the Page With the Console

Run:
[Link]("h1").textContent = "Hello from the
Console!";
Your heading should change.
Now:
[Link]("body").[Link] = "lightblue";
Your page background should change.
Try:
[Link]("button").[Link] = "24px";
Your button should become larger.
You just used JavaScript to manipulate:
DOM
+
Styles
This connects everything we've learned.

22. [Link]()
One of the most important debugging tools in JavaScript is:
[Link]()
Example:
const name = "Bro";

[Link](name);
You'll see:
Bro
MDN documents [Link]() as one of the Console API
methods used to output messages to the debugging console.
This helps answer:
"Is my code reaching this point?"
For example:
[Link]("Script started");
Then:
[Link]("Button found");
Then:
[Link]("Click event fired");
You can track execution.

23. Debugging With [Link]()

Imagine:
const button = [Link]("#testButton");

[Link](button);
If the Console shows something like:
<button id="testButton">
great.
But if you see:
null
then your selector didn't find the element.
Now you know the problem.
You can investigate:
Is the ID correct?
Is the HTML element present?
Did the script run?
Is the selector correct?
This is a much better debugging approach than randomly
changing code.

24. Console Log Levels

You may encounter:
[Link]("Normal message");
[Link]("Information");
[Link]("Warning");
[Link]("Error");
DevTools can categorize these messages by severity and lets
you filter by log level.
For now, mainly use:
[Link]()
and:
[Link]()
Later, you'll use more advanced debugging techniques.

25. Reading Console Errors

Let's deliberately create an error.
Change:
const button = [Link]("#testButton");
to:
const button = [Link]("#doesNotExist");
Now your code tries to do:
[Link](...)
But button is:
null
The Console may display an error similar to:
Cannot read properties of null
Don't be scared by this.
Read the error as a message from the browser.
It is essentially saying:
"You tried to use something as though it existed, but I couldn't
find it."
That gives you a clue.

26. Understanding an Error Message

An error often contains:
Error message
+
File name
+
Line number
For example:
[Link]
This means the browser can often tell you:
"The problem appears around line 5 in [Link]."
You can click the link in DevTools and jump toward the source
location.
Chrome's Console can also show stack traces for errors, helping
you trace the chain of calls that led to a problem.
27. Don't Just Read the Last Word of the Error
Beginners often see:
TypeError
and panic.
Instead, break it apart.
Ask:
What happened?
Where did it happen?
Which file?
Which line?
What value was involved?
For example:
Cannot read properties of null
Ask:
What is null?
If you have:
const button = [Link]("#doesNotExist");
then:
button === null
Now the problem becomes understandable.

28. A Debugging Mindset

Never think:
"The computer is stupid."
Instead think:
"The computer did exactly what I told it to do. What assumption
did I make that was wrong?"
That mindset is extremely powerful.
Example:
const button = [Link]("#button");
You assumed:
#button exists
Reality:
#button does not exist
The bug is the mismatch between your assumption and reality.
DevTools helps you find that mismatch.

29. The Network Panel

Now open:
Network
Then reload:
Ctrl + R
The Network panel records network requests while DevTools is
open, and Chrome's documentation provides tools for filtering,
inspecting, and analysing those requests.
You may see:
Name
Status
Type
Initiator
Size
Time
For our project, you might see requests resembling:
[Link]
[Link]
[Link]
If you have images:
[Link]
[Link]
you may see those too.

30. What Is a Network Request?

When the browser needs a resource, it requests it.
For example:
Browser
↓
"Give me [Link]"
↓
Server / File system
↓
"Here is [Link]"
In a larger website:
HTML
↓
CSS
↓
JavaScript
↓
Images
↓
Fonts
↓
API requests
The Network panel lets you observe this activity.
This is why it is extremely useful for debugging missing files and
API problems. Chrome's Network documentation specifically
focuses on inspecting requested resources and network activity.

31. Filter Network Requests

The Network panel can contain a lot of information.
You may have filters such as:
All
Fetch/XHR
Doc
CSS
JS
Img
Font
For your current stage, the most useful ones are:
Doc
CSS
JS
Img
Fetch/XHR
For example:
CSS
↓
Find stylesheet requests

JS
↓
Find JavaScript files

Img
↓
Find image requests

Fetch/XHR
↓
Find API/data requests
We'll study Fetch/XHR in depth when we reach APIs.

32. The Status Column

You may see:
200
304
404
500
Common beginner meanings:
200
↓
Request succeeded

404
↓
Resource not found

500
↓
Server-side error
These numbers are HTTP status codes.
For now, focus mainly on:
200 → Successful
404 → Not Found
Imagine:
[Link] 200
[Link] 404
[Link] 200
Your webpage loads.
Your JavaScript works.
But your CSS doesn't.
That immediately points you toward:
[Link]
Then inspect:
Request URL
Maybe your HTML says:
<link rel="stylesheet" href="[Link]">
but the file is:
[Link]
There's your bug.

33. Network Request Details

Click a request such as:
[Link]
You may see information including:
Headers
Preview
Response
Timing
Don't worry about mastering every tab yet.
The important beginner skill is learning to ask:
Did the browser request the file?

What URL did it request?

Did the request succeed?

What response came back?

That's enough for now.

34. Your First Network Debugging Lab

Let's deliberately break your CSS.
In HTML, change:
<link rel="stylesheet" href="[Link]">
to:
<link rel="stylesheet" href="[Link]">
Save.
Open Network.
Reload.
Now look for:
[Link]
You should see a failed request or a not-found result, depending
on how you're loading your local file.
This demonstrates:
HTML says:
"Load [Link]"

Browser:
"Okay, I'll try."

Browser:
"Can't find it."

Network:
"Here's the failed request."
Now fix:
<link rel="stylesheet" href="[Link]">
Reload.
Verify the correct stylesheet loads.
Congratulations.
You just used DevTools to diagnose a real bug.

35. The Sources Panel

Now open:
Sources
The Sources panel can show loaded resources such as:
HTML
CSS
JavaScript
Images
It also supports JavaScript debugging and can be used to create
snippets and workspaces with more advanced configurations.
For now, focus on:
Finding source files
Reading JavaScript
Setting breakpoints

36. What Is a Breakpoint?

Imagine JavaScript is running:
const name = "Bro";

const age = 15;

const message = "Hello";

[Link](message);
Normally the browser executes this code automatically.
A breakpoint tells the debugger:
"Pause execution here."
Then you can inspect:
Variables
Values
Execution state
Call stack
Chrome's Sources tools support JavaScript debugging and
breakpoints.
We'll learn proper breakpoints later during the JavaScript phase.
For now, I want you to understand:
Normal execution
↓
Code runs continuously

Breakpoint
↓
Execution pauses
↓
You inspect what's happening
This is much more powerful than just adding hundreds of
[Link]() statements.

37. [Link]() vs Breakpoint

Suppose you have:
const username = "Bro";
const score = 95;

if (score > 80) {

[Link]("High score");
}
With [Link]():
[Link](username);
[Link](score);
You manually print values.
With a breakpoint:
Pause here
↓
Inspect username
Inspect score
Inspect conditions
Step through code
Both are useful.
Our progression will be:
Console
↓
[Link]()
↓
Sources
↓
Breakpoints
↓
Advanced debugging

38. A Complete Debugging Scenario

Let's say your button doesn't work.
The webpage looks correct.
You click:
[Test JavaScript]
Nothing happens.
What do you do?

Step 1 — Observe

Button visible ✅
Button clickable ✅
No response ❌

Step 2 — Check Console

Open:
Console
Do you see an error?
If yes:
Read error
↓
Find file
↓
Find line
↓
Investigate

Step 3 — Check DOM

In Elements:
Does button exist?
Maybe:
<button id="testButton">

Step 4 — Check JavaScript

In Sources or VS Code:
[Link]("#testButton")
Does the selector match?

Step 5 — Test Console

Run:
[Link]("#testButton")
If result:
null
You found the problem.
Step 6 — Check IDs

HTML:
id="testButton"
JavaScript:
"#testButton"
Do they match exactly?

Step 7 — Verify

Fix the code.

Reload.
Click.
Confirm the button works.
This is debugging.

39. Debugging Is a Process, Not Guesswork

Here's the process I want you to memorise:
REPRODUCE
↓
OBSERVE
↓
INSPECT
↓
FORM A HYPOTHESIS
↓
TEST THE HYPOTHESIS
↓
FIX
↓
VERIFY
Let's break it down.

Reproduce

Can you make the problem happen consistently?

Observe

What exactly happens?

Inspect

Use DevTools.

Hypothesis

What do you think is wrong?

Test

Check whether your theory matches reality.

Fix

Change your actual source code.

Verify

Test again.
This is much better than:
Change random code
↓
Refresh
↓
Still broken
↓
Change more random code
↓
😵
Never debug by randomly changing ten things at once.
Change one meaningful thing.
Then test.

40. The Golden Rule of Debugging

Change one thing at a time.
Imagine the page is broken.
You simultaneously change:
HTML
CSS
JavaScript
Folder names
File paths
Now it works.
Congratulations.
You have no idea why.
😂
Instead:
Hypothesis:
The JavaScript selector is wrong.

Test:
Check selector.

Result:
Selector is wrong.
Fix:
Correct selector.

Verify:
Button works.
Now you know exactly what happened.

41. Deliberate Bug Lab #1 — HTML/JavaScript Mismatch

Start with:
<button id="testButton" type="button">
Test JavaScript
</button>
JavaScript:
const button = [Link]("#testButton");

[Link]("click", () => {
[Link]("Button clicked");
});
Everything works.
Now change HTML to:
<button id="testBtn" type="button">
Test JavaScript
</button>
Don't change JavaScript.
Reload.
Click the button.
Nothing happens.
Open Console.
Investigate:
[Link]("#testButton")
Result:
null
Now investigate actual HTML:
id="testBtn"
There is the mismatch.

Fix

Either:
id="testButton"
or:
[Link]("#testBtn")

42. Deliberate Bug Lab #2 — CSS File Path

Project:
lesson-06-environment/
├── [Link]
├── [Link]
└── [Link]
HTML:
<link
rel="stylesheet"
href="css/[Link]"
>
But there is no css folder.
Reload.
The styling should disappear.
Open:
Network
Find:
[Link]
Investigate the requested location.
The browser is looking for:
css/[Link]
But your actual file is:
[Link]
Fix:
<link
rel="stylesheet"
href="[Link]"
>
Verify.

43. Deliberate Bug Lab #3 — JavaScript Syntax Error

Change your JavaScript to:
const button = [Link]("#testButton"

[Link]("click", () => {
[Link]("Hello");
});
Save.
Reload.
Open Console.
You should see a syntax-related error.
Look at:
File name
Line number
Error message
The problem is that the first line is missing:
)
Correct code:
const button = [Link]("#testButton");

[Link]("click", () => {
[Link]("Hello");
});
Now reload.
The script should run again.

44. The Three Most Important Debugging Questions

When a JavaScript interaction doesn't work, ask:

Question 1

Did the JavaScript file load?

Check:
Network

Question 2

Did JavaScript produce an error?

Check:
Console
Question 3

Does JavaScript find the correct DOM element?

Check:
[Link](...)
This simple sequence solves a surprising number of beginner
bugs.

45. Your First Full Debugging Workflow

Imagine this project:
my-project/
├── [Link]
├── [Link]
└── [Link]

HTML

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">

<meta
name="viewport"
content="width=device-width, initial-scale=1.0"
>

<title>Debugging Practice</title>

<link rel="stylesheet" href="[Link]">

 <script src="[Link]" defer></script>
</head>

<body>
<main>
<h1 id="title">Debugging Practice</h1>

<p id="message">
Click the button.
</p>

<button id="actionButton" type="button">

Click Me
</button>
</main>
</body>
</html>

CSS

body {
font-family: system-ui, sans-serif;
}

main {
max-width: 600px;
margin: 40px auto;
padding: 24px;
}

JavaScript

const button = [Link]("#actionButton");

const message = [Link]("#message");

[Link]("click", () => {
[Link] = "Button clicked!";
});
Now let's pretend the button isn't working.
Your debugging process:
1. Click button
↓
2. Nothing happens
↓
3. Open Console
↓
4. Check for errors
↓
5. Check Network
↓
6. Confirm [Link] loaded
↓
7. Inspect button in Elements
↓
8. Check id="actionButton"
↓
9. Run querySelector in Console
 ↓
10. Inspect JavaScript
↓
11. Fix
↓
12. Reload
↓
13. Test again
That process is now part of your skillset.

46. A Very Useful Console Trick

Suppose you've selected an element in the Elements panel.
Chrome DevTools provides a special reference called:
$0
In the Console, $0 refers to the currently selected DOM element
in the Elements panel.
So if you select your button, you can try:
$0
Then:
$[Link]
And:
$[Link]
This can be incredibly convenient when exploring a page.
This is a DevTools convenience feature, not standard JavaScript
syntax you should use in normal application code.

47. Inspecting an Element With the Console

Suppose $0 refers to:
<button id="testButton">
Test JavaScript
</button>
Try:
$[Link]
You may get:
"BUTTON"
Try:
$[Link]
You may get:
"testButton"
Try:
$[Link]
You may get:
"Test JavaScript"
This is another way to connect:
DOM
↕
JavaScript

48. Don't Confuse DevTools Changes With Real Code Changes

This is a crucial rule.

DevTools:

Temporary experimentation

VS Code:

Permanent source-code changes

Example:
You change:
background: yellow;
in DevTools.
You like it.
Now update:
[Link]
in VS Code.
Then save.
That's the permanent change.
Think:
DevTools
↓
Experiment

VS Code
↓
Commit the actual change
Unless you've deliberately configured a workspace workflow,
DevTools edits are not your normal source-of-truth workflow.
Chrome's Sources documentation describes more advanced
workspaces that can save DevTools changes to files, but that is
beyond our beginner setup for now.

49. Elements vs Sources

This distinction can be confusing.

Elements

You're looking at:

Current DOM
You can inspect:
Current structure
Current styles
Layout
Events

Sources

You're looking at:

Loaded source resources
You can inspect:
JavaScript
CSS
Images
Other loaded resources
and use debugging tools such as breakpoints.
Chrome documents the Elements panel as a DOM
inspection/editing tool and Sources as a source/resource viewing
and JavaScript debugging environment.

50. Elements vs View Source

This is another important distinction.
You may right-click a webpage and find:
View Page Source
That typically shows the original HTML source delivered to the
browser.
DevTools Elements shows the current DOM.
If JavaScript changes:
<h1>Hello</h1>
into:
<h1>Welcome</h1>
then:
Page Source
↓
Hello

Current DOM
↓
Welcome
This is why DevTools is often more useful for understanding the
current state of an interactive webpage.

51. A Professional Debugging Mental Model

Imagine your webpage has four layers:
LAYER 1
HTML
↓
Does the element exist?

LAYER 2
CSS
↓
Does the element look correct?

LAYER 3
JavaScript
↓
Does the interaction run?
LAYER 4
Network
↓
Did required files/data arrive?
Then use:
Elements
↓
HTML + CSS

Console
↓
JavaScript errors/logs

Network
↓
Files + requests

Sources
↓
JavaScript execution
This is a very useful mental map.

52. Debugging Decision Tree

When something breaks:
Something doesn't work
│
 ▼
Is the page visible?
│ │
NO YES
│ │
▼ ▼
Check HTML What is broken?
and Network │
├─────────────┐
│ │
▼ ▼
Styling Interaction
│ │
▼ ▼
Elements Console
│ │
▼ ▼
CSS rules JS errors
│
▼
Sources
│
▼
Breakpoint
You don't need to memorise this exactly.
The point is:
Choose the DevTools panel based on the problem you're
investigating.
53. The Most Common Beginner Debugging Mistakes

Mistake 1: Not checking the Console

If JavaScript isn't working:

Console
should often be one of your first stops.

Mistake 2: Randomly changing code

Don't change 10 things simultaneously.

Change one thing.
Test.

Mistake 3: Ignoring the exact error

Read the actual error message.

The error often contains a useful clue.

Mistake 4: Forgetting to save the source file

You changed:
[Link]
but forgot:
Ctrl + S
Then you blame the browser.
Classic beginner moment. 😂

Mistake 5: Looking only at the visual result

A webpage can look correct while the Console contains an error.
Always check both:
Visual result
+
DevTools

Mistake 6: Confusing DevTools edits with source edits

You changed the DOM in DevTools.

Then refreshed.
The change disappeared.
That's expected.

54. Your First Debugging Project

Create:
debugging-lab/
├── [Link]
├── [Link]
└── [Link]
Use this HTML:
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">

<meta
name="viewport"
content="width=device-width, initial-scale=1.0"
 >

<title>Debugging Lab</title>

<link rel="stylesheet" href="[Link]">

<script src="[Link]" defer></script>

</head>

<body>
<main>
<h1 id="title">Debugging Lab</h1>

<p id="message">
Press the button.
</p>

<button id="debugButton" type="button">

Press Me
</button>
</main>
</body>
</html>
CSS:
body {
margin: 0;
min-height: 100vh;
 display: grid;
place-items: center;
font-family: system-ui, sans-serif;
}

main {
width: min(90%, 600px);
padding: 32px;
text-align: center;
}

button {
padding: 12px 18px;
font: inherit;
cursor: pointer;
}
JavaScript:
const button = [Link]("#debugButton");
const message = [Link]("#message");

[Link]("click", () => {
[Link] = "You successfully debugged the
page!";
});

55. Debugging Lab Mission 1

First, verify:
HTML ✅
CSS ✅
JavaScript ✅
Then:
Open DevTools
↓
Elements
↓
Inspect h1
↓
Inspect button
↓
Change h1 text
↓
Change button padding
↓
Refresh
↓
Observe changes disappear

56. Debugging Lab Mission 2

Open Console.
Run:
[Link]("#debugButton")
Then:
[Link]("#message")
Then:
[Link]("#missingElement")
Observe the difference.
You should see something like:
Existing element
↓
Element object

Missing element
↓
null
This is extremely important.

57. Debugging Lab Mission 3

Break the JavaScript.
Change:
"#debugButton"
to:
"#wrongButton"
Reload.
Now debug it.
Your process must be:
1. Reproduce
2. Console
3. Read error
4. Check Elements
5. Compare IDs
6. Fix source
7. Save
8. Reload
9. Verify
Do not immediately look at the answer.
Try to diagnose it yourself.

58. Debugging Lab Mission 4

Break CSS.
Change:
href="[Link]"
to:
href="[Link]"
Reload.
Open:
Network
Find the failed request.
Then restore:
href="[Link]"
Reload again.
Verify that the stylesheet loads.

59. Debugging Lab Mission 5

Break the JavaScript syntax.
Write:
const button = [Link]("#debugButton"

[Link]("click", () => {
[Link]("Clicked");
});
Reload.
Open Console.
Read the error.
Identify:
Where?
What?
Why?
Then fix:
const button = [Link]("#debugButton");

[Link]("click", () => {
[Link]("Clicked");
});

60. Your First "Think Like a Developer" Exercise

Imagine a user reports:
"The login button appears, but clicking it does nothing."
What questions would you ask?
Try:
1. Is the button actually present?
2. Does the JavaScript file load?
3. Is there a Console error?
4. Is an event listener attached?
5. Is the selector correct?
6. Does the click event fire?
7. Does the event handler contain an error?
8. Does the button call an API?
9. Did the API request succeed?
Notice how the investigation expands.
A simple button could involve:
HTML
↓
CSS
↓
JavaScript
↓
Event
↓
API
↓
Server
↓
Database
That's why debugging is a core developer skill.

61. Debugging Is Layered

A modern application may look like:
USER
↓
UI
↓
HTML
↓
CSS
↓
JavaScript
↓
DOM
↓
API request
↓
Server
↓
Database
If something fails, you need to locate which layer failed.
For example:
Button visible
✅ HTML

Button looks correct

✅ CSS

Click detected
✅ JavaScript event

API request sent

✅ Network

Server returns error

❌ Back end
At that point, changing CSS won't help.
That's why professional debugging is about isolating the failing
layer.

62. Your Core DevTools Cheat Sheet

Elements

Use when:
Inspect HTML
Inspect DOM
Inspect CSS
Inspect layout
Inspect box model
Inspect event listeners

Console

Use when:
Run JavaScript
View errors
View warnings
Use [Link]()
Inspect values
Test selectors

Network

Use when:
Check resource loading
Find 404 errors
Inspect CSS/JS/image requests
Inspect API requests
Check response status

Sources

Use when:
Inspect source files
Debug JavaScript
Set breakpoints
Pause execution
Inspect execution state

63. The Ultimate Beginner Debugging Checklist

When something breaks:
┌──────────────────────────────────────┐
│ DEBUGGING CHECKLIST │
├──────────────────────────────────────┤
│ 1. What exactly is broken? │
│ 2. Can I reproduce it? │
│ 3. Did I save the file? │
│ 4. Is the HTML correct? │
│ 5. Is the CSS loaded? │
│ 6. Is the JavaScript loaded? │
│ 7. Is there a Console error? │
│ 8. Does the DOM element exist? │
│ 9. Is my selector correct? │
│10. Did a network request fail? │
│11. What does the error actually say? │
│12. Did my fix actually work? │
└──────────────────────────────────────┘

64. Flashcards

Flashcard 1

Front: What are DevTools?

Back: Browser-provided development tools used to inspect, test,
and debug webpages and web applications.

Flashcard 2

Front: What is the Elements panel used for?

Back: Inspecting and temporarily editing the current DOM and
investigating associated CSS.

Flashcard 3

Front: What is the Console used for?

Back: Viewing messages and errors and running JavaScript.

Flashcard 4

Front: What is the Network panel used for?

Back: Inspecting network requests and resources loaded by a
webpage.

Flashcard 5

Front: What is the Sources panel used for?

Back: Viewing loaded source files and debugging JavaScript.

Flashcard 6

Front: What does [Link]() do?

Back: Outputs a value or message to the debugging console.

Flashcard 7
Front: What does null often mean when using querySelector()?
Back: No matching element was found.

Flashcard 8

Front: What does a 404 generally indicate?

Back: The requested resource was not found at that location.

Flashcard 9

Front: What is a breakpoint?

Back: A debugging point where execution can pause so you can
inspect the program's state.

Flashcard 10

Front: Are DevTools changes automatically permanent source-

code changes?
Back: Normally no; typical DevTools edits are temporary unless
using advanced workspace configurations.

Flashcard 11

Front: What does the Computed panel show?

Back: Resolved CSS property values applied to an element as
rendered.

Flashcard 12

Front: What is the basic debugging cycle?

Back: Reproduce → Observe → Inspect → Hypothesize → Test →
Fix → Verify.

65. Lesson Test

Section A — Multiple Choice

1. What is the main purpose of DevTools?

A. Browse social media

B. Inspect and debug websites
C. Create databases
D. Replace the operating system

2. Which panel should you use to inspect the current

DOM?

A. Network
B. Elements
C. Sources only
D. Console only

3. Which panel is most appropriate for JavaScript errors?

A. Console
B. Elements
C. Network
D. Settings

4. Which panel helps you identify a missing CSS file?

A. Network
B. Elements only
C. Console only
D. Sources only

5. Which panel is used for JavaScript debugging and

breakpoints?

A. Network
B. Sources
C. Elements
D. Styles

6. What does [Link]("#button") return

if no matching element exists?

A. false
B. 0
C. null
D. undefined always

7. What does [Link]() do?

A. Saves a JavaScript file
B. Outputs information to the console
C. Creates an HTML element
D. Sends an HTTP request

8. What does a 404 usually indicate?

A. Successful request
B. Resource not found
C. JavaScript executed successfully
D. Browser closed

66. Section B — True or False

9. Changes made to the DOM in DevTools normally change

your original HTML file automatically.
10. DevTools can be used to inspect CSS.
11. The Console can be used to run JavaScript.
12. The Network panel can help diagnose missing files.
13. A breakpoint can pause JavaScript execution during
debugging.
14. You should change many unrelated things at once
when debugging.
15. Reading the exact error message is an important
debugging technique.
16. The current DOM can differ from the original HTML
source after JavaScript modifies the document.

67. Section C — Explain

17. Explain the difference between the Elements and

Sources panels.
18. Explain the difference between the Styles and
Computed views.
19. What is the difference between a temporary DevTools
edit and a permanent source-code change?
20. Why is the Console useful when debugging JavaScript?
 21. Why is the Network panel useful when CSS or JavaScript
doesn't load?
22. Explain the debugging cycle:

Reproduce
Observe
Inspect
Hypothesize
Test
Fix
Verify

23. Why is changing one thing at a time important?

68. Section D — Debugging Scenarios

Scenario 1

Your button is visible, but clicking it does nothing.

You run:
[Link]("#myButton")
and get:
null
What should you investigate?

Scenario 2

Your page loads, but none of your CSS works.

What two DevTools areas should you check first?

Scenario 3
The Console says:
Cannot read properties of null
What kind of problem might this indicate?

Scenario 4

The Network panel shows:

[Link]
404
What should you investigate?

Scenario 5

You changed the heading in Elements, refreshed, and the old

heading returned.
Why?

69. Final Practical Challenge

Build this project:
devtools-practice/
├── [Link]
├── [Link]
└── [Link]
Create:
<h1 id="title">DevTools Practice</h1>

<p id="message">
I am learning how to debug websites.
</p>
<button id="debugButton">
Test Interaction
</button>
JavaScript:
const button = [Link]("#debugButton");
const message = [Link]("#message");

[Link]("click", () => {
[Link] = "The interaction works!";
});
Then complete these tasks in order.

Task 1

Inspect the <h1> in Elements.

Task 2

Change the heading temporarily.

Task 3

Change its font size in the Styles panel.

Task 4

Inspect its Computed styles.

Task 5

Find the button's event listener.

Task 6

Use Console:
[Link]("#debugButton")
Task 7

Use:
[Link]("#message").textContent

Task 8

Change the paragraph using Console.

Task 9

Inspect Network and confirm HTML, CSS, and JavaScript

resources.

Task 10

Break the button selector deliberately.

Task 11

Use Console to discover the problem.

Task 12

Fix it in VS Code.

Task 13

Break your CSS path.

Task 14

Find the failed request in Network.

Task 15

Fix the path.

Task 16

Reload and verify everything works.

70. Your Phase 0 Progress
Look at your journey:
0.1 ✅ Internet and World Wide Web
↓
0.2 ✅ Websites and Web Applications
↓
0.3 ✅ Front-End / Back-End / Full Stack
↓
0.4 ✅ HTML + CSS + JavaScript
↓
0.5 ✅ Files, Folders, Paths
↓
0.6 ✅ Development Environment
↓
0.7 ✅ Browser DevTools + Debugging
You have now crossed an important line.
You're no longer just learning:
"How do I write code?"
You're beginning to learn:
"How do I understand what my code is actually doing?"
That is a massive upgrade.
Your new developer mindset should be:
I don't guess.
I inspect.

I don't randomly change things.

I form a hypothesis.
I don't panic at errors.
I read them.

I don't assume the browser is broken.

I investigate.

I don't stop when code fails.

I debug.
And the four DevTools tools I want you to remember from today
are:
ELEMENTS
→ What is on the page?

CONSOLE
→ What is JavaScript saying?

NETWORK
→ What resources/data are moving?

SOURCES
→ How is the code executing?
Chrome's official DevTools documentation and MDN's developer-
tools guidance both treat these tools as core parts of inspecting
and debugging modern web pages.
-------------------------------------X------------------------------------------

Lesson 0.8

Domains, Hosting, Servers, DNS, HTTPS, and Deployment

Welcome to Lesson 0.8, bro. 🌍🚀

This is the lesson where we connect everything you've learned
so far.

Until now, you've been building websites on your own

computer:

Your computer
↓
VS Code
↓
[Link]
[Link]
[Link]
↓
Browser
↓
You see your website

But there is a problem.

Right now, only you can easily access your website.

If you want a friend in another city—or someone anywhere in the

world—to open your website, your files need to be made
available over the public internet.

That introduces several new concepts:

Domain
Hosting
Web server
IP address
DNS
DNS records
HTTPS
TLS certificates
Deployment

And this is the journey we're going to understand today:

YOU WRITE CODE

↓
YOUR PROJECT
 ↓
DEPLOYMENT
↓
HOSTING
↓
WEB SERVER
↓
DOMAIN + DNS
↓
HTTPS
↓
PUBLIC INTERNET
↓
VISITOR'S BROWSER

By the end, you should understand what happens when

someone types:

[Link]

into their browser.

What you'll learn

In this lesson, you'll learn:

1. What "going live" means

2. What hosting is
3. What a web server is
4. What a domain name is
5. What a domain registrar does
6. What DNS is
7. What DNS records are
8. What nameservers are
9. What an IP address does
10. What HTTP and HTTPS do
11. What TLS certificates are
12. What deployment means
13. Static hosting vs server-side hosting
14. Localhost vs public websites
 15. The difference between a domain and hosting
16. How DNS connects a domain to hosting
17. What happens when someone visits your site
18. What happens when you update your website
19. A complete deployment pipeline
20. Common beginner misunderstandings
21. Practical exercises
22. Cheat sheet
23. Flashcards
24. Test

1. What Does "Going Live" Mean?

Imagine you've built:

my-portfolio/
├── [Link]
├── [Link]
└── [Link]

Right now, you can open:

[Link]

and see your website.

But if you send the file to your friend, they would need the whole
project and would have to open it locally.

That's not the same as having a public website.

A website is considered published or deployed when its

resources are made available through internet-accessible
infrastructure so other people can access them through a URL.
MDN's publishing guidance describes deployment as the process
of putting a website online so it can be accessed by users over
the internet.

Before deployment:

Your Computer
↓
Your Browser
↓
You

After deployment:

Your Code
↓
Hosting Infrastructure
↓
Internet
↓
Anyone with the URL

That's the big transformation.

2. What Is Hosting?

Web hosting means providing the infrastructure that stores

and serves your website or application so people can access it
over the internet.

For a simple static website, the hosting environment can serve

files such as:

HTML
CSS
JavaScript
Images
Fonts

For a more complex application, the infrastructure may also run

server-side application code and connect to databases and other
services. MDN distinguishes static servers, which serve hosted
files as-is, from dynamic server architectures that add
application-server and database components.

Think of hosting like renting space for your website.

Your computer:

Your bedroom
↓
You store your project

Hosting:

A place on internet-connected infrastructure

↓
Your website is stored and served to visitors

So:

Your Laptop
↓
Good for development

Hosting Infrastructure
↓
Good for serving the website to visitors

3. What Is a Web Server?

A web server has two related meanings.

It can refer to:

1. The computer or infrastructure that hosts a website

2. Software that handles web requests and sends responses

When a browser requests a resource, the web server can

respond with that resource.

For a static website:

Browser
│
│ "Give me [Link]"
▼
Web Server
│
│ "Here is [Link]"
▼
Browser
MDN describes a static web server as a computer plus HTTP
server software that sends hosted files to the browser as-is. A
dynamic web server adds additional application and data-
processing components.

4. Static Web Hosting

Suppose you have:

[Link]
[Link]
[Link]
images/

A static host can serve those files.

The simplified flow is:

Visitor
↓
Requests [Link]
↓
Server finds [Link]
↓
Server sends [Link]
↓
Browser parses HTML
↓
Browser requests CSS, JS, images
↓
Browser renders page

The server doesn't necessarily need to generate a brand-new

HTML page separately for each visitor.

The same prepared file may be returned to many visitors.

That's the core idea behind static hosting. MDN defines a static
site as one that generally returns the same hard-coded content
for a given resource request.
5. Dynamic Hosting

Now imagine your website has:

Login
Dashboard
User profile
Shopping cart
Order history

The server may need to:

Identify the user

↓
Check permissions
↓
Read database information
↓
Process business logic
↓
Return appropriate data

The architecture becomes more like:

Browser
↓
Web Server
↓
Application
↓
Database
↓
Application
↓
Web Server
↓
Browser

A dynamic web server typically adds application-server and

database components to the basic web-serving infrastructure.
6. Static vs Dynamic Hosting
Static Hosting Dynamic Hosting
Primarily serves prepared files Runs application logic
Often simpler Usually more complex
Good for portfolios and simple Useful for accounts and
sites dashboards
Doesn't inherently require a Commonly works with
database databases
Can still use JavaScript Uses client and server logic
Can generate personalised
Can still be interactive
responses

Important:

Static does not mean boring.

A static website can still have:

 Animations
 Interactive menus
 Forms
 JavaScript
 Dark mode
 Client-side API requests
 Calculators
 Games

"Static" mainly describes how the content is generated and

served.

7. What Is a Domain Name?

A domain name is a human-readable name used to identify a

destination on the internet.
For example:

[Link]

or:

[Link]

Instead of asking users to remember an IP address like:

[Link]

they can remember a human-friendly name.

ICANN explains that DNS makes the internet easier to navigate

by allowing human-readable domain names to be used instead
of difficult-to-remember IP addresses. MDN similarly describes
domain names as human-readable addresses for internet-
accessible web servers.

8. Domain Name vs Website

This is one of the biggest beginner misunderstandings.

A domain:

[Link]

is not the website itself.

Think:

Domain
↓
The address people use

Hosting
↓
Where the website is served from

Website
↓
The actual content and application

Analogy:

Domain
↓
Street address

Hosting
↓
Building/space

Website
↓
Business inside the building

The analogy is simplified, but it works.

You can have:

A domain without a website

You can have:

A hosted website without your own custom domain

And you can eventually connect:

Custom domain
+
Hosting
+
Website

to create a public web presence.

9. What Is a Domain Registrar?

A domain registrar is a service through which domain names

can be registered.
The exact registration process depends on the domain extension
and registry arrangements, but the general idea is:

You want:
[Link]

You register the domain

↓
You gain control over that domain
↓
You configure its DNS
↓
You connect it to your hosting

ICANN coordinates important parts of the global domain name

system, including the DNS root zone, while domain registration
itself operates through registries and registrars within the
domain-name ecosystem.

Don't worry about the commercial details yet.

For your mental model:

Registrar
↓
Helps you register/manage a domain

Hosting provider
↓
Provides infrastructure for your website

DNS
↓
Connects the domain name to the appropriate destination

These roles can sometimes be offered by the same company,

but conceptually they are different jobs.

10. A Domain Has Parts

Consider:
[Link]

Break it down:

www . mywebsite . example

↑ ↑ ↑
subdomain name top-level domain

Let's simplify.

www

This is a subdomain.

mywebsite

This is the main domain label.

.example

This is the top-level domain portion.

You may see:

.com
.org
.net
.in
.edu

and many others.

The exact rules and availability depend on the particular top-

level domain.

For now, understand:

Domain
↓
Human-readable internet identity/address

11. What Is DNS?

DNS stands for:

Domain Name System

We introduced DNS in Lesson 0.1.

Now we're going deeper.

DNS allows domain names to be associated with the information

needed to reach internet resources. ICANN describes DNS as the
system that maps familiar text-based domain names to network
addressing information, and notes that DNS data is stored in a
distributed hierarchy of name servers.

Think:

You type:

[Link]
↓
DNS
↓
Finds appropriate destination information
↓
Browser connects
↓
Website loads

DNS is often compared to an address book.

You know:

Person's name

The system helps you find:

Their contact information

Similarly:

Domain name

helps the system find:

Where the requested internet service is located

12. DNS Is Not Hosting

This is crucial.

Consider:

Domain:
[Link]

and:

Hosting:
Some hosting infrastructure

DNS connects the two conceptually.

Domain
↓
DNS configuration
↓
Hosting destination
↓
Website

You can think of DNS as the routing/addressing layer.

Hosting is the infrastructure serving the content.

13. What Are DNS Records?

DNS isn't just one piece of information.

A domain can have multiple DNS records that describe different

services or destinations.

Common record types include:

A
AAAA
CNAME
MX
TXT
You don't need to master all of them yet.

But understanding their broad purposes is useful.

A Record

An A record maps a hostname to an IPv4 address.

Conceptually:

[Link]
↓
[Link]

The browser can then use that addressing information to reach

the relevant destination.

AAAA Record

An AAAA record is used for IPv6 addressing.

Conceptually:

[Link]
↓
IPv6 address

IPv6 provides a newer IP addressing system alongside IPv4.

CNAME Record

A CNAME record can make one hostname an alias of another

hostname.

Conceptually:

[Link]
↓
[Link]
The exact behaviour depends on the DNS setup and provider.

MX Record

An MX record is associated with mail delivery for a domain.

For example:

[Link]
↓
Mail server

This is why your website's DNS configuration can affect email

services too.

TXT Record

A TXT record stores text data associated with a DNS name.

It is commonly used for verification and other configuration

purposes.

The DNS system is much richer than simply "domain → IP

address"; DNS zones contain multiple records and are served
through authoritative name servers.

14. DNS Records — Beginner Cheat Sheet

Record Basic idea
A Hostname → IPv4 address
AAAA Hostname → IPv6 address
CNAME Hostname → another hostname
MX Mail delivery destination
TXT Text/configuration/verification data
At our current stage, the most important ones for website
hosting are:

A
AAAA
CNAME

You don't need to memorise DNS syntax yet.

15. What Are Nameservers?

Nameservers are servers responsible for answering DNS queries

for a domain or participating in the DNS resolution process.

At a simplified level:

Browser asks:
"Where is [Link]?"

DNS resolver
↓
Finds authoritative DNS information
↓
Gets answer
↓
Returns result

ICANN explains that DNS is distributed across a hierarchy and

that authoritative name servers hold DNS data for domains.

As a beginner, think:

DNS
↓
The system

Nameserver
↓
A server involved in providing DNS answers
16. The Complete DNS Journey

Suppose you type:

[Link]

The simplified process is:

1. Browser sees domain

↓
2. DNS lookup begins
↓
3. DNS system finds relevant information
↓
4. Browser learns where to connect
↓
5. Browser establishes the appropriate connection
↓
6. Browser sends HTTP request
↓
7. Server responds
↓
8. Browser renders page

DNS resolution is more complicated internally than this

simplified sequence, and may involve recursive resolvers,
caching, and authoritative servers. The important beginner
concept is that DNS helps the browser find the appropriate
destination before web requests are made.

17. DNS Caching

Here's something interesting.

DNS answers can be cached.

That means a browser, operating system, network, or DNS

resolver may temporarily remember DNS information instead of
looking it up from scratch every time.
This is why DNS changes can sometimes take time to appear
everywhere.

Conceptually:

You change DNS

↓
One system sees new value
↓
Another system still has old cached value
↓
Cache expires
↓
New value is retrieved

DNS records have a TTL, or time-to-live, which helps control how

long DNS information can be cached. ICANN's DNS materials
describe TTL as part of DNS resource records and caching
behaviour.

This is why you shouldn't panic immediately if you make a DNS

change and don't see the expected result everywhere.

18. What Is an IP Address?

An IP address is a network address used to identify a

destination on an IP network.

You may encounter:

IPv4

such as:

[Link]

or:

IPv6

such as:
2001:db8::10

For website access, DNS helps connect human-friendly domain

names with the addressing information needed to reach the
appropriate destination.

Mental model:

Domain
↓
Human-friendly name

IP address
↓
Network destination address

19. What Is HTTP?

HTTP stands for:

HyperText Transfer Protocol

HTTP is an application-layer protocol used for exchanging

resources over the web.

A browser sends a request.

The server sends a response.

Browser
│
│ HTTP Request
▼
Server
│
│ HTTP Response
▼
Browser

HTTP is a client-server protocol and is used to retrieve resources

such as HTML documents, while also supporting broader
machine-to-machine and API communication.
20. HTTP Request Example

Conceptually:

GET /[Link]

means something like:

"Please give me the resource at /[Link]."

The server might respond:

200 OK

along with:

<!doctype html>
<html>
...
</html>

The browser then processes that response.

21. HTTP Methods

You may eventually encounter methods such as:

GET
POST
PUT
PATCH
DELETE

A simplified beginner understanding:

GET
↓
Retrieve data

POST
↓
Send data / create something

PUT
↓
Replace/update something

PATCH
↓
Partially update something

DELETE
↓
Remove something

We won't dive deeply into HTTP methods yet.

We'll revisit them when we learn APIs.

22. What Is HTTPS?

HTTPS stands for:

HyperText Transfer Protocol Secure

HTTPS uses HTTP over a secure TLS connection.

The goal is to protect communication between the browser and

server against network-level interception and tampering and to
authenticate the server through certificates.

You often see:

https://

instead of:

http://

Let's Encrypt describes HTTPS certificates as TLS certificates

used to enable secure HTTPS connections.
23. What Is TLS?

TLS stands for:

Transport Layer Security

TLS provides cryptographic protection for network

communication.

Simplified:

HTTP
↓
Without TLS

HTTPS
↓
HTTP + TLS protection

The browser and server establish a secure connection using TLS.

You don't need to understand cryptographic mathematics right

now.

For our level:

HTTP
↓
Web communication

HTTPS
↓
Web communication protected with TLS

24. What Is an SSL Certificate?

You will often hear people say:

"SSL certificate."

Modern secure web connections use TLS, the successor to SSL.

In casual conversation, people still often say "SSL certificate,"
but technically the security protocol today is TLS.

A certificate helps establish the identity of the server for a

domain and participates in the process of creating a trusted TLS
connection.

Certificate Authorities issue certificates after appropriate domain

validation.

For example, Let's Encrypt operates as a Certificate Authority

and provides free TLS certificates after domain control is
demonstrated through its validation process.

25. HTTPS Does Not Mean "The Website Is Good"

This is a very important distinction.

If you see:

🔒 [Link]

it does not automatically mean:

The company is trustworthy

The information is accurate
The product is legitimate
The website has no bugs
The website can't be compromised

HTTPS primarily tells you that:

 The connection is using TLS

 The browser has performed certificate verification according
to its trust model

So:

HTTPS
↓
Secure connection
NOT

HTTPS
↓
Guaranteed trustworthy website

Keep those separate.

26. What Is Deployment?

Deployment means putting your application into an

environment where it can be used by its intended users.

For a simple website:

Your computer
↓
Upload/build your website
↓
Hosting infrastructure
↓
Website becomes accessible

For a more complex project:

Write code
↓
Commit code
↓
Build project
↓
Run tests
↓
Deploy
↓
Start production application
↓
Users access it

Modern deployment workflows can be automated so that

changes pushed to a source repository trigger building and
deployment processes. MDN's deployment guidance describes
workflows involving source repositories and automated
deployment pipelines.

27. Development vs Production

This is an important concept.

Development environment

This is where you build and test.

For example:

Your computer
localhost
VS Code
DevTools

Production environment

This is where real users access the application.

For example:

Public domain
Public hosting
Production server
Production database

Mental model:

DEVELOPMENT
↓
You are building

PRODUCTION
↓
Users are using

Later you'll also encounter:

Testing
Staging
Production

A company might have separate environments to test changes

before exposing them to real users.

28. What Is localhost?

When you're developing locally, you may see:

[Link]

or:

[Link]

localhost refers to the computer you're currently using.

It is commonly associated with the loopback address and is used

for local development.

So:

localhost

basically means:

"This computer."

For example:

Browser
↓
localhost:3000
↓
Your own computer

A website running on localhost is not automatically publicly

accessible from the internet.

This is a crucial distinction.

29. Local vs Public

Local development

Your computer
↓
localhost
↓
You

Public website

Internet
↓
Domain
↓
Hosting/server
↓
Anyone with access

So:

localhost
≠
public domain

This is why you can build an entire website without anyone else
seeing it.

30. The Complete Deployment Journey

Let's imagine you've built:

my-portfolio/
├── [Link]
├── [Link]
└── [Link]

Here's what happens.

Step 1 — Development

You write:

HTML
CSS
JavaScript

in VS Code.

Step 2 — Testing

You open the site locally.

Browser
↓
Check layout
↓
Check interactions
↓
Check DevTools
↓
Fix bugs

Step 3 — Deployment

You place the website on hosting infrastructure.

Your project
↓
Hosting

The hosting system can now serve your files.

Step 4 — Domain

You have a domain such as:

[Link]

Step 5 — DNS

You configure DNS so the domain points toward the appropriate

hosting destination.

[Link]
↓
DNS
↓
Hosting destination

Step 6 — HTTPS

Your hosting setup uses a TLS certificate for the domain.

[Link]

Step 7 — Visitor

Someone opens:

[Link]

Their browser:

DNS lookup
↓
Find destination
↓
Establish secure connection
↓
Send HTTP request
↓
Receive response
↓
Load resources
↓
Render page
Your website is now available to them.

31. The Complete Architecture

Here's the diagram I want you to remember:

USER
│
▼
BROWSER
│
│
[Link]
│
▼
DNS
│
Find destination
│
▼
HOSTING / SERVER
│
┌─────────┴─────────┐
│ │
▼ ▼
STATIC FILES APPLICATION
│ │
│ ▼
│ DATABASE
│
└─────────┬─────────┘
│
▼
HTTP RESPONSE
│
▼
BROWSER
│
▼
WEB PAGE
For a simple static portfolio:

Browser
↓
DNS
↓
Hosting
↓
HTML/CSS/JS
↓
Browser

For a complex application:

Browser
↓
DNS
↓
Hosting
↓
Web server
↓
Application server
↓
Database
↓
Response
↓
Browser

These are simplified architectures, but they are excellent mental

models.

32. Domain + Hosting + DNS

Let's make this crystal clear.

Imagine you own:

[Link]
And your hosting provider gives you:

Hosting destination

You configure:

DNS

so that:

[Link]
↓
DNS
↓
Your hosting

Now visitors can use:

[Link]

This is the relationship:

DOMAIN
"What name do people use?"

DNS
"Where should that name lead?"

HOSTING
"Where does the website actually live and get served from?"

33. A Common Beginner Mistake

Many beginners think:

"I bought a domain, so I have a website."

Not necessarily.

You may have:

Domain ✅
Website ❌
Hosting ❌

Or:

Website ✅
Hosting ✅
Custom domain ❌

To create the complete public experience, you generally need:

Website/application
+
Hosting/infrastructure
+
Domain (optional but common)
+
DNS configuration
+
HTTPS

The exact requirements vary by hosting architecture, but these

are the core concepts.

34. Another Beginner Mistake

Someone might say:

"My website is hosted on my domain."

That's a bit imprecise.

A more useful mental model is:

Website
↓
Hosted on infrastructure

Domain
↓
Points users toward that service through DNS

The domain isn't literally a hard drive containing your website.

Your website content is served by hosting infrastructure.

35. Static Hosting Example

Imagine:

my-portfolio/
├── [Link]
├── [Link]
├── [Link]
└── images/

You deploy it to a static hosting platform.

The host serves:

[Link]
[Link]
[Link]
images/

Then:

Visitor
↓
Domain
↓
DNS
↓
Hosting
↓
[Link]
↓
Browser

The browser then requests:

[Link]
[Link]
images/[Link]

The page gets assembled in the browser.

This is a very common architecture for portfolios and simple
content sites. MDN's publishing guidance covers static hosting
as a straightforward way to publish a basic website.

36. Dynamic Application Example

Now imagine:

Student Learning Platform

A user visits:

[Link]

The process could be:

Browser
↓
DNS
↓
Hosting
↓
Web server
↓
Application
↓
Check user session
↓
Query database
↓
Retrieve progress
↓
Generate/return data
↓
Browser

The user sees:

Welcome, Bro!

HTML: 90%
CSS: 70%
JavaScript: 25%

Another user might see completely different information.

That's why dynamic applications require more infrastructure.

37. What Is a CDN?

You may eventually hear:

CDN — Content Delivery Network

A CDN is a distributed network of servers designed to deliver

content to users from locations that can be closer to them,
improving delivery performance and reducing the distance
content must travel.

Simplified:

Without CDN:

India User
↓
Server in another continent
↓
Content

With CDN:

India User
↓
Nearby CDN edge location
↓
Cached content

This is a simplified explanation; CDN architectures differ and not

every resource is necessarily cached.

For now:

CDN
↓
Distributed delivery infrastructure

You don't need to learn CDN configuration yet.

But understanding the concept will help later when we discuss

performance.

38. What Happens When You Update Your Website?

Suppose you change:

<h1>My Portfolio</h1>

to:

<h1>My Web Development Portfolio</h1>

Locally:

Edit file
↓
Save
↓
Refresh

But for a public website:

Edit code
↓
Commit/push changes
↓
Build/deploy process
↓
Hosting updates
↓
Visitors receive new version

Depending on the architecture, the exact steps may vary.

With modern deployment platforms, the workflow can be

automated:
Code change
↓
Git push
↓
Automatic build
↓
Automatic deployment
↓
New version live

Automated deployment pipelines are common in modern web

development workflows, and MDN's deployment material
demonstrates repository-driven deployment patterns.

39. What Is Git Doing Here?

We'll study Git later.

But the basic idea is:

Git
↓
Tracks changes to your code

A typical workflow might eventually become:

Write code
↓
Save
↓
Git commit
↓
Git push
↓
Deployment system
↓
Build
↓
Production
This is one reason Git becomes such an important skill for
professional developers.

40. Continuous Deployment

A modern workflow can be:

Developer
↓
Pushes code
↓
Automated system detects change
↓
Runs checks
↓
Builds application
↓
Deploys
↓
Website updates

You make a code change.

The deployment pipeline handles the rest.

That's the basic idea behind automated continuous deployment.

We'll learn the practical version much later.

41. Build vs Deploy

Don't confuse these.

Build

Transform your source code into the version you want to run or
publish.

For a very basic HTML/CSS/JS website:

Source files
↓
May already be deployable

For a modern framework project:

Source code
↓
Build process
↓
Optimised output

Deploy

Put the resulting application or files into the environment where

users can access them.

Think:

BUILD
↓
Prepare it

DEPLOY
↓
Put it where users can access it

These steps can happen together automatically in modern

tooling.

42. Localhost vs Hosting

Let's compare.

Your local project

C:\Users\You\Documents\my-site

This is stored on your computer.

Local development server

[Link]

The website is running on your computer.

Public hosting

[Link]

The website is accessible through the public internet.

Think:

Local
↓
You are testing

Public
↓
Users are accessing

This distinction will become very important when we start

deploying our own projects.

43. What Is a Port?

You may eventually see:

localhost:3000
localhost:5173
localhost:8080

The number after : is a port.

For example:

localhost:3000
↑
port

A port helps the operating system distinguish between different

network services running on the same machine.

Imagine your computer running:

localhost:3000
↓
Frontend development server

localhost:5000
↓
Backend server

Both run on the same computer but use different ports.

We'll explore ports more deeply when we introduce local

development servers and APIs.

44. The Full Journey From Code to Visitor

Now let's combine everything.

You write:

<h1>Hello World</h1>

Then:

Step 1
You save your code
Step 2
You test locally
Step 3
You deploy the website
Step 4
Hosting infrastructure serves it
Step 5
Your domain is connected through DNS
Step 6
HTTPS is enabled

Now someone types:

[Link]

Their browser:
1. Reads the URL
↓
2. Resolves the domain through DNS
↓
3. Finds the appropriate destination
↓
4. Establishes a secure TLS connection
↓
5. Sends an HTTP request
↓
6. Server returns HTML
↓
7. Browser requests CSS/JS/images
↓
8. Browser processes DOM and CSS
↓
9. JavaScript runs
↓
10. Browser renders the page

This connects almost everything we've learned in Phase 0.

MDN's "How the web works" material similarly describes the

browser using DNS to locate the server, then communicating
with the server through HTTP to retrieve the webpage and its
resources.

45. The Mega Architecture Diagram

This is the diagram I want you to remember.

YOUR COMPUTER
│
▼
VS CODE / GIT
│
▼
YOUR PROJECT
┌─────────┴─────────┐
│ │
 ▼ ▼
HTML/CSS/JS Build Process
│
▼
DEPLOYMENT
│
▼
HOSTING INFRASTRUCTURE
│
┌────────────┴────────────┐
│ │
▼ ▼
Static Files Application Server
│
▼
DATABASE
│
▼
DOMAIN ◄────── DNS ──────► HOSTING
│
▼
HTTPS / TLS
│
▼
INTERNET
│
▼
VISITOR BROWSER
│
▼
DNS LOOKUP
│
▼
SERVER CONNECTION
│
▼
HTTP REQUEST
│
▼
HTTP RESPONSE
│
 ▼
HTML + CSS + JavaScript
│
▼
RENDERED PAGE

That is the web-development ecosystem we've been building

in our heads since Lesson 0.1.

46. A Realistic Example

Imagine you're building:

Bro's Portfolio

Your project:

bro-portfolio/
├── [Link]
├── [Link]
├── [Link]
├── css/
│ └── [Link]
├── js/
│ └── [Link]
└── images/
└── [Link]

Development

You work locally:

VS Code
↓
Chrome
↓
DevTools

Deployment

You publish the website to hosting:

Hosting
↓
Serves your files

Domain

You use:

[Link]

DNS

You configure:

[Link]
↓
Your hosting destination

HTTPS

You enable a TLS certificate:

[Link]

Visitor

Someone opens:

[Link]

The complete process:

Visitor
↓
Domain
↓
DNS
↓
Hosting
↓
HTML
↓
CSS + JS + Images
↓
Browser
↓
Portfolio

You've just built a real public website architecture.

47. What You Don't Need to Worry About Yet

At this stage, you do not need to master:

DNSSEC
BGP
TLS cryptography
Load balancing
Kubernetes
Containers
CDN cache invalidation
Reverse proxies
Database replication
Cloud architecture
Infrastructure as Code

Those are important topics in bigger systems, but we have

plenty of time.

Your current mental model should be:

Domain
↓
DNS
↓
Hosting
↓
Server
↓
HTTP/HTTPS
↓
Browser
That's enough for now.

48. Common Beginner Mistakes

Mistake 1 — Domain = Hosting

No.

Domain
↓
Address/identity

Hosting
↓
Infrastructure

Mistake 2 — Hosting = Website

Not exactly.

Hosting provides the infrastructure that serves the website.

Your website is the actual code/content/application.

Mistake 3 — DNS = Website

No.

DNS helps map domain names to internet destinations.

It doesn't contain your HTML, CSS, and JavaScript.

Mistake 4 — HTTPS = Trust

No.

HTTPS protects the connection.

It does not guarantee that the website is honest or secure in
every other sense.

Mistake 5 — localhost = public website

No.

localhost
↓
Your own computer

A public deployment:

Internet
↓
Public hosting

Mistake 6 — Deployment means just uploading files

Sometimes it can be that simple for static websites.

But modern deployment can also involve:

Build
Tests
Environment variables
Database migrations
Infrastructure
Monitoring
Rollback

Deployment complexity depends heavily on the application

architecture.

Mistake 7 — Every website needs a custom domain

No.
You can publish a website using a hosting provider's assigned
address.

A custom domain is common and useful, but it isn't conceptually

required to understand hosting.

49. Practical Exercise 1 — Draw the Architecture

Take a piece of paper or create a diagram.

Draw:

User
↓
Browser
↓
Domain
↓
DNS
↓
Hosting
↓
Server
↓
Website

Then add:

HTTPS

between:

Browser

and:

Server

Now add:

Database
only if the website is dynamic.

This is teaching you to distinguish:

Static site

from:

Dynamic application

50. Practical Exercise 2 — Classify These

For each example, decide whether it likely needs:

Static Hosting
Dynamic Server
Database

A — Personal Portfolio

About Me
Projects
Contact

B — Student Dashboard

Login
Marks
Attendance
Assignments

C — Product Landing Page

Product information
Images
Features
Buy button

D — Online Shopping Platform

Accounts
Cart
Orders
Payments

E — Simple Documentation Site

Tutorials
Guides
Code examples

Think carefully.

The answer isn't always just:

Static

or:

Dynamic

You need to consider what users actually do.

51. Practical Exercise 3 — Trace a URL

Take a URL such as:

[Link]

Break it down:

Scheme:
?

Domain:
?

Path:
?

Then answer:

What does DNS help with?

?

Where would hosting fit?

?

Where does HTTPS fit?

?

What does the browser request?

?

Don't worry about knowing the exact infrastructure of the real

website.

We're practicing the architecture.

52. Practical Exercise 4 — Local vs Public

Create a table:

Concept Local Development Public Deployment

Internet-accessible
Location Your computer
infrastructure
Example
localhost Public domain
address
Who can Usually you/local
Public users
access network
Purpose Development/testing Real usage
DevTools Yes Yes
Hosting Local machine Hosting infrastructure

This comparison will become very important when we start

deploying real projects.

53. Practical Exercise 5 — The Deployment Story

Explain this in your own words:

I write a website
↓
I host it
↓
I connect a domain
↓
DNS points the domain toward the hosting
↓
HTTPS secures the connection
↓
Users visit the website

Try to explain each line without copying the notes.

If you can do that, you've understood the lesson.

54. Bonus Practical — Open DevTools on a Public Website

Take a normal website you already use.

Open:

Ctrl + Shift + I

Go to:

Network

Reload the page.

Look for:

Document
CSS
JS
Images
Fonts
Fetch/XHR

Notice that one webpage can involve many different requests.

Then look at the URL.

Identify:

Scheme
Domain
Path

This connects:

Lesson 0.1
How the web works

Lesson 0.5
File paths

Lesson 0.7
DevTools

Lesson 0.8
Hosting and deployment

That's the whole point of Phase 0: building one connected

mental model rather than memorising isolated facts.

55. Cheat Sheet

Domain

Human-readable web address

Example:

[Link]

Hosting
Infrastructure that stores/serves your website or runs your
application

Web Server

Software/infrastructure that handles web requests and

responses

DNS

System that helps map domain names to destination information

IP Address

Network address used to identify a destination

DNS Records

A
→ IPv4 address

AAAA
→ IPv6 address

CNAME
→ Another hostname

MX
→ Mail service destination

TXT
→ Text/configuration/verification data

HTTP

Protocol used for communication on the web

HTTPS

HTTP communication protected with TLS

TLS Certificate

Certificate used as part of establishing trusted HTTPS

connections

Deployment

Putting software into an environment where users can access it

Localhost

Your own computer

Production

Environment where the application is available to real users

56. The One Diagram to Memorise

DOMAIN
│
▼
DNS
│
▼
HOSTING
│
▼
WEB SERVER
│
┌───────────┴───────────┐
│ │
▼ ▼
STATIC FILES APPLICATION
│
 ▼
DATABASE
│
└───────────┬───────────┘
│
▼
HTTPS
│
▼
BROWSER
│
▼
USER

The simplified flow when visiting a site:

User
↓
Browser
↓
DNS
↓
Server
↓
HTTP/HTTPS
↓
Response
↓
Browser
↓
Rendered page

57. Flashcards

Flashcard 1

Front: What is web hosting?

Back: Infrastructure used to store, serve, or run a website or
web application so users can access it over the internet.

Flashcard 2
Front: What is a domain name?
Back: A human-readable name used to identify an internet
destination.

Flashcard 3

Front: What is DNS?

Back: The Domain Name System, which helps map domain
names to the information needed to reach internet destinations.

Flashcard 4

Front: Is a domain the same as hosting?

Back: No. A domain is an address/name; hosting provides the
infrastructure serving the website.

Flashcard 5

Front: What does a web server do?

Back: It handles web requests and returns responses or
resources.

Flashcard 6

Front: What is an A record?

Back: A DNS record that maps a hostname to an IPv4 address.

Flashcard 7

Front: What is a CNAME record?

Back: A DNS record that aliases one hostname to another
hostname.

Flashcard 8

Front: What is HTTP?

Back: A protocol used to exchange web resources and
communicate between clients and servers.

Flashcard 9

Front: What does HTTPS add to HTTP?

Back: TLS-based protection for the communication.

Flashcard 10
Front: What is a TLS certificate used for?
Back: It participates in establishing a trusted secure connection
for a domain.

Flashcard 11

Front: What is deployment?

Back: Putting an application or website into an environment
where users can access it.

Flashcard 12

Front: What is localhost?

Back: A hostname commonly used to refer to the computer on
which the request is being made.

Flashcard 13

Front: What is production?

Back: The environment in which the application is made
available for real users.

Flashcard 14

Front: What is the difference between static and dynamic

hosting?
Back: Static hosting primarily serves prepared files; dynamic
hosting may run application logic and use databases or other
backend services.

Flashcard 15

Front: What happens when a user visits a domain?

Back: The browser uses DNS to find the destination, connects to
the server, sends a request, receives responses, and renders the
returned resources.

58. Lesson Test

Section A — Multiple Choice

1. What is web hosting?

A. A programming language
B. Infrastructure used to serve a website or application
C. A browser
D. A CSS property

2. What is a domain name?

A. A database
B. A human-readable internet address/name
C. A web server program
D. A JavaScript function

3. What does DNS primarily help with?

A. Styling HTML
B. Mapping domain names to destination information
C. Creating CSS animations
D. Storing passwords

4. What does HTTPS provide?

A. A programming language
B. TLS-protected web communication
C. A database
D. A domain registrar

5. Which DNS record is associated with IPv4 addresses?

A. MX
B. TXT
C. A
D. CNAME

6. Which DNS record is commonly used as an alias to

another hostname?

A. A
B. CNAME
C. MX
D. TXT

7. What does deployment mean?

A. Deleting your source code
B. Making your application available in its target environment
C. Writing HTML
D. Registering a domain only

8. What does localhost generally refer to?

A. Another country
B. Your own computer
C. A DNS registrar
D. A public CDN

59. Section B — True or False

9. A domain name and hosting are the same thing.

10. A website can be hosted without a custom domain.
11. DNS helps browsers find internet destinations.
12. HTTPS guarantees that a website is trustworthy.
13. A static website can still use JavaScript.
14. A dynamic application may use databases.
15. localhost automatically makes a website publicly
available on the internet.
16. DNS records can be cached.
17. A public website may use both a domain and hosting.
18. Deployment is always as simple as copying files.

60. Section C — Explain

19. Explain the difference between a domain and hosting.

20. Explain what DNS does.
21. Explain the difference between HTTP and HTTPS.
22. Explain what a TLS certificate does at a high level.
23. Explain the difference between local development and
production.
24. Explain static hosting and dynamic hosting.
25. Explain what happens when a user enters a domain
into a browser.
26. Explain why DNS is sometimes compared to an address
book.
61. Section D — Architecture Questions

Imagine you're building:

My Student Portfolio

It contains:

About Me
Projects
Skills
Contact

Answer:

27. Would this likely need static hosting or dynamic

hosting?
28. Does it require a database?
29. Does it need a custom domain?
30. Could it be hosted without one?
31. What does DNS do if you use a custom domain?
32. What does HTTPS protect?

Now imagine you're building:

Student Learning Dashboard

It contains:

Login
Attendance
Marks
Assignments
Teacher Dashboard

Answer:

33. Is static hosting alone likely enough?

34. Would a database likely be useful?
35. Where would server-side application logic fit?
 36. What information might the browser request through
an API?

62. Section E — Trace the Request

Imagine a user enters:

[Link]

Put these into the correct conceptual order:

A. Server sends response

B. Browser resolves domain using DNS
C. Browser renders resources
D. Browser sends HTTP request
E. User enters URL
F. Browser establishes appropriate secure connection

Your answer should look something like:

1 → ?
2 → ?
3 → ?
4 → ?
5 → ?
6 → ?

63. Final Practical Challenge

Draw the architecture for:

My Future Portfolio

Your diagram must include:

Your Computer
VS Code
HTML
CSS
JavaScript
Hosting
Web Server
Domain
DNS
HTTPS
Visitor Browser

Your final diagram should resemble:

You
↓
VS Code
↓
HTML/CSS/JS
↓
Deploy
↓
Hosting
↓
Web Server
↓
Domain + DNS
↓
HTTPS
↓
Internet
↓
Visitor Browser

Then explain in your own words:

What happens when someone visits your portfolio?

Try to explain it in 8–12 steps.

64. Your Phase 0 Progress

Look at this journey:

0.1 ✅ Internet and World Wide Web

↓
0.2 ✅ Webpages, Websites and Web Applications
 ↓
0.3 ✅ Front-End / Back-End / Full Stack
↓
0.4 ✅ HTML + CSS + JavaScript
↓
0.5 ✅ Files, Folders and Paths
↓
0.6 ✅ Development Environment
↓
0.7 ✅ Browser DevTools and Debugging
↓
0.8 ✅ Domains, DNS, Hosting and Deployment

You've now built a seriously solid Phase 0 foundation.

Your mental model should now look like this:

WEB DEVELOPMENT
│
┌────────────────┴────────────────┐
│ │
▼ ▼
DEVELOPMENT DEPLOYMENT
│ │
VS CODE HOSTING
│ │
HTML/CSS/JS WEB SERVER
│ │
BROWSER DNS
│ │
DEVTOOLS DOMAIN
│ │
DEBUGGING HTTPS/TLS
│ │
└────────────────┬────────────────┘
│
▼
PUBLIC WEBSITE
│
▼
USERS
The big takeaway from Lesson 0.8 is:

Your code is created on your computer, hosting

infrastructure makes it available, DNS helps connect a
human-readable domain to the appropriate destination,
HTTPS protects the web connection, and the browser
retrieves and renders the resources for the user.

MDN's current web-development materials describe this same

broad journey from creating a website to publishing it for the
world, while ICANN provides the foundational DNS/domain-name
perspective and Let's Encrypt documents the certificate-based
mechanism behind HTTPS.

-------------------------------------X------------------------------------------

Phase 0.10 — Final Revision, Cheat Sheets, Flashcards &

Assessment

Difficulty: Beginner → Intermediate Foundation

Estimated Study Time: 2–4 hours (or split across multiple

sessions)

Lesson Roadmap

This lesson contains 10 modules:

1. Complete Phase 0 Revision Notes

2. Master Mind Maps
3. Master Cheat Sheets
4. Memory Tricks
5. Complete Flashcards
6. 100-Question Final Test
7. Practical Assessments
8. Debugging Challenge
9. Readiness Checklist
10. Final Graduation
MODULE 1 — COMPLETE PHASE 0 REVISION

0.1 — Internet & World Wide Web

The Internet

The Internet is a global network of interconnected

computer networks.

Think of it as the world's largest road system.

It transports data.

It does not care whether the data is:

 Web pages
 Emails
 Video calls
 Games
 Cloud backups

The Internet simply moves data.

World Wide Web (WWW)

The Web is one service that runs on the Internet.

Think:

Internet
│
├── Web
├── Email
├── FTP
├── Video Calls
├── Online Games
├── Cloud Storage
└── Streaming

A common interview question:

Is the Internet the same as the Web?

Answer:

No.

The Web depends on the Internet.

The Internet does not depend on the Web.

Browser

A browser:

 Requests web pages

 Downloads resources
 Builds the DOM
 Applies CSS
 Executes JavaScript
 Renders the page

Examples:

 Chrome
 Firefox
 Edge
 Safari

Request Flow

User
↓
Browser
↓
DNS
↓
Server
↓
HTML
↓
Browser
↓
CSS + JS
↓
Rendered Page

0.2 — Websites vs Web Applications

Website

Main purpose:

Information.

Examples:

 Portfolio
 Blog
 News

Web Application

Main purpose:

Interaction.

Examples:

 Gmail
 Google Docs
 Canva
 Banking

Static Website

Content is usually the same for every visitor.

Dynamic Website
Content changes.

Example:

Your YouTube homepage.

0.3 — Frontend vs Backend

Frontend

Runs in:

Browser.

Responsible for:

 UI
 Layout
 Animations
 User interaction

Technologies:

HTML
CSS
JavaScript

Backend

Runs on:

Server.

Responsible for:

 Authentication
 Database
 Business logic
 APIs

Languages:
  Java
 Python
 JavaScript ([Link])
 C#
 Go
 PHP

Database

Stores information.

Examples:

Users
Orders
Products
Messages

Full Stack

Knows:

Frontend

Backend

0.4 — HTML + CSS + JavaScript

The famous trio.

HTML

Purpose:

Structure.
Example:

Heading
Paragraph
Button
Image

CSS

Purpose:

Presentation.

Controls:

 Colors
 Fonts
 Layout
 Animation
 Responsive design

JavaScript

Purpose:

Behavior.

Examples:

 Button click
 Form validation
 Theme switcher
 API calls

Together

HTML
↓
Structure

CSS
↓

Appearance

JavaScript
↓

Behavior

0.5 — Files, Folders & Paths

Typical project:

project/

├── [Link]

├── css/

│ └── [Link]

├── js/

│ └── [Link]

└── images/

└── [Link]

Relative Paths

./

Current folder
../

Parent folder

Example:

images/[Link]

css/[Link]

../[Link]

Absolute URL

[Link]

0.6 — Development Environment

Essential tools:

 Browser
 VS Code
 Live Server
 Terminal
 File Explorer

Workflow:

Write Code

Save

Browser Refresh

↓
Inspect

Debug

Repeat

0.7 — DevTools

Important panels:

Elements

Console

Network

Sources

Application

Performance

Common uses:

Inspect HTML

Edit CSS

Test JavaScript

Find errors

Check requests

Debug
0.8 — Domains, DNS & Hosting

Domain

Human-readable address.

Example:

[Link]

DNS

Converts:

[Link]

93.x.x.x

Hosting

Computer that stores website files.

HTTPS

Encrypted communication.

Protects data in transit.

Deployment

Moving your project:

Local Computer

Hosting
↓

Public Website

0.9 — Standards & Accessibility

Semantic HTML

Choose elements by meaning.

Good:

<header>

<nav>

<main>

<footer>

Not everything should be a <div>.

Accessibility

Goal:

Everyone should be able to use your website.

WCAG Framework:

POUR

Perceivable

Operable

Understandable
Robust

Responsive Design:

Desktop

Tablet

Mobile

Progressive Enhancement:

HTML

CSS

JavaScript

Core first.

Enhancements later.

MODULE 2 — MASTER MIND MAP

INTERNET
│
▼
WEB
│
▼
BROWSER
│
 ┌───────────────┼───────────────┐
▼ ▼ ▼
HTML CSS JavaScript
│ │ │
Structure Appearance Behaviour
│ │ │
└───────────────┼───────────────┘
▼
DOM
│
▼
DevTools
│
▼
Debugging
│
▼
Deployment
│
┌───────────────────┼──────────────────┐
▼ ▼ ▼
Domain DNS Hosting
│
▼
HTTPS
│
▼
User

MODULE 3 — MASTER CHEAT SHEETS

Cheat Sheet 1 — Roles

Technolog
Purpose
y
HTML Structure
Appearanc
CSS
e
Technolog
Purpose
y
JavaScript Behavior

Cheat Sheet 2 — Frontend vs Backend

Backen
Frontend
d
Browser Server
UI Logic
HTML Java
CSS Python
JavaScript [Link]

Cheat Sheet 3 — Paths

./

Current Folder

../

Parent Folder

Cheat Sheet 4 — DevTools

Panel Purpose
Elements Inspect HTML/CSS
Console JavaScript errors
Network Requests
Sources Debug JS
 Panel Purpose
Application Storage

Cheat Sheet 5 — Accessibility

Remember:

POUR

Perceivable

Operable

Understandable

Robust

MODULE 4 — MEMORY TRICKS

HTML

Skeleton 🦴

CSS

Clothes 👕

JavaScript

Muscles & Brain 💪🧠

Internet:

Roads

Web:

Buildings

Browser:

Vehicle

Server:

Warehouse

DNS:

Phonebook / Contact List

Hosting:

Land

Domain:

House Address

Deployment:

Moving into the house

MODULE 5 — MASTER FLASHCARDS

Here are 20 representative flashcards. Your complete course

deck will eventually grow to 300+ cards.

1. Q: What does HTML do?

A: Provides structure and meaning.
2. Q: What does CSS do?
A: Controls appearance and layout.
3. Q: What does JavaScript do?
A: Adds behavior and interactivity.
4. Q: Browser or server: where does HTML render?
A: Browser.
5. Q: Browser or server: where does backend code run?
A: Server.
6. Q: What is DNS?
A: Translates domain names into IP addresses.
7. Q: What is hosting?
A: A server that stores and serves website files.
8. Q: Difference between a website and a web app?
A: Websites mainly present information; web apps
emphasize interaction.
9. Q: What is the DOM?
A: The browser's object representation of an HTML
document.
10. Q: What is a relative path?
A: A path relative to the current file.
11. Q: What does ../ mean?
A: Go to the parent folder.
12. Q: Why use semantic HTML?
A: To give content meaningful structure.
13. Q: Link or button: which navigates?
A: Link.
14. Q: Link or button: which performs an action?
A: Button.
15. Q: Expand POUR.
A: Perceivable, Operable, Understandable, Robust.
16. Q: What is responsive design?
A: Adapting layouts to different screen sizes.
17. Q: What is progressive enhancement?
A: Start with a solid foundation and enhance it.
18. Q: Name three DevTools panels.
A: Elements, Console, Network.
19. Q: What is deployment?
A: Publishing a project so users can access it.
20. Q: What is HTTPS?
A: Encrypted communication between browser and server.
MODULE 6 — FINAL EXAM

Deck A — Internet, Web, Browsers and Servers

1. What is the internet?

Answer: The internet is a global network of interconnected

computer networks that communicate and exchange data.

2. Is the internet the same as the World Wide Web?

Answer: No. The internet is the underlying network

infrastructure. The web is one service that operates through the
internet.

3. What is the World Wide Web?

Answer: The web is a system of linked documents, websites,

applications, and resources accessed over the internet using
browsers.

4. Name three services that use the internet besides the

web.

Answer: Email, video calls, online gaming, file transfer,

messaging, and cloud storage are examples.

5. What is a computer network?

Answer: A computer network is a group of connected devices

that can communicate and share data or resources.

6. What is a client in web development?

Answer: A client is a program or device that requests resources
or services. A web browser usually acts as the client.

7. What is a server?

Answer: A server is a computer or software system that

receives requests and provides resources, data, or services.

8. What is the client-server model?

Answer: It is a model in which a client sends a request to a

server, and the server processes it and sends back a response.

9. What is a web browser?

Answer: A browser is software that requests, processes, and

displays web content.

10. Name four web browsers.

Answer: Google Chrome, Mozilla Firefox, Microsoft Edge, and

Safari.

11. What does a browser do after receiving HTML?

Answer: It parses the HTML, creates the DOM, loads related

resources, applies CSS, runs JavaScript, calculates layout, and
renders the page.

12. What is the difference between a browser and a

search engine?
Answer: A browser is an application used to access the web. A
search engine is a web service used to find webpages.

13. Is Google Chrome a browser or search engine?

Answer: Google Chrome is a browser.

14. Is Google Search a browser or search engine?

Answer: Google Search is a search engine.

15. What is an IP address?

Answer: An IP address is a network address used to identify

and locate a device or destination on an IP network.

16. Why are domain names used instead of IP addresses?

Answer: Domain names are easier for humans to remember

and use than numeric or hexadecimal IP addresses.

17. What is DNS?

Answer: DNS stands for Domain Name System. It helps convert

domain names into information needed to locate internet
destinations.

18. What happens when you type a domain into a

browser?

Answer: The browser resolves the domain through DNS,

connects to the server, sends a request, receives resources, and
renders the webpage.
19. What is an HTTP request?

Answer: An HTTP request is a message sent by a client asking a

server for a resource or requesting an action.

20. What is an HTTP response?

Answer: An HTTP response is the server's reply containing a

status, headers, and usually content or data.

Deck B — Websites and Web Applications

21. What is a webpage?

Answer: A webpage is one individual web document or view

accessed through a browser.

22. What is a website?

Answer: A website is a collection of related webpages,

resources, and functionality usually organised under a shared
identity or domain.

23. What is a web application?

Answer: A web application is software accessed through a

browser that allows users to perform tasks or interact with data.

24. What is the main difference between a traditional

website and a web application?
Answer: A traditional website mainly presents information,
while a web application focuses more heavily on interaction and
completing tasks.

25. Can a product be both a website and a web

application?

Answer: Yes. Many modern products contain informational

website pages and application-like features.

26. What is a static website?

Answer: A static website generally serves prepared files and

content that does not need to be generated separately for every
request.

27. Does “static” mean a website cannot have

animations?

Answer: No. Static describes how content is produced and

served, not whether the page has visual movement or JavaScript
interactions.

28. What is a dynamic website?

Answer: A dynamic website generates, retrieves, or customises

content using application logic, user information, or stored data.

29. Give one example of dynamic content.

Answer: A personalised dashboard showing a particular user's

marks, orders, messages, or progress.
30. What is application state?

Answer: State is the information describing an application's

current situation, such as logged-in user, cart items, current
score, or selected theme.

31. What is an MPA?

Answer: MPA stands for Multi-Page Application. Navigation

commonly loads a new HTML document from the server.

32. What is an SPA?

Answer: SPA stands for Single-Page Application. JavaScript

commonly updates the current document and manages views
without full document reloads for every internal route.

33. Is an SPA automatically better than an MPA?

Answer: No. The right architecture depends on content,

accessibility, performance, complexity, and project
requirements.

34. What is a PWA?

Answer: A Progressive Web App is a web application enhanced

with app-like features such as installation or offline capabilities,
depending on platform support.

35. What is SaaS?

Answer: Software as a Service is software delivered as an

online service, often through a browser and commonly using
accounts or subscriptions.
Deck C — Front End, Back End and Full Stack

36. What is front-end development?

Answer: Front-end development involves building the user-

facing parts of websites and applications that are experienced
mainly in the browser.

37. What are the three foundational front-end

technologies?

Answer: HTML, CSS, and JavaScript.

38. What is back-end development?

Answer: Back-end development involves server-side application

logic, APIs, authentication, permissions, data processing, and
database communication.

39. Where does front-end code primarily run?

Answer: In the user's browser.

40. Where does back-end code primarily run?

Answer: On servers or server-side runtime environments.

41. What is a full-stack developer?

Answer: A full-stack developer works across both front-end and

back-end parts of an application.
42. Does full stack mean knowing every technology?

Answer: No. It means being able to work across multiple

application layers, not mastering every language, framework,
database, and cloud system.

43. What is a tech stack?

Answer: A tech stack is the collection of technologies used to

build, run, store, and deploy an application.

44. What is a database?

Answer: A database is a system used to store, organise,

retrieve, and manage persistent data.

45. Give three examples of data stored in a database.

Answer: User accounts, products, messages, scores, orders,

attendance, and course progress.

46. What is an API?

Answer: An API is a defined interface that allows software

systems or components to communicate.

47. How can a front end use an API?

Answer: The front end sends a request to the API, receives data
or a result, and updates the user interface.

48. What is UI?

Answer: UI means User Interface—the visual and interactive
controls users work with.

49. What is UX?

Answer: UX means User Experience—the overall usability,

clarity, effectiveness, and feeling of using a product.

50. What is DevOps?

Answer: DevOps broadly covers practices and tools used to

build, test, deploy, operate, automate, and monitor software.

Deck D — HTML, CSS, JavaScript and the Browser

51. What does HTML do?

Answer: HTML defines the content, structure, and semantic

meaning of a webpage.

52. What does CSS do?

Answer: CSS controls presentation, styling, spacing, layout,

responsiveness, transitions, and animations.

53. What does JavaScript do?

Answer: JavaScript adds programming logic, behaviour,

interactivity, data handling, and dynamic page updates.

54. Is HTML a programming language?

Answer: HTML is primarily a markup language, not a general-
purpose programming language.

55. What does HTML stand for?

Answer: HyperText Markup Language.

56. What does CSS stand for?

Answer: Cascading Style Sheets.

57. What is the DOM?

Answer: The DOM, or Document Object Model, is the browser's

tree-like object representation of a document.

58. Why is the DOM important?

Answer: It gives JavaScript a structured way to access and

modify document elements, attributes, and content.

59. What is the CSSOM?

Answer: The CSSOM is the browser's object representation of

CSS rules and style information.

60. What is the difference between HTML source and the

DOM?

Answer: HTML source is the original markup. The DOM is the

browser's current representation and may be changed by
JavaScript.
61. What is rendering?

Answer: Rendering is the process through which the browser

turns HTML, CSS, images, fonts, and other resources into visual
output.

62. What is layout in browser rendering?

Answer: Layout is the stage where the browser calculates the

size and position of elements.

63. What is painting?

Answer: Painting is the process of drawing visual elements such

as text, backgrounds, borders, and images.

64. What is a browser event?

Answer: An event is something that happens in the browser,

such as a click, key press, form submission, or input change.

65. What is an event listener?

Answer: An event listener is code registered to run when a

particular event occurs.

Deck E — Files, Folders and Paths

66. What is a file extension?

Answer: A file extension is the ending of a filename that

commonly identifies its format, such as .html, .css, or .js.
67. Which extension is used for HTML files?

Answer: .html

68. Which extension is used for CSS files?

Answer: .css

69. Which extension is used for JavaScript files?

Answer: .js

70. What is a project root?

Answer: The project root is the top-level folder from which the
project's files and folders are organised.

71. What is a file path?

Answer: A file path describes how to locate a file or folder.

72. What is a relative path?

Answer: A relative path locates a resource based on the current

document or base location.

73. What does ./ mean in a relative path?

Answer: It represents the current directory.

74. What does ../ mean?

Answer: It means move up to the parent directory.

75. What does ../../ mean?

Answer: It means move up two directory levels.

76. What is an absolute URL?

Answer: A complete URL containing the full address, such as

[Link]

77. What does a leading / mean in a web URL path?

Answer: It generally starts the path from the site's root.

78. What is href commonly used for?

Answer: It identifies a referenced destination or resource, such

as a link target or stylesheet.

79. What is src commonly used for?

Answer: It identifies the source of a resource that an element

loads, such as an image or script.

80. Why might CSS fail to load even when the CSS code is
correct?

Answer: The filename, extension, path, folder location, or letter

case may be incorrect.
Deck F — Environment, DevTools and Debugging

81. What is a code editor?

Answer: A code editor is software designed for writing, editing,

and managing source code.

82. What code editor are we using?

Answer: Visual Studio Code, commonly called VS Code.

83. What is a workspace in VS Code?

Answer: A workspace is the project context, commonly an

opened project folder containing related files.

84. What is the basic development loop?

Answer: Write → Save → Run → Observe → Inspect → Debug →

Fix → Verify.

85. What are browser DevTools?

Answer: DevTools are browser-provided tools for inspecting,

testing, analysing, and debugging webpages.

86. What is the Elements panel used for?

Answer: It is used to inspect and temporarily edit the current

DOM, CSS rules, computed styles, and layout.
87. What is the Console used for?

Answer: It is used to run JavaScript, view logs, inspect values,

and read errors or warnings.

88. What is the Network panel used for?

Answer: It is used to inspect resource requests, status codes,

loading times, and API communication.

89. What is the Sources panel used for?

Answer: It is used to inspect loaded source files and debug

JavaScript using tools such as breakpoints.

90. What does [Link]() do?

Answer: It prints a value or message to the browser's

debugging console.

91. What does querySelector() return when no matching

element is found?

Answer: It returns null.

92. What does a 404 status usually mean?

Answer: The requested resource was not found at the

requested location.

93. What is a breakpoint?

Answer: A breakpoint pauses JavaScript execution at a selected
line so the program's state can be inspected.

94. What is the correct debugging cycle?

Answer: Reproduce → Observe → Inspect → Form a hypothesis

→ Test → Fix → Verify.

95. Why should you change only one thing at a time

while debugging?

Answer: It allows you to identify exactly which change fixed or

caused the problem.

Deck G — Domains, Hosting, Standards and Accessibility

96. What is the difference between a domain and

hosting?

Answer: A domain is the human-readable address. Hosting is

the infrastructure that stores, serves, or runs the website.

97. What is deployment?

Answer: Deployment is the process of placing a website or

application into an environment where its intended users can
access it.

98. What is semantic HTML?

Answer: Semantic HTML means using elements according to

their meaning and purpose rather than only their appearance.
99. What does POUR stand for in accessibility?

Answer: Perceivable, Operable, Understandable, and Robust.

100. What is progressive enhancement?

Answer: Progressive enhancement means starting with a solid,

meaningful foundation and then adding styling and advanced
behaviour in layers.

MODULE 7 — PRACTICAL ASSESSMENTS

You'll complete practical tasks such as:

 Draw the request flow from typing a URL to rendering a

webpage.
 Organize a web project into folders.
 Identify broken file paths.
 Use DevTools to inspect and debug a page.
 Explain the difference between static and dynamic
websites.
 Design a semantic page structure.
 Perform a basic accessibility review.
 Explain how a website becomes publicly available.

MODULE 8 — DEBUGGING CHALLENGE

You'll be given intentionally broken mini-projects where you

must identify issues like:

 Incorrect file paths

 Missing CSS
 Broken JavaScript links
 Incorrect HTML structure
 Semantic mistakes
 Accessibility issues

This mirrors what real developers do daily.

MODULE 9 — PHASE 0 READINESS CHECKLIST

Before starting HTML, you should confidently answer YES to

these:

 ✅ I understand the difference between the Internet and the

Web.
 ✅ I know how a browser loads a webpage.
 ✅ I know the roles of HTML, CSS, and JavaScript.
 ✅ I understand frontend vs backend.
 ✅ I can organize a web project.
 ✅ I understand relative paths.
 ✅ I know how to use DevTools.
 ✅ I understand domains, DNS, hosting, and deployment.
 ✅ I know why semantic HTML matters.
 ✅ I understand the basics of accessibility and responsive
design.

If you can genuinely tick these off, you're ready.

MODULE 10 — 🎓 PHASE 0 GRADUATION

Congratulations! 🎉

You have completed the Foundation Phase of the course.

You now possess the vocabulary and mental models that many
beginners skip. That foundation will make learning HTML much
smoother because you'll understand why things work, not just
how to type tags.

END OF PHASE 0
 PHASE 1
Roadmap for Phase 1:
Lesso Practical
Topic What You'll Learn
n Outcome
What HTML is, markup,
HTML Create your first
1.1 elements, first
Introduction HTML page
document
Tags vs elements,
Tags, Elements Write correctly
1.2 attributes, nesting, void
& Attributes structured HTML
elements
Document doctype, html, head, Build a proper
1.3
Structure body, metadata HTML document
Headings & h1–h6, p, whitespace, Create
1.4
Paragraphs hierarchy structured text
strong, em, mark, small, Mark up
1.5 Text Semantics
code, br, hr meaningful text
Lesso Practical
Topic What You'll Learn
n Outcome
a, href,
Links & Create page
1.6 relative/absolute URLs,
Navigation navigation
fragments
img, src, alt,
Add accessible
1.7 Images dimensions, figure,
images
figcaption
Build menus
1.8 Lists ul, ol, li, dl, dt, dd and structured
lists
Organise
Generic
1.9 div, span, classes, IDs content
Containers
correctly
header, nav, main, Build
1.10 Semantic HTML section, article, aside, professional
footer page structure
Create
table, tr, th, td, thead,
1.11 Tables accessible data
tbody, captions
tables
form, label, input, Build your first
1.12 Forms — Basics
button form
Text, email, password,
Build useful
1.13 Input Types number, date,
form controls
checkbox, radio, file
Form Labels, required,
Create better
1.14 Accessibility & constraints, validation
forms
Validation basics
Advanced Form select, option, textarea, Build complete
1.15
Controls fieldset, legend forms
audio, video, iframe, Add media
1.16 Multimedia
embedded content responsibly
Configure
The <head> title, meta, link, favicon,
1.17 document
Deep Dive useful metadata
metadata
Semantic structure,
Accessibility & Write accessible
1.18 keyboard access, alt,
Best Practices HTML
labels
1.19 HTML Revision Complete revision, Measure your
& Assessment flashcards, cheat HTML
Lesso Practical
Topic What You'll Learn
n Outcome
sheets, test knowledge
Multi-page website Build a
Final HTML
1.20 using everything complete HTML-
Project
learned only website

LESSON 1.1

Introduction to HTML

Today's goals

By the end of this lesson, you should understand:

What HTML is
What markup means
What an HTML element is
What a tag is
What an attribute is
How HTML elements are nested
What the DOM tree looks like
How to create your first HTML document
How to open and inspect it

1. What Is HTML?

HTML stands for:

HyperText Markup Language

HTML is the language used to structure web content and

give it meaning.

For example:

<h1>My Portfolio</h1>

This tells the browser:

"My Portfolio is a level-one heading."

And:

<p>I am learning web development.</p>

tells the browser:

"This is a paragraph."

The key idea:

HTML
↓
What is this content?
What role does it have?
How is it structured?

The WHATWG HTML Standard defines HTML documents as trees

built from elements and text; HTML elements and attributes
provide semantics and structure that browsers and other tools
can interpret.

2. HTML Is a Markup Language

Let's say I give you plain text:

My Web Development Journey

I am learning HTML.

A browser can display that text, but it doesn't automatically

know the intended structure.

Now add HTML:

<h1>My Web Development Journey</h1>

<p>I am learning HTML.</p>

Now the browser understands:

h1
↓
Main heading
p
↓
Paragraph

So the markup adds structure and meaning.

That's what HTML does.

3. HTML Is Not CSS

Consider:

<h1>My Portfolio</h1>

HTML says:

This is a heading.

CSS can later say:

h1 {
color: darkblue;
font-size: 48px;
}

CSS says:

Make the heading look like this.

So:

HTML → Meaning and structure

CSS → Presentation

We'll learn CSS in Phase 2.

4. HTML Is Not JavaScript

JavaScript adds programming behaviour.

Suppose we have:

<button>Click Me</button>

HTML says:

There is a button.

JavaScript could later make it do something:

[Link]("click", () => {
alert("Hello!");
});

So:

HTML
↓
Button exists

JavaScript
↓
Button responds

For now, just remember:

HTML → Structure
CSS → Style
JavaScript → Behaviour

5. What Is a Tag?

Consider:

<p>

This is an opening tag.

And:

</p>

This is a closing tag.

The general structure is:

<element-name>

and:

</element-name>

The closing tag contains:

before the element name.

6. What Is an Element?

Look at:

<p>Hello, bro!</p>

The complete structure is an HTML element.

Break it down:

<p> → Opening tag

Hello, bro! → Content

</p> → Closing tag

Together:

Opening tag
+
Content
+
Closing tag
=
HTML element

This distinction is useful:

Tag
↓
<p>

Element
↓
<p>Hello, bro!</p>

MDN's current HTML reference describes HTML elements as

structures created using tags, while the HTML Standard
describes documents as trees of elements and text.

7. Your First Element

Write:

<h1>Hello, World!</h1>

The browser understands:

h1
↓
Heading

The text is:

Hello, World!

The complete element is:

<h1>Hello, World!</h1>

8. Your Second Element

Write:

<p>I am learning HTML.</p>

The browser understands:

p
↓
Paragraph
So:

<h1>Hello, World!</h1>

<p>I am learning HTML.</p>

creates:

Hello, World!

I am learning HTML.

HTML's main role includes giving text structure through

elements such as headings and paragraphs.

9. Nesting Elements

HTML elements can be placed inside other HTML elements.

Example:

<p>
I am learning <strong>HTML</strong>.
</p>

The structure is:

p
├── "I am learning "
├── strong
│ └── "HTML"
└── "."

Here:

<p>
↓
Parent element

<strong>
↓
Child element
10. Parent, Child and Sibling

Consider:

<main>
<h1>My Website</h1>

<p>Welcome!</p>
</main>

The DOM structure is roughly:

main
├── h1
└── p

Therefore:

main
↓
Parent

h1
p
↓
Children

And:

h1
p
↓
Siblings

This tree structure becomes extremely important when you later

learn:

CSS selectors
DOM manipulation
JavaScript
Accessibility
The HTML Standard describes HTML elements as forming a tree
through the DOM.

11. Correct Nesting

Correct:

<p>
This is <strong>very important</strong>.
</p>

The structure is:

<p>
<strong>
</strong>
</p>

The inner element closes first.

Incorrect

<p>
This is <strong>very important.
</p>
</strong>

This creates overlapping element boundaries.

HTML elements should be nested properly rather than

overlapping each other. The HTML specification explicitly
describes correct nesting as elements being completely
contained inside other elements when nested.

Think:

Correct:

┌─────────────── <p> ────────────────┐

│ │
│ ┌────── <strong> ──────┐ │
│ │ │ │
│ └───────────────────────┘ │
│ │
└────────────────────────────────────┘

Not:

<p>───────────────┐
│
<strong>──────┤
│
</p>───────────────┘
<strong> closes later ❌

12. Attributes

Now let's look at:

<html lang="en">

This has:

Element
↓
html

Attribute
↓
lang

Value
↓
en

The general structure is:

<element attribute="value">

Another example:

<a href="[Link]">About</a>
Here:

a
↓
Element

href
↓
Attribute

[Link]
↓
Attribute value

Attributes provide additional values that configure elements or

adjust their behaviour.

We'll study attributes in detail in Lesson 1.2.

13. Void Elements

Some HTML elements don't wrap content and don't have normal
closing tags.

Example:

<img
src="[Link]"
alt="Profile photograph"
>

You don't write:

<img></img>

Other examples include:

<meta>
<link>
<input>
<br>
<hr>
These are called void elements in HTML terminology.

Don't worry about memorising them all yet.

We'll learn the important ones as we encounter them.

14. Your First HTML Document

Now let's create your first actual HTML project.

Create:

web-development-course/
└── 02-phase-1-html/
└── lesson-01/
└── [Link]

Open [Link] in VS Code.

Write:

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">

<meta
name="viewport"
content="width=device-width, initial-scale=1"
>

<title>My First HTML Page</title>

</head>

<body>
<h1>My First HTML Page</h1>

<p>
I have officially started learning HTML.
</p>
 <p>
HTML gives structure and meaning to web content.
</p>
</body>
</html>

Save the file.

Open it in your browser.

You should see:

My First HTML Page

I have officially started learning HTML.

HTML gives structure and meaning to web content.

🎉 This is your first Phase 1 webpage.

15. Understanding the Complete Structure

Here's the structure visually:

<!doctype html>

<html>
│
├── <head>
│ ├── <meta charset="UTF-8">
│ ├── <meta name="viewport" ...>
│ └── <title>
│
└── <body>
├── <h1>
├── <p>
└── <p>

The HTML document is a tree.

The root is:

<html>

Inside it:

<head>
<body>

Inside <head>:

<meta>
<meta>
<title>

Inside <body>:

<h1>
<p>
<p>

This is the same tree-like document model we've been

discussing since Phase 0.

16. <!doctype html>

<!doctype html>

This tells the browser to use the modern HTML parsing mode.

It is a document type declaration, not a normal HTML

element.

Put it at the beginning of your HTML document:

<!doctype html>

This short HTML doctype is the standard modern form used in

HTML documents.

17. <html>
<html lang="en">

This is the root HTML element.

Everything in the document is contained inside it.

The attribute:

lang="en"

declares English as the document's language.

The document then closes:

</html>

So:

<html>
Everything
</html>

The HTML standard defines the html element as the root

element of an HTML document.

18. <head>
<head>

The <head> contains document metadata.

In our example:

<head>
<meta charset="UTF-8">

<meta
name="viewport"
content="width=device-width, initial-scale=1"
>

<title>My First HTML Page</title>

</head>

This information is mostly about the document rather than the

primary visible page content. The HTML Standard defines the
head as a place for document metadata.
19. <meta charset="UTF-8">
<meta charset="UTF-8">

This declares the document's character encoding.

UTF-8 allows the document to represent a very large range of

characters.

For example:

Hello
नमस्ते
こんにちは
🚀

This is why we generally include:

<meta charset="UTF-8">

near the beginning of the <head>.

20. <meta name="viewport">

<meta
name="viewport"
content="width=device-width, initial-scale=1"
>

This helps mobile browsers establish the viewport configuration

used by the page.

We'll go much deeper into responsive CSS in Phase 2.

For now:

viewport
↓
Important for responsive pages
21. <title>
<title>My First HTML Page</title>

This defines the document title.

You can usually see it in:

 The browser tab

 Bookmarks
 Browser history
 Other browser UI

It is not normally displayed as the main heading inside

the webpage.

Compare:

<title>My First HTML Page</title>

with:

<h1>My First HTML Page</h1>

The first:

Browser/document title

The second:

Visible page heading

They serve different purposes.

22. <body>
<body>

The body contains the document's main visible content.

For example:

<body>
<h1>My First HTML Page</h1>
 <p>I am learning HTML.</p>
</body>

This is where you'll eventually place:

Headings
Paragraphs
Links
Images
Lists
Tables
Forms
Articles
Navigation
Videos

and much more.

23. <h1>
<h1>My First HTML Page</h1>

h1 represents a top-level heading.

HTML provides headings from:

h1
h2
h3
h4
h5
h6

We'll study heading hierarchy carefully in Lesson 1.4.

For now:

h1
↓
Highest-level heading

h2
↓
Heading beneath h1

h3
↓
Heading beneath h2

The important thing is to use headings according to document

structure, not merely to make text bigger. MDN's current HTML
guidance treats headings as fundamental structural elements.

24. <p>
<p>
I have officially started learning HTML.
</p>

The <p> element represents a paragraph.

Use it for actual paragraphs of text.

Don't use it merely because you want some random spacing.

CSS controls spacing.

HTML communicates meaning.

25. Your First DevTools Investigation

Open your page in Chrome.

Press:

Ctrl + Shift + I

Go to:

Elements

You should see the DOM structure.

Something similar to:

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

<body>
<h1>My First HTML Page</h1>

<p>
I have officially started learning HTML.
</p>

<p>
HTML gives structure and meaning to web content.
</p>
</body>
</html>

Now connect this to our earlier lessons:

HTML source
↓
Browser parses it
↓
DOM tree
↓
DevTools displays current DOM

26. Practical Exercise 1 — Personal Introduction

Modify your page.

Create:

<h1>About Me</h1>

<p>
My name is ______.
</p>

<p>
 I am learning web development.
</p>

<p>
My current goal is ______.
</p>

Replace the blanks with your own information.

Don't add CSS yet.

Our goal is to learn HTML structure, not design.

27. Practical Exercise 2 — Add a Learning Section

Add:

<h2>What I Am Learning</h2>

<p>
I am currently learning HTML.
</p>

Your structure should look like:

h1
├── p
├── p
├── p
└── h2
└── p

This gives us our first look at heading hierarchy.

28. Practical Exercise 3 — Add More Structure

Build:

<h1>My Web Development Journey</h1>

<h2>About Me</h2>

<p>
I am a beginner learning web development.
</p>

<h2>My Goals</h2>

<p>
I want to learn HTML, CSS, and JavaScript.
</p>

<h2>My Current Progress</h2>

<p>
I have completed Phase 0.
</p>

Look at the structure:

h1
│
├── h2
│ └── p
│
├── h2
│ └── p
│
└── h2
└── p

This is a much more meaningful document structure than simply

using large text everywhere.

29. Common Beginner Mistakes

Mistake 1 — Forgetting to close elements

Wrong:

<p>Hello
Correct:

<p>Hello</p>

Some HTML elements are void elements, but normal elements

generally need proper opening and closing tags.

Mistake 2 — Incorrect nesting

Wrong:

<p>
<strong>Hello</p>
</strong>

Correct:

<p>
<strong>Hello</strong>
</p>

Mistake 3 — Using <h1> for everything

Wrong thinking:

I need big text.

↓
Use h1.

Correct thinking:

What is this content?

↓
Choose the meaningful HTML element.
↓
Use CSS for appearance.

Mistake 4 — Confusing <title> and <h1>

<title>
controls the document title.

<h1>

represents a page heading.

Different jobs.

Mistake 5 — Putting visible content in <head>

Wrong:

<head>
<h1>Hello</h1>
</head>

Main visible content belongs in:

<body>

Mistake 6 — Using HTML for spacing

Bad:

<p>First paragraph</p>
<br>
<br>
<br>
<p>Second paragraph</p>

Don't use repeated <br> elements as a general layout system.

Later, CSS will handle spacing.

HTML should communicate structure.

30. Your First HTML Mental Model

Remember:
<!doctype html>
↓
Document type declaration

<html>
↓
Root element

<head>
↓
Document metadata

<body>
↓
Main page content

Inside <body>:

<h1>
↓
Main heading

<h2>
↓
Subheading

<p>
↓
Paragraph

And:

Elements
↓
Can contain other elements
↓
Create a tree
↓
Become the DOM

This is the foundation of everything we'll do in HTML.

31. Lesson 1.1 Cheat Sheet
HTML
HyperText Markup Language
↓
Structure + meaning

TAG
<p>

ELEMENT
<p>Hello</p>

ATTRIBUTE
href="[Link]"

OPENING TAG
<p>

CLOSING TAG
</p>

PARENT
Element containing another element

CHILD
Element inside another element

SIBLINGS
Elements sharing the same parent

VOID ELEMENT
Element without normal closing tag

Basic document

<!doctype html>

<html lang="en">
 <head>
<meta charset="UTF-8">

<meta
name="viewport"
content="width=device-width, initial-scale=1"
>

<title>Page Title</title>
</head>

<body>
<h1>Main Heading</h1>

<p>Paragraph.</p>
</body>

</html>

32. Lesson 1.1 Flashcards

Card 1

Q: What does HTML stand for?

A: HyperText Markup Language.

Card 2

Q: What is HTML's primary job?

A: To structure web content and communicate its meaning.

Card 3

Q: What is a tag?
A: Markup syntax such as <p> or </p> used to form HTML
elements.

Card 4
Q: What is an HTML element?
A: A complete HTML structure consisting of an element's
markup and its content where applicable.

Card 5

Q: What is an attribute?
A: Additional information that configures or describes an HTML
element.

Card 6

Q: What does lang="en" indicate?

A: The document content is in English.

Card 7

Q: What does <head> contain?

A: Document metadata and references to resources such as
stylesheets and scripts.

Card 8

Q: What does <body> contain?

A: The document's main page content.

Card 9

Q: What does <title> define?

A: The document's title, commonly shown in the browser tab.

Card 10

Q: What is a void element?

A: An HTML element that doesn't contain child content and
doesn't use a normal closing tag.

Card 11

Q: What is the DOM?

A: The browser's object representation of the document
structure.

Card 12
Q: What is a parent element?
A: An element that contains another element.

Card 13

Q: What are siblings?

A: Elements that share the same parent.

Card 14

Q: Why is semantic HTML important?

A: It communicates meaning and structure to browsers,
assistive technologies, and other tools.

33. Lesson 1.1 Mini Test

Try these without looking back.

Section A — Multiple Choice

1. HTML primarily defines:

A. Database structure
B. Webpage structure and meaning
C. Server hardware
D. Internet speed

2. Which is an element?

A. href
B. "[Link]"
C. <p>Hello</p>
D. class

3. Which is an attribute?

A. <p>
B. href="[Link]"
C. Hello
D. </p>

4. Where does the document title normally go?

A. <body>
B. <main>
C. <head>
D. <footer>

5. Which element contains the main visible document

content?

A. <head>
B. <body>
C. <meta>
D. <title>

Section B — True or False

6. HTML is primarily a markup language.

7. CSS is responsible for the semantic structure of a webpage.

8. JavaScript can modify the DOM.

9. <h1> and <p> can be siblings if they share the same parent.

10. <img> normally needs a closing </img> tag.

Section C — Identify the Parts

For:

<a href="[Link]">About Me</a>

Identify:

Element:
Opening tag:
Attribute:
Attribute value:
Content:
Closing tag:
Section D — Structure

Given:

<main>
<h1>My Website</h1>

<p>Welcome!</p>

<p>I am learning HTML.</p>

</main>

Answer:

Parent:
Children:
Siblings:

34. Your Lesson 1.1 Practical

Create this page:

My Web Development Journey

│
├── About Me
│ └── Paragraph
│
├── What I Am Learning
│ └── Paragraph
│
└── My Goal
└── Paragraph

The HTML should use:

<!doctype html>
<html>
<head>
<body>
<title>
<h1>
<h2>
<p>

Your final structure should approximately be:

<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">

<meta
name="viewport"
content="width=device-width, initial-scale=1"
>

<title>My Web Development Journey</title>

</head>

<body>
<h1>My Web Development Journey</h1>

<h2>About Me</h2>
<p>
...
</p>

<h2>What I Am Learning</h2>
<p>
...
</p>

<h2>My Goal</h2>
<p>
...
</p>
</body>
</html>

Use your own words for the paragraphs.

Then open it in Chrome and inspect it using DevTools.

35. Phase 1 Progress

You've now completed:

Phase 0
├── 0.1 ✅ Internet & Web
├── 0.2 ✅ Websites & Web Apps
├── 0.3 ✅ Frontend / Backend / Full Stack
├── 0.4 ✅ HTML / CSS / JavaScript
├── 0.5 ✅ Files / Folders / Paths
├── 0.6 ✅ Development Environment
├── 0.7 ✅ DevTools / Debugging
├── 0.8 ✅ Domains / DNS / Hosting
├── 0.9 ✅ Standards / Accessibility
└── 0.10 ✅ Final Revision / Assessment

Phase 1 — HTML
└── 1.1 ✅ Introduction to HTML

Lesson 1.2 — Tags, Elements, Attributes, Nesting & Void

Elements
Welcome back, bro. 😎
In Lesson 1.1, you learned the basic HTML document:
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">

<meta
name="viewport"
content="width=device-width, initial-scale=1"
 >

<title>My First HTML Page</title>

</head>

<body>
<h1>My First HTML Page</h1>

<p>I am learning HTML.</p>

</body>
</html>
Today we're going to zoom way in and understand exactly how
HTML syntax works.
The HTML Living Standard defines HTML elements, attributes,
and attribute values as meaningful parts of the language, and
browsers parse HTML according to defined parsing rules—even
when the source contains errors. That makes understanding the
syntax properly very important, even though browsers can
sometimes recover from mistakes.

What you'll learn today

By the end of Lesson 1.2, you should understand:
1. Tags
2. Elements
3. Opening and closing tags
4. Attributes
5. Attribute names and values
6. Quotation rules
7. Multiple attributes
8. Global attributes
9. id
10. class
11. lang
12. title
13. data-*
14. hidden
15. Boolean attributes
16. Nesting
17. Parent, child, sibling relationships
18. Void elements
19. HTML comments
20. Whitespace
21. Case sensitivity
22. Common syntax mistakes
23. How the browser parses broken HTML

1. The Anatomy of HTML

Let's start with this:
<p>Hello, bro!</p>
We can break it down into:
<p> Hello, bro! </p>
↑ ↑ ↑
Opening Content Closing
tag tag
The complete thing is:
HTML Element
The individual pieces are:
<p>
↓
Opening tag

Hello, bro!
↓
Text content

</p>
↓
Closing tag
The HTML specification treats elements as structural units in the
document tree, and their names and attributes carry defined
semantics.

2. Tags vs Elements
This distinction is small but important.

Tag

This is a tag:
<p>
This is also a tag:
</p>

Element

This is the complete element:

<p>Hello, bro!</p>
So:
Opening tag
+
Content
+
Closing tag
=
Element
For a normal element:
<h1>My Portfolio</h1>
we have:
<h1>
↓
Opening tag

My Portfolio
↓
Content

</h1>
↓
Closing tag
As we continue, you'll often hear developers casually say "tag"
when they mean "element." That's common in conversation, but
understanding the distinction is useful.

3. Opening Tags
An opening tag looks like:
<element-name>
Examples:
<p>
<h1>
<main>
<section>
<article>
The basic structure is:
<
element name
>
For example:
<p>
means:
<
p
>
The browser recognises p as the element name.

4. Closing Tags
A closing tag usually looks like:
</element-name>
Notice the /.
For example:
</p>
The structure is:
<
/
element name
>
So:
<p>Hello</p>
means conceptually:
Start a paragraph
↓
Hello
↓
End the paragraph

5. Not Every Element Has a Closing Tag

Some elements are void elements.
For example:
<img src="[Link]" alt="Profile photograph">
There is no:
</img>
Similarly:
<input type="text">
doesn't have:
</input>
In HTML syntax, void elements do not have end tags. This is a
property of the HTML syntax itself; it is different from the
separate concept of an element having a "nothing" content
model.
We'll come back to void elements in detail shortly.
6. Attributes
Now let's look at:
<a href="[Link]">About Me</a>
The element is:
a
The attribute is:
href
The attribute value is:
[Link]
So:
href="[Link]"
is the complete attribute.
Attributes are placed in the start tag and generally consist of an
attribute name and value. HTML also defines a special class of
attributes, called global attributes, that can be used across
HTML elements.

7. Attribute Anatomy
Consider:
<img src="[Link]" alt="My profile photograph">
Let's dissect it.
<img
src="[Link]"
alt="My profile photograph"
>
We have:
Element name
↓
img
Attribute 1
↓
src

Attribute 1 value
↓
[Link]

Attribute 2
↓
alt

Attribute 2 value
↓
My profile photograph
The general pattern is:
<element attribute="value">

8. Multiple Attributes
An element can have multiple attributes.
Example:
<img
src="[Link]"
alt="My profile photograph"
width="300"
height="300"
>
Here we have:
src
alt
width
height
Each attribute is separated from the next by whitespace.
So the browser can conceptually read:
img
├── src
├── alt
├── width
└── height
Attributes must not be duplicated on the same start tag using
names that match case-insensitively.
So avoid:
<input id="email" id="username">
That's invalid HTML syntax because id appears twice on the
same start tag.

9. Attribute Values and Quotes

The most common style is:
attribute="value"
For example:
<a href="[Link]">
You can also use single quotes:
<a href='[Link]'>
Both are valid HTML attribute-value quoting styles.
HTML also permits certain attribute values to be left unquoted
when they satisfy specific restrictions, but quoted values are
generally the clearest style for beginners and reduce accidental
syntax problems. The HTML syntax specification defines double-
quoted, single-quoted, and restricted unquoted attribute-value
forms.

Our course convention

We'll normally write:

attribute="value"
using double quotes.
For consistency, I recommend you do the same.

10. Why Quotes Matter

Consider:
<p title="This is a helpful message">
Hello
</p>
This is clear.
Now imagine:
<p title=This is a helpful message>
The spaces make the intended attribute value ambiguous and
invalid under the unquoted attribute rules.
When an attribute value contains whitespace or certain special
characters, it needs to be quoted.
So:
title="This is a helpful message"
is the safe, readable choice.
11. Empty Attributes
HTML has an empty attribute syntax where an attribute can
appear without an explicit value.
For example:
<input disabled>
However, you need to understand that this interacts with the
concept of boolean attributes, which we'll cover next.
The HTML specification defines empty attribute syntax
separately from normal quoted and unquoted attribute values.

12. Boolean Attributes

Now we get to an important concept.
A boolean attribute represents a true/false state through its
presence or absence.
Example:
<input disabled>
The disabled attribute is present.
Therefore:
disabled = true
If we remove it:
<input>
then:
disabled = false
The HTML standard explicitly defines boolean attributes this
way: presence means true; absence means false.

13. The Big Boolean Attribute Rule

This is extremely important:
<input disabled="false">
does not mean disabled is false.
The attribute is still present.
Therefore the boolean attribute is still true.
Conceptually:
disabled
↓
Present
↓
TRUE
The value "false" does not turn it off.
The HTML standard explicitly says the strings "true" and "false"
are not valid values for boolean attributes. To represent false,
omit the attribute entirely.
So:
<input disabled>
means:
Disabled = true
Whereas:
<input>
means:
Disabled = false
This is one of those tiny HTML details that saves you from weird
bugs later.

14. Common Boolean Attributes

You'll encounter boolean attributes such as:
disabled
checked
required
multiple
autofocus
controls
defer
readonly
selected
hidden
The exact meaning depends on the element.
For example:
<input type="checkbox" checked>
means the checkbox has the checked attribute.
And:
<input type="text" required>
means the required constraint is specified.
The HTML specification defines boolean attributes for many
elements, including form controls and scripting/media-related
elements.

15. id — The Unique Identifier

The id attribute gives an element an identifier.
Example:
<p id="intro">
Welcome to my website.
</p>
The identifier is:
intro
You can later refer to it from:
CSS
JavaScript
URL fragments
For example:
<a href="#intro">
Jump to introduction
</a>
The id value identifies the target.
The HTML standard says an element's id identifies that element
and should be unique within its tree; it must not contain ASCII
whitespace. The identifier can be used for fragments, CSS
targeting, and scripting.

16. id Should Usually Be Unique

Good:
<h1 id="page-title">
My Portfolio
</h1>

<p id="intro">
Welcome!
</p>
Different IDs:
page-title
intro
Avoid:
<h1 id="title">My Portfolio</h1>
<p id="title">Welcome!</p>
Both elements have:
id="title"
This creates a duplicate identifier problem.
A good mental model:
id
↓
One specific element
Think:
Student ID
↓
Identifies one student

17. class — Grouping Elements

The class attribute is used to assign one or more class names to
an element.
Example:
<p class="highlight">
Important information.
</p>
You can also have multiple class names:
<p class="highlight important">
Important information.
</p>
Now the element belongs to:
highlight
important
The HTML standard defines class as a space-separated set of
tokens representing the classes to which an element belongs.
Classes are commonly used by CSS selectors and DOM APIs.

18. id vs class
This is one of the most important beginner distinctions.

id

Identifies a particular element.

<h1 id="main-title">
My Website
</h1>
Mental model:
id
↓
This particular element

class

Groups elements into a category.

<p class="highlight">Important.</p>

<p class="highlight">Also important.</p>

Mental model:
class
↓
These elements share a category
We will use both heavily when we reach CSS and JavaScript.
19. One Element Can Have an id and class
That's completely fine:
<button
id="submit-button"
class="primary-button"
>
Submit
</button>
Now:
id
↓
submit-button
and:
class
↓
primary-button
The two attributes serve different purposes.

20. Multiple Classes

You can assign several classes:
<button class="button primary large">
Submit
</button>
This element belongs to three classes:
button
primary
large
The classes are separated by spaces.
Think of this as:
class="class1 class2 class3"
The HTML standard defines the class value as space-separated
tokens, which is why spaces separate individual class names.

21. lang — Language Information

You've already seen:
<html lang="en">
The lang attribute specifies the primary language of an
element's content and relevant text-valued attributes.
It can also be applied to individual elements.
For example:
<p lang="fr">
Bonjour!
</p>
The lang attribute uses language tags such as those defined by
BCP 47.
For our normal English pages:
<html lang="en">
is a good starting point.

22. Why lang Matters

The language information can help software determine things
like:
Pronunciation
Translation
Font choices
Form control presentation
Language-specific processing
For example, assistive technology may use language
information when determining how to pronounce text.
So this:
<html lang="en">
is not just decoration.
It communicates information about your document.

23. title — Additional Advisory Information

The title attribute can provide a title or advisory information for
certain elements.
Example:
<button title="Save your work">
Save
</button>
You may encounter it on:
<a title="Read the article">
Read
</a>
However, don't treat title as a replacement for visible labels,
accessible names, or proper instructions.
For example, don't build:
<button title="This button saves your document">
💾
</button>
and assume title alone solves every accessibility concern.
We'll examine accessibility and accessible names more deeply
later.
The HTML standard defines title as a global attribute with
advisory information semantics, though its exact use and effect
depend on the element and user agent.

24. data-* Custom Data Attributes

HTML provides a standard mechanism for storing custom, non-
visible data using attributes beginning with:
data-
Example:
<button
data-course-id="101"
data-level="beginner"
>
Start Course
</button>
Here we have:
data-course-id
data-level
These attributes can store custom data associated with the
element.
The HTML standard explicitly provides data-* attributes for
embedding custom non-visible data, which can then be
accessed through DOM APIs.

25. data-* Is Not a Replacement for Semantics

Don't do this:
<div data-type="button">
Click Me
</div>
and assume you've created a button.
You haven't.
You've created:
A div
+
custom data
The actual semantic element is still:
<button>
So:
<button data-action="save">
Save
</button>
makes sense.
But:
<div data-action="save">
Save
</div>
doesn't magically become a button.
Custom data stores information.
It doesn't redefine the element's core semantics.

26. hidden
The hidden attribute can indicate that an element is not
currently relevant for display.
For example:
<p hidden>
This content is currently hidden.
</p>
The HTML standard defines hidden as an enumerated attribute
with hidden states, including a hidden-until-found mode in
modern HTML.
For now, the basic mental model is:
<p hidden>
means:
This content is hidden from normal rendering.
However, hidden is not a general substitute for CSS visibility or
every JavaScript UI state. We'll explore when and how to use it
appropriately later.

27. class Is Not Just for CSS

Beginners often think:
class
↓
CSS only
Not true.
Classes are also useful for:
CSS selectors
JavaScript DOM selection
DOM APIs
Grouping elements conceptually
Example:
<p class="message">
Hello
</p>
CSS could select:
.message {
color: blue;
}
JavaScript could select:
[Link](".message");
So:
class
↓
A shared identifier/category

28. HTML Nesting

Now let's go deeper into nesting.
Consider:
<main>
<h1>My Website</h1>

<p>Welcome to my website.</p>
</main>
The tree is:
main
├── h1
│ └── "My Website"
│
└── p
└── "Welcome to my website."
This means:
main
↓
Parent of h1 and p
And:
h1
p
↓
Siblings
The browser constructs a tree-like DOM from the document, and
these parent/child relationships are fundamental to CSS
selectors, scripting, and accessibility.

29. Deep Nesting

You can nest multiple levels.
Example:
<main>
<section>
<article>
<h2>My First Article</h2>

<p>
This is my article.
</p>
</article>
</section>
</main>
Tree:
main
└── section
└── article
├── h2
 └── p
Relationships:
main
↓
Ancestor of everything below

section
↓
Child of main
Ancestor of article

article
↓
Child of section
Parent of h2 and p
This vocabulary becomes very useful later.

30. Ancestor vs Descendant

If:
<main>
<section>
<article>
<p>Hello</p>
</article>
</section>
</main>
Then:
main
is an ancestor of:
section
article
p
And:
p
is a descendant of:
article
section
main
So:
Ancestor
↓
Higher in the tree

Descendant
↓
Lower in the tree
This terminology will become very important when we learn CSS
selectors.

31. Correct Nesting Rules

Correct:
<section>
<article>
<p>Hello</p>
</article>
</section>
The structure is:
<section>
<article>
<p>
</p>
</article>
</section>
Each element closes in the reverse order in which its containing
structure was opened.

32. Incorrect Nesting

Avoid:
<section>
<article>
<p>Hello
</section>
</p>
</article>
This is structurally confused.
Browsers have defined error-recovery rules for parsing
malformed HTML, so they may still produce some DOM rather
than simply crashing. But your source is still wrong, and the
resulting DOM may not be what you intended.
This creates one of the most important rules in HTML:
Do not rely on the browser's error recovery.
Write correctly nested HTML.
33. Whitespace
Consider:
<p>Hello</p>
<p>World</p>
and:
<p>
Hello
</p>

<p>
World
</p>
The source formatting is different, but the basic document
structure is the same.
Whitespace in HTML source can sometimes be treated as inter-
element whitespace and, depending on context, can affect text
nodes and rendering. So don't assume every space or newline is
always ignored—but also don't be afraid to format your HTML
neatly. The HTML syntax and DOM rules define how whitespace
is parsed and represented.
Our preferred formatting style will be:
<main>
<h1>My Website</h1>

<p>
Welcome to my website.
</p>
</main>
Readable code is easier to maintain.
34. Indentation
Indentation does not usually change the semantic meaning of
ordinary HTML structure, but it makes nesting visible to humans.
Compare:
<main><section><article><p>Hello</p></article></
section></main>
with:
<main>
<section>
<article>
<p>Hello</p>
</article>
</section>
</main>
Same basic structure.
Much easier to read:
Indentation
↓
Visual map of the tree
We'll consistently indent nested elements.

35. HTML Comments

HTML comments use:
<!-- This is a comment -->
The browser doesn't render the comment as page content.
Example:
<main>
 <!-- Main content begins here -->

<h1>My Website</h1>
</main>
Comments can help explain code.
But don't overuse them.
Bad:
<!-- This is an h1 -->
<h1>Hello</h1>
The code is already obvious.
Better:
<!-- Primary page content -->
<main>
...
</main>
Use comments when they add useful context.

36. Important Warning About Comments

Do not put secrets in HTML comments.
Bad:
<!--
Admin password: ...
API secret: ...
-->
HTML sent to a browser is visible to the user.
Even if something isn't displayed on the page, it may still be
accessible through:
View Source
DevTools
Downloaded HTML
Network responses
So HTML comments are not a secure place for confidential
information.

37. Case and HTML Names

HTML syntax is generally handled case-insensitively for ASCII
letters in many parsing contexts, but our course convention is to
use lowercase element names and lowercase attribute names.
Write:
<p>Hello</p>
not:
<P>Hello</P>
and:
<div class="card">
rather than inconsistent capitalization.
The HTML parser has defined rules for handling tag and attribute
names, but consistent lowercase style improves readability and
keeps your code aligned with common authoring conventions.

38. Whitespace in Attribute Names and Values

Correct:
<p class="message">
Not:
<p class = "message">
The second may still be parsed by HTML because the syntax
permits certain whitespace around =, but our normal style is:
attribute="value"
This is cleaner and easier to read.
The HTML syntax explicitly allows zero or more ASCII whitespace
characters around the = in quoted attribute forms.

39. Attribute Ordering

Consider:
<img
src="[Link]"
alt="Profile photograph"
width="300"
height="300"
>
The order of attributes usually does not change the element's
meaning.
You could write:
<img
height="300"
alt="Profile photograph"
width="300"
src="[Link]"
>
and the attributes still represent the same properties.
For readability, we will use a consistent order where practical:
id
class
important semantic/configuration attributes
src/href
alt
dimensions
data-* attributes
There is no universal mandatory ordering rule for all attributes.
Consistency is the key.

40. Attribute Names Are Not Arbitrary

You can't invent standard HTML attributes and expect browsers
to give them standard meaning.
For example:
<p magic="yes">
Hello
</p>
The browser may carry the attribute in the DOM, but magic is
not automatically a standard HTML feature.
For custom application data, use:
data-magic="yes"
The HTML standard explicitly provides data-* for custom non-
visible data.

41. Standard Attribute vs data-*

Compare:
<input required>
with:
<input data-required="yes">
The first has standard HTML semantics.
The browser understands:
required
↓
This field is subject to required-field validation
The second is simply custom data:
data-required
↓
Custom information for your application
They're fundamentally different.

42. Global Attributes

Some attributes can be used on many or all HTML elements.
Examples include:
id
class
lang
title
hidden
data-*
The HTML Standard defines a set of global attributes that may
be used across HTML elements, with specific semantics for each.
Let's look at a few important ones.

43. Global Attribute Cheat Table

Attribut
Basic purpose
e
id Unique identifier
class Grouping into classes
lang Language information
title Advisory information
hidden Indicates hidden
Attribut
Basic purpose
e
content/state
data-* Custom application data
Later you'll also encounter global attributes such as:
dir
style
tabindex
contenteditable
spellcheck
inert
translate
We won't dive deeply into every global attribute right now.

44. The style Attribute

You can technically write CSS directly inside HTML:
<p style="color: blue;">
Hello
</p>
This is called an inline style.
It works.
But during our normal projects, we will generally keep CSS in
external stylesheets:
<link rel="stylesheet" href="[Link]">
rather than filling HTML with inline styles.
Why?
Because separation keeps:
HTML
↓
Structure

CSS
↓
Presentation
clear and maintainable.
The HTML standard recognises style as a global attribute
containing CSS declarations, but whether and when to use it is a
design and maintenance decision.

45. HTML Entities — A Quick Introduction

Sometimes you need to represent special characters in HTML.
For example:
<p>5 &lt; 10</p>
This displays:
5 < 10
Here:
&lt;
represents:
<
Another example:
<p>Tom &amp; Jerry</p>
displays:
Tom & Jerry
This is known as a character reference.
You don't need to memorise many yet.
The important idea is:
Special character
↓
May need an appropriate HTML character reference
We'll return to this when we discuss text content and HTML
syntax more deeply.

46. Why < and > Matter

HTML uses:
<
>
to define markup.
So if you want to display literal markup-like text, you may need
character references.
For example:
<p>Use &lt;p&gt; for a paragraph.</p>
The browser displays:
Use <p> for a paragraph.
This is an important distinction:
<p>
could mean:
An actual paragraph element
while:
&lt;p&gt;
means:
The visible text "<p>"

47. Void Elements — Deeper Look

Let's revisit void elements.
Common current HTML void elements include:
<area>
<base>
<br>
<col>
<embed>
<hr>
<img>
<input>
<link>
<meta>
<source>
<track>
<wbr>
They don't have closing tags in HTML syntax.
Examples:
<br>
<hr>
<img src="[Link]" alt="A photo">
<input type="text">
Notice:
No </br>
No </hr>
No </img>
No </input>
48. Don't Confuse HTML With XML/XHTML Self-Closing Syntax
You may see:
<img src="[Link]" alt="Photo" />
This is common in some coding styles and XML-derived syntax.
For HTML, the trailing / is not what makes the element void.
This:
<img src="[Link]" alt="Photo">
is the normal HTML syntax.
And:
<img src="[Link]" alt="Photo" />
may also be parsed in HTML, but the / does not create a closing
tag or change the void nature of the element.
For our course, use:
<img src="[Link]" alt="Photo">
The HTML standard defines void elements by the HTML syntax;
the slash before > is not a substitute for an end tag.

49. Common Void Element Mistakes

Wrong:
<img src="[Link]"></img>
Wrong:
<input></input>
Wrong:
<br></br>
Use:
<img src="[Link]" alt="Photo">
<input type="text">
<br>
50. Boolean vs Normal Attributes
Compare:
<input type="text" value="Bro">
with:
<input type="text" required>
The first:
value
↓
Has a value
The second:
required
↓
Presence indicates the boolean state
So:
Normal attribute
↓
Often has a meaningful value

Boolean attribute
↓
Presence/absence represents state
The HTML specification makes this distinction explicitly.

51. A Real Example Combining Everything

Let's look at:
<input
id="email"
 class="form-control required-field"
type="email"
name="email"
placeholder="Enter your email"
required
autocomplete="email"
>
Let's identify everything.

Element

input

Global attribute: id

id="email"

Global attribute: class

class="form-control required-field"

Element-specific attribute: type

type="email"

Element-specific attribute: name

name="email"

Element-specific attribute: placeholder

placeholder="Enter your email"

Boolean attribute

required

Element-specific behaviour

autocomplete="email"
One element can therefore have several attributes, each with a
different job.

52. A Second Real Example

Look at:
<button
id="save-button"
class="button primary"
type="button"
data-action="save"
title="Save your work"
>
Save
</button>
Breakdown:
Element
↓
button

id
↓
save-button

class
↓
button primary

type
↓
button

data-*
↓
Custom application data

title
↓
Advisory information

Content
↓
Save
This one example brings together several concepts from today's
lesson.

53. HTML Is a Tree, Not Just a String

When you write:
<main>
<section>
<h1>Hello</h1>
</section>
</main>
don't think only:
Characters in a file
Think:
main
 │
section
│
h1
│
Hello
That tree becomes the foundation for:
CSS
DOM
JavaScript
Accessibility
This is one of the biggest mental shifts you'll make as a
beginner.
You're not just writing text.
You're constructing a document tree.

54. Browser Parsing

You might write:
<p>Hello
without the closing tag.
The browser may still render something.
Why?
Because HTML parsing has defined error-recovery rules.
The HTML parsing specification explicitly defines how browsers
parse documents, including documents containing parse errors.
But:
A browser successfully displaying your page does not
automatically mean your source is correct.
That's why we'll learn to write valid, semantic HTML instead of
depending on browser recovery.

55. "The Browser Fixed It" Is Not a Good Strategy

Imagine:
<p>
Hello
<div>
World
</div>
The browser may attempt to repair the document structure.
But you don't want to think:
"Cool, the browser fixed it."
Instead think:
"I wrote invalid or poorly structured HTML. I need to fix my
source."
Otherwise you may end up with:
Source HTML
≠
DOM you expected
And debugging becomes harder.

56. Your First Complete Syntax Diagram

Memorise this:
HTML ELEMENT
│
├── Opening Tag
│ └── <p>
│
├── Content
│ └── Hello
│
└── Closing Tag
└── </p>
With attributes:
ELEMENT
│
├── Opening Tag
│ │
│ ├── Element Name
│ │ └── a
│ │
│ ├── Attribute
│ │ ├── Name
│ │ │ └── href
│ │ └── Value
│ │ └── [Link]
│ │
│ └── >
│
├── Content
│ └── About
│
└── Closing Tag
└── </a>
This is the anatomy of:
<a href="[Link]">About</a>

57. Practical Lab 1 — Element Anatomy

Create:
<h1 id="page-title" class="main-heading">
My Website
</h1>
Identify:
Element name:
Opening tag:
Closing tag:
Content:
Attribute 1:
Attribute 1 value:
Attribute 2:
Attribute 2 value:
Expected:
Element name:
h1

Opening tag:
<h1 id="page-title" class="main-heading">

Closing tag:
</h1>
Content:
My Website

Attribute 1:
id

Attribute 1 value:
page-title

Attribute 2:
class

Attribute 2 value:
main-heading

58. Practical Lab 2 — Nesting

Create:
<main>
<section>
<h1>My Portfolio</h1>

<p>
Welcome to my website.
</p>
</section>
</main>
Draw the DOM tree:
?
├── ?
│ ├── ?
│ └── ?
Answer:
main
└── section
├── h1
└── p
Now identify:
Parent of section:
Parent of h1:
Sibling of h1:
Ancestor of p:
Answer:
Parent of section:
main

Parent of h1:
section

Sibling of h1:
p

Ancestor of p:
section and main
59. Practical Lab 3 — Boolean Attributes
Consider:
<input type="checkbox" checked>
Question:
Is checked true or false?
Answer:
True
Now:
<input type="checkbox">
Answer:
False
Now:
<input type="checkbox" checked="false">
Answer:
Still true
Why?
Because:
checked attribute exists
↓
Boolean attribute is true
Remember:
Boolean attributes are about presence and absence, not the text
"true" or "false".

60. Practical Lab 4 — id vs class

Given:
<p id="intro" class="text highlight">
Welcome!
</p>

<p class="text">
Another paragraph.
</p>
Answer:
Which element has the id "intro"?
The first paragraph.
Which elements have class "text"?
Both paragraphs.
Which element has class "highlight"?
Only the first paragraph.
Think:
id
↓
Specific identifier

class
↓
Shared grouping

61. Practical Lab 5 — Fix the HTML

Correct this:
<main>
<h1 id="title" id="main-title">My Website</h1>

<p class="text" class="important">

 Welcome.
</p>

<input disabled="false">

<img src="[Link]"></img>
</main>
There are several problems.
A better version is:
<main>
<h1 id="main-title">My Website</h1>

<p class="text important">

Welcome.
</p>

<input>

<img
src="[Link]"
alt="Description of the photo"
>
</main>

Problems we fixed

Problem 1

Duplicate id:
id="title" id="main-title"
An element should not have duplicate occurrences of the same
attribute name.

Problem 2

Duplicate class attributes:

class="text" class="important"
Use one class attribute with multiple space-separated class
names:
class="text important"

Problem 3

Boolean attribute:
disabled="false"
This is still present, so it represents the true state.
Remove it if you want the control enabled.

Problem 4

Void element:
<img></img>
img is a void element and doesn't use a closing tag.

Problem 5

Accessibility:
The meaningful image should have suitable alternative text with
alt.

62. Practical Lab 6 — Build a Profile Card

Create:
<article
id="profile-card"
class="card featured"
>
<h2>My Profile</h2>

<p>
I am learning HTML.
</p>

<button
type="button"
data-action="greet"
>
Say Hello
</button>
</article>
Identify:
Root element:
id:
Classes:
Child elements:
Boolean attributes:
data-* attribute:
Answer:
Root element:
article

id:
profile-card
Classes:
card
featured

Child elements:
h2
p
button

Boolean attributes:
None

data-* attribute:
data-action

63. Mini Project — HTML Syntax Playground

Create:
phase-1-html/
└── lesson-02/
└── [Link]
Use:
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta
name="viewport"
content="width=device-width, initial-scale=1"
>

<title>HTML Syntax Playground</title>

</head>

<body>
<main id="main-content" class="page">
<h1 id="page-title" class="heading">
HTML Syntax Playground
</h1>

<section class="lesson">
<h2>What I Am Learning</h2>

<p>
I am learning tags, elements, attributes,
nesting, and HTML syntax.
</p>

<button
id="test-button"
class="button primary"
type="button"
data-action="test"
 title="Run the test"
>
Test My HTML
</button>
</section>

<section class="lesson">
<h2>My Progress</h2>

<label>
<input
type="checkbox"
checked
>
I understand HTML elements.
</label>
</section>
</main>
</body>
</html>
Your goal is to inspect every part and identify:
Elements
Attributes
Attribute values
Parent-child relationships
Siblings
Global attributes
Boolean attributes
data-* attributes
Open the page in Chrome.
Then inspect it using DevTools.

64. DevTools Challenge

Open:
Ctrl + Shift + I
Go to:
Elements
Select:
<button id="test-button">
Then answer:
What is its tag name?

What is its id?

What classes does it have?

What is its type?

What data attribute does it have?

What is its text content?

Who is its parent?

What are its siblings?
This connects what you're learning directly to the DOM.

65. Lesson 1.2 Common Mistakes Cheat Sheet

❌ Duplicate id
<h1 id="one" id="two">

✅ One id
<h1 id="title">

---

❌ Multiple class attributes

<p class="one" class="two">

✅ Multiple classes in one attribute

<p class="one two">

---

❌ Boolean "false"
<input disabled="false">

✅ Omit attribute for false

<input>

---
❌ Closing a void element
<img></img>

✅ Void element
<img src="[Link]" alt="Photo">

---

❌ Incorrect nesting
<p><strong>Hello</p></strong>

✅ Correct nesting
<p><strong>Hello</strong></p>

---

❌ Fake custom semantics

<div data-type="button">Save</div>

✅ Use the real element

<button>Save</button>

66. Lesson 1.2 Master Cheat Sheet

HTML Syntax

<element>
Content
</element>

Element with attribute

<element attribute="value">

Multiple attributes

<element
attribute1="value1"
attribute2="value2"
>

ID

id="unique-name"

Class

class="group-name"

Multiple classes

class="group-one group-two"

Language

lang="en"

Custom data

data-name="value"

Boolean attribute

disabled
Present:
true
Absent:
false
Comment

<!-- Comment -->

Current directory reference

./

Parent directory

../

67. Lesson 1.2 Flashcards

Card 1

Q: What is the difference between a tag and an element?

A: A tag is markup such as <p> or </p>; an element is the
complete structure such as <p>Hello</p>.

Card 2

Q: What is an opening tag?

A: The starting markup that identifies the element.

Card 3

Q: What is a closing tag?

A: The ending markup, usually containing /, that closes a normal
element.

Card 4

Q: What is an attribute?
A: Additional information or configuration associated with an
element.

Card 5

Q: Where are attributes written?

A: Inside an element's start tag.
Card 6

Q: What is the usual attribute syntax?

A: attribute="value".

Card 7

Q: What is a boolean attribute?

A: An attribute whose presence represents true and absence
represents false.

Card 8

Q: What does disabled="false" mean for a boolean disabled

attribute?
A: The attribute is present, so it still represents true.

Card 9

Q: What is id used for?

A: Identifying a particular element; the value should be unique
within its tree.

Card 10

Q: What is class used for?

A: Grouping elements into one or more classes.

Card 11

Q: Can one element have multiple classes?

A: Yes, using space-separated class names.

Card 12

Q: What does lang describe?

A: The primary language of an element's content and relevant
text attributes.

Card 13
Q: What are data-* attributes?
A: A standard mechanism for storing custom application data on
elements.

Card 14

Q: What is a void element?

A: An element that has no end tag in HTML syntax.

Card 15

Q: Name five void elements.

A: Examples include img, input, br, meta, and link.

Card 16

Q: What does <!-- --> create?

A: An HTML comment.

Card 17

Q: What is a parent element?

A: An element that directly contains another element.

Card 18

Q: What is a child element?

A: An element directly contained by another element.

Card 19

Q: What are sibling elements?

A: Elements that share the same parent.

Card 20

Q: What is an ancestor?
A: An element higher in the tree that contains another element
somewhere below it.

Card 21
Q: What is a descendant?
A: An element somewhere inside another element's subtree.

Card 22

Q: Why should HTML be correctly nested?

A: To create the intended document structure and avoid relying
on browser error recovery.

Card 23

Q: What happens if HTML has parsing errors?

A: Browsers use defined parsing and error-recovery rules, but
the resulting DOM may not match what the author intended.

Card 24

Q: What is the difference between id and class?

A: id identifies a specific element; class groups elements.

Card 25

Q: What is the main idea of data-*?

A: Store custom application data without inventing nonstandard
HTML semantics.

68. Lesson 1.2 Test

Try this without looking back.

Part A — Multiple Choice

1. Which is the complete HTML element?

A.
<p>
B.
</p>
C.
<p>Hello</p>
D.
Hello

2. Which part is the attribute?

<a href="[Link]">About</a>
A. a
B. href
C. [Link]
D. About

3. What does ../ mean in a relative path?

A. Current file
B. Parent directory
C. Site root
D. Internet

4. What does the presence of a boolean attribute

generally represent?

A. False
B. True
C. Error
D. Empty string only

5. Which is a void element?

A. <p>
B. <section>
C. <img>
D. <article>
6. Which is the correct way to assign multiple classes?

A.
<p class="one" class="two">
B.
<p class="one two">
C.
<p classes="one two">
D.
<p class="one, two">

7. Which is generally intended to identify a specific

element?

A. class
B. id
C. data-*
D. style

8. Which attribute is designed for custom application

data?

A. magic
B. custom
C. data-*
D. app-*

9. Which is correct?

A.
<p><strong>Hello</p></strong>
B.
<p><strong>Hello</strong></p>
C.
<p><strong>Hello</p></strong></p>
D.
<p></strong>Hello</p>

10. What is a sibling element?

A. An element with no parent

B. An element inside every other element
C. An element that shares the same parent as another element
D. The root element

Part B — True or False

11.

<input disabled="false">
represents a false disabled state.

12.

An element can have one id and multiple classes.

13.

HTML comments are visible as normal page content.

14.

<img> requires a closing </img> tag.

15.

Browsers have defined rules for parsing malformed HTML.

16.
You should rely on browser error recovery instead of writing
valid HTML.

17.

data-* attributes provide custom application data.

18.

The id value should normally be unique within its document tree.

19.

Two elements can share the same class.

20.

Correct nesting means inner elements close before their

containing outer elements.

Part C — Identify Everything

Analyze:
<button
id="save-button"
class="button primary"
type="button"
data-action="save"
title="Save your work"
>
Save
</button>
Identify:
21. Element name
22. Number of attributes
23. ID
24. Classes
25. Type value
26. data-* attribute
27. title value
28. Text content
29. Parent element — is one shown in this snippet?
30. Is this a void element?

Part D — Fix the HTML

Correct this code:

<main>
<h1 id="title" id="main-title">
My Portfolio
</h1>

<p class="intro" class="highlight">

Welcome to my website.
</p>

<input
type="checkbox"
checked="false"
>

<img src="[Link]"></img>
</main>
Find at least four problems and correct them.

Part E — DOM Tree Challenge

Given:
<main id="page">
<section class="about">
<h1>About Me</h1>

<p>I am learning HTML.</p>

<p>I enjoy building websites.</p>

</section>
</main>
Answer:
31. What is the root element shown?
32. What is the parent of section?
33. What is the parent of h1?
34. What are the siblings of h1?
35. What are the siblings of the two p elements?
36. Is main an ancestor of p?
37. Is section a descendant of main?
38. How many direct children does section have?
39. What is the id of main?
40. What is the class of section?

69. Practical Challenge

Build this structure from scratch:
My Learning Profile
│
├── About Me
│ ├── Name paragraph
│ └── Goal paragraph
│
├── Learning Status
│ ├── HTML checkbox
│ ├── CSS checkbox
│ └── JavaScript checkbox
│
└── Actions
└── Save button
Your HTML must demonstrate:
✅ id
✅ class
✅ multiple classes
✅ data-* attribute
✅ boolean attribute
✅ nesting
✅ parent-child relationships
✅ correct indentation
✅ comments
✅ a void element
A possible structure:
<main
id="profile"
class="profile-page learner"
>
<!-- About section -->

<section class="section about">

<h1>My Learning Profile</h1>

<p>
My name is Bro.
</p>

<p>
My goal is to become a web developer.
</p>
</section>

<!-- Learning status -->

<section class="section progress">

<h2>Learning Status</h2>

<label>
<input
type="checkbox"
checked
>
HTML
 </label>

<label>
<input
type="checkbox"
>
CSS
</label>

<label>
<input
type="checkbox"
>
JavaScript
</label>
</section>

<!-- Actions -->

<section class="section actions">

<h2>Actions</h2>

<button
class="button primary"
type="button"
data-action="save"
>
 Save
</button>
</section>
</main>
The exact text can be your own.
Your task is to understand why every piece is where it is.

70. Lesson 1.2 — Key Takeaways

You should now think of HTML like this:
HTML
│
├── Elements
│ ├── Opening tag
│ ├── Content
│ └── Closing tag
│
├── Attributes
│ ├── id
│ ├── class
│ ├── lang
│ ├── title
│ ├── data-*
│ └── Boolean attributes
│
├── Nesting
│ ├── Parent
│ ├── Child
│ ├── Sibling
│ ├── Ancestor
│ └── Descendant
│
└── Special syntax
├── Void elements
├── Comments
└── Character references
The five big ideas I want locked into your brain are:
1. Element ≠ tag

2. Attributes belong in the start tag

3. id identifies; class groups

4. Boolean attributes work by presence/absence

5. HTML is a tree, so nesting matters

The HTML Living Standard is the source of truth for these syntax
and semantic rules: it defines element/attribute meanings,
global attributes, boolean-attribute behavior, parsing rules, and
the distinction between ordinary and void elements.

Phase 1 Progress
PHASE 1 — HTML

1.1 ✅ Introduction to HTML

1.2 ✅ Tags, Elements, Attributes, Nesting & Void Elements
1.3 ⬜ HTML Document Structure
1.4 ⬜ Headings & Paragraphs
1.5 ⬜ Text-Level Semantics
1.6 ⬜ Links & Navigation
1.7 ⬜ Images
1.8 ⬜ Lists
1.9 ⬜ div & span
1.10 ⬜ Semantic HTML
1.11 ⬜ Tables
1.12 ⬜ Forms
1.13 ⬜ Input Types
1.14 ⬜ Form Accessibility & Validation
1.15 ⬜ Advanced Form Controls
1.16 ⬜ Multimedia
1.17 ⬜ Metadata
1.18 ⬜ Accessibility & Best Practices
1.19 ⬜ Revision & Assessment
1.20 ⬜ Final HTML Project
---------------------------------X----------------------------------------------