DEV Community: Md Umar Siddique

JavaScript: The Chosen One — Why the Browser Speaks Only JavaScript (and Why We Can’t Replace It)

Md Umar Siddique — Thu, 05 Jun 2025 04:30:00 +0000

A language everyone loves to hate.

Built in 10 days.

Still running the world.

If you're like me, then you must have thought that every single frontend role mentions JavaScript. Not Python (or maybe your favorite language). Not the "elegant" TypeScript you've been hearing about. Just plain old JavaScript—the language everyone loves to complain about.

You start wondering: "Why is this weird, quirky language still running the entire internet?" You've heard the horror stories—automatic type coercion, the dreaded undefined, and don't even get me started on this binding.

But here's the uncomfortable truth: JavaScript isn't going anywhere.

This is the story of why JavaScript became the chosen one—not by design, but by destiny. It's about more than being "first." It's about being perfectly imperfect for the chaotic world of the web.

This is Episode 4 of our series — Unpacking JavaScript: 10 Days That Changed the Internet — Why the Browser Speaks Only JavaScript and Why We Can’t Replace It.

Missed the previous episodes? Check out:

Episode 1: Birth of JavaScript: 10 Days, One Man, and a New Era

Episode 2: Why JavaScript Survived – Wars, Standards, and Second Chances

Episode 3: The Philosophy of JavaScript: Messy, Mighty, and Made for the Web

Ready to understand why we can't escape JavaScript? Let's dive in.

The Historical Foundation: More Than Just "Being First"
The Technical Monopoly: Why Browsers Only Speak JavaScript
JavaScript's Unique Architectural Advantages
The Ecosystem Explosion: Network Effects in Action
Why Alternatives Fall Short
The Developer Reality: Making Peace with JavaScript
The Inconvenient Truth
Closing Thought
MCQ: Test Your JavaScript Knowledge

The Historical Foundation: More Than Just "Being First"

The 10-Day Genesis

It started with urgency. In May 1995, Brendan Eich had just 10 days to create a scripting language for Netscape Navigator.

• The rush job that changed everything: The goal was simple—make web pages interactive. What emerged was JavaScript, borrowing syntax from Java, functions from Scheme, and prototypes from Self.

• The embedding advantage: Unlike other languages that needed external runtimes or plugins, JavaScript was embedded directly into the browser engine. No installation, no setup, no barriers.

The beauty of this "rushed" design was its simplicity. While other languages required complex setup procedures, JavaScript just worked.

The Network Effect Explosion

• Browser wars accelerated adoption: As Netscape and Internet Explorer battled for dominance, both browsers had to support JavaScript to remain viable. This created an immediate universal standard—not by committee, but by market necessity.

• The point of no return: By 2000, millions of websites depended on JavaScript. Removing it would break the internet. This created a lock-in effect that persists today.

Key Insight: JavaScript's dominance wasn't planned—it was inevitable once browsers made it universal.

The Technical Monopoly: Why Browsers Only Speak JavaScript

Native Language Privilege

JavaScript enjoys a privilege no other language possesses in the browser environment:

• Direct execution: Every browser ships with a JavaScript engine (V8 in Chrome, SpiderMonkey in Firefox, JavaScriptCore in Safari). These engines don't just run JavaScript—they are optimized specifically for it.

• Zero compilation step: While TypeScript, Dart, or CoffeeScript must be transpiled to JavaScript, vanilla JavaScript runs directly. This eliminates build steps and enables immediate execution.

• Runtime flexibility: JavaScript's dynamic nature allows for runtime code generation, evaluation, and modification. Features like eval(), dynamic imports, and runtime type checking work because browsers understand JavaScript semantically.

Deep Browser Integration

• DOM API marriage: JavaScript wasn't just designed as a general-purpose language—it was crafted specifically to manipulate web documents. APIs like document.querySelector(), addEventListener(), and window.location aren't external libraries—they're native extensions of the JavaScript runtime in browsers.

• Event-driven architecture alignment: The browser's event-driven model (clicks, scrolls, network requests) maps perfectly to JavaScript's event loop and callback system.

Consider this simple example:

document.getElementById('button').addEventListener('click', function() {
    fetch('/api/data')
        .then(response => response.json())
        .then(data => document.getElementById('result').textContent = data.message);
});

This single block demonstrates JavaScript's native integration with DOM manipulation, event handling, and network requests—all without importing a single library.

JavaScript's Unique Architectural Advantages

The Event Loop: Built for the Web

• Single-threaded simplicity: While other languages manage complex threading models, JavaScript's single-threaded event loop with non-blocking I/O is perfect for UI applications. No race conditions, no deadlocks.

• Asynchronous by default: Modern JavaScript's async/await syntax makes asynchronous programming intuitive. While Python has asyncio and Java has CompletableFuture, JavaScript's async model is native and pervasive.

// Natural async flow in JavaScript
async function loadUserData(userId) {
    const user = await fetch(`/api/users/${userId}`);
    const preferences = await fetch(`/api/preferences/${userId}`);
    return { user: await user.json(), preferences: await preferences.json() };
}

Dynamic Flexibility: A Double-Edged Sword

• Runtime adaptability: JavaScript's dynamic typing allows for flexible API responses, runtime code generation, and adaptive programming patterns that would be impossible in statically typed languages.

• Prototype-based inheritance: While class-based inheritance creates rigid hierarchies, JavaScript's prototype system allows for flexible object composition and runtime modification of object behavior.

The flexibility that makes JavaScript "messy" also makes it incredibly adaptable to the unpredictable nature of web development.

The Ecosystem Explosion: Network Effects in Action

NPM: The Largest Package Registry

• Scale of adoption: NPM hosts over 2 million packages—more than Python's PyPI, Java's Maven Central, and Rust's Crates.io combined. This represents a massive community solving problems specifically for web development.

• Specialization depth: Need to parse dates? Moment.js and date-fns. State management? Redux, MobX, Zustand. Animation? Three.js, GSAP, Framer Motion. The JavaScript ecosystem has specialized solutions for every web development challenge.

Framework Maturity and Diversity

• Multiple paradigms supported: React's component model, Vue's template approach, Angular's full framework solution, and Svelte's compile-time optimization all coexist in the JavaScript ecosystem.

• Full-stack JavaScript: Node.js enabled JavaScript on the server, creating isomorphic applications where the same code runs on both client and server. Frameworks like Next.js, Nuxt.js, and SvelteKit leverage this for powerful full-stack solutions.

Tooling Ecosystem Maturity

The JavaScript tooling ecosystem has evolved into a sophisticated development environment:

• Build tools: Webpack, Vite, Rollup, and Parcel provide optimized bundling
• Testing frameworks: Jest, Vitest, Cypress, and Playwright offer comprehensive testing
• Development experience: Hot module replacement, source maps, and browser DevTools create unmatched workflows

Why Alternatives Fall Short

TypeScript: The Enhanced JavaScript

• Dependency on JavaScript: TypeScript is a superset of JavaScript, not a replacement. Every TypeScript project ultimately compiles to JavaScript. TypeScript inherits both JavaScript's capabilities and its limitations.

• Complexity trade-offs: While TypeScript adds type safety, it also adds compilation steps, configuration complexity, and learning overhead. For simple scripts or rapid prototyping, vanilla JavaScript's simplicity remains advantageous.

• Ecosystem compatibility: TypeScript's strength lies in its seamless integration with the JavaScript ecosystem. It doesn't replace JavaScript—it enhances it.

Python: Beautiful but Bounded

• Runtime requirements: Python in the browser requires either server-side rendering (losing client-side interactivity) or tools like Pyodide/Brython that create large runtime bundles and performance overhead.

• DOM access limitations: Python's elegant syntax can't directly manipulate DOM elements. It needs wrapper libraries that ultimately call JavaScript functions.

• Ecosystem mismatch: Python's strengths (data science, AI, scripting) don't align with frontend development needs (user interfaces, event handling, real-time interactions).

WebAssembly: The Future That Isn't (Yet)

• Performance vs. accessibility trade-off: While WebAssembly enables near-native performance for compute-intensive tasks, it lacks direct DOM access and requires JavaScript orchestration for UI interactions.

• Development complexity: WebAssembly requires compilation from languages like Rust or C++, creating complex toolchains that contradict the web's low-barrier-to-entry philosophy.

• Complementary, not competitive: WebAssembly excels at computational tasks but still needs JavaScript for DOM manipulation and browser API access.

The Developer Reality: Making Peace with JavaScript

The Pragmatic Choice

As a developer in 2025, you have a choice: fight against JavaScript's dominance or embrace it strategically.

• Market demand: JavaScript skills are required for virtually every frontend role and increasingly for backend positions with Node.js adoption.

• Versatility: JavaScript knowledge translates across web development, mobile development (React Native), desktop applications (Electron), and server-side development.

• Career investment: Time spent mastering JavaScript pays dividends across multiple domains, unlike specialized languages that serve narrow use cases.

Learning Strategy for Modern Developers

• Start with the fundamentals: Understanding JavaScript's core concepts (closures, prototypes, async programming) provides a foundation that applies across all JavaScript frameworks and libraries.

• Embrace the ecosystem: Rather than fighting JavaScript's quirks, learn to leverage its ecosystem. Use ESLint for code quality, Prettier for formatting, and TypeScript when type safety matters.

• Focus on modern JavaScript: ES6+ features like arrow functions, destructuring, modules, and async/await have significantly improved the language's ergonomics.

The Inconvenient Truth

The web was built on three pillars: HTML for structure, CSS for presentation, and JavaScript for behavior. While HTML and CSS have competitors, JavaScript's monopoly on browser behavior remains absolute.

This isn't a failure of innovation—it's the result of JavaScript being perfectly suited to its environment. Its dynamic nature matches the unpredictable web, its event-driven model aligns with user interactions, and its ecosystem has grown to encompass every conceivable web development need.

The Network Effect Lock-In

JavaScript's dominance creates a self-reinforcing cycle:
• More developers learn JavaScript → More JavaScript projects → More job opportunities → More developers learn JavaScript

This cycle is so powerful that even superior alternatives struggle to gain traction. It's not enough to be better than JavaScript—a replacement would need to be dramatically better AND provide a clear migration path for billions of lines of existing code.

Closing Thought

JavaScript wasn't chosen by design committees or academic consensus. It was chosen by developers, shaped by real-world needs, and refined through decades of practical use.

Whether you're a Python developer wondering why the web isn't more "elegant," a systems programmer confused by JavaScript's loose typing, or a student choosing your first language, the message is clear: JavaScript is the language of the web, and that's not changing anytime soon.

The sooner you make peace with JavaScript—learn its patterns, understand its ecosystem, and appreciate its unique fit for web development—the sooner you'll be able to build the interactive, dynamic applications that define the modern web.

JavaScript isn't just the language of the web by accident. It's the language of the web by design, evolution, and necessity. And that makes it, quite literally, the chosen one.

Thank You

Thanks for reading this deep dive into JavaScript's dominance. This is the last part of the series Unpacking JavaScript: 10 Days That Changed the Internet. If this changed your perspective on JavaScript, sparked a memory of your own battles with the language, or just made you appreciate the chaos that built the modern web—drop a comment below.

If you found this helpful, a like or share would mean a lot—it helps get the story to more curious developers like you.

Let's connect:

GitHub

X/Twitter

MCQ: Test Your JavaScript Knowledge

Questions

1. What was the original time frame for creating JavaScript?
A. 30 days
B. 10 days
C. 3 months
D. 6 weeks

2. Which JavaScript engine powers Google Chrome?
A. SpiderMonkey
B. JavaScriptCore
C. V8
D. Chakra

3. What makes JavaScript unique in browser environments?
A. It's the fastest language
B. It has the best syntax
C. It's embedded directly in browser engines
D. It's the easiest to learn

4. What is the largest package registry in the world?
A. PyPI (Python)
B. NPM (JavaScript)
C. Maven Central (Java)
D. Crates.io (Rust)

5. Why can't TypeScript completely replace JavaScript?
A. TypeScript is slower
B. TypeScript compiles to JavaScript
C. TypeScript has fewer features
D. TypeScript isn't supported by browsers

6. What architectural advantage does JavaScript have for web development?
A. Multi-threaded processing
B. Static typing
C. Single-threaded event loop
D. Manual memory management

Answers

B. 10 days - Brendan Eich created JavaScript in just 10 days at Netscape in 1995.
C. V8 - Google's V8 engine powers Chrome and Node.js.
C. It's embedded directly in browser engines - Unlike other languages that need compilation or transpilation.
B. NPM (JavaScript) - With over 2 million packages, NPM is the world's largest package registry.
B. TypeScript compiles to JavaScript - TypeScript is a superset that ultimately depends on JavaScript.
C. Single-threaded event loop - Perfect for UI applications and asynchronous web operations.

The Philosophy of JavaScript: Messy, Mighty, and Made for the Web

Md Umar Siddique — Tue, 03 Jun 2025 04:00:00 +0000

"JavaScript is a language of many paradigms. It borrows ideas from functional programming, object-oriented programming, and procedural programming."
— Kyle Simpson

Why does JavaScript feel... different?

Every developer has that moment. You're writing code, everything seems logical, and then JavaScript does something that makes you pause and think: "Wait, that actually worked?"

A variable becomes a function.

An object transforms mid-execution.

Async operations flow like water.

Other languages demand you follow their rules. JavaScript asks: "What are you trying to accomplish?" Then it finds a way — often multiple ways — to make it happen.

This isn't accident. It's intentional design philosophy that emerged from a simple truth: the web is chaotic, unpredictable, and constantly changing. So JavaScript was built to match that energy.

It's messy by design.

Flexible by necessity.

Powerful by choice.

This is Episode 3 of our series — Unpacking JavaScript: 10 Days That Changed the Internet — diving into the core philosophy that made JavaScript the backbone of modern development.

Missed the previous episodes? Check out:

Episode 1: Birth of JavaScript: 10 Days, One Man, and a New Era

Episode 2: Why JavaScript Survived – Wars, Standards, and Second Chances

Ready to understand why JavaScript feels different? Let's unpack the philosophy.

JavaScript Wasn't Designed — It Was Assembled
"Everything Is an Object"... Kinda
Functions as First-Class Citizens
Prototype over Class: A Radical Choice
Safety First: The Browser Sandbox
The Web Is Async — So JavaScript Had to Be
Democracy in Code: JS for Everyone
The Good Parts vs. The Wild Parts
Why JavaScript's Philosophy Still Matters
The Mighty Mess
Closing Thought
MCQ: Strengthen Your Understanding

JavaScript Wasn't Designed — It Was Assembled

JavaScript wasn't born in a corporate boardroom or university lab. It emerged from the messy, chaotic early days of the web, when browsers were battling for dominance and developers needed something—anything—to make web pages come alive.

Brendan Eich had 10 days and clear orders:

Java-like syntax (to comfort Java devs)
Scheme/Lisp-style functions (for power)
Self-like prototypal inheritance (for flexibility)

// The result: flexible, forgiving, and sometimes confusing
let data = "Hello World";
data = 42;
data = { message: "I'm an object now" };
data = function() { return "And now I'm a function"; };

It was a Frankenstein of good intentions. But this flexibility wasn't accidental — it was intentional. The web needed a language that could adapt, bend, and evolve alongside the rapidly changing landscape of browser wars and emerging technologies.

The Assembly Philosophy:

Evolution over perfection
Accessibility over complexity
Flexibility over strictness
Speed over purity

"Everything Is an Object"... Kinda

In JavaScript, nearly everything behaves like an object, even when it technically isn't one.

typeof [] // "object"
typeof {} // "object" 
typeof (() => {}) // "function" (but still an object!)

// You can even attach properties to functions!
function greet() { return "Hello!"; }
greet.author = "JavaScript";
console.log(greet.author); // "JavaScript"

This object-oriented flexibility was revolutionary for web development. You could:

Attach properties to functions
Iterate over arrays like objects
Manipulate everything with consistent interfaces

It was almost too flexible — but that flexibility was the point.

Speed and convenience were prioritized over strictness or purity.

On the web, you needed quick, fluid access to everything. This decision enabled the kind of dynamic, interactive web experiences that define modern applications.

Functions as First-Class Citizens

This was one of JavaScript's most radical features — functions weren't just code blocks, they were values that could be passed around like any other data.

function greet(name) {
  return "Hello, " + name;
}

const sayHi = greet;
console.log(sayHi("Developer")); // "Hello, Developer"

// Functions can be passed as arguments
function processData(data, callback) {
  return callback(data.toUpperCase());
}

processData("javascript", console.log); // "JAVASCRIPT"

This opened the door to:

Callbacks for event handling
Closures for data privacy
Higher-order functions for abstraction
Functional programming patterns

In the browser, this wasn't just powerful — it was necessary. Event-driven design wasn't common, it was the only way to build interactive web applications.

Prototype over Class: A Radical Choice

While most developers expected traditional class hierarchies, JavaScript took a different path — prototypal inheritance, where objects simply link to other objects.

const person = {
  greet() {
    return "Hi there!";
  }
};

const user = Object.create(person);
user.name = "Developer";
console.log(user.greet()); // "Hi there!"

This was unusual and often confusing. But JavaScript's prototypal inheritance was simpler under the hood — just objects referencing other objects. No complex class hierarchies, no multiple inheritance problems.

Later, classes were added in ES6 to appease developers:

class Person {
  greet() {
    return "Hi there!";
  }
}

class Developer extends Person {
  code() {
    return "console.log('Hello World!')";
  }
}

But under the hood? Still prototypes. JavaScript didn't abandon its philosophy — it just provided familiar syntax while maintaining its flexible foundation.

Safety First: The Browser Sandbox

JavaScript needed to be powerful enough to create rich web experiences but safe enough to run untrusted code from anywhere on the internet.

This led to JavaScript's security-first design philosophy:

The Browser Fortress:

No direct file system access
Limited network capabilities (same-origin policy)
Automatic memory management
No direct hardware interaction

// JavaScript protects users by making this impossible:
// deleteFile("/system/important.txt"); // Nope!
// accessCamera(); // Not without permission!
// modifyOtherWebsites(); // Blocked by same-origin policy!

This safety-first approach meant JavaScript could spread across the web without users fearing for their security. Every website could include JavaScript without administrators worrying about system compromises.

Revolutionary result: enabling the interactive web while maintaining security.

The Web Is Async — So JavaScript Had to Be

Web applications depend on:

Network requests
User input
Timers and events
Real-time updates

JavaScript's single-threaded, event-driven model handles this chaos with elegant simplicity:

// The evolution of async JavaScript

// Callbacks (messy but functional)
getData(function(result) {
  processData(result, function(processed) {
    saveData(processed, function(saved) {
      console.log('Done!');
    });
  });
});

// Promises (cleaner)
fetch('/data')
  .then(response => response.json())
  .then(data => processData(data))
  .then(result => saveData(result))
  .then(() => console.log('Done!'));

// Async/await (elegant)
async function handleData() {
  const response = await fetch('/data');
  const data = await response.json();
  const processed = await processData(data);
  await saveData(processed);
  console.log('Done!');
}

The progression: Callbacks → Promises → async/await

It was messy at first, but became one of JavaScript's greatest strengths. No thread management, no race conditions — just non-blocking, event-driven flow that mirrors how users actually interact with web applications.

Democracy in Code: JavaScript for Everyone

JavaScript's most revolutionary stance was its commitment to accessibility. While other languages required computer science degrees, JavaScript welcomed anyone with a text editor and curiosity.

// Your first JavaScript program:
alert("Hello, World!");

// And you can run it immediately in any browser
// No compilation, no setup, no barriers

This wasn't accidental. JavaScript's creators understood that the web's success depended on democratizing programming.

The Beginner-Friendly Design:

Forgiving syntax with helpful coercion
Built-in debugging tools in every browser
Immediate feedback and results
Extensive community support

Anyone could view source, write a script, and make the web move.

This philosophy of inclusion has onboarded millions of developers who might never have programmed otherwise. Frontend developers, designers, content creators, and entrepreneurs all found their way into programming through JavaScript's welcoming embrace.

The Good Parts vs. The Wild Parts

Douglas Crockford famously wrote "JavaScript: The Good Parts" to isolate what was elegant from what was chaotic.

He praised:

First-class functions
Object literals
Prototypes
Dynamic typing

He warned against:

with statements
== type coercion
Global variables
this confusion

// The Good Parts
const user = {
  name: "Developer",
  greet: function() {
    return `Hello, ${this.name}!`;
  }
};

// The Wild Parts  
if ("0" == false) { // true (wat?)
  console.log("JavaScript being JavaScript");
}

But even the "bad parts" were survivable — and fixable through:

Better practices
Linting tools (ESLint)
Type checking (TypeScript)
Modern frameworks

JavaScript's philosophy was always evolution over revolution, pragmatism over purity.

Why JavaScript's Philosophy Still Matters

As we look toward the future of web development, JavaScript's core philosophy remains as relevant as ever:

** In an AI-driven world:** JavaScript's flexibility makes it ideal for rapid experimentation and prototype development.

** In a mobile-first era:** JavaScript's cross-platform capabilities through React Native, Ionic, and PWAs make it more valuable than ever.

⚡ In a real-time web: JavaScript's event-driven architecture provides the foundation for WebSockets, WebRTC, and modern real-time applications.

** In a complex dev landscape:** JavaScript's beginner-friendly nature ensures new developers can still find an accessible entry point.

The Ripple Effect:

JSON became the universal data format
Node.js brought event-driven philosophy to servers
React/Vue/Angular adopted component-based thinking
Modern Web APIs follow promise-based patterns

Even other languages adopted JavaScript-inspired features: arrow functions, async/await syntax, and JSON-first APIs.

The Mighty Mess

JavaScript's quirks aren't accidents — they're survival strategies.

The loose rules, the prototypal inheritance, the asynchronous defaults, the forgiving syntax — they weren't mistakes. They were deliberate choices that enabled JavaScript to adapt, grow, and eventually power everything from web browsers to servers to mobile apps.

The Survival Philosophy:

Built fast to win browser wars
Made forgiving so beginners could learn
Designed flexible to run anywhere
Kept open so anyone could contribute

JavaScript wasn't made to be clean — it was made to be useful.

Understanding this philosophy helps us work with JavaScript more effectively. Instead of fighting its flexible nature, we can embrace it.

Closing Thought

JavaScript doesn't just work on the web — it IS the web.

Its philosophy of accessibility, flexibility, safety, and pragmatism continues to shape how we think about programming languages and software development.

The next time you write a JavaScript function, remember: you're not just writing code. You're participating in a philosophical tradition that believes:

Programming should be accessible
The web should be safe
Developers should be free to solve problems creatively
Sometimes, good enough is better than perfect

That's the true power of JavaScript — not just what it can do, but what it represents: a messy, mighty language made for a web where anything is possible.

Up Next: Episode 4

Episode 2: "JavaScript: The Chosen One — Why the Browser Speaks Only JavaScript (and Why We Can’t Replace It)"

Discover the surprising reasons JavaScript became the undisputed lingua franca of the web—and why no other language, no matter how elegant or powerful, has been able to dethrone it. From browsers to servers, and beyond, this episode unpacks the deep roots and far-reaching impact of JavaScript’s reign.

Thank You

Thanks for reading Episode 3 of the series - Unpacking JavaScript: 10 Days That Changed the Internet.

Which "weird" JavaScript feature finally clicked for you after reading this? Drop a comment below — I'd love to feature some insights in the next episode!

Found this helpful? A ❤️ or 🔄 share would mean the world — it helps more developers discover JavaScript's fascinating philosophy.

Let’s connect:

GitHub
LinkedIn
X/Twitter

MCQ: Strengthen Your Understanding

Quiz Questions

1. Which languages primarily influenced JavaScript's initial design?

A. C++ and Python
B. Java, Scheme, and Self
C. Ruby and Perl
D. C and Assembly

2. What makes functions "first-class citizens" in JavaScript?

A. They have better performance
B. They can be passed, assigned, and returned like variables
C. They are globally scoped
D. They use less memory

3. JavaScript originally used which inheritance model?

A. Classical inheritance (like Java)
B. Prototypal inheritance
C. Multiple inheritance
D. Interface-based inheritance

4. What philosophy guided JavaScript's approach to browser security?

A. Trust but verify
B. Sandbox everything
C. Allow all access
D. User-controlled permissions

5. How does JavaScript handle asynchronous operations?

A. Multi-threading
B. Event-driven, single-threaded model
C. Synchronous blocking
D. Parallel processing

Quiz Answers

B. Java, Scheme, and Self — The three main influences on JavaScript's design
B. They can be passed, assigned, and returned like variables — This is what makes them "first-class"
B. Prototypal inheritance — Objects linking to other objects, not classes
B. Sandbox everything — Safety first in the browser environment
B. Event-driven, single-threaded model — No threads, just events and callbacks

Why JavaScript Survived – Wars, Standards, and Second Chances

Md Umar Siddique — Sun, 01 Jun 2025 04:00:00 +0000

"The strength of a language is not in its design, but in its community." — Douglas Crockford

A language born in chaos.
Shaped by urgency.
Misunderstood for years.

When JavaScript launched in 1995, it wasn't ready — but the web was changing fast. The browser wars were heating up, and JavaScript became a weapon, rushed into battle without a blueprint.

Each browser implemented it differently. Bugs were everywhere. Developers were frustrated. Critics called it a mistake.

But JavaScript didn't die. It adapted. It grew stronger with every challenge — and somehow, it won.

This is the second episode of our series — Unpacking JavaScript: 10 Days That Changed the Internet — and it dives into the survival story that almost never happened.
If you're curious how JavaScript was nearly broken (but came back stronger), you're in the right place.

And if you want to know about JavaScript's Birth story and how it all began, check out my previous article.

How did that happen? Let's unpack the story.

The Browser Wars Begin
ECMAScript: The First Step Toward Unity
The Dark Age (1999–2005)
AJAX and the Comeback Nobody Saw Coming
ES5 and the Second Chance
Frameworks, Ecosystem, and the Community
Why JavaScript Survived
Recap
Closing Thought
MCQ: Strengthen Your Understanding

The Browser Wars Begin

It started with Netscape's bold move: shipping JavaScript with Navigator 2.0 in late 1995.

Microsoft, never one to watch from the sidelines, responded fast — releasing Internet Explorer with their own version of JavaScript: JScript, a reverse-engineered clone.

That kicked off a brutal battle:

Netscape vs. Microsoft
JavaScript vs. JScript
Developers vs. sanity

Every browser had subtle (and not-so-subtle) differences in how they implemented JavaScript.

"Write once, debug everywhere."

For developers, it was a nightmare. For the web, it was chaos.

But out of that chaos came the need for something essential: a standard.

ECMAScript: The First Step Toward Unity

To stop JavaScript from splintering into a dozen incompatible versions, Netscape submitted it to ECMA International — a neutral standards body.

In 1997, the first official standard was born:
ECMAScript 1 (ES1)

For the first time, there was a blueprint. A common goal. A way for browser makers to align.

This was JavaScript's first breath of legitimacy — it wasn't just a browser hack anymore. It was a language.

With ES3 (1999), things were looking hopeful.

But then… everything went quiet.

The Dark Age (1999–2005)

From 1999 to 2005, JavaScript almost faded into the background.

Browser innovation slowed down
Flash and Java Applets took over interactivity
JavaScript was mocked as a "toy language" — barely suitable for simple form validation

It wasn't cool. It wasn't powerful. It wasn't the future.

But this lull gave JavaScript something rare: time to mature. Quietly, the seeds of its rebirth were being planted.

AJAX and the Comeback Nobody Saw Coming

In 2005, something changed everything: Google Maps.

It let users pan, zoom, and interact — all without reloading the page.

How?
A little-known technique called AJAX — Asynchronous JavaScript and XML.

Gmail, Google Maps, and Facebook were all-in on JavaScript — and suddenly, everyone else followed.

This was the Ajax Revolution — and JavaScript was no longer a joke. It was a superpower.

ES5 and the Second Chance

With developers returning, the community demanded more from JavaScript.

In 2008, after years of infighting, the long-awaited ECMAScript 5 (ES5) was released.

It brought:

Object.create()
Array.forEach(), map(), filter()
Better handling of properties and edge cases

And in 2015, everything changed again with ES6 (ES2015):

let, const
Arrow functions () => {}
Promises
Modules
Classes (syntactic sugar)

This was the renaissance — JavaScript finally felt modern.

Frameworks, Ecosystem, and the Community

As JavaScript evolved, a powerful ecosystem grew around it — driven by innovation, need, and an unstoppable developer movement.

jQuery (2006): Made DOM scripting and cross-browser compatibility dramatically easier.
Node.js (2009): Brought JavaScript to the server, enabling full-stack development.
AngularJS (2010): Introduced a new way to build single-page applications with two-way data binding.
React (2013): Changed the game with component-based architecture and a virtual DOM.
Vue.js (2014): Combined the best ideas from Angular and React into a lightweight, flexible framework.
TypeScript (2012): Added static typing and tooling support, bringing large-scale engineering discipline to JavaScript.

But more than tools, what truly saved JavaScript was its community:

Developers shared patterns, created libraries, and mentored each other.
Standards bodies opened up — inviting contributions and feedback.
The language evolved, not by accident, but by collective force.

JavaScript went from "barely usable" to "absolutely everywhere" — thanks to the people who believed it could be more.

Why JavaScript Survived

JavaScript didn't survive because it was perfectly designed.

It survived because:

It adapted fast
It was in the right place (the browser)
People cared enough to fix its flaws
The community fought for it

From the edge of extinction to the center of modern development — this is how JavaScript survived.

Closing Thought

JavaScript didn't survive because it was perfectly designed — it survived because people believed it could be more.

From browser wars to standards battles, from the dark ages to the AJAX revolution — JavaScript's story is proof that community and persistence can transform even the most chaotic beginnings into something extraordinary.

Up Next:

Episode 3: “The Philosophy of JavaScript: Messy, Mighty, and Made for the Web"

In the next episode, we'll explore JavaScript's transformation into a full-stack force — running on browsers, servers, mobile apps, and beyond. How did a simple scripting language become the backbone of modern development?

Thank You

Thanks for reading Episode 2 of the series - Unpacking JavaScript: 10 Days That Changed the Internet.

If this survival story resonated with you, sparked a memory of your own JavaScript battles, or just made you appreciate the chaos that built the modern web — drop a comment below. I'd love to hear your take, continue the conversation, or geek out with fellow JavaScript survivors.

If you found this helpful, a like or share would mean a lot — it helps get the story to more curious developers like you.

Let's connect:

GitHub
LinkedIn
X/Twitter

MCQ: Strengthen Your Understanding

Questions

1. What was Microsoft's response to Netscape's JavaScript?
A. They created their own language called ActiveScript
B. They reverse-engineered JavaScript and created JScript
C. They partnered with Netscape to improve JavaScript
D. They ignored JavaScript completely

2. When was the first ECMAScript standard (ES1) released?
A. 1995
B. 1996
C. 1997
D. 1999

3. What period is referred to as JavaScript's "Dark Age"?
A. 1995-1997
B. 1997-2000
C. 1999-2005
D. 2000-2008

4. What revolutionary technique made Google Maps possible in 2005?
A. WebSockets
B. AJAX (Asynchronous JavaScript and XML)
C. Flash integration
D. Server-side rendering

5. Which JavaScript version is considered the "renaissance moment" with modern syntax?
A. ES3 (1999)
B. ES5 (2009)
C. ES6/ES2015 (2015)
D. ES7 (2016)

6. What year was Node.js released, bringing JavaScript to the server?
A. 2008
B. 2009
C. 2010
D. 2011

Answers

B. They reverse-engineered JavaScript and created JScript
C. 1997
C. 1999-2005
B. AJAX (Asynchronous JavaScript and XML)
C. ES6/ES2015 (2015)
B. 2009

Birth of JavaScript: 10 Days, One Man, and a New Era

Md Umar Siddique — Thu, 22 May 2025 03:30:00 +0000

"Always bet on JavaScript." — Brendan Eich

Every powerful invention has a story — often chaotic, usually rushed, and occasionally misunderstood.
JavaScript's story is no different.

In this first episode, we journey back to 1995, when one man — in just 10 days — wrote the foundation for what would become the most widely-used programming language on the internet.

Why care about JavaScript's history?
Writing code is one thing — understanding the language shows love.
I fell for JavaScript, and that led me deep into its past.
If you're even a little curious (or a little obsessed), this story is for you.

So, Let’s begin with: The Web Before JavaScript

The Web Before JavaScript
Enter Netscape: The Startup That Started the Browser War
Brendan Eich and the 10-Day Miracle
Why JavaScript? Why Not Java or C++?
Why the Name "JavaScript"?
JavaScript's DNA: Born of Necessity, Built for the Web
A New Era Begins
Closing Thought
MCQ: Strengthen Your Understanding

The Web Before JavaScript

In the early '90s, the web was a static place.

HTML gave structure to documents.
Links let users click around.
Forms could collect data, but always required a page reload.
CSS didn't even exist yet.

There was no interactivity, no animations, no dynamic behavior.
Pages were digital brochures, not applications.

The web needed a brain — something to react to users, validate input, and update content without reloading the entire page.

Enter Netscape: The Startup That Started the Browser War

Netscape was the dominant web browser company at the time, founded by Marc Andreessen, the same mind behind Mosaic (the first graphical browser).

Netscape had a bold vision:

"The web should be alive — not static."

They wanted a scripting language that:

Ran directly in the browser
Could manipulate the page (DOM)
Was lightweight and forgiving
Was easy for web designers, not just hardcore developers

Brendan Eich and the 10-Day Miracle

To solve this, Netscape brought in Brendan Eich — a brilliant programmer with a deep background in designing languages.

Originally, he was supposed to add Scheme to the browser — a simple, elegant language from the Lisp family, known for its power and minimalism. But Netscape leadership had a different idea. They wanted a language that looked a bit like Java (which was very popular at the time), but was much easier to use, especially for beginners.

Eich was given just 10 days to create a working version.

In that short time, he:

Took Java's familiar curly-brace syntax to make it look approachable.
Borrowed dynamic features from Scheme — like treating functions as values.
Used an idea called prototypes (from a language called Self) instead of traditional classes for objects — making it more flexible.
Delivered the first version of the language, initially called Mocha, then LiveScript, and finally… JavaScript.

Yes — JavaScript was created in just 10 days.

"It had to be done fast. We knew it wasn't perfect, but it worked."
— Brendan Eich

Why JavaScript? Why Not Java or C++?

Netscape already supported Java Applets — but they were:

Slow to load
Required a separate runtime
Not integrated with the DOM
Too heavy for quick scripting

C++ was out of the question:

Compiled, not interpreted
Unsafe for user-facing environments
Not beginner-friendly

JavaScript, on the other hand, was:

Lightweight
Interpreted by the browser
Safe (sandboxed)
Forgiving and flexible

JavaScript wasn't designed to be perfect — it was designed to be accessible.

Why the Name "JavaScript"?

Initially called Mocha, then LiveScript, the name was changed to JavaScript as a marketing stunt.

At the time, Java was exploding in popularity, and Netscape wanted to ride the hype.

Even though Java and JavaScript are completely different, the name stuck — and confused generations of developers in the process.

Java is to JavaScript as car is to carpet.

JavaScript's DNA: Born of Necessity, Built for the Web

Brendan Eich didn't just create a language — he gave it a unique personality, shaped by the needs of the early web. From day one, JavaScript was built around three big ideas:

Functions Are First-Class In JavaScript, functions aren't just instructions — they're values. You can store them in variables, pass them around, and return them from other functions. This makes JavaScript incredibly flexible and enables things like callbacks and closures.
Objects Use Prototypes, Not Classes Instead of using classes like Java or C++, JavaScript lets objects inherit directly from other objects — a model called prototypal inheritance. It's simpler under the hood and makes the language more dynamic (even if a bit confusing at first).
It's Built for the Browser JavaScript is event-driven — meaning it reacts to things like clicks, scrolls, or keystrokes. This made it perfect for interactive web pages that respond to user actions without reloading.

It wasn't perfect. It wasn't polished. But it was exactly what the web needed — and that made it revolutionary.

A New Era Begins

In the months following its release:

JavaScript shipped with Netscape Navigator 2.0 in 1995.
Microsoft quickly created its own version, called JScript, for Internet Explorer.
This kicked off the infamous browser wars, where different browsers implemented JavaScript in conflicting ways.

The web was chaotic, and JavaScript's early days were rough — full of bugs, inconsistencies, and developer frustration.

But against all odds, JavaScript survived. And over time, it evolved to become the most important language of the web.

The fact that JavaScript even survived is a story worth telling on its own — full of twists, rivalries, and redemption. We'll explore that journey in the next episode: Episode 2 – "Why JavaScript Survived: Wars, Standards, and Second Chances"

Closing Thought

The first version of JavaScript may have been written in just 10 days — but its impact has lasted decades.

It wasn't built to be perfect. It was built to bring the web to life — and it did exactly that.

Up Next:

Episode 2: "Why JavaScript Survived: Wars, Standards, and Second Chances"

In the next episode, we'll explore how JavaScript almost collapsed under its own success — and how a community, a standards body, and a few smart bets helped it rise again.

Thank You

Thanks for reading Episode 1 of our series - Unpacking JavaScript: 10 Days That Changed the Internet.

If something sparked a thought, raised a question, or just made you curious — drop a comment below. I’d love to hear your take, continue the conversation, or geek out with fellow JavaScript lovers.

If you found this helpful, a like or share would mean a lot — it helps get the story to more curious developers like you.

Let’s connect:

GitHub
LinkedIn
X/Twitter

MCQ: Strengthen Your Understanding

Questions

1. Who created JavaScript, and how long did it take?
A. Douglas Crockford – 3 weeks
B. Brendan Eich – 10 days
C. Tim Berners-Lee – 1 month
D. Marc Andreessen – 5 days

2. What was JavaScript's inheritance model inspired by?
A. Java
B. Python
C. Self language
D. Ruby

3. What triggered the browser wars in the 1990s?
A. Competing programming languages
B. Poor documentation
C. Conflicting JavaScript implementations in browsers
D. JavaScript being too slow

Answers

B. Brendan Eich – 10 days
C. Self language
C. Conflicting JavaScript implementations in browsers

Why HTML Exists—And What Most Developers Miss

Md Umar Siddique — Thu, 08 May 2025 02:30:00 +0000

I’ve witnessed many people treat HTML as just a content container, but that’s only one part of what HTML is really about. I used to think of it that way myself—though not entirely—when I built my Tic Tac Toe game (the repository has been made private for now)

I used a <div> element for clicking to get X or O instead of a <button> element. It worked fine—the app ran without issues—but when it comes to accessibility, things look different.

When people with disabilities try to use my app with a screen reader, it doesn't work. The screen reader skips those 9 <div> elements because they contain no text and no ARIA labels.
When users try to navigate using the keyboard, they can't. That's because <div> elements—like many HTML elements—are not part of the default tab order. They aren't focusable with the Tab key. To make them keyboard-accessible, you must add the attribute tabindex="0".

This small Tic Tac Toe example—a drop in the vast ocean of HTML—shows us that HTML is far more than just a content wrapper.

The purpose of this article is to give you a broad overview of HTML, so you can include all essential features in your web pages. For example: for better search visibility—SEO, for accessibility—ARIA labels, and more.

At the end of this article, you’ll find 5 quizzes designed to strengthen your understanding of HTML’s true purpose. Each quiz comes with detailed solutions and explanations to deepen your insight.

I’ve also added a “Things to Keep in Mind” section—your quick guide to remembering what truly matters when writing clean, semantic, and accessible HTML.

Let's dive in!

What is HTML?
Why Does HTML Exist?
HTML Exists to Make the Web Meaningful—But For Whom?
3.1 For Humans (Web Users)
3.2 For Machines (Browsers, Search Engines, etc.)
How HTML Makes the Web Meaningful
4.1 For Humans (Web Users)
4.2 For Machines (Browsers, Search Engines, etc.)
Why You Shouldn’t Treat HTML as Just a Content Container (The Real Reason Behind the Existence of HTML)
Common Misconceptions
Things to keep in mind
REACAP
HTML Quiz: Test your understanding of HTML
WRAP UP
Solutions

What is HTML?

HTML stands for HyperText Markup Language. It's the standard language used to create and structure content on the web. HTML isn't a programming language but a markup language used to define elements like headings, paragraphs, images, links, and more.

Key Points:

Structure: HTML builds the structure of a webpage using tags like <h1>, <p>, <a>, and others.
HyperText: Allows linking to other documents or different parts of the same document via hyperlinks (<a href="URL">).
Markup: Means wrapping content in tags to give it structure and meaning—like bold text, lists, images, and so on.

Basic Example of HTML:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Simple HTML Page</title>
  </head>
  <body>
    <h1>Welcome to My Website</h1>
    <p>This is a paragraph of text.</p>
    <a href="https://www.example.com">Click here to visit Example</a>
  </body>
</html>

Breakdown:

<html>: Root element of the web page.
<head>: Contains metadata like title, character encoding, etc.
<body>: Holds the visible content like headings, text, and links.
<h1>: Indicates the main heading.
<p>: Represents a paragraph.
<a>: Defines a hyperlink.

Why Does HTML Exist?

The Core Reason:

HTML (HyperText Markup Language) exists to structure content on the web. It forms the skeleton of every webpage, telling browsers what to display and how different elements relate to one another.

The Origin Story:

In the early '90s, Sir Tim Berners-Lee (the inventor of the web) needed a way to share and connect scientific documents across computers. He created HTML as a simple markup language to:

Add headings, paragraphs, lists, etc.
Link documents through hypertext (hence the name).

What HTML Does:

Structures text, media, and interactive components.
Uses semantic tags (<article>, <nav>, <footer>, etc.) to add meaning.
Works with CSS for styling and JavaScript for behavior.
Enables accessibility and searchability.

Without HTML:

Browsers wouldn't know how to display content.
The web would be plain, unreadable text.
There would be no websites, just scattered, unstructured data.

So, simply put: HTML makes the web usable, organized, and meaningful. Without it, the internet as we know it wouldn't exist—it'd be like reading a book with no chapters, no titles, and no structure.

When you dig deeper, you'll see that HTML's real purpose is to make the web meaningful. But for whom? And how? Let's move on.

HTML Exists to Make the Web Meaningful—But For Whom?

1. For Humans (Web Users):

HTML helps present content in a way that's easy to read and navigate, improving user experience. A well-structured page helps users locate and understand information effortlessly.

For developers (like you!), HTML's clear layout makes it easier to read and maintain the code.

It uses intuitive text-based tags, simplifying development.
The layout resembles plain text, making it easy to update or fix.

Here's an example:

<h1>Welcome to My Website</h1>
<p>This is a paragraph of text explaining what the website is about.</p>
<a href="https://example.com">Click here to learn more</a>

Even if you're new to coding, you can tell what each element means—it's human-readable.

2. For Machines (Browsers, Search Engines, etc.):

When we say HTML is machine-readable, we mean that browsers, search engines, and assistive technologies can interpret its structure and content without needing a visual layout.

Structure and Rendering:

Browsers read HTML to determine how to render and structure content. For instance, headings appear large, paragraphs are spaced, and lists are styled appropriately. HTML also helps search engines identify key content areas.

Example:

<h1>SEO Best Practices</h1>
<p>Learn how to improve your website's ranking on search engines.</p>
<h2>Why SEO Matters</h2>
<p>SEO helps increase visibility and drive traffic to your website.</p>

<h1> signals the main heading.
<h2> introduces a subheading under the main topic.

Search engines prioritize content inside <h1>, improving visibility and ranking.

Accessibility and Indexing:

HTML tags like <alt> for images and semantic tags like <header>, <footer>, and <article> help both screen readers and search engines interpret the content.

Example:

<img src="logo.png" alt="Company Logo">

The alt attribute gives visually impaired users context and helps search engines with image indexing.

Semantic Tag Example:

<article>
  <h2>Blog Post Title</h2>
  <p>This is a blog post about web development and HTML.</p>
</article>

The <article> tag identifies a standalone piece of content, helping search engines categorize it.

Why Both Matter:

For humans, HTML structures content to make websites easy to read, navigate, and use.
For machines, HTML defines content structure so browsers can render it, and search engines can index it. It also enables accessibility via screen readers.

This dual role—human-readable and machine-readable—makes HTML the backbone of the modern web.

How HTML Makes the Web Meaningful

1. For Humans (Web Users):

How does HTML help people interact with and understand web content?

Clear Structure: HTML organizes content into sections, headings, and links, making it easy to read and explore. Users can find what they need more quickly.
Example: A well-structured page lets users easily browse "About Us," "Services," or "Contact" via headings (<h1>, <h2>) and links (<a>), improving usability.
Interactivity: HTML allows interactive elements like forms and buttons that respond to user input. These features provide a more engaging experience.
Example: A contact form or a search bar helps users interact with the site based on their needs.

<form action="/submit">
  <label for="email">Email:</label>
  <input type="email" id="email" name="email">
  <button type="submit">Submit</button>
</form>

Accessibility: HTML supports features like alt text, keyboard navigation, and ARIA labels, making the web inclusive and usable for people with disabilities.
Example: Adding an alt attribute to an image ensures screen readers can describe it to users.

<img src="logo.png" alt="Company Logo">

2. For Machines (Browsers, Search Engines, etc.):

HTML isn't just for human eyes. It plays a critical role in helping machines understand, process, and present web content accurately. This enables browsers to render pages, search engines to index content, screen readers to describe interfaces to users with disabilities, and more.

1. Accessibility (a11y)

HTML allows assistive technologies—like screen readers—to interpret content and interactions for users with disabilities. Without proper markup, these users would be left out.

1.1 ARIA (Accessible Rich Internet Applications) Attributes

ARIA attributes help bridge gaps where native HTML elements don't provide enough semantic meaning.
Examples include aria-label, aria-hidden, aria-live, aria-expanded, etc.

<button aria-label="Close menu">✖</button>

aria-label gives a custom name to elements.
aria-hidden="true" hides elements from screen readers.
aria-live="polite" announces dynamic content changes.

Note: Use ARIA only when semantic HTML doesn't suffice—native elements are preferred for accessibility.

1.2 Proper Labeling with `<label>` and Form Controls

Associating <label> elements with <input>, <select>, and <textarea> makes forms understandable to screen readers.

<label for="email">Email address:</label>
<input type="email" id="email" name="email">

1.3 Alt Text for Images

The alt attribute describes images for screen reader users and improves SEO.

<img src="team.jpg" alt="Team photo at the annual meeting">

1.4 Keyboard Navigation Support

HTML supports tabbing through interactive elements like <button>, <a>, and form fields.
Custom interactive components must handle keyboard events like Enter and Space.

2. Semantics

Semantic HTML tells machines the meaning of content—not just how it looks. It helps browsers render pages properly, and lets search engines and screen readers understand the structure.

2.1 Meaningful Tags Instead of Generic Containers

Using elements like <article>, <section>, <nav>, <aside>, and <footer> creates a logical page outline.

<article>
  <h2>How to Start a Blog</h2>
  <p>Here are the first steps to creating your own blog...</p>
</article>

2.2 Headings Hierarchy (`<h1>` to `<h6>`)

Headings define document structure and help both machines and users scan content.

<h1>Main Topic</h1>
  <h2>Sub-topic</h2>
    <h3>Detail</h3>

Screen readers often use headings to build a navigation list for users.

2.3 Landmark Roles (Built-in with Semantic Tags)

These define page regions:

<header>, <main>, <nav>, <footer>, <aside>—all act as landmarks for assistive tech and SEO bots.

3. SEO (Search Engine Optimization)

Search engines use HTML to index, understand, and rank web pages. Clean, semantic, and well-structured HTML helps content rank better.

3.1 Title and Meta Tags

The <title> tag and <meta> tags (especially description) help search engines summarize your page in search results.

<title>Top SEO Tips for 2025</title>
<meta name="description" content="Boost your website's visibility with these essential SEO strategies.">

3.2 Proper Use of Headings

Search engines use headings to understand topic relevance. Misusing <h1> for visual design (instead of structure) can confuse crawlers.

3.3 Alt Text and Image Indexing

Images with alt attributes can show up in Google Image Search and improve overall page relevance.

3.4 Anchor Text and Links (`<a>`)

Search engines analyze the text inside links to understand what the linked page is about.

<a href="/seo-guide">Read our complete SEO guide</a>

3.5 Structured Data (Microdata, JSON-LD)

Though not part of standard HTML tags, embedding structured data improves how content appears in search (e.g., rich snippets, FAQs, star ratings).

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Top SEO Tips for 2025"
}
</script>

4. Performance and Rendering

HTML also informs how browsers parse and render pages efficiently, impacting speed and user experience.

4.1 Efficient Markup

Avoid deeply nested or redundant elements. Clean, minimal HTML speeds up parsing and rendering.

4.2 Lazy Loading with loading="lazy"

HTML now supports native lazy loading for images and iframes.

<img src="large-image.jpg" loading="lazy" alt="Nature view">

4.3 Defer/Async Script Tags

Though technically JavaScript-related, the way HTML links to scripts impacts performance.

<script src="script.js" defer></script>

4.4 Media Queries and Responsive Tags

HTML works with CSS for responsive rendering, but HTML elements like <picture> and <source> improve image loading and device optimization.

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg">
  <img src="small.jpg" alt="Product photo">
</picture>

5. Security

While HTML alone isn't responsible for full security, correct HTML practices can prevent common vulnerabilities and help browsers enforce safer behavior.

5.1 Content Security Policy (CSP) with `<meta>` Tags

CSP is a browser feature that helps prevent cross-site scripting (XSS) attacks by controlling which resources the browser is allowed to load.

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://trusted.cdn.com">

5.2 Form Input Validation

Using proper HTML attributes like type, required, pattern, and maxlength helps filter out bad input before it hits the server.

<input type="email" required maxlength="50">

5.3 Avoiding Inline JavaScript

Avoid using onclick, onload, and other inline event handlers, which are prone to injection attacks. Use external JavaScript with defer instead.

<!-- Less secure -->
<button onclick="alert('Hi')">Click</button>

<!-- More secure -->
<button id="greetBtn">Click</button>
<script defer src="script.js"></script>

5.4 Sandboxing with `<iframe>`

The sandbox attribute restricts iframe behavior, preventing it from running scripts or accessing cookies.

<iframe src="https://example.com" sandbox></iframe>

5.5 Autocomplete Off for Sensitive Fields

To protect user data (e.g., passwords or credit card info), use autocomplete="off".

<input type="password" autocomplete="off">

Conclusion: Machines Rely on Meaningful HTML

HTML isn't just about displaying content. It is the language that tells machines what content means, how to present it, and how to support all users. A well-coded page:

Is accessible to screen readers and users with disabilities
Provides clear structure via semantics
Boosts SEO visibility
Enables faster, optimized performance in browsers

When you write HTML with machines in mind, you make the web better for everyone.

Why You Shouldn’t Treat HTML as Just a Content Container (The Real Reason Behind the Existence of HTML)

Many developers—especially beginners—see HTML as nothing more than a way to put text and images on a screen. But that's a massive underestimation. HTML is the bedrock of the modern web—not just for visual design, but for usability, discoverability, performance, and even security.

1. Accessibility: It's for Everyone, Not Just the Visually Able

HTML provides built-in ways to make content usable by people with disabilities. Using the right semantic tags (like <button> instead of <div>) ensures that screen readers can announce content and actions. Skip those, and you're silently excluding users who rely on assistive technologies.

Use correct tags like <label> and <input> for forms
Add alt text for images
Apply ARIA roles only when semantic HTML isn't enough
Ensure keyboard navigation via tabindex and native focusable elements

Don't just build for eyes—build for everyone.

2. SEO: HTML Tells Search Engines What Matters

Google doesn't "see" your site—it reads it. Without proper headings, semantic structure, or alt text, search engines may miss your content entirely. Clean, semantic HTML helps bots understand what your site is about and rank it accordingly.

Use <title> and <meta name="description">
Structure content with <h1> to <h6>
Add meaningful anchor text and internal links
Describe images for better indexing

If it's not visible to search engines, it's invisible to users.

3. Performance: HTML Affects Load Time and Efficiency

HTML impacts how browsers load and render pages. Bloated, messy markup slows things down. But clean, minimal HTML helps browsers parse faster and reduces page weight.

Avoid unnecessary <div>s
Use semantic tags for structure
Use lazy-loading for images (loading="lazy")
Defer non-essential scripts with <script defer>

Faster HTML = faster pages = happier users.

4. Security: HTML Helps Prevent Vulnerabilities

While most security issues relate to backend or JavaScript code, HTML plays a role in defense too. Using correct attributes and avoiding bad practices can protect users and your site.

Use autocomplete="off" for sensitive input fields
Sanitize inputs using proper <input> attributes (type, maxlength, pattern)
Add a Content Security Policy (CSP) with <meta> tags
Avoid inline JavaScript like onclick="..."

Bad HTML can open doors to bad actors.

5. Semantics and Machine Readability: It's Not Just for You

Using <section>, <article>, <nav>, and other semantic elements gives machines context. Screen readers, search engines, and even AI tools rely on this structure to process content correctly.

Use semantic tags for logical structure
Maintain heading hierarchy
Identify roles with ARIA only when needed
Label interactive elements meaningfully

HTML tells machines what your content means, not just what it looks like.

6. Maintainability and Scalability: Future-Proof Your Code

Readable, semantic HTML is easier to update, debug, and scale. Generic containers like <div> give no context to you or other developers.

Semantic tags reduce documentation and guesswork
Good structure supports clean CSS and JS integration
Accessible markup avoids technical debt and rewrites

Future you (or your team) will thank you.

Final Word: HTML Is Not Just About Content

HTML is the language of meaning on the web. Ignoring its features is like writing a book with no punctuation, no chapters, and no paragraphs. The words may be there, but no one can make sense of them—human or machine.

So the next time you write a <div> where a <button> belongs, pause and think:

Am I using HTML to its full potential—or just placing content on a screen?

Common Misconceptions

Misconception 1: "HTML is just for visual structure"

Reality: HTML provides semantic meaning that impacts accessibility, SEO, and user experience.

Misconception 2: "Any tag will work as long as it looks right with CSS"

Reality: Using incorrect tags breaks accessibility and harms SEO, even if visually identical.

Misconception 3: "Div is the default container for everything"

Reality: Divs should be used only when no semantic element is appropriate.

Misconception 4: "HTML is the easiest part of web development"

Reality: Writing proper, semantic HTML requires deep understanding and careful consideration.

Misconception 5: "Nobody looks at the HTML anyway"

Reality: Screen readers, search engines, and other machines analyze your HTML constantly.

Things to keep in mind

Start with Semantics: Choose the most appropriate HTML element for the content's meaning, not its appearance.
Prioritize Accessibility: Ensure your site works for everyone by following WCAG guidelines and testing with screen readers.
Maintain Clean Structure: Use a logical hierarchy of elements with proper nesting and organization.
Optimize for Performance: Keep HTML lean and efficient, avoiding unnecessary elements and attributes.
Test Across Devices: Ensure your HTML works on different browsers, screen sizes, and assistive technologies.
Keep Security in Mind: Follow security best practices in forms, links, and embedded content.
Use Validation Tools: Regularly check your HTML with validators to catch errors and improve quality.
Stay Updated: Follow evolving HTML standards and implement new semantic elements as they become available.

REACAP

HTML is often underestimated as merely a tool for displaying content, but it's the foundation of a meaningful and accessible web. Beyond its role in structuring text and images, HTML plays a vital part in accessibility, SEO, performance, and security.

The article explores the true value of HTML, emphasizing its dual role for both humans and machines. For users, HTML enhances readability, navigation, and interactivity while ensuring inclusivity for those with disabilities. For machines, it provides structure for search engines, browsers, and assistive technologies to interpret and render content correctly.

Key points include:

Accessibility: HTML ensures content is usable by all, especially those relying on screen readers and keyboard navigation.
SEO: Semantic HTML improves visibility and ranking in search engines by providing clear structure and descriptive content.
Performance: Clean, efficient HTML reduces page load time, improving user experience.
Security: HTML helps mitigate common vulnerabilities by using proper attributes and forms.
Semantics and Machine Readability: Properly structured HTML makes content understandable to both humans and machines.
Maintainability: Well-written HTML ensures the scalability and ease of future updates.

Ultimately, HTML is much more than a simple content container. It is the backbone of the web, ensuring that content is accessible, understandable, and usable by everyone. Treating HTML with its full potential leads to a better, more inclusive web.

HTML Quiz: Test your understanding of HTML

Test your understanding of HTML's true purpose with these 5 mind-binding questions covering accessibility, SEO, performance, security, and semantics.

Questions

ACCESSIBILITY CHALLENGE:

In a Tic-Tac-Toe game, you need 9 clickable squares. Which implementation would create the most serious accessibility issues and why?
- A) Nine <button> elements with aria-label attributes
- B) Nine <div> elements with tabindex="0" and role="button"
- C) Nine <div> elements with onclick handlers but no accessibility enhancements
- D) Nine <a> elements with href="#" and appropriate aria-label attributes
SEO PUZZLE:

A website has perfect content but is invisible to search engines. What HTML structure issue below would cause the MOST damage to its search ranking?
- A) Using multiple <h1> tags throughout the page
- B) Having all page content inside <div> tags with no semantic structure
- C) Missing alt text on decorative images
- D) Using <b> instead of <strong> for emphasis
PERFORMANCE RIDDLE:

Four developers implement the same image gallery. Whose implementation would likely perform the best on mobile devices?
- A) Developer A uses 20 high-res images with width and height attributes
- B) Developer B uses 20 high-res images with CSS to resize them smaller
- C) Developer C uses 20 high-res images with loading="lazy" and the <picture> element with multiple sources
- D) Developer D uses 20 divs with background-image CSS properties
SECURITY CONUNDRUM:

Which HTML implementation creates the biggest security vulnerability?
- A) A form with <input type="password"> without autocomplete="off"
- B) An iframe without the sandbox attribute
- C) A button with an inline onclick="eval(location.hash.substring(1))" attribute
- D) A form that uses GET instead of POST for submission
SEMANTICS MYSTERY:

A screen reader user complains they can't find the main content on your page. All content displays visually, but which HTML issue below is most likely causing this problem?
- A) Using CSS display:none on some elements
- B) Not using the <main> element or role="main" anywhere on the page
- C) Having all page content in a single <div> with no semantic structure
- D) Using ARIA labels inconsistently

WRAP UP

Thank you for taking the time to read this deep dive into the true purpose of HTML! I hope this article has changed how you think about HTML and its importance in web development.

If you found this content valuable, please consider:

Sharing it with fellow developers who might still be treating HTML as "just divs"
Implementing these principles in your next project
Auditing your existing websites for accessibility and semantic structure
Following me for more web development insights and best practices

Remember, each time you choose a semantic element over a generic div, you're making the web a better place for everyone. Your HTML choices matter!

Happy coding, and here's to building a more accessible, performant, and meaningful web together.

- MD UMAR SIDDIQUE

P.S. Have questions or want to share how you've improved your HTML practices? Drop a comment below or reach out to me directly. I'd love to hear your thoughts!

Let's connect:

GitHub
LinkedIn
X/Twitter

Solutions

ACCESSIBILITY CHALLENGE: Answer: C) Nine <div> elements with onclick handlers but no accessibility enhancements

Explanation: This is the most problematic implementation because:

<div> elements are not inherently focusable, so keyboard users can't navigate to them without tabindex
Without ARIA roles or labels, screen readers won't recognize these elements as interactive
Onclick handlers alone don't provide any accessibility information
This matches the Tic-Tac-Toe example in the article where using divs instead of buttons created accessibility barriers

SEO PUZZLE: Answer: B) Having all page content inside <div> tags with no semantic structure

Explanation: Search engines rely heavily on semantic HTML to understand content hierarchy and importance. Without semantic tags like <h1>, <article>, <section>, etc., search engines struggle to determine:

What the main topic is
How content is organized and related
Which content is most important
What the page is actually about

This makes it nearly impossible for search engines to properly index and rank the page, essentially making it "invisible" despite having good content.

PERFORMANCE RIDDLE: Answer: C) Developer C uses 20 high-res images with loading="lazy" and the <picture> element with multiple sources

Explanation: This implementation offers several performance advantages:

loading="lazy" defers loading of off-screen images until they're needed
The <picture> element with multiple sources allows the browser to choose the most appropriate image size based on device characteristics
This approach reduces initial page load time and data consumption, particularly important on mobile devices
It delivers appropriately sized images to different devices, avoiding the performance penalty of loading oversized images on small screens

SECURITY CONUNDRUM: Answer: C) A button with an inline onclick="eval(location.hash.substring(1))" attribute

Explanation: This is extremely dangerous because:

It uses eval(), which executes arbitrary JavaScript code
It pulls that code from the URL hash, allowing attackers to execute any JavaScript by crafting a malicious URL
This is a textbook example of an XSS (Cross-Site Scripting) vulnerability
It bypasses Content Security Policy and could lead to complete compromise of user data

SEMANTICS MYSTERY: Answer: C) Having all page content in a single <div> with no semantic structure

Explanation: Screen readers rely on semantic structure to create a navigable overview of page content:

Without semantic elements like <main>, <nav>, <article>, etc., screen readers can't create a document outline
Screen reader users often navigate by semantic landmarks to quickly jump to main content
A page with just divs offers no meaningful navigation structure for assistive technology
This forces screen reader users to navigate through the entire document linearly, making it difficult to find the main content

Why Isn't Your CSS Working? Common Pitfalls and Best Practices

Md Umar Siddique — Thu, 24 Apr 2025 04:00:00 +0000

You know Cascading and Specificity, you write styles accordingly—yet your styles still don’t apply as expected? The issue may not lie in how these concepts work, but in some common pitfalls you might be falling into, knowingly or not.

This article aims to solidify your understanding beyond just theory, showing how these mistakes affect not only CSS, but also frameworks and libraries like React, vue and even vanilla JavaScript.

To help you apply what you've learned, I’ve included 5 real-world quiz scenarios that will deepen your understanding and sharpen your debugging instincts.

This is Part 3 of our “Why Isn’t Your CSS Working?” series. As mentioned in the earlier articles, learning Specificity first makes Cascading easier to grasp—which is why we tackled them in that order. We didn’t stop at theory: we used real examples, DevTools, case studies and investigative studies to connect the dots.

So if you're already comfortable with these two core forces of CSS, you're ready for what’s next.

If not, I highly recommend revisiting:

Because what comes next builds on that foundation—and dives into best practices and common pitfalls that trip up even experienced developers.

Assuming you’ve got those covered—let’s dive in.

A Top-Down Look at Common Pitfalls That Break Your CSS
Using too many ID selectors
Relying on deeply nested selectors
Overusing !important
Forgetting about the cascade
From Messy to Maintainable: Mastering Specificity, Structure & Scalable CSS
Bottom Line
Quick Quiz: What's the Problem & How Would You Fix It?
Wrap up
Solutions – Let's Debug Together

A Top-Down Look at Common Pitfalls That Break Your CSS

Before we get hands-on, let’s take a step back and look at some of the most common CSS mistakes that can cause major headaches in real-world projects:

Using too many ID selectors – IDs are powerful but rigid. Classes are more flexible and reusable.
Relying on deeply nested selectors – The deeper the selector, the harder it becomes to override styles cleanly.
Overusing !important – It might feel like a quick fix, but it often turns debugging into a nightmare.
Forgetting about the cascade – Always check if another rule later in the stylesheet is silently overriding your styles.

Each of these mistakes connects directly to what we’ve already covered about specificity and cascading. So let’s break them down one by one and understand the best practices to avoid them.

1. Using too many ID selectors

Using too many id selectors will technically work. IDs are unique and valid selectors. The browser doesn’t explode. 😅

But... here’s the catch:

Using too many id selectors becomes a maintenance nightmare, and can seriously mess with:

1. CSS Specificity Wars

ID selectors are very high in specificity.

Selector Type	Specificity Score
Element	`0-0-1`
Class	`0-1-0`
ID	`1-0-0`

So if you style with:

#myBtn {
  background-color: red;
}

And later try:

.btn {
  background-color: green;
}

The green won’t apply, unless you do:

button#myBtn.btn {
  background-color: green !important;
}

Now you’ve entered the !important vortex of doom💀.

2. Hard to Reuse Styles

IDs are unique, so you can't reuse their styles across multiple components or elements. You’d have to duplicate styles or write new rules for each ID — anti-DRY (Don’t Repeat Yourself).

3. Conflicts in JavaScript & React

In React (and modern JavaScript), you rarely need to use ids. Since:

IDs must be unique — hard to guarantee in component-based systems.
It can break modularity and component isolation.
You're better off using:
- refs
- data-* attributes

when targeting elements programmatically.

Best Practices

DO	AVOID
Use classes for styling	Relying on too many IDs
Use `id` for anchor links (`#`)	Using IDs for layout styling
Use `ref`s in React, not `id`s	Targeting IDs in deep CSS
Use BEM or module CSS for scoping	Overwriting IDs with `!important`

Use `id` for:

Navigation targets (<a href="#contact">)
ARIA accessibility (aria-labelledby="#some-id")
Unique inputs for labels (<label for="email">)

TL;DR:

Too many ID selectors? Technically fine. Practically painful.

Prefer class, data-*, or ref for flexibility, reusability, and maintainability.

Pro Tip: Think of id as a one-time-use sticky note.

But class? That’s your favorite reusable label-maker.

2. Relying on deeply nested selectors

Relying too much on deeply nested selectors in CSS is like trying to find your socks in a Russian nesting doll. It might work, but it’s a pain to maintain.

Example of Deep Nesting

.wrapper .main-content .article .content-block .paragraph .link {
  color: blue;
}

Looks scary? It is

Problems with Deep Nesting

1. Fragile CSS

If the HTML structure changes even slightly, your styles break.

   <div class="article">
   - <div class="content-block">
   + <section class="content-block"> <!-- Boom, broken -->

Now your styles don’t apply anymore.

2. Poor Reusability

You can't reuse .link styles outside of that exact hierarchy.

Your CSS becomes tightly coupled to the HTML structure.

3. Specificity Gets Out of Control

The more you nest, the harder it is to override.

   /* Good luck overriding this without !important or deep selectors */
   .wrapper .main-content .article .content-block .paragraph .link {
     color: red;
   }

4. Hard to Read & Maintain

Future-you (or your teammates) won’t thank you when they have to unravel spaghetti CSS.

Best Practices

1. Keep selectors shallow:

  .link {
    color: blue;
  }

2. Use meaningful class names:

  .article-link {
    color: blue;
  }

3. Use BEM or CSS Modules if you're in React:

  .article__link {
    color: blue;
  }

  // CSS Modules (React)
  styles.link

TL;DR:

Deep nesting = CSS quicksand.

Avoid it when possible.

Stick to shallow, reusable, and intentional selectors — and your future self will high-five you 👏.

3. Overusing `!important`

Now let's talk about !important — the most powerful and most abused tool in CSS.

What happens when you use `!important`?

It forces a style to override anything else — regardless of specificity.

#someId {
  color: red !important;
}

This will beat:

Classes
Inline styles (unless they also use !important)
Even other ID styles without !important

So… it works. But here’s why it’s dangerous:

1. You break the CSS cascade

CSS is supposed to flow from general → specific → contextual → override.

!important skips the line like a VIP with no chill.

2. It's hard to debug

You or your team might spend hours yelling at your screen like:

“WHY THE HELL ISN’T THIS STYLE APPLYING???”

...only to realize another rule has !important.

3. You create a war of `!important` escalation

To override this:

   .button {
     background: red !important;
   }

Now someone else writes:

   .page .button {
     background: blue !important;
   }

Then you go:

   html body .page .button {
     background: green !important;
   }

Until everything is a specificity monster. 💀

When is `!important` okay?

Good Use Cases	Bad Use Cases
Utility classes (e.g., Tailwind)	Fixing bugs you don’t understand
Print styles that must override	Overriding your own styles constantly
External libs you can't control	Using it as a lazy bandaid

Best Practices

Use !important sparingly — like hot sauce 🌶️: just a dash, or it ruins the whole dish.
Fix the specificity hierarchy instead.
Use CSS modules, BEM, or scoped styles in React.
If you're always reaching for !important, your CSS architecture needs a rethink.

TL;DR:

!important is like yelling in CSS — it works, but if everyone starts yelling, it becomes chaos.

Use it rarely. Fix specificity issues instead. Your future self will thank you.

4. Forgetting about the cascade

Forgetting the cascade in CSS is like baking a cake and forgetting it needs layers — it might look okay at first, but then everything collapses into a confusing mess. Let's break this down real smooth.

First: What is the Cascade?

The "C" in CSS — it decides which styles win when multiple rules apply.

It’s based on:

Source order (last rule wins)
Specificity
Importance (!important)
Origin (inline, internal, external)

What Happens If You Ignore It?

1. Confusing Conflicts

You're like: "Why isn't my style working??"

But CSS is like: "Because that earlier, more specific rule beat yours!"

/* Defined early */
.card h2 {
  color: red;
}

/* Later but less specific */
h2 {
  color: blue;
}

Result? color: red; still wins.

2. You Start Using !important Everywhere

When you're like:

.button {
  background: green !important;
}

...just to "force" styles to apply. But then the next thing needs !important too. It's a slippery slope.

3. CSS Becomes Unpredictable

Without knowing what overrides what, you end up playing a guessing game instead of writing clean styles.

How to Work With the Cascade

Order Matters

Later rules override earlier ones if specificity is the same.

h1 {
  color: blue;
}

h1 {
  color: red; /* this one wins */
}

Use Class Selectors Over Tags

/* Better than styling all <p> elements */
.card-text {
  color: #333;
}

Keep Specificity Low When You Can

Avoid long chains like:

.main .container .card .title {
  font-size: 2rem;
}

Use classes directly:

.card-title {
  font-size: 2rem;
}

Best Practices

Bad Practice	Better Practice
Ignoring order	Write styles in order of importance
Overusing `!important`	Use proper specificity
Nesting like crazy	Use flat, reusable classes

TL;DR:

"CSS isn’t broken — you just forgot the rules of the game."

– Every DevTools Console Ever

Understand the cascade: it's the foundation of clean, predictable CSS

Favor class selectors over deep, rigid chains

Respect the order of your stylesheets

Use !important only when truly necessary

Write CSS like you're handing it off to a tired future-you

From Messy to Maintainable: Mastering Specificity, Structure & Scalable CSS

Now let's dive deep AF into these core CSS practices that separate juniors from pros — whether you’re working in vanilla HTML/CSS/JS or a framework like React, Vue, Angular, Svelte, or even with Tailwind / SCSS / Styled Components.

Keep Specificity Low with Class-Based Styling

Why?

Lower specificity = easier to override styles, fewer !important wars.

Bad:

#form .button.primary {
  background-color: red;
}

High specificity
Hard to override
Tightly coupled to DOM structure

Good:

.btn-primary {
  background-color: red;
}

Reusable anywhere
Easy to override later with just .btn-primary
Easier to scale in teams

In Frameworks (React/Vue/etc.)

Component structure = already scoped

// React + CSS Modules
<button className={styles.btnPrimary}>Click Me</button>

/* CSS */
.btnPrimary {
  background-color: red;
}

Or:

<!-- Vue Single File Component -->
<template>
  <button class="btn-primary">Click Me</button>
</template>

<style scoped>
.btn-primary {
  background-color: red;
}
</style>

Keep classes flat & consistent — don't nest selectors unless truly needed.

Use a Consistent Naming Convention like BEM

Why?

BEM (Block Element Modifier) = modular, clear, predictable.

Structure:

.block {}         
.block__element {}
.block--modifier {}

Example:

.card {}
.card__title {}
.card__title--large {}

<div class="card">
  <h2 class="card__title card__title--large">Title</h2>
</div>

In React, this helps avoid naming conflicts when using global CSS.

In Vanilla JS:

No magic here — you manually assign classes:

document.querySelector('.card__title').classList.add('card__title--large');

In React:

If using BEM with CSS Modules:

<div className={`${styles.card} ${styles['card--highlight']}`}></div>

But with Tailwind, you skip BEM (class utilities win here):

<div className="bg-white p-4 shadow rounded-lg"></div>

Keep Styles Modular

What does modular mean?

Scoped to 1 component, not global.

Bad:

/* Global styles.css */
h2 {
  font-weight: bold;
}

Might affect all h2s on the site
Easy to cause accidental style leaks
Exception: However, if you're targeting all h2s in your app then it's fine to use it.

Good:

/* UserProfile.module.css */
.user__title {
  font-weight: bold;
}

Only affects UserProfile component
Safe to reuse h2 elsewhere

Frameworks Do This Better

React: Use CSS Modules, Styled Components, or Tailwind
Vue: Use <style scoped>
Angular: Each component has its own .scss/.css
Svelte: Styles are scoped by default

Debug Specificity Issues with DevTools

How to Inspect:

Right-click > Inspect Element
Go to "Computed" tab
See which rule applied, and which got overridden (crossed out)

Example:

.button {
  color: blue;
}

#main .button.primary {
  color: red;
}

In DevTools, you’ll see:

color: blue; crossed out
color: red; applied

Learn to use this to:

Find why your styles aren’t applying
Identify where you need to reduce specificity
Avoid using !important unless absolutely necessary

TL;DR Dev Wisdom

Anti-Pattern	Best Practice
Deep nested selectors	Flat, class-based styling
Inline styles everywhere	CSS Modules, Tailwind, SCSS
Global `#ids` for everything	Component-based modular classes
No naming convention	BEM / consistent class names
!important wars	Understand and respect the cascade

Bonus Pro Tips

Vanilla: Split your styles by feature, not by type (form.css, not buttons.css).
React: Prefer CSS Modules / Tailwind over global CSS.
Tailwind: Keep utility classes organized with clsx() or classnames.
SASS: Use nesting sparingly, don’t go beyond 2–3 levels.

Final Words

The difference between messy and clean CSS is not magic — it’s discipline and naming conventions.

Bottom Line

Even if you’ve got specificity and cascading down, CSS still has a few curveballs to throw. In this part of the series, we tackled common pitfalls that quietly break your styles — and how to avoid them like a pro:

Don't Overuse ID Selectors: IDs have heavyweight specificity. If you style with them often, they’ll win every battle — whether you want them to or not. Prefer classes unless you really need an override.
Avoid Deep Nesting: More selectors ≠ more control. Deeply nested styles are fragile, hard to override, and scream “I will break if you change one thing.” Keep it shallow and modular.
Beware of !important Abuse: It's a CSS nuke. While useful in rare edge cases, overusing !important creates debugging nightmares and traps you in a specificity arms race.
Think Before You Override Framework Styles: Frameworks like Bootstrap or Material UI bring powerful defaults — but overriding them carelessly can backfire. Learn their structure first, then customize smartly.
Tame Scoped & Component Styles: In React, Vue, or similar setups, styles can be scoped to components or injected dynamically. That’s great — until your class doesn’t apply and you don’t know why. Use DevTools to confirm exactly what’s being rendered and where.
Watch Out for Typos and Mismatches: A lowercase letter, a stray underscore, or the wrong casing can silently kill a style. Always double-check your naming and make DevTools your best friend.

At the end of the day, clean CSS is less about clever hacks and more about predictability, readability, and sanity. Avoid overengineering, keep styles modular, and debug with intention. And remember — CSS isn’t broken, it’s just misunderstood.

Quick Quiz: What's the Problem & How Would You Fix It?

Time to put your CSS sleuthing skills to the test. Below are some broken-style scenarios. For each one, think:

What’s the issue? Why isn’t the CSS working? And how would you fix it?

You’ll find the answers at the end of this article.

Q1.

You wrote a .card class with new styles, but they aren’t taking effect on your HTML.

You notice there’s already a #card style declared in the stylesheet.

Why isn’t your .card class working?

Q2.

You added styles for a button inside a component, but it's showing browser defaults.

The styles are in the parent CSS file.

Why aren’t the styles being applied inside the component?

Q3.

You used Tailwind classes and tried to override one with your own class using !important,

but it still doesn’t change.

Why didn’t your override work, even with !important?

Q4.

To fix a layout bug, you added a long selector: div.main > section .profile h2.

It worked temporarily, but things broke again after a small markup change.

What’s the risk with this fix? How could you approach it better?

Q5.

Your input field has a .form-input class with custom styles,

but it still shows a thick blue outline and unwanted padding.

What could be causing this? How would you track it down?

Wrap up

Now that we’ve come this far, I hope this article genuinely helps you on your journey as a developer.

I created this series — "Why Isn't Your CSS Working?" — so you don’t have to struggle the way I did during my own CSS learning phase. I was stuck for 4–5 months, often writing CSS rules that simply wouldn’t apply. Out of frustration, I’d sometimes delete all my HTML and CSS and start over.

But once I understood the two core forces — Specificity and Cascading — and learned how to debug with DevTools, everything started making sense. With time and experience, I learned how to write clean, predictable, and robust CSS.

Of course, UI design isn’t easy — especially when you’re aiming for something unique and creative. But writing CSS, or recreating a designer’s layout, becomes much more manageable once you're comfortable with how cascading and specificity work under the hood.

Thanks so much for reading till the end — I truly appreciate it. 🙏

If this series helped you, consider sharing it with someone else who’s battling stubborn CSS. Let’s make debugging a little less painful for everyone.

Catch up on previous parts:

Let's connect:

GitHub
LinkedIn
X/Twitter

- Cover image designed by Anique azar

Solutions – Let's Debug Together

Let’s look under the hood and solve each mystery one by one:

A1. ID trumps class

The existing #card rule has higher specificity than your .card class.

CSS specificity means your class styles are being overridden.

Fix:

Avoid using ID selectors for styling. Use class names instead.

Or, if needed, increase the specificity of your class selector.

A2. Scoped or isolated styles

In frameworks like React or Vue, styles may be scoped to a component.

Global styles from a parent file won’t automatically apply inside unless imported correctly.

Fix:

Ensure your styles are available in the component,

or move them into the component’s own scoped CSS/module file.

A3. Tailwind’s built-in `!important`

Tailwind uses !important under the hood.

If your override doesn’t match that level of specificity and importance, it won't win.

Fix:

Use your own !important, increase specificity, or use inline styles carefully.

A4. Overly deep nesting

Selectors like div.main > section .profile h2 are fragile —

they rely on a very specific HTML structure and break with small changes.

Fix:

Keep selectors shallow and modular. Use utility classes or scoped styles instead.

A5. Browser or framework styles interfering

The thick blue outline and padding likely come from default browser styles

or something like Bootstrap’s default form styles.

Fix:

Inspect the element in DevTools, identify the source of the style,

and override it with a CSS reset, normalize.css, or custom utilities.

Why Isn’t Your CSS Working? Understanding Cascading

Md Umar Siddique — Tue, 15 Apr 2025 06:13:03 +0000

CSS stands for Cascading Style Sheets. As the name suggests, a Style Sheet is a file used to style your web page. (Fun fact: the file extension for CSS is simply .css—just like its acronym with a dot in front!)

With CSS, you can apply styles to elements on your webpage using CSS Selectors, which target HTML elements based on their attributes, classes, IDs, or other properties. CSS allows you to design beautiful websites and even animate elements to enhance user interaction.

Now that we understand the “Style Sheet” part—short and crisp—let’s break down the Cascading aspect.

This is Part Two of our “Why Isn’t Your CSS Working?” series. In the previous article, we explored specificity in depth. Now, it’s time to apply that knowledge to better understand cascading—and how both work together to determine which style rules win.

I’ve explained cascading through an investigative, real-world approach—so it feels more practical and relatable, not just theory.

Although cascading and specificity are theory-heavy topics, this approach will help you actually understand and apply them, rather than just memorize the rules. At the end of this article you'll get the opportunity to strenthen your know with a quiz - I also provided the answer and its explaination

If you're already familiar with specificity, then you're good to go

If not, I highly recommend checking out my previous article: Why Isn't Your CSS Working? Understanding Specificity

The Cascade: Why Order Matters
1. Cascading Rule #1: Source Order (Last Rule Wins)
2. Cascading Rule #2: Higher Specificity Overrides Source Order
3. Cascading Rule #3: Importance of Rules
4. Cascading Rule #4: Origin of Styles
5. Contextual Importance: Inline Styles > All
Difference Between Cascading and Specificity
How Cascading and Specificity Both Are Soulmates
Bottom line
Quick Quiz: Strengthen Your Understanding of the Cascade
Wrapping Up

12. SOLUTION OF THE QUIZ

The Cascade: Why Order Matters

Which color do you think will be applied to the .text class—red or blue?

Let’s check the browser to see for ourselves:

Wait, blue is applied—but what happened to red? To understand this, let’s inspect the element using the browser’s DevTools. I’m using Chrome DevTools.

As you can see, the .text class with color: red; is crossed out, meaning the browser ignored it, and color: blue; is applied instead. And this brings us to:

1. Cascading Rule #1: Source Order (Last Rule Wins)

If two rules have the same specificity targeting the same element, the one that appears later in the stylesheet will override the earlier one.

How does this happen?

Browsers read styles from top to bottom, so the last matching rule takes precedence.
When two rules have the same specificity and target the same element with the same selector, the one that appears later will override the earlier one.
The browser disregards the earlier rule because the later one takes priority during rendering.

2. Cascading Rule #2: Higher Specificity Overrides Source Order

Even if a rule appears later in the stylesheet, it won’t win if an earlier rule has higher specificity.

Let’s say you define a class selector after an ID selector—but both target the same element.

The browser will still apply the ID rule because its specificity is stronger.

Let’s check what the browser renders.

Let’s inspect it using the browser’s DevTools:

As you can see, the ID selector’s color red is applied, and the class selector’s blue is crossed out.

That’s because ID selectors are more specific—even if they appear earlier in the CSS file.

I used the color property here, but the same rule applies to any property—like background, font-size, and more.

3. Cascading Rule #3: Importance of Rules

Now you know that the browser prioritizes the last rule when the specificity and selector are the same—and that higher specificity can override the last rule.

However, there’s one more way to override both: by using !important.

Let’s investigate it by checking the code, the browser, and DevTools—just like before.

You can see how we used !important in our stylesheet.

color: red; is applied instead of color: blue;.

The .text class with color: blue; is crossed out and ignored by the browser.

That’s the power of the !important keyword.

Behind the Scenes

When a rule is marked as !important, it gets higher priority than other rules with the same specificity—regardless of their position in the stylesheet.

The browser internally flags this rule as more important and ensures it’s applied over all others.

However, when multiple !important rules conflict, the browser still uses:

Specificity (higher wins)
Source order (last one wins)

...to decide which one takes effect.

Let’s See Conflicting `!important` Rules in Action

Specificity (Higher Wins) w

Let’s select the same element using two class selectors and one ID selector—and mark all of them !important.

Let’s see in the browser which one wins.

Now, let’s inspect the styles in DevTools and see what happened to the other rules.

After following along this far, you’ve probably already guessed it—the other rules have been crossed out.

Here, the browser applied the style based on specificity.

Although all rules had the !important flag, the ID selector had the highest specificity, so its style (color: red;) was applied.

Source Order (last one wins)

What happens if we comment out the rule with the ID selector? Let’s find out.

Let’s check the browser to see which rule gets applied.

Color green is applied—now let’s inspect it in DevTools.

Oh! It’s source order at work—since the ID rule is commented out, the browser applied the last !important rule it found. The earlier one was crossed out.

Pitfall: Don’t overuse !important, or debugging will become a nightmare!

Now that you have a solid understanding of source order, specificity, and importance, it’s time to move on to the next rule, which is:

4. Cascading Rule #4: Origin of Styles

I am going to show you one of the interesting things about the browser.

As you can see, I did not apply any style to the anchor tag, but it already comes with blue color and underline. But why?

Wait for a second — don’t think too much. I’ll explain it soon, but first, have a look at the image below:

Did you notice that?

a:-webkit-any-link {
    color: -webkit-link;
    cursor: pointer;
    text-decoration: underline;
}

The browser styled it by itself — what we call user-agent (browser default) styles.

Styles can come from:

the browser (user-agent styles),
a user’s custom settings, or
your CSS file (Author styles).

And usually, Author styles override user-agent styles.

Here’s an illustration:

As you see, I applied two properties that changed the color to purple and removed the underline.

Congratulations, it worked!

It overrode the user-agent styles — meaning the browser default styles — through my custom stylesheet. However, notice that it didn’t override cursor: pointer; because I didn’t write any rule for cursor, so the browser kept it.

That’s the full story on Cascading Rule #5: Origin of Styles.

When styles are defined by the Author, they override the user-agent styles because the specificity of Author styles is higher.

Note: Every browser has its own default style on elements, so different browsers style elements differently.

5. Contextual Importance: Inline Styles > All

Inline styles (e.g., style="color: red;" directly on an element) are more specific than anything in your stylesheet — unless something in your stylesheet uses !important and has higher specificity.

Let’s see it in action:

We used a combined ID and class selector for higher specificity, giving the color property the value goldenrod.

Now we defined inline CSS with the style attribute and gave the value for the color property as red. Let’s check out the browser:

Inline CSS won because it has the highest specificity. Let’s inspect in DevTools:

Oh no! The combined ID and class selector:

#text_id.text {
    color: goldenrod;
}

Lost to:

element.style {
    color: red;
}

Which is inline CSS.

But here’s the catch — look at this:

We marked the CSS with the !important keyword. Let’s see the result in the browser:

!important overrode the inline CSS. Don’t believe me? Let’s check in DevTools:

The !important rule overrides even the highest specificity like inline CSS — as I told you earlier in

3. Cascading Rule #3: Importance of Rules:

The browser internally flags this rule as more important and ensures it’s applied over all others.

No matter what the specificity is — if a rule is flagged with !important, it wins.

However, by now you understand that inline CSS has the highest specificity among all — unless !important steps in.

That’s the end of this article!

Just kidding haha!

I’m fully committed to helping you master CSS cascading rules. I won’t let you move on while you’re still confused — together, we’ll make sure you understand everything deeply and clearly.

In the previous part Why Isn't Your CSS Working? Understanding Specificity, I told you that Cascading and Specificity are soulmates.

But before we understand how, let’s first understand the difference between Cascading and Specificity.

Difference Between Cascading and Specificity

Both Cascading and Specificity help the browser decide which CSS rule to apply, but they play different roles in that decision:

Specificity is about how strongly a selector targets an element. Selectors with higher specificity override those with lower specificity.
- ID selectors have more specificity than class selectors.
- Class selectors are more specific than element selectors.
- Inline styles have the highest specificity (unless !important is used).
Cascading is the algorithm the browser uses when there are conflicting styles. It evaluates multiple factors in a specific order:
1. Importance (!important)
2. Origin of styles (author, user, browser)
3. Specificity
4. Source order (last one wins)

In summary:

Specificity is just one piece of the Cascade puzzle.

When two rules conflict, the browser first checks for importance, then origin, then specificity, and finally source order to make the final decision.

How Cascading and Specificity Both Are Soulmates

You can't fully understand one without the other — that's why Cascading and Specificity are often called soulmates.

Cascading provides the rules.
Specificity provides the weight.

They work together to resolve conflicts and determine which CSS rule is the winner when multiple rules target the same element.

Think of Specificity as the "strength" of a rule and Cascading as the "judge" that decides which rule actually wins.

One sets the priority, and the other makes the final call.

Together, they ensure your styles behave as expected — or help you figure out why they don’t.

Why Are Media Queries Written at the End of a CSS File?

To understand why media queries (@media) are typically placed at the end of a CSS file, let’s walk through a simple, real-world example. This will help us see how cascading and source order influence which styles get applied by the browser.

We’ll begin by writing a media query for screens with a maximum width of 400px and styling a <p> element with the class .text.

When we open this in the browser on a desktop screen (width greater than 400px), the media query does not apply. So, we see no visible changes from the .text class.

Inspecting the element in DevTools, we can see that the styles are coming from the body tag and the universal selector *.

Now let’s shrink the screen size below 400px. The media query condition is now true, so the styles inside the media query apply.

In DevTools, we can clearly see that the .text class styles from the media query—background-color: white and color: red—are now active.

But what happens if we define the same .text class again, outside of the media query, and after it in the CSS file?

Let’s look at the result on a desktop screen first.

Now let’s test it on a screen width below 400px, where the media query should apply.

Despite meeting the media query condition, the styles defined after the media query still apply. That’s because when two rules have the same specificity, the one that appears later in the stylesheet wins due to cascading and source order.

DevTools confirms this by showing that the media query styles are crossed out and overridden.

Now let’s update the media query and use an ID selector like #text, which is more specific than the .text class outside the media query.

This time, when the screen width is under 400px, the styles inside the media query take effect, despite being written earlier in the file.

DevTools shows that the ID-based styles are applied and the class-based styles are overridden.

When we return to desktop width, the ID selector condition no longer applies, so the .text class styles are once again active.

And DevTools reflects this switch accurately.

From this, it becomes clear: even though media queries are conditional, they are still part of the CSS cascade. If a rule with the same specificity comes after a media query, it will override it—even if the media query condition is met.

That’s why it’s a best practice to write your media queries at the bottom of your CSS file. This way, they can override earlier styles and you don’t have to resort to unnecessarily increasing specificity.

Otherwise, your stylesheet becomes hard to manage as you constantly fight your own rules with repeated selectors.

So the conclusion is: we write media queries at the bottom so that the cascade works in our favor when using the same selectors with the same specificity.

Now that you understand how media queries and cascade order work together, here’s something to think about:

Why do we usually place the universal selector (*) at the top of a CSS file?

You already know its specificity, and now you understand how cascade order works. Give it a thought. If you’re not sure, feel free to search or ask me.

Bottom line

This article explains how cascading works in CSS and how it interacts with specificity to determine which style rules are applied. Here's a summary of the key points:

Cascading Style Sheets (CSS) is used to style web pages through selectors that target HTML elements.
The Cascade is the algorithm browsers use to determine which CSS rules to apply when there are conflicts.
Cascading Rule #1: Source Order – When rules have the same specificity and target the same element, the last rule defined in the stylesheet wins.
Cascading Rule #2: Specificity – Rules with higher specificity override those with lower specificity, regardless of source order (ID selectors > class selectors > element selectors).
Cascading Rule #3: Importance – Rules marked with !important override normal rules regardless of specificity or source order.
Cascading Rule #4: Origin of Styles – Styles can come from the browser (user-agent styles), user's custom settings, or author styles. Author styles typically override user-agent styles.
Cascading Rule #5: Inline Styles – Inline styles (written directly in the HTML) have higher specificity than styles in external stylesheets, unless overridden by !important.
Relationship between Cascading and Specificity – Specificity is just one part of the cascade. The browser evaluates conflicts by checking importance, origin, specificity, and source order—in that order.
Media Queries and Source Order – Media queries are conditional, but they still participate in the cascade. If a rule with the same specificity appears after a media query, it can override the media query styles—even when the condition matches. That's why we usually write media queries at the bottom of our CSS files: so they have the final say when adapting styles for different screen sizes without needing to increase specificity.
When debugging CSS issues, browser DevTools are invaluable as they show which rules are being applied and which are being overridden.
Overusing !important can lead to maintenance nightmares and should be avoided when possible.

Quick Quiz: Strengthen Your Understanding of the Cascade

Question:

What color will the paragraph text render in the browser?

<p class="message">Hello, world!</p>

And the CSS:

/* style.css (linked in the HTML head) */
.message {
  color: green;
}

<style>
  .message {
    color: blue;
  }
</style>

<style>
  .message {
    color: red !important;
  }
</style>

Options:

A) Green
B) Blue
C) Red
D) Red with !important, so it overrides the others

Wrapping Up

That's the end of this Part Two article of the "Why Isn't Your CSS Working?" series.

Here, we've covered cascading in depth — exploring how browsers determine which styles to apply when rules conflict.

But the most important takeaway is how Cascading and Specificity work together as soulmates of CSS — one providing the rules, the other providing the weight.

In the previous article - Why Isn't Your CSS Working? Understanding Specificity, we mastered specificity. Now, with both pieces of the puzzle, you're equipped to solve almost any CSS styling mystery you encounter.

In the next part of this series, we will be looking at Common Pitfalls and Best Practices to help you avoid frustrating debugging sessions and write more maintainable CSS.

I hope this helped you in your web development journey.

If you have any confusion, corrections, or suggestions, feel free to drop a comment below!

Thanks for reading.

Let's connect:

GitHub
LinkedIn
X/Twitter

- Cover image designed by Anique azar

SOLUTION OF THE QUIZ

Answer:

➡️ D) Red with !important, so it overrides the others

Explanation:

Even though all the selectors have the same specificity (just a class selector), the cascade takes into account source order and importance.

Here's how the rules stack up:

style.css sets the color to green.
An internal <style> tag (which comes after the external CSS) sets it to blue.
Another <style> tag later sets the color to red, but this time with !important.

Because !important overrides all normal declarations—regardless of specificity or order—the text color ends up being red.

Why Isn't Your CSS Working? Understanding Specificity

Md Umar Siddique — Wed, 09 Apr 2025 06:57:37 +0000

Ever felt like screaming at your CSS because it won’t apply your styles? You tweak a color, refresh… nothing. Or worse, some rule overrides it. The culprits? CSS Cascading and Specificity—the forces deciding which styles win.

Specificity isn’t just a beginner’s hurdle—I’ve seen it frustrate seasoned developers as well. I’ve been there myself.

This is part one of our “Why Isn’t Your CSS Working?” series. Before tackling cascading, you must master specificity, the ranking system that decides which styles apply over others.

Many tutorials teach cascading first, but without understanding specificity, it feels unpredictable. Mastering it now makes cascading much clearer in the next part.

While writing this article, I considered all the real-world problems I’ve faced—many of which both beginners and advanced devs deal with daily. At the end of this article, you’ll get a case study to cement your understanding and a quiz to test it.

This is theory-heavy, but trust me, it’ll make CSS far less frustrating in the future. Let’s dive in!

What is Specificity?
Specificity Calculation (The Simple Formula) In Depth
How Combined Selectors Affect Specificity Ranking
Specificity of Inline CSS, Internal CSS, External CSS
An Exception in CSS Specificity – !important
Specificity in Action (A Case Study)
Bottom Line
Quick Quiz: Strengthen Your Understanding of the Specificity
Wrapping Up
SOLUTION OF THE QUIZ

What is Specificity?

Specificity determines which CSS rule takes precedence when multiple rules apply to the same element. The general rule is: more specific rules override less specific ones.

Think of specificity as a ranking system. For example, in the military, a lieutenant can give orders in the absence of a general. However, if the general is present, their orders take priority over the lieutenant’s because they hold a higher rank. Similarly, in CSS, a more specific rule will always override a less specific one.

Specificity Calculation (The Simple Formula) in depth

Now that you understand what specificity is, let’s break down how it’s calculated. The easiest way to think about specificity is to assign a score to each type of selector.

We’ll use a ranking system to make specificity easier to understand. If we assign ranks to a a selector:

A → High Rank
B → Medium Rank
C → Low Rank
If combined, the ranking increases → AB is stronger than A or AC, just as BC is stronger than B or C.
If the same rank appears multiple times, the last one takes priority → For example, if AB appears first and another AB appears later, the second one will override the first. (Which is known as cascading, which will be discussed in the next part of this series.)

The Specificity Formula

(ID count, Class/Attribute/Pseudo-class count, Element/Pseudo-element count)

Feeling overwhelmed? No worries! Let’s break it down step by step.

1. Understanding Specificity of an ID Selector

Suppose we write CSS for an element using an ID selector:

#myElement {
    color: blue;
}

Let’s apply the specificity formula by replacing the values:

ID count = 1 (since we are using a single ID selector)
Class/Attribute/Pseudo-class count = 0 (since no classes, attributes, or pseudo-classes are used)
Element/Pseudo-element count = 0 (since no element names or pseudo-elements are used)

Thus, the specificity value is:

(1, 0, 0)

Why does `1` in place of `The ID count` appear in the first position?

CSS specificity prioritizes ID selectors, giving them the highest weight. That’s why they always take the first position in the specificity tuple.

Since ID selectors uniquely identify elements, they have high specificity, so we assign them Rank A.

This is the specificity of an ID selector. This is easier than it looks, isn't it?

2. Understanding Specificity of Class/Attribute/Pseudo-class Selector

Now that we’ve assigned values for an ID selector, understanding Class, Attribute, and Pseudo-class selectors becomes easier. Let’s start with the Class Selector.

1. Class Selector

Here’s our specificity formula again:

(ID count, Class/Attribute/Pseudo-class count, Element/Pseudo-element count)

For class selectors, we replace the Class/Attribute/Pseudo-class count portion with 1, just like we did for ID selectors, but in its respective position.

Let’s see it in action:

/* Class Selector Example */
.button {
    color: blue;
}

Since we are selecting an element by its class name, we assign:

ID count = 0 (No ID selector used)
Class/Attribute/Pseudo-class count = 1 (One class selector used)
Element/Pseudo-element count = 0 (No element or pseudo-element used)

Thus, the specificity value is:

(0, 1, 0)

Since class selectors have a lower specificity than ID selectors, we assign them Rank B.

2. Attribute Selector

/* Attribute Selector Example */
input[type="text"] {
    border: 1px solid red;
}

For an attribute selector like [type="text"], the specificity is:

(0, 1, 0)

Because:

ID count = 0 (No ID selector used)
Class/Attribute/Pseudo-class count = 1 (One attribute selector used)
Element/Pseudo-element count = 0 (No element or pseudo-element used)

Since it has the same specificity as a class selector, we also assign it Rank B.

3. Pseudo-class Selector

/* Pseudo-class Selector Example */
a:hover {
    text-decoration: underline;
}

A pseudo-class like :hover follows the same rule:

(0, 1, 0)

ID count = 0 (No ID selector used)
Class/Attribute/Pseudo-class count = 1 (One pseudo-class used)
Element/Pseudo-element count = 0 (No element or pseudo-element used)

Just like class and attribute selectors, pseudo-classes hold Rank B.

Why does `1` in place of `Class/Attribute/Pseudo-class count` appear in the second position?

CSS specificity prioritizes Class, Attribute, and Pseudo-class selectors after ID selectors, giving them the second highest weight. That’s why they always take the second position in the specificity tuple.

This covers the Class, Attribute, and Pseudo-class selectors. Their specificity is equal, making them more powerful than element selectors but weaker than ID selectors.

3. Understanding Specificity of Element/Pseudo-element Selector

Now that we’ve covered Class, Attribute, and Pseudo-class selectors, understanding Element and Pseudo-element selectors is straightforward. These selectors have the lowest specificity in CSS.

1. Element Selector

Here’s our specificity formula again:

(ID count, Class/Attribute/Pseudo-class count, Element/Pseudo-element count)

For element selectors, we replace the Element/Pseudo-element count portion with 1, while keeping the other values as 0.

Let’s see it in action:

/* Element Selector Example */
p {
    font-size: 16px;
}

Since we are selecting an element by its tag name, we assign:

ID count = 0 (No ID selector used)
Class/Attribute/Pseudo-class count = 0 (No class, attribute, or pseudo-class used)
Element/Pseudo-element count = 1 (One element selector used)

Thus, the specificity value is:

(0, 0, 1)

Since element selectors have the lowest specificity, we assign them Rank C.

2. Pseudo-element Selector

/* Pseudo-element Selector Example */
p::before {
    content: "Note: ";
    font-weight: bold;
}

A pseudo-element like ::before or ::after follows the same rule:

(0, 0, 1)

ID count = 0 (No ID selector used)
Class/Attribute/Pseudo-class count = 0 (No class, attribute, or pseudo-class used)
Element/Pseudo-element count = 1 (One pseudo-element used)

Since pseudo-elements behave like elements in specificity calculations, they share Rank C with element selectors.

Why does `1` in place of `Element/Pseudo-element count` appear in the third position?

CSS specificity does not prioritize Element/Pseudo-element selectors as highly as Class, Attribute, Pseudo-class, or ID selectors, giving them the lowest weight. That’s why they always take the third position in the specificity tuple.

Still, there is a lower level of specificity available—the most lowest—and we are going to explore it in this next section.

4. Understanding Specificity of the Universal Selector

Now that we've explored ID selectors, class/attribute/pseudo-class selectors, and element/pseudo-element selectors, let's look at the universal selector *.

The universal selector applies to all elements, but it holds the lowest possible specificity in CSS.

Let’s revisit our specificity formula:

(ID count, Class/Attribute/Pseudo-class count, Element/Pseudo-element count)

Universal Selector Example

/* Universal Selector Example */
* {
    margin: 0;
    padding: 0;
}

Let’s break this down using the specificity formula:

ID count = 0 (No ID selector used)
Class/Attribute/Pseudo-class count = 0 (No class, attribute, or pseudo-class used)
Element/Pseudo-element count = 0 (No element or pseudo-element used)

So the specificity of the universal selector is:

(0, 0, 0)

Why is the universal selector the weakest?

The universal selector * is designed to target everything, but with no priority. It acts like a default fallback. That’s why it holds zero specificity — it’s not targeting any specific type, class, or ID.

You can think of it as a private in the military ranking analogy — it follows all orders but can't override anyone.

Finalizing CSS Ranking System:

Rank A → ID selectors (1, 0, 0)
Rank B → Class, Attribute, Pseudo-class selectors (0, 1, 0)
Rank C → Element, Pseudo-element selectors (0, 0, 1)

We now understand that Rank A (ID selectors) overrides Rank B (Class, Attribute, Pseudo-class selectors), which in turn overrides Rank C (Element, Pseudo-element selectors) — and all universal selectors get overridden by all of them.

But what happens when we combine multiple selectors? Can a compound selector (a combination of classes, attributes, or pseudo-classes) override an ID selector?

How Combined Selectors Affect Specificity Ranking

We have seen how different ranks (A, B, and C) influence which styles take precedence. But what happens when we combine or repeat them?

1. Combination of `A` and `B` (`AB`)

When A (high rank) and B (medium rank) are combined, the result is stronger than A or B alone. This makes AB more dominant than a standalone A or B.

#id.class {
  color: blue;
}

Or Descendant Selector (A B)

.container p {
  color: blue;
}

or Child Selector (A > B)

.container > p {
  color: red;
}

Or Adjacent Sibling Selector (A + B)

h2 + p {
  margin-top: 0;
}

Or General Sibling Selector (A ~ B)

h2 ~ p {
  color: gray;
}

Rank: (1, 1, 0)
Since it contains both A and B, it is stronger than a single A or B.

2. Combination of `B` and `C` (`BC`)

When B (medium rank) and C (low rank) are combined, the result becomes stronger than B or C alone, but still weaker than any selector containing A.

.class div {
  font-size: 16px;
}

Or Descendant Selector (B C)

.container span {
  color: blue;
}

Or Child Selector (B > C)

.box > h2 {
  color: red;
}

Or Adjacent Sibling Selector (B + C)

.note + h4 {
  margin: 10px 0;
}

Or General Sibling Selector (B ~ C)

.alert ~ h2 {
  font-weight: bold;
}

Rank: (0, 1, 1)
Since it contains both a class and an element selector, it’s stronger than either alone, but cannot beat a selector with an ID.

3. Repeating `A` (`AA`)

If A (ID selectors) appears more than once in a selector chain, the specificity doubles, making it stronger than any combination of B and C, but with one catch: you cannot apply more than one ID to a single element in valid HTML.

Invalid example (for concept only):

#id1#id2 {
  background: red;
}

Valid and practical form:

<div id="container">
  <div id="item">Hello</div>
</div>

Is Descendant Selector (A A)

#container #item {
  color: green;
}

Or Child Selector (A > A)

#parent > #child {
  font-size: 18px;
}

Or Adjacent Sibling Selector (A + A)

#heading + #subheading {
  margin-top: 0;
}

Or General Sibling Selector (A ~ A)

#main ~ #footer {
  color: gray;
}

Rank: (2, 0, 0)
Contains two A selectors — very high specificity, but only valid if used on different elements in hierarchy.

4. Repeating `B` (`BB`)

If B (class selectors) are repeated within a selector, the specificity gains weight, becoming stronger than a single B, and even combinations like BC, but it’s still weaker than A-based selectors.

.class1.class2 {
  border: 1px solid black;
}

Or Descendant Selector (B B)

.card .highlight {
  background: yellow;
}

Or Child Selector (B > B)

.wrapper > .info {
  color: red;
}

Or Adjacent Sibling Selector (B + B)

.title + .subtitle {
  margin-left: 10px;
}

Or General Sibling Selector (B ~ B)

.alert ~ .message {
  padding: 10px;
}

Rank: (0, 2, 0)
Combining multiple class selectors gives a stronger edge than a single class or element — but not strong enough to beat an ID selector.

5. Repeating `C` (`CC`)

When C (element selectors) are repeated or chained, they gain a little specificity boost — but even multiple elements remain the weakest in the specificity hierarchy.

You cannot combine it like:

sectionarticle {
  font-size: 18px;
}

Beacause sectionarticle is an invalid HTML tag.

Only Descendant Selector (C C)

section article {
  font-size: 18px;
}

Or Child Selector (C > C)

ul > li {
  list-style: none;
}

Or Adjacent Sibling Selector (C + C)

h1 + h2 {
  color: red;
}

Or General Sibling Selector (C ~ C)

p ~ span {
  font-weight: bold;
}

Rank: (0, 0, 2)
Repeating element selectors increases weight slightly, but they are still easily overridden by any class or ID selector.

Specificity of Inline CSS, Internal CSS, External CSS

You can add CSS to an HTML document in three ways:

1. External CSS – written in a separate `.css` file and linked using the `<link>` tag.

<link rel="stylesheet" href="styles.css">

Specificity: External CSS has the lowest specificity if it uses general selectors. However, its rules can still override others depending on how specific the selectors are — which we have already seen above, and through the use of the !important keyword — which we will see shortly.

2. Internal CSS – written inside `<style>` tags within the `<head>` section of the HTML document.

<head>
  <style>
    div {
      width: 400px;
      background-color: green;
    }
  </style>
</head>

Specificity: Internal CSS has medium specificity. It overrides external if the selector is the same. Otherwise, higher specificity of external CSS can override internal CSS styles. It also gets overridden by inline styles for the same element.

3. Inline CSS – written directly in an HTML element’s `style` attribute.

<p style="color: red;">This is Inline CSS.</p>

Specificity: Inline CSS has the highest specificity. It overrides both internal and external styles applied to the same element — even if the element is targeted using an ID selector or a combination of ID or class selectors.

However, there is one exception — the !important keyword, which can override inline styles if applied properly.

An Exception in CSS Specificity – `!important`

Normally, inline CSS has the highest specificity compared to internal and external styles.

However, there's an important exception — the !important declaration.

When you add !important to a CSS rule, it tells the browser:

"No matter what the specificity is, apply this rule."

Even inline styles will be overridden by a rule marked !important.

Example:

<style>
  #text_id {
    color: blue !important;
  }
</style>

<div id="text_id" style="color: red;">
  This will appear in blue, not red.
</div>

How `!important` Works

It boosts the priority of a CSS declaration above others — including inline styles, ID selectors, class selectors, and element selectors.
It does not change the specificity value of a rule — it simply forces the rule to win in the cascade.
If multiple !important rules apply to the same property, then specificity comes back into play — the more specific selector wins.

(Don’t worry about Cascading as it’s the subject of our next part of this series, where we’ll understand it in depth through an investigative case study.)

Now that you understand specificity in depth, let’s do a case study to explore its practical implementation.

Specificity in Action (A Case Study)

Let’s write a basic <p> element with some lorem text. We’ll use this element across all the cases below:

Case I – Apply color green using an element selector:

Specificity is : (0, 0, 1)

It worked — as expected. If you’ve correctly linked your .css file, this should always work.

But what happens if we apply a class selector to this same element while keeping the element selector as well?

Let’s find out.

Case II – Give the same element color blue using a class selector, while the element selector is still win

Specificity is : (0, 1, 0)

Before it comes to your mind why I used the class selector above the element selector in the stylesheet — even though we applied the element selector first — let me clarify:

This is due to cascading, which we’ll fully cover in the next part of this series.

But to give you a quick preview — cascading is a rule that applies CSS based on the order of appearance when two selectors have equal specificity. For example:
p {
  color: red;
}
p {
  color: yellow;
}
The yellow color will be applied because it comes last.

However, in this case, the class selector has higher specificity than the element selector, so the text color in the <p> element is changed to blue.

Case III – Give the same element color red using an ID selector, while the class and the element selector are still win

Specificity is : (1, 0, 0)

As you can see, the ID selector overrides all the selectors even though they appear later in the stylesheet.

But what if we use a combined class selector? Will it win over the ID selector?

Case IV – Give the same element color `cyan` using a combined class selector, while the ID, the class, and the element selector are still win. Then remove the ID selector to see what happens.

Specificity is: (1, 2, 0)

The class selector gets a score of 2 because we used a combined class selector (.class1.class2), and the ID selector gets a score of 1 — however, the ID selector still wins.

Why? Because ID specificity (1, 0, 0) is always higher than any number of class selectors.

But what if we comment out the ID selector?

Let's see:

Specificity is: (0, 2, 0)

So now that the ID selector is removed, the combined class selector wins — and the color changes to cyan.

No matter how many classes, attributes, or elements you combine — an ID selector will always win if it’s present.

Case V – Apply the color `goldenrod` using a combined selector of ID and class, while the ID, class, and element selectors are still applied.

Specificity is: (1, 1, 0)

Since the selector combines both an ID and a class, the specificity becomes (1, 1, 0), which is more specific than just the ID alone (1, 0, 0).

That’s why goldenrod wins instead of red.

Combining selectors increases specificity — making your rule stronger in the cascade.

Case VI – Use Internal CSS with the same selector (`#text_id.text_class`), applying the color `cadetblue`

Why are we using the same selector (#text_id.text_class)?

Because if we use only the ID selector (#text_id), it has lower specificity than the combined ID and class selector (#text_id.text_class).

So no matter where we use #text_id, it will be overridden by the more specific #text_id.text_class.

Now let’s apply #text_id.text_class in Internal CSS and change the color to cadetblue — see what happens:

If we target an element with the same selector in Internal CSS, it has higher priority than External CSS. So, the color cadetblue wins.

However, it still gets overridden by inline styles on the same element.

Case VII – Use Inline CSS for the same element, applying the color `grey`

As you can see, inline CSS, with style attribute, overrides everything — external, internal, or embedded styles — even selectors with high specificity, and color grey wins.

But wait, there’s one thing that can break inline style priority:

A keyword called !important.

Case VIII – Use a CSS specificity exception (`!important`) with the element selector, applying the color `green`

The keyword !important breaks all the rules of specificity, so the color green defined with the <p> (element) selector is applied.

When you add !important to a CSS rule, it tells the browser:

"No matter what the specificity is, apply this rule."

Even inline styles get overridden by a low-specificity rule (like an element selector) if it’s marked !important.

Bottom Line

CSS specificity determines which rule wins when multiple rules target the same element. Here's a recap of what we learned:

Element selectors have the lowest specificity — they work until something more specific comes along.
Class selectors override element selectors because they have higher specificity.
ID selectors beat both element and class selectors — no matter where they appear in the stylesheet.
Combined selectors (like .class1.class2 or #id.class) have higher specificity than their individual parts. More selectors = more specific.
Internal CSS (within <style>) can override external CSS if specificity is equal, due to its higher location in the cascade.
Inline styles override both external and internal styles, regardless of their specificity.
The !important keyword breaks all specificity rules. It forces a style to apply, even beating inline styles — no matter the selector's specificity.

Think of specificity like weight classes — the heavier rule always wins.

And !important is like a cheat code — use it only when absolutely necessary, as it can make debugging harder.

Quick Quiz: Strengthen Your Understanding of the Specificity

Question:

What color will the <h1> element render in the browser?

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

#header h1 { color: blue; }
.title { color: red; }
h1 { color: green; }

Wrapping Up

That’s the end of this Part One article of the “Why Isn’t Your CSS Working?” series.

Here, we’ve covered specificity in depth — from element, class, ID, to inline and even !important.

But this is only half the picture.

Next, we’ll explore the second half of the puzzle: Cascading — the rule of order.

Because Specificity and Cascading are the soulmates of CSS — understanding one without the other still leads to confusion.

I hope this helped you in your web development journey.

If you have any confusion, corrections, or suggestions, feel free to drop a comment below!

Thanks for reading.

Let's connect:

GitHub
LinkedIn
X/Twitter

- Cover image designed by Anique azar

SOLUTION OF THE QUIZ

Answer: Red

Explanation

Let’s break down the specificity of each selector:

#header h1 → Specificity: (1, 0, 1)

This targets an <h1> inside an element with the ID header.

But in our HTML, the <h1> itself has the ID header, it’s not inside an element with that ID.

So this rule does not apply.
.title → Specificity: (0, 1, 0)

This applies to any element with the class title.

The <h1> has this class, so this rule applies.
h1 → Specificity: (0, 0, 1)

This applies to all <h1> tags.

So it also applies.

Now, between .title and h1, the .title selector has higher specificity, so its color red wins.

DEV Community: Md Umar Siddique

JavaScript: The Chosen One — Why the Browser Speaks Only JavaScript (and Why We Can’t Replace It)

Table of Contents

The Historical Foundation: More Than Just "Being First"

The 10-Day Genesis

The Network Effect Explosion

The Technical Monopoly: Why Browsers Only Speak JavaScript

Native Language Privilege

Deep Browser Integration

JavaScript's Unique Architectural Advantages

The Event Loop: Built for the Web

Dynamic Flexibility: A Double-Edged Sword

The Ecosystem Explosion: Network Effects in Action

NPM: The Largest Package Registry

Framework Maturity and Diversity

Tooling Ecosystem Maturity

Why Alternatives Fall Short

TypeScript: The Enhanced JavaScript

Python: Beautiful but Bounded

WebAssembly: The Future That Isn't (Yet)

The Developer Reality: Making Peace with JavaScript

The Pragmatic Choice

Learning Strategy for Modern Developers

The Inconvenient Truth

The Network Effect Lock-In

Closing Thought

Thank You

MCQ: Test Your JavaScript Knowledge

Questions

Answers

The Philosophy of JavaScript: Messy, Mighty, and Made for the Web

Table of Contents

JavaScript Wasn't Designed — It Was Assembled

"Everything Is an Object"... Kinda

Functions as First-Class Citizens

Prototype over Class: A Radical Choice

Safety First: The Browser Sandbox

The Web Is Async — So JavaScript Had to Be

Democracy in Code: JavaScript for Everyone

The Good Parts vs. The Wild Parts

Why JavaScript's Philosophy Still Matters

The Mighty Mess

Closing Thought

Up Next: Episode 4

Thank You

MCQ: Strengthen Your Understanding

Quiz Questions

Quiz Answers

Why JavaScript Survived – Wars, Standards, and Second Chances

Table of Contents

The Browser Wars Begin

ECMAScript: The First Step Toward Unity

The Dark Age (1999–2005)

AJAX and the Comeback Nobody Saw Coming

ES5 and the Second Chance

Frameworks, Ecosystem, and the Community

Why JavaScript Survived

Closing Thought

Up Next:

Thank You

MCQ: Strengthen Your Understanding

Questions

Answers

Birth of JavaScript: 10 Days, One Man, and a New Era

Table of Contents

The Web Before JavaScript

Enter Netscape: The Startup That Started the Browser War

Brendan Eich and the 10-Day Miracle

In that short time, he:

Why JavaScript? Why Not Java or C++?

Why the Name "JavaScript"?

JavaScript's DNA: Born of Necessity, Built for the Web

A New Era Begins

Closing Thought

Up Next:

Thank You

MCQ: Strengthen Your Understanding

Questions

Answers

Why HTML Exists—And What Most Developers Miss

1.2 Proper Labeling with `<label>` and Form Controls

2.2 Headings Hierarchy (`<h1>` to `<h6>`)

3.4 Anchor Text and Links (`<a>`)

5.1 Content Security Policy (CSP) with `<meta>` Tags

5.4 Sandboxing with `<iframe>`