Web Interfaces: HTML, CSS, and JavaScript
EE 547 - Unit 7
Web Pages Combine Three Technologies With Distinct Roles
HTML Markup Language
Tags describe document structure
<h1> tag marks heading Browser renders “Alice Chen” as large, bold text </h1> closes the heading tag
<p> tag marks paragraph Browser renders as normal text with spacing </p> closes the paragraph
<a> tag creates link href attribute specifies destination URL Browser renders “View Orders” as clickable text Click navigates to /orders
Nesting creates hierarchy:
<section> contains heading and paragraph Indentation shows structure (not required, aids readability) Browser understands parent-child relationships
Attributes configure elements:
class attribute names element for styling Multiple elements can share same class Browser applies CSS rules matching class names
HTML Evolved From Document Exchange to Application Platform
HTML evolution 1995-2025:
Structure (1995-1997)
- Tables for data (not layout)
- Forms for basic interaction
- Images and links
Separation (1997-2000)
- CSS replaces style attributes
<font>deprecated- Semantic markup emphasized
Failed strictness (2000)
- XHTML required perfect syntax
- One error = blank page
- Developers rejected complexity
Pragmatic evolution (2008-2014)
HTML5 accepts messy reality
Error recovery built-in
New elements for applications:
<canvas>for graphics<video>/<audio>native<section>,<article>semantics
Living standard (2014+)
- No more version numbers
- Continuous small updates
- Focus on web applications
- Web Components for reusability
Backward compatibility:
- 1995 HTML still renders
- Progressive enhancement works
- 30-year-old sites still function
Document Object Model - Tree Structure
Browser parses HTML into tree of nodes
HTML text:
<div id="profile">
<h1>Alice Chen</h1>
<p>Email: alice@example.com</p>
<section>
<h2>Activity</h2>
<p>Orders: 47</p>
</section>
</div>Browser builds DOM tree:
div (id="profile")
├── h1
│ └── "Alice Chen"
├── p
│ └── "Email: alice@example.com"
└── section
├── h2
│ └── "Activity"
└── p
└── "Orders: 47"Each tag becomes node in tree Text becomes leaf nodes Parent-child relationships preserved from nesting
DOM allows programmatic access:
JavaScript can traverse and modify tree:
// Get element by ID
let profile = document.getElementById('profile');
// Get child elements
let heading = profile.querySelector('h1');
// Modify content
heading.textContent = 'Alice C. Chen';
// Add new element
let newPara = document.createElement('p');
newPara.textContent = 'Phone: 555-0123';
profile.appendChild(newPara);Changes to DOM immediately reflected in display.
Tree structure enables:
Navigation between elements:
- Parent node contains children
- Children reference parent
- Siblings at same level
Styling rules:
- CSS matches elements by tag, class, or ID
- Cascade applies from parent to children
- Inheritance passes properties down tree
JavaScript manipulation:
- Traverse tree to find elements
- Add or remove nodes
- Modify attributes and content
- Attach event handlers to nodes
Browser maintains this tree in memory while page displayed.
CSS Applies Presentation
Stylesheet defines visual properties
HTML without styling:
Browser applies default styles:
<h1>renders 32px, bold, Times New Roman<p>renders 16px, normal weight, Times New Roman- Black text on white background
CSS overrides defaults:
h1 {
font-size: 48px;
color: #2c3e50;
font-family: Arial, sans-serif;
margin-bottom: 20px;
}
p {
font-size: 18px;
color: #34495e;
line-height: 1.6;
}Browser applies these rules to matching elements.
Class selectors target specific elements:
.stat-card {
background-color: #f8f9fa;
border-radius: 8px;
padding: 20px;
}
.number {
font-size: 36px;
font-weight: bold;
color: #3498db;
}
.label {
font-size: 14px;
color: #7f8c8d;
}Elements with matching class names receive these styles.
CSS separates content from presentation:
Same HTML:
Different stylesheets produce different appearance:
- Desktop: Large heading, serif font
- Mobile: Smaller heading, sans-serif
- Print: Black text, minimal styling
- Dark mode: Light text on dark background
Content unchanged - only presentation differs.
Cascade and inheritance:
Paragraph inherits font from body Element with class="special" overrides color
Rules cascade from general to specific.
Client-Side Rendering
Browser transforms HTML into pixels on user’s machine
Server sends HTML text:
Browser operations (client-side):
Parse HTML into DOM tree Apply CSS to calculate styles Compute layout (positions and sizes) Paint pixels to screen
All rendering happens on user’s computer, not server.
Server responsibility:
@app.route('/profile/<int:user_id>')
def show_profile(user_id):
user = db.query("SELECT * FROM users WHERE id = ?", user_id)
html = f"""
<h1>Welcome, {user.name}</h1>
<p>Total Orders: {user.order_count}</p>
"""
return htmlServer queries database and generates HTML text (7ms) Server sends HTML to client Server done - rendering is client’s responsibility
Client responsibility:
Browser receives HTML text Parses into DOM Applies styles Calculates layout for screen size Renders pixels
Total client rendering time: 80ms on user’s CPU
Server handles 1000 users: 7 seconds total CPU Clients handle 1000 renderings: Distributed across 1000 machines
Rendering distribution:
1000 concurrent users viewing profiles
Server work:
- 1000 HTML generations
- 7ms each
- Total: 7 seconds of server CPU
Client work:
- 1000 renderings
- 80ms each
- Happens on 1000 different CPUs simultaneously
- No server load
Each user’s browser uses their own CPU for rendering.
Server only generates markup - does not render pixels.
Same Protocol - Different Content Types
HTTP serves both documents and data
API request for data:
GET /users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGci...Server returns structured data:
Service consumes data programmatically.
Browser request for document:
Server returns marked-up document:
<h1>Alice Chen</h1>
<p>Email: alice@example.com</p>
<p>Total Orders: 47</p>
<p>Total Spent: $2,847.50</p>Browser renders document visually.
Both use HTTP - Content-Type header determines interpretation.
Flask serving both:
@app.route('/users/<int:user_id>')
def get_user(user_id):
user = db.query(
"SELECT * FROM users WHERE id = ?",
user_id
)
accept = request.headers.get('Accept', '')
if 'application/json' in accept:
return {
'user_id': user.id,
'email': user.email,
'order_count': user.orders
}
else:
return render_template(
'profile.html',
user=user
)Same database query Different response format based on Accept header
APIs and browsers share HTTP infrastructure - serve different purposes.
Execution Boundary - Server vs Client
Code runs in two separate environments
Server-side (before response sent):
@app.route('/dashboard')
def dashboard():
# Runs on server
user_id = session.get('user_id')
# Server accesses database
user = db.query(
"SELECT * FROM users WHERE id = ?",
user_id
)
orders = db.query(
"SELECT * FROM orders WHERE user_id = ?",
user_id
)
# Server has secrets
stripe_key = os.environ['STRIPE_SECRET_KEY']
# Generate HTML
html = render_template(
'dashboard.html',
user=user,
orders=orders
)
return html
# Server execution endsBrowser receives:
Client-side (after HTML received):
<script>
// Runs in browser
document.getElementById('refresh')
.addEventListener('click', function() {
// Browser makes HTTP request
fetch('/api/orders')
.then(r => r.json())
.then(data => {
// Update page
updateOrderList(data);
});
});
</script>JavaScript executes in browser - different environment than server Python.
Server environment:
Accesses database directly Reads files from disk Has environment variables with secrets Calls other backend services Stores session data
Client environment:
Modifies DOM elements Responds to user events (clicks, typing) Stores data in browser (localStorage, cookies) Cannot access database Cannot read server files Cannot access API keys
Communication only through HTTP requests.
Security Boundary
Client code and data visible to user
HTML and JavaScript sent to browser:
<script>
function submitOrder() {
let price = document.getElementById('price').value;
// Client-side validation
if (price < 100) {
alert('Minimum order $100');
return;
}
// Submit to server
fetch('/api/orders', {
method: 'POST',
body: JSON.stringify({price: price})
});
}
</script>User opens DevTools console and bypasses validation:
// Modify price directly
document.getElementById('price').value = 0.01;
// Call submit function
submitOrder();
// Or make request directly
fetch('/api/orders', {
method: 'POST',
body: JSON.stringify({price: 0.01})
});Order submitted at $0.01 because client validation bypassed.
Server must enforce rules:
@app.route('/api/orders', methods=['POST'])
def create_order():
price = request.json['price']
# Server validation required
if price < 100:
return {'error': 'Minimum order $100'}, 400
order = db.insert('orders', price=price)
return {'order_id': order.id}, 201Server validation cannot be bypassed - code not visible to user.
User can view all client-side code:
Browser View Source shows HTML and JavaScript DevTools shows network requests Console allows code execution Elements tab shows DOM structure
User cannot view server code:
Python code stays on server Database queries never sent to client Environment variables inaccessible Business logic hidden
Client-side validation improves user experience:
- Immediate feedback on errors
- Reduces unnecessary requests
- Guides user input
Server-side validation enforces security:
- Cannot be bypassed
- Protects data integrity
- Required for all operations
Both serve different purposes - client for usability, server for security.
Network Crossing Cost
Each HTTP request crosses network boundary
Local function call (same process):
def calculate_total(items):
return sum(item.price for item in items)
total = calculate_total(cart_items)
# Execution: 0.00001msFunction executes in process memory.
HTTP request to server:
fetch('/api/cart/total')
.then(response => response.json())
.then(data => displayTotal(data.total));Request components:
- DNS lookup: 20-120ms (if not cached)
- TCP connection: 50-100ms
- TLS handshake: 50-100ms (HTTPS)
- Server processing: 10-50ms
- Network transfer: 1ms each direction
Total: 150-400ms depending on distance and caching
Geographic distance:
- Same datacenter: 1-5ms round-trip
- Same city: 10-20ms
- Same continent: 50-100ms
- Cross-continent: 150-250ms
- Transoceanic: 250-400ms
Round-trip time accumulates with each request.
Network crossing unavoidable:
Physical distance limits speed of light in fiber Signal must travel to server and back Cannot eliminate latency
Design implications:
Minimize number of requests Combine related data in single response Cache responses when appropriate Use connection reuse (HTTP/2)
Single request returning combined data:
@app.route('/api/checkout-data')
def checkout_data():
return {
'user': get_user(),
'cart': get_cart(),
'shipping': get_shipping(),
'tax': calculate_tax()
}One request with all data vs four separate requests.
Multiple Requests
Sequential requests accumulate latency
Checkout page loading data sequentially:
// Get user first
fetch('/api/user')
.then(r => r.json())
.then(user => {
displayUser(user);
// Then get cart (waits for user)
return fetch('/api/cart');
})
.then(r => r.json())
.then(cart => {
displayCart(cart);
// Then shipping (waits for cart)
return fetch('/api/shipping');
})
.then(r => r.json())
.then(shipping => {
displayShipping(shipping);
});Each request waits for previous to complete:
- Request 1: 150ms
- Request 2 starts, completes: 150ms
- Request 3 starts, completes: 150ms
Total: 450ms (3 × 150ms)
Parallel requests start simultaneously:
Promise.all([
fetch('/api/user').then(r => r.json()),
fetch('/api/cart').then(r => r.json()),
fetch('/api/shipping').then(r => r.json())
])
.then(([user, cart, shipping]) => {
displayUser(user);
displayCart(cart);
displayShipping(shipping);
});All three requests start at time 0:
- All complete at 150ms
Total: 150ms
Parallel requests when data independent.
Dependencies require sequencing:
Some requests depend on previous responses:
// Must be sequential
fetch('/api/user')
.then(r => r.json())
.then(user => {
// Need user.id for cart
return fetch(`/api/cart?user_id=${user.id}`);
});Second request needs data from first.
Server-side combination:
Instead of client making multiple requests:
// Single request
fetch('/api/checkout-data')
.then(r => r.json())
.then(data => {
displayUser(data.user);
displayCart(data.cart);
displayShipping(data.shipping);
});Server endpoint combines data:
@app.route('/api/checkout-data')
def checkout_data():
user = get_user()
cart = get_cart(user.id)
shipping = get_shipping(user.zip)
return {
'user': user,
'cart': cart,
'shipping': shipping
}One client request Server makes internal queries (no network latency) Returns combined response
HTML Document Anatomy
Tags, Elements, and Attributes
Multiple attributes example:
<a href="https://example.com"
target="_blank"
title="Visit our site"
class="external-link">
Click here
</a>Each attribute:
- Has a name and value
- Separated by spaces
- Order doesn’t matter
- Values in quotes (single or double)
Common global attributes:
id="unique-name"
- Must be unique on page
- Used for JavaScript/CSS targeting
- Fragment navigation (#section)
class="style-name"
- Can be reused
- Multiple classes allowed
- CSS styling hook
data-*="custom"
- Store custom data
- JavaScript access
- No visual effect
Boolean attributes:
Presence = true, absence = false
Block vs Inline - Different Layout Behaviors
Default display behavior:
<!-- Block elements -->
<h1>Title</h1>
<p>First paragraph.</p>
<p>Second paragraph.</p>
<!-- Renders as: -->
Title
First paragraph.
Second paragraph.Each block starts a new line.
<!-- Inline elements -->
<p>
Text with <strong>bold</strong>
and <a href="#">link</a> inside.
</p>
<!-- Renders as: -->
Text with bold and link inside.Inline elements flow with text.
Layout implications:
Block elements:
- Cannot place side-by-side without CSS
- Height determined by content
- Width fills parent container
- Create document structure
Inline elements:
- Cannot set width/height (except img, input)
- Padding/margin behaves differently
- Cannot contain block elements
- Flow within text content
Invalid nesting:
Character Encoding Matters
Complete declaration:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>International Site</title>
</head>
<body>
<h1>Café München</h1>
<p>Price: 50€</p>
<p>北京 • москва • القاهرة</p>
<p>Emoji: 🎉 🚀 ❤️</p>
</body>
</html>UTF-8 Coverage:
- ASCII: 1 byte (a, b, c)
- Latin: 2 bytes (é, ñ, ü)
- Asian: 3 bytes (中, 日, 한)
- Emoji: 4 bytes (😀, 🎯)
Server should also send:
Meta tag provides fallback when:
- Server header missing
- File opened locally
- Saved for offline viewing
Without charset declaration, browsers guess encoding based on:
- User’s system locale
- Content patterns
- Often wrong for international content
Character Encoding - Why It Matters
Characters require encoding to bytes
Same character “é” (U+00E1):
UTF-8: C3 A9 (2 bytes)
UTF-16: 00 E1 (2 bytes)
ISO-8859-1: E1 (1 byte)Code point (what) ≠ byte representation (how)
UTF-8 dominates (97% of web):
Variable length: 1-4 bytes per character
1 byte: ASCII (0-127)
a → 612 bytes: Latin, Greek, Cyrillic (128-2047)
é → C3 A93 bytes: CJK, most common scripts (2048-65535)
中 → E4 B8 AD4 bytes: Emoji, rare scripts (65536+)
😀 → F0 9F 98 80
Continuation bytes start with 10 (self-synchronizing)
Backward compatible with ASCII
HTML declaration required:
Wrong encoding = mojibake:
File saved UTF-8, browser reads Latin-1:
"Café" → "Café"File saved Latin-1, browser reads UTF-8:
Shows: �Common failure points:
Database connections, form submissions, file storage—all must use matching encoding.
Common mojibake patterns:
| Original | Wrong Display | Cause |
|---|---|---|
| Café | Café | UTF-8 as Latin-1 |
| “smart” | “smart†| Windows-1252 as UTF-8 |
| 北京 | ?????? | Lost in conversion |
Always declare encoding explicitly:
- HTTP Content-Type header
<meta charset="UTF-8">in first 1024 bytes- Database connection encoding
- Form accept-charset attribute
HTML Character Entities
HTML uses <, >, & as syntax
To display these in content, use entities.
Reserved characters:
| Character | Entity | Purpose |
|---|---|---|
& |
& |
Entity/reference start |
< |
< |
Tag start |
> |
> |
Tag end |
" |
" |
Attribute delimiter |
Common symbols:
| Symbol | Entity | Name |
|---|---|---|
| © | © |
Copyright |
| € | € |
Euro |
| — | — |
Em dash |
| (space) | |
Non-breaking space |
Numeric references (any Unicode):
Both render: á
Non-breaking space:
prevents line break between words.
Keeps “Price:” and “$50” together.
Code examples need entities:
Without entities, <script> would execute as JavaScript.
Use entities when:
- Displaying code examples in HTML
- Showing reserved characters
- Ensuring characters don’t break parsing
- Preventing line breaks (
)
HTML5 Semantic Elements - Structure with Meaning
Semantic elements (HTML5):
Each tag describes its content purpose:
<header> - Introductory content <nav> - Navigation links <main> - Primary page content <article> - Self-contained content <section> - Thematic grouping <aside> - Tangential content <footer> - Footer information <figure> - Illustration with caption <figcaption> - Caption for figure <details> - Collapsible content <summary> - Details heading <mark> - Highlighted text <time> - Date/time data <address> - Contact information
Before HTML5 (div soup):
<div class="header">
<div class="nav">...</div>
</div>
<div class="content">
<div class="article">...</div>
<div class="sidebar">...</div>
</div>
<div class="footer">...</div>With HTML5 semantics:
<header>
<nav>...</nav>
</header>
<main>
<article>...</article>
<aside>...</aside>
</main>
<footer>...</footer>Benefits:
- Search engines understand structure
- Screen readers navigate better
- Code self-documents purpose
- CSS targeting more meaningful
- HTML validators check nesting rules
Semantic = meaning, not style
DOM Tree Structure
Nesting creates hierarchy:
<article>
<header>
<h2>Article Title</h2>
<time>Jan 15, 2025</time>
</header>
<section>
<p>First paragraph...</p>
<p>Second paragraph...</p>
</section>
<footer>
<a href="/share">Share</a>
</footer>
</article>Tree relationships:
- Parent: article contains all
- Children: header, section, footer
- Siblings: paragraphs at same level
- Descendants: All nested elements
JavaScript access:
// Get element
let article =
document.querySelector('article');
// Navigate tree
let title =
article.querySelector('h2');
// Modify content
title.textContent = 'New Title';
// Add element
let newPara =
document.createElement('p');
article.appendChild(newPara);Browser maintains tree in memory. Changes immediately update display.
Text Hierarchy with Headings
Semantic importance, not size:
<h1>Research Paper</h1>
<p>Introduction text...</p>
<h2>Methodology</h2>
<p>We conducted...</p>
<h3>Data Collection</h3>
<p>Samples were...</p>
<h3>Analysis Method</h3>
<p>Statistical...</p>
<h2>Results</h2>
<p>Our findings...</p>Screen reader navigation:
User hears: “Heading level 1: Research Paper” “Heading level 2: Methodology” “Heading level 3: Data Collection”
Can jump between headings with keyboard.
SEO impact:
Search engines:
- h1 = primary topic
- h2 = major sections
- h3-h6 = supporting structure
Weight content by heading level.
Common mistakes:
<!-- WRONG: Using for size -->
<h1>Welcome</h1>
<h3>Subtitle text</h3>
<!-- RIGHT: Proper hierarchy -->
<h1>Welcome</h1>
<h2>Subtitle text</h2>CSS controls size, HTML provides structure.
Links and Navigation
Relative path resolution:
Current page: https://example.com/blog/posts/article.html
contact.html→/blog/posts/contact.html/contact.html→/contact.html../index.html→/blog/index.html../../home.html→/home.html
Images with Purpose
Alt text purposes:
Accessibility
- Screen readers speak alt text
- Describes image for blind users
Failed loads
- Shown when image doesn’t load
- Network issues or 404 errors
SEO value
- Search engines index alt text
- Helps image search ranking
Responsive images:
<img src="photo.jpg"
srcset="photo-400.jpg 400w,
photo-800.jpg 800w,
photo-1200.jpg 1200w"
sizes="(max-width: 600px) 100vw,
(max-width: 1000px) 50vw,
800px"
alt="Product photo">Browser chooses appropriate size:
- Mobile: 400px version
- Tablet: 800px version
- Desktop: 1200px version
Common formats:
- JPEG: Photos, gradients
- PNG: Logos, transparency
- WebP: Modern, smaller files
- SVG: Scalable graphics
Container Elements - Structure Without Semantics
IFrames - Embedding Pages and Security Boundaries
IFrame embeds another HTML page:
Browser makes HTTP request to src URL and renders the result inside a rectangle on the current page.
Common uses: Maps, videos (YouTube), payment forms (Stripe), third-party widgets
Security: Same-origin policy
Origin = protocol + domain + port
Different origins cannot access each other:
Parent (example.com):
<iframe id="map" src="https://maps.google.com/embed">
</iframe>
<script>
// BLOCKED - different origin
iframe.contentDocument.getElementById('map');
// SecurityError: Blocked
</script>IFrame (maps.google.com):
Same origin can access:
Parent (example.com):
<iframe src="/widget.html"></iframe>
<script>
// ALLOWED - same origin
iframe.contentDocument.getElementById('btn');
</script>Origin comparison:
https://example.com:443≠http://example.com:80(protocol)https://example.com≠https://www.example.com(domain)https://example.com≠https://example.com:8080(port)
PostMessage enables controlled cross-origin communication
Parent sends message:
iframe.contentWindow.postMessage(
{action: 'resize', height: 400},
'https://widget.com' // Target origin
);IFrame receives:
window.addEventListener('message', (event) => {
// MUST verify sender origin
if (event.origin !== 'https://parent.com') {
return; // Ignore untrusted messages
}
if (event.data.action === 'resize') {
// Handle message
}
});Always verify event.origin before processing messages.
IFrame Sandbox - Restricting Capabilities
Sandbox attribute restricts iframe capabilities
No sandbox (default - full permissions):
Default IFrame permissions:
- Execute JavaScript
- Submit forms
- Open popups
- Navigate parent
- Access parent (if same origin)
Full sandbox (maximum restriction):
Sandboxed IFrame restrictions:
- No JavaScript execution
- No form submission
- No popups
- No parent navigation
- Treated as unique origin (even if same domain)
Selective permissions:
Enables only JavaScript and form submission.
Real-world examples:
Payment form (needs scripts, forms, origin):
<iframe src="https://stripe.com/checkout"
sandbox="allow-scripts
allow-forms
allow-same-origin">
</iframe>Third-party widget (scripts only, isolated):
User-generated content (display only):
Multiple permissions:
Space-separated list enables selected capabilities.
Form Submission Flow
Form Data Encoding
Why Client Validation Isn’t Enough
Server must validate everything:
@app.route('/register', methods=['POST'])
def register():
email = request.form['email']
age = request.form['age']
# Server validation (required!)
if not '@' in email:
return "Invalid email", 400
if int(age) < 13 or int(age) > 120:
return "Invalid age", 400
# Only now safe to process
create_user(email, age)Why Separation Matters
CSS Rule Structure
CSS connects to HTML through selectors:
HTML elements:
CSS rules:
Browser matches:
- Finds all
<h1>elements - Applies h1 rule properties
- Finds all
<p>elements - Applies p rule properties
Both paragraphs get same styling - selector matches element type.
Comments for documentation:
/* comment */ ignored by browser.
Element Selectors Match Tag Names
Element selectors target HTML tags directly:
h1 {
color: blue;
font-size: 32px;
}
p {
color: gray;
line-height: 1.6;
}
a {
color: green;
text-decoration: none;
}HTML:
Result:
- h1 rule → ALL h1 elements turn blue
- p rule → BOTH paragraphs turn gray
- a rule → ALL links turn green
Universal selector targets everything:
Asterisk matches every single element on page.
Resets all default spacing - common in CSS reset stylesheets.
Class Selectors for Reusable Styles
Classes identified by period (.):
CSS:
.highlight {
background: yellow;
}
.important {
font-weight: bold;
color: red;
}
.hidden {
display: none;
}HTML:
<p class="highlight">
Highlighted paragraph
</p>
<span class="important">
Critical information
</span>
<div class="highlight important">
Both classes applied
</div>
<section class="hidden">
Not displayed
</section>Class advantages:
- Apply to any element type
- Reuse across multiple elements
- Combine multiple classes
- Semantic naming
Class naming conventions:
- Use descriptive names
- Lowercase with hyphens
.error-messagenot.red-text- Name by purpose, not appearance
ID Selectors for Unique Elements
IDs identified by hash (#):
CSS:
#header {
background: navy;
padding: 20px;
}
#sidebar {
width: 300px;
float: left;
}
#main-content {
margin-left: 320px;
}
#footer {
background: gray;
text-align: center;
}HTML:
<header id="header">
<h1>Site Title</h1>
</header>
<aside id="sidebar">
<nav>...</nav>
</aside>
<main id="main-content">
<p>Page content...</p>
</main>
<footer id="footer">
<p>Copyright 2025</p>
</footer>Each ID must be unique on the page - only one id="header" allowed.
When to use each:
Classes:
- Buttons, cards, alerts
- Any reusable component
- Multiple on same page
- Styling groups of elements
IDs:
- Page sections (header, footer)
- JavaScript hooks
- Fragment navigation (#section)
- Form label associations
Specificity matters:
ID wins over class due to higher specificity.
Descendant Selectors - Context Matters
Style based on location:
/* Paragraphs in articles */
article p {
font-size: 18px;
line-height: 1.8;
}
/* Paragraphs in asides */
aside p {
font-size: 14px;
color: #666;
}
/* Links in navigation */
nav a {
text-decoration: none;
padding: 10px;
}
/* Links in content */
article a {
color: blue;
text-decoration: underline;
}Nested descendants:
Matches links inside list items inside unordered lists inside nav inside header.
Can traverse any depth - not just direct children.
Direct child selector (>):
> restricts to immediate children only.
Combining Selectors
Combining for specificity:
Element and class:
Only <p class="intro">, not other .intro elements.
Multiple classes:
Must have BOTH classes.
<!-- Matched -->
<button class="button primary">
Yes
</button>
<!-- Not matched -->
<button class="button">
No (missing primary)
</button>
<!-- Not matched -->
<button class="primary">
No (missing button)
</button>Adjacent sibling (+):
First paragraph after any h1 gets larger font.
Used for styling lead paragraphs after headings.
Specificity - Which Rule Wins?
Specificity calculation:
p { } /* 0-0-1 = 1 */
.class { } /* 0-1-0 = 10 */
#id { } /* 1-0-0 = 100 */
p.class { } /* 0-1-1 = 11 */
#id p { } /* 1-0-1 = 101 */
#id .class p { } /* 1-1-1 = 111 */Format: ID-Class-Element
Higher specificity wins regardless of declaration order (unless !important used).
Override with !important (avoid):
Overrides everything except other !important rules.
Makes CSS hard to maintain - use sparingly.
Specificity Calculation - Point System
Specificity battle example:
/* Score: 0-0-1-1 = 11 */
div.content {
color: blue;
}
/* Score: 0-1-0-1 = 101 WINS */
div#main {
color: green;
}
/* Score: 0-0-2-3 = 23 */
body div.content.highlight {
color: red;
}Green wins despite being in middle.
Common misconceptions:
11 classes (110) beats 1 ID (100)? NO
ID still wins - categories don’t overflow.
Debugging specificity:
Browser DevTools shows:
- Crossed out = overridden
- Which rule is winning
- Computed final value
When specificity fails:
Red wins - !important changes rules.
Only another !important with higher specificity can override.
Box Model - Foundation of Layout
Every HTML element is a rectangular box with four areas:
Content - Text, images, or other content Padding - Space inside the border Border - Edge of the element Margin - Space outside to other elements
Colors and Values
Gradients:
/* Linear gradient */
.hero {
background: linear-gradient(
135deg,
#667eea 0%,
#764ba2 100%
);
}
/* Radial gradient */
.spotlight {
background: radial-gradient(
circle at center,
rgba(255,255,255,0.8),
transparent
);
}Shadows:
.card {
box-shadow:
0 4px 6px rgba(0,0,0,0.1),
0 1px 3px rgba(0,0,0,0.08);
}
.text-glow {
text-shadow:
0 0 20px rgba(52,152,219,0.5);
}Layered shadows create depth and hierarchy.
Display Property - Element Flow
Inline-block combines both:
Cards sit side-by-side but accept width/height/padding like blocks.
Positioning Elements
Responsive Design with Media Queries
/* Mobile first approach */
.container {
width: 100%;
padding: 10px;
}
.card {
width: 100%;
margin-bottom: 20px;
}
/* Tablet and up */
@media (min-width: 768px) {
.container {
max-width: 750px;
margin: 0 auto;
padding: 20px;
}
.card {
width: 48%;
display: inline-block;
}
}
/* Desktop */
@media (min-width: 1024px) {
.container {
max-width: 1200px;
padding: 40px;
}
.card {
width: 31%;
}
}
/* Print styles */
@media print {
.no-print {
display: none;
}
body {
font-size: 12pt;
color: black;
}
}
Breakpoints:
- Mobile: < 768px
- Tablet: 768-1024px
- Desktop: > 1024px
Mobile-first benefits:
- Faster mobile loading
- Progressive enhancement
- Better default experience
JavaScript is a Programming Language in the Browser
Full programming language features:
// Variables and data types
let userName = "Alice";
const maxAttempts = 3;
let attempts = 0;
let isLoggedIn = false;
// Functions
function validateEmail(email) {
const pattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
return pattern.test(email);
}
// Conditionals
if (attempts >= maxAttempts) {
console.log("Too many attempts");
lockAccount();
} else {
attempts++;
}
// Loops
const items = ["Home", "About", "Contact"];
for (let item of items) {
createNavLink(item);
}
// Objects and arrays
const user = {
name: "Alice",
email: "alice@example.com",
orders: [101, 102, 103]
};JavaScript has everything Python has:
- Variables, functions, objects
- Control flow (if/else, loops)
- Data structures (arrays, objects)
- Error handling (try/catch)
Different from server languages:
JavaScript CANNOT:
- Read/write local files
- Access database directly
- Run system commands
- Access other programs
JavaScript CAN:
- Modify web page (DOM)
- Make HTTP requests
- Store data in browser
- Respond to user events
DOM Manipulation - Changing the Page
JavaScript modifies HTML after loading:
Initial HTML:
<div id="message">Welcome</div>
<ul id="list">
<li>Item 1</li>
<li>Item 2</li>
</ul>
<button id="addBtn">Add Item</button>JavaScript manipulation:
// Get element by ID
const message = document.getElementById('message');
// Change text content
message.textContent = 'Hello, Alice!';
// Change styles
message.style.color = 'blue';
message.style.fontSize = '24px';
// Add CSS class
message.classList.add('highlight');
// Create new element
const newItem = document.createElement('li');
newItem.textContent = 'Item 3';
// Add to existing list
const list = document.getElementById('list');
list.appendChild(newItem);
// Remove element
const firstItem = list.firstElementChild;
firstItem.remove();
// Change HTML content
message.innerHTML = '<strong>Welcome</strong> back!';Page updates immediately without server request.
Common DOM methods:
// Finding elements
getElementById('id')
querySelector('.class')
querySelectorAll('p')
// Modifying elements
element.textContent = 'text'
element.innerHTML = '<b>html</b>'
element.style.property = 'value'
element.classList.add('class')
element.setAttribute('attr', 'val')
// Creating/removing
createElement('tag')
appendChild(element)
removeChild(element)
element.remove()Changes happen instantly in browser. No network request needed.
Event-Driven Programming
Code runs in response to user actions:
// Click event
const button = document.getElementById('submitBtn');
button.addEventListener('click', function(event) {
console.log('Button clicked!');
// Do something
});
// Form submission
const form = document.getElementById('loginForm');
form.addEventListener('submit', function(event) {
event.preventDefault(); // Stop page reload
const email = document.getElementById('email').value;
const password = document.getElementById('password').value;
if (validateLogin(email, password)) {
submitLogin(email, password);
} else {
showError('Invalid credentials');
}
});
// Input changes
const searchBox = document.getElementById('search');
searchBox.addEventListener('input', function(event) {
const query = event.target.value;
if (query.length > 2) {
fetchSearchResults(query);
}
});
// Mouse events
element.addEventListener('mouseover', highlight);
element.addEventListener('mouseout', unhighlight);
// Keyboard events
document.addEventListener('keydown', function(event) {
if (event.key === 'Escape') {
closeModal();
}
});
Asynchronous Operations - fetch()
Making HTTP requests from JavaScript:
// Simple GET request
fetch('/api/users')
.then(response => response.json())
.then(data => {
console.log(data);
updateUserList(data);
})
.catch(error => {
console.error('Error:', error);
});
// POST request with data
fetch('/api/users', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
},
body: JSON.stringify({
name: 'Alice',
email: 'alice@example.com'
})
})
.then(response => response.json())
.then(newUser => {
addUserToList(newUser);
});
// Modern async/await syntax
async function loadUserData() {
try {
const response = await fetch('/api/user/123');
const user = await response.json();
displayUser(user);
// Load related data
const ordersResponse = await fetch(`/api/orders?user=${user.id}`);
const orders = await ordersResponse.json();
displayOrders(orders);
} catch (error) {
showError('Failed to load data');
}
}
// Page stays responsive during fetch
loadUserData(); // Non-blocking
console.log('This runs immediately');
No page reload:
Traditional form submission:
- Submit form
- Page reloads completely
- New HTML from server
- User loses scroll position
With fetch():
- JavaScript sends request
- Page stays as is
- Response updates part of page
- User continues working
Asynchronous requests prevent UI blocking - user interaction continues during 200ms network round trip.
Browser APIs Available to JavaScript
Browser provides APIs beyond DOM manipulation for storage, networking, and media.
Dynamic Content Loading
Infinite scroll implementation:
let page = 1;
let loading = false;
// Detect scroll near bottom
window.addEventListener('scroll', function() {
const scrollHeight = document.documentElement.scrollHeight;
const scrollTop = document.documentElement.scrollTop;
const clientHeight = document.documentElement.clientHeight;
// Near bottom?
if (scrollTop + clientHeight >= scrollHeight - 100) {
loadMoreContent();
}
});
async function loadMoreContent() {
if (loading) return; // Already loading
loading = true;
showLoadingSpinner();
try {
const response = await fetch(`/api/items?page=${page}`);
const items = await response.json();
if (items.length > 0) {
appendItemsToList(items);
page++;
} else {
showEndOfContent();
}
} catch (error) {
showError('Failed to load more');
}
loading = false;
hideLoadingSpinner();
}Search suggestions:
const searchInput = document.getElementById('search');
let searchTimeout;
searchInput.addEventListener('input', function() {
clearTimeout(searchTimeout);
const query = this.value;
if (query.length < 2) {
hideSuggestions();
return;
}
// Debounce: Wait 300ms after typing stops
searchTimeout = setTimeout(() => {
fetchSuggestions(query);
}, 300);
});
async function fetchSuggestions(query) {
const response = await fetch(`/api/search?q=${query}`);
const suggestions = await response.json();
displaySuggestions(suggestions);
}Single Page Applications (SPAs)
SPA routing example:
// Simple client-side router
class Router {
constructor() {
this.routes = {};
window.addEventListener('popstate', () => this.handleRoute());
}
addRoute(path, handler) {
this.routes[path] = handler;
}
navigate(path) {
window.history.pushState({}, '', path);
this.handleRoute();
}
handleRoute() {
const path = window.location.pathname;
const handler = this.routes[path] || this.routes['/404'];
handler();
}
}
// Usage
const router = new Router();
router.addRoute('/', () => loadHomePage());
router.addRoute('/about', () => loadAboutPage());
router.addRoute('/contact', () => loadContactPage());
// Navigation without page reload
document.querySelectorAll('a[data-route]').forEach(link => {
link.addEventListener('click', (e) => {
e.preventDefault();
router.navigate(e.target.href);
});
});Trade-offs:
- SPAs eliminate reload delay but increase initial load time
- SPAs suit applications, traditional navigation suits content sites
- SPAs need JavaScript frameworks (React, Vue, Angular)
Browser Sandbox - Protection Model
Sandbox prevents malicious code from:
- Reading your files
- Installing software
- Accessing other websites’ data
- Mining cryptocurrency using your CPU
- Stealing passwords from other tabs
Client-Side Code is Completely Visible
Anyone can view and modify JavaScript:
Original code in your file:
// api-key.js
const API_KEY = 'sk-abc123secret456';
const ADMIN_PASSWORD = 'supersecret';
function checkPremiumUser() {
return user.subscription === 'premium';
}
function calculatePrice(items) {
let total = 0;
for (let item of items) {
total += item.price * item.quantity;
}
// Apply secret discount
if (user.vip) {
total *= 0.5; // 50% off for VIPs
}
return total;
}
async function processPayment(amount) {
const response = await fetch('/api/payment', {
method: 'POST',
headers: {
'Authorization': `Bearer ${API_KEY}`
},
body: JSON.stringify({ amount })
});
return response.json();
}User opens DevTools:
- Views all source code
- Sees API keys and passwords
- Modifies functions in console
- Bypasses client-side checks
What NOT to put in JavaScript:
- API keys
- Passwords
- Secret algorithms
- Premium content
- Security logic
- User authentication
Server must enforce all rules:
@app.route('/api/payment', methods=['POST'])
def payment():
# Server-side validation
amount = request.json['amount']
user = get_current_user()
# Recalculate on server
real_amount = calculate_price_server_side()
if amount != real_amount:
return {'error': 'Invalid amount'}, 400
# Process payment with server-side API key
process_payment(real_amount, SERVER_API_KEY)Performance Constraints
JavaScript blocks rendering:
<!-- Blocks HTML parsing -->
<script src="large-library.js"></script>
<p>This won't appear until JS loads</p>
<!-- Better: Async loading -->
<script src="large-library.js" async></script>
<p>This appears immediately</p>
<!-- Better: Defer until DOM ready -->
<script src="app.js" defer></script>Bundle size matters:
// Bad: Including entire library
import _ from 'lodash'; // 70KB
const unique = _.uniq([1, 2, 2, 3]);
// Good: Import only needed function
import uniq from 'lodash/uniq'; // 2KB
const unique = uniq([1, 2, 2, 3]);Mobile performance:
Desktop with fast CPU:
- Parse 1MB JS: 100ms
- Execute complex function: 10ms
Mobile with slow CPU:
- Parse 1MB JS: 1000ms
- Execute same function: 100ms
Critical rendering path:
// Bad: Runs immediately, blocks page
for (let i = 0; i < 1000000; i++) {
// Heavy computation
}
// Good: Defer heavy work
requestIdleCallback(() => {
// Heavy computation when idle
});
// Good: Web Worker for heavy tasks
const worker = new Worker('heavy-task.js');
worker.postMessage({cmd: 'start'});Mobile users on slow connections suffer most from large JavaScript bundles.
Security Best Practices
Remember: Client-side JavaScript is for user experience, not security.
All security enforcement must happen on the server where users cannot modify the code.
Web Server Maps URL to File System Path
HTTP request contains URL path:
Web server receives request on port 80 (HTTP) or 443 (HTTPS).
Server extracts path component: /docs/api.html
Path resolution algorithm:
document_root = /var/www/html
requested_path = /docs/api.html
file_path = document_root + requested_path
= /var/www/html/docs/api.htmlServer attempts to open file at computed path.
If file exists:
- Read file contents into memory
- Determine MIME type from extension (.html → text/html)
- Send HTTP 200 response with file contents
If file doesn’t exist:
- Send HTTP 404 Not Found response
No code execution occurs between request and response.
Server performs pure I/O operation:
- Map URL to file system path
- Read bytes from disk
- Write bytes to network socket
This mapping is deterministic - same URL always maps to same file path.
URL components:
- Protocol:
http:// - Host:
example.com - Path:
/docs/api.html← used for file mapping - Query parameters: ignored by static server
Common document roots:
- Apache:
/var/www/html - Nginx:
/usr/share/nginx/html - Flask:
project_directory/static/
Security consideration:
Path traversal attempts blocked:
GET /../../../etc/passwd HTTP/1.1Server validates path doesn’t escape document root.
Flask Static File Convention
Flask project structure:
project/
app.py
templates/
index.html
results.html
static/
styles.css
app.js
images/
logo.pngFlask establishes two conventions:
templates/ directory:
Contains HTML files returned by route functions:
from flask import Flask, render_template
app = Flask(__name__)
@app.route('/')
def index():
return render_template('index.html')
@app.route('/results')
def results():
# This could pass data to template
return render_template('results.html')Route / executes index() function. Function returns contents of templates/index.html.
static/ directory:
Contains CSS, JavaScript, images, data files.
No route function needed - Flask automatically maps:
- URL
/static/styles.css→ filestatic/styles.css - URL
/static/images/logo.png→ filestatic/images/logo.png
HTML references static files:
Development server behavior:
Flask development server handles both:
- Route execution for templates
- Static file serving
Production deployment:
Nginx serves static files directly:
location /static {
alias /path/to/project/static;
expires 1y;
}
location / {
proxy_pass http://flask_app;
}Static files bypass Flask entirely in production.
Browser Loads Page Through Multiple Requests
Initial HTML request:
<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="/static/main.css">
<link rel="stylesheet" href="/static/theme.css">
<script src="/static/vendor.js"></script>
<script src="/static/app.js"></script>
</head>
<body>
<img src="/static/logo.png">
<img src="/static/hero.jpg">
</body>
</html>Browser parses HTML sequentially.
Each external resource reference triggers new HTTP request.
Request sequence:
- GET / → Returns HTML (45ms)
- Browser parses
<head>, finds two<link>tags - GET /static/main.css (parallel)
- GET /static/theme.css (parallel)
- Browser finds two
<script>tags - GET /static/vendor.js (parallel)
- GET /static/app.js (parallel)
- Browser parses
<body>, finds<img>tags - GET /static/logo.png (parallel)
- GET /static/hero.jpg (parallel)
CSS may reference additional resources:
/* main.css */
@font-face {
font-family: 'Custom';
src: url('/static/fonts/custom.woff2');
}
body {
background: url('/static/bg.jpg');
}- GET /static/fonts/custom.woff2
- GET /static/bg.jpg
Total: 9 HTTP requests to display one page.
Browser constraints:
- HTTP/1.1: Maximum 6 concurrent connections per domain
- Must wait for HTML before discovering CSS/JS
- Must wait for CSS before discovering CSS-referenced images
- Render-blocking resources (CSS, synchronous JS) delay page display
Performance implications:
Each file requires:
- DNS lookup (cached after first)
- TCP connection establishment
- HTTP request/response cycle
- Download time based on file size
Optimization strategies:
- Bundle multiple CSS/JS files
- Inline critical CSS
- Use CSS sprites for small images
- Enable HTTP/2 for multiplexing
- Set cache headers for static assets
Session State Problem in Static Serving
User visits three pages in sequence:
- User visits
/login.html- Enters username and password
- Clicks submit button
- Browser redirects to
/dashboard.html- Should show “Welcome, Alice”
- Should display user’s data
- User clicks link to
/settings.html- Should show Alice’s settings
- Should allow updates
Static file limitations:
Page 1: /login.html
<form action="/authenticate" method="POST">
<input name="username">
<input name="password">
<button>Login</button>
</form>Form submission fails - no /authenticate handler exists.
Page 2: /dashboard.html
Server has no memory of login attempt. No way to identify user.
Page 3: /settings.html
Each request independent - no connection between pages.
HTTP statelessness prevents session tracking:
Each request stands alone - no built-in connection between requests.
Static server processes requests independently:
- Request 1: Read login.html, return it
- Request 2: Read dashboard.html, return it
- Request 3: Read settings.html, return it
No mechanism to:
- Remember who logged in
- Carry identity across requests
- Maintain user context between pages
Session mechanism (requires code execution):
# Login endpoint
@app.route('/authenticate', methods=['POST'])
def authenticate():
username = request.form['username']
password = request.form['password']
user = verify_credentials(username, password)
if user:
session_id = generate_token()
store_session(session_id, user.id)
response = redirect('/dashboard')
response.set_cookie('session', session_id)
return response
# Dashboard with session
@app.route('/dashboard')
def dashboard():
session_id = request.cookies.get('session')
user_id = lookup_session(session_id)
user_data = get_user_data(user_id)
return render_template('dashboard.html',
user=user_data)Static serving cannot execute any of this logic.
Product Search Demonstrates Query Complexity
User searches for “laptop under 1000”
Search requires:
- Parse search query into terms and constraints
- Build database query with appropriate filters
- Execute query against product database
- Format results as HTML
- Handle pagination for large result sets
Breaking down the search:
Text parsing:
- “laptop” → product name/description match
- “under” → price comparison operator
- “1000” → price constraint value
SQL query construction:
SELECT * FROM products
WHERE (name LIKE '%laptop%'
OR description LIKE '%laptop%')
AND price < 1000
ORDER BY relevance DESC
LIMIT 20 OFFSET 0Consider search variations:
- “gaming laptop” → two terms to match
- “laptop 500-1000” → price range
- “dell laptop” → brand + category
- “laptop with 16gb ram” → specification filter
- “cheapest laptop” → sort by price ascending
- “laptop -gaming” → exclusion filter
Each variation requires different query logic.
Pagination adds another dimension:
Page 1: OFFSET 0 Page 2: OFFSET 20 Page 3: OFFSET 40
Combined with search terms: infinite URL combinations.
Relevance scoring:
SELECT *,
(CASE WHEN name LIKE '%laptop%' THEN 10 ELSE 0 END +
CASE WHEN brand = 'Dell' THEN 5 ELSE 0 END +
CASE WHEN description LIKE '%laptop%' THEN 3 ELSE 0 END)
AS relevance
FROM products
WHERE ...
ORDER BY relevance DESCRequires computation impossible in static files.
Query variations multiply infinitely:
Search terms × Price ranges × Brands × Specifications × Sort orders × Pages
“laptop” → 47 results “gaming laptop” → 12 results “dell laptop” → 23 results “laptop 16gb” → 8 results
Each requires different SQL query.
Cannot pre-generate HTML for every possible search.
Form Data Transformation Pipeline
Registration form submission lifecycle:
Browser sends raw form data:
POST /register HTTP/1.1
Content-Type: application/x-www-form-urlencoded
email=alice%40example.com&password=secretpass123&
country=US&newsletter=onStep 1: Parse URL encoding
# URL encoded string
raw = "email=alice%40example.com&password=secretpass123"
# Parse into dictionary
data = {
'email': 'alice@example.com', # %40 decoded to @
'password': 'secretpass123',
'country': 'US',
'newsletter': 'on'
}Step 2: Validate each field
errors = []
# Email validation
if not re.match(r'^[^@]+@[^@]+\.[^@]+$', data['email']):
errors.append('Invalid email format')
# Password strength
if len(data['password']) < 8:
errors.append('Password too short')
# Country code check
if data['country'] not in VALID_COUNTRIES:
errors.append('Invalid country')Step 3: Business logic checks
# Check email uniqueness
existing = db.execute(
"SELECT id FROM users WHERE email = ?",
data['email']
).fetchone()
if existing:
return error("Email already registered")
# Rate limiting
recent = db.execute(
"SELECT COUNT(*) FROM users
WHERE ip_address = ?
AND created_at > datetime('now', '-1 hour')",
request.remote_addr
).fetchone()[0]
if recent > 5:
return error("Too many registrations")
Step 4: Password transformation
# Never store plain text
plain_password = data['password']
# Generate salt and hash
salt = bcrypt.gensalt(rounds=12)
password_hash = bcrypt.hashpw(
plain_password.encode('utf-8'),
salt
)
# Result: $2b$12$KIXx...QW8e (60 bytes)Step 5: Database insertion
user_id = db.execute(
"""INSERT INTO users
(email, password_hash, country,
newsletter, created_at, ip_address)
VALUES (?, ?, ?, ?, datetime('now'), ?)""",
data['email'], password_hash, data['country'],
data['newsletter'] == 'on', request.remote_addr
).lastrowidEach step requires computation unavailable in static serving.
Complete Request/Response Cycle - Timeline View
User clicks “View Orders” link:
Browser initiates request sequence:
Phase 1: DNS Lookup (15ms) Browser cache: app.example.com → miss OS cache: miss DNS query: app.example.com → 93.184.216.34
Phase 2: TCP Connection (25ms) Three-way handshake:
- SYN →
- ← SYN-ACK
- ACK → Connection established to port 443 (HTTPS)
Phase 3: TLS Handshake (40ms) Certificate verification Cipher suite negotiation Session key exchange
Phase 4: HTTP Request (5ms)
GET /orders HTTP/1.1
Host: app.example.com
Cookie: session=abc123def456Phase 5: Server Processing (85ms)
Nginx receives request (1ms)
Routes to Flask application (2ms)
Flask executes route function (82ms):
- Verify session (5ms)
- Query database for orders (45ms)
- Render template with data (32ms)
Phase 6: Response Transfer (30ms) Server sends 15KB HTML document Network transfer at 4Mbps
Total time: 200ms from click to HTML received
Timing breakdown:
- DNS cached after first request (saves 15ms)
- TLS handshake only on new connections
- Database query dominates server time (45ms of 85ms)
- Network transfer time depends on document size
- User perceives delay of ~200ms as “instant”
Server processing (85ms):
- Session validation against Redis cache
- SQL query:
SELECT * FROM orders WHERE user_id = 42 - Template engine combines data with HTML
- Response compression (gzip)
Server Routes Request to Code or Files
Nginx receives all HTTP requests first:
server {
listen 443 ssl;
server_name app.example.com;
# Static files - served directly
location /static {
alias /var/www/app/static;
expires 1y;
add_header Cache-Control "public";
}
# Media uploads - served directly
location /media {
alias /var/www/app/uploads;
expires 30d;
}
# Everything else - proxy to Flask
location / {
proxy_pass http://localhost:5000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}Routing decision tree:
- Request arrives:
GET /orders HTTP/1.1 - Check location blocks in order
/ordersdoesn’t match/staticor/media- Matches
/(catch-all) - Proxy request to Flask application
Flask application receives proxied request:
@app.route('/orders')
def view_orders():
# This code executes
user_id = session.get('user_id')
orders = Order.query.filter_by(
user_id=user_id
).all()
return render_template('orders.html',
orders=orders)Static file requests never reach Flask.
Performance comparison:
| Request Type | Processing Time | Operations |
|---|---|---|
| Static CSS | 0.3ms | Read file from disk |
| Static Image | 0.5ms | Read file from disk |
| Dynamic Page | 85ms | Session + DB + Template |
| API Endpoint | 45ms | Session + DB + JSON |
Static files bypass application code - direct disk-to-network transfer (0.5ms) vs database queries and template rendering (45ms).
Browser Constructs Page from Multiple Files
HTML response references multiple resources:
<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="/static/base.css">
<link rel="stylesheet" href="/static/orders.css">
<script src="/static/vendor.js"></script>
<script src="/static/app.js"></script>
</head>
<body>
<img src="/static/logo.png" alt="Logo">
<h1>Your Orders</h1>
<div class="order-list">
<!-- Order data here -->
</div>
</body>
</html>Browser discovers resources progressively:
- Parse HTML line by line
- Find
<link>tag → Request base.css - Find second
<link>→ Request orders.css - Find
<script>tags → Request both JS files - Continue parsing, find
<img>→ Request logo.png
CSS may reference more resources:
/* base.css */
@font-face {
font-family: 'Custom';
src: url('/static/fonts/custom.woff2');
}
body {
background: url('/static/patterns/grid.svg');
}
/* orders.css */
.order-icon {
background: url('/static/icons/package.svg');
}Browser can’t discover these until CSS loads and parses.
Cascade effect: Must load A before discovering B exists.
Connection limit creates “rounds”:
With 6 parallel connections and 9 resources:
- Round 1: HTML (1 connection)
- Round 2: 5 resources from HTML (5 connections)
- Round 3: 3 resources from CSS (3 connections)
Each round adds latency. HTTP/2 multiplexing eliminates this bottleneck.
Render Pipeline Transforms Data to Pixels
Browser converts HTML/CSS to visual display:
Step 1: Parse HTML → DOM Tree
Creates tree structure:
div (class="order")
├── h2
│ └── "Order #1234"
└── p
└── "Total: $89.99"Step 2: Parse CSS → CSSOM
Creates style rules tree.
Step 3: Combine DOM + CSSOM → Render Tree
Each DOM node gets computed styles:
div.order: border, padding inherited from CSSh2: 24px navy textp: Default styles
Step 4: Layout (Reflow)
Calculate exact position and size:
- div.order: x=10, y=50, width=400, height=80
- h2: x=20, y=60, width=380, height=30
- p: x=20, y=95, width=380, height=20
Step 5: Paint
Draw pixels to screen in order:
- Background colors
- Borders
- Text
- Images
Performance implications:
- Reflow (layout recalculation): Expensive
- Triggered by: Size changes, position changes
- Affects all child elements
- Repaint: Moderate cost
- Triggered by: Color changes, visibility
- Doesn’t recalculate positions
- Composite: Cheap
- Triggered by: Opacity, transforms
- GPU accelerated
JavaScript DOM changes restart pipeline from step 1.
Developer Tools Reveal the Process
Network tab shows request waterfall:
Name Status Type Size Time
─────────────────────────────────────────────
orders 200 html 15KB 85ms
base.css 200 css 8KB 50ms
orders.css 200 css 5KB 45ms
vendor.js 200 js 45KB 100ms
app.js 200 js 12KB 70ms
logo.png 200 png 3KB 30ms
custom.woff2 200 font 25KB 30ms
grid.svg 200 svg 2KB 15ms
package.svg 200 svg 1KB 15ms
─────────────────────────────────────────────
Total: 111KB 440msWaterfall reveals:
- Parallel requests limited to 6
- CSS files loaded before fonts discovered
- Blocking resources delay page render
Elements tab shows current DOM:
View Source shows:
Elements tab shows (after JavaScript):
JavaScript modified DOM after page load.
Console shows JavaScript activity:
[10:23:45.123] Fetching user data...
[10:23:45.234] API response: 200 OK
[10:23:45.245] Updated 3 elements
[10:23:45.267] Error: Cannot read property
'name' of undefined at line 47Errors appear immediately with file and line number.
What DevTools reveals:
- Network: Every HTTP request with timing
- Elements: Current DOM state (after JS changes)
- Console: JavaScript execution and errors
- Sources: Set breakpoints in JavaScript
DevTools reveals runtime behavior:
- View Source: Shows original HTML sent by server
- Inspect Element: Shows current DOM after JavaScript