JScript and Other Interesting Quirks of Internet Explorer

From PiRho Knowledgebase
Revision as of 20:12, 13 March 2026 by Dex (talk | contribs) (Created page with " Internet Explorer is often remembered for its incompatibilities and proprietary behaviour. However, many of its quirks — particularly around JScript and the browser runtime — were early experiments that anticipated features later standardised across the web. Understanding these decisions provides valuable insight into how modern JavaScript engines, APIs, and developer tools evolved. == Context == During the late 1990s and early 2000s, the web was still defining i...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Internet Explorer is often remembered for its incompatibilities and proprietary behaviour. However, many of its quirks — particularly around JScript and the browser runtime — were early experiments that anticipated features later standardised across the web. Understanding these decisions provides valuable insight into how modern JavaScript engines, APIs, and developer tools evolved.

Context

During the late 1990s and early 2000s, the web was still defining itself. There was no ECMAScript consensus in practice, CSS was incomplete, and browsers acted as both runtime and application platform.

Internet Explorer was developed in this environment:

  • Rapid iteration
  • No stable standards enforcement
  • Strong pressure to enable rich applications inside the browser
  • Tight coupling to the Windows platform

Many “quirks” were not accidents — they were pragmatic design decisions made before the web had agreed on how things *should* work.

JScript: A Parallel Evolution

JScript was Microsoft’s implementation of ECMAScript, created to avoid trademark issues with JavaScript. While broadly compatible, it diverged in subtle but important ways.

Early Language Extensions

JScript introduced or popularised:

  • Conditional compilation
  • `try...catch` support earlier than some competitors
  • COM object instantiation via `ActiveXObject`
  • Tight integration with host objects (WScript, VBScript, Shell)

These features blurred the line between “scripting language” and “application glue”.

In hindsight, this resembles:

  • Node.js host bindings
  • Browser APIs exposed as global objects
  • JavaScript used as orchestration rather than pure computation

The DOM Before the DOM

Before DOM standards stabilised, Internet Explorer implemented its own object model.

Notable behaviours:

  • `document.all`
  • Non-standard event models (`window.event`)
  • Direct element properties (`element.innerText`)
  • Implicit global IDs mapping to elements

While problematic for portability, these ideas anticipated:

  • Fast element lookup
  • Declarative data binding
  • Rich interaction models without full page reloads

Modern frameworks effectively recreated these ideas — but with standards backing them.

The Event Model: Wrong, But Early

Internet Explorer’s event model is often criticised, yet it attempted to solve real problems:

  • Event bubbling control
  • Performance on slow hardware
  • Simpler mental models for developers

Features included:

  • Centralised event object
  • Implicit access via `window.event`
  • Early focus on keyboard and accessibility events

Today’s event systems:

  • Normalise event objects
  • Abstract bubbling and capturing
  • Provide synthetic events

The destination looks familiar — only the route was different.

XML, XSLT, and Data Islands

One of Internet Explorer’s most overlooked innovations was its deep XML support.

Capabilities included:

  • Native XML DOM
  • XSLT processing in-browser
  • XPath queries
  • Data islands embedded directly in HTML

This enabled:

  • Client-side transformations
  • Separation of data and presentation
  • Early declarative UI concepts

These ideas reappear later as:

  • JSON + templates
  • Virtual DOMs
  • Reactive UI frameworks
  • Client-side rendering pipelines

IE simply arrived there too early.

ActiveX: Power at a Cost

ActiveX is remembered primarily as a security risk, but conceptually it was:

  • A component model
  • A capability extension system
  • A bridge between browser and OS

What ActiveX attempted:

  • Hardware access
  • Native code execution
  • Enterprise integration
  • Rich client capabilities

Modern equivalents exist:

  • Browser permissions
  • WebUSB / WebSerial
  • Electron
  • Progressive Web Apps

The difference is governance, sandboxing, and user consent — not ambition.

Quirks Mode: Accidental Graceful Degradation

Quirks Mode is often mocked, but it solved a real problem: “How do we avoid breaking the entire web overnight?”

By detecting legacy markup, IE:

  • Preserved backwards compatibility
  • Allowed standards mode to evolve
  • Enabled gradual migration

This is an early form of:

  • Progressive enhancement
  • Graceful degradation
  • Feature detection over version detection

A lesson still relevant today.

Why These Decisions Matter

Internet Explorer’s quirks highlight an important truth: The web evolved through experimentation, not purity.

Many ideas that failed initially:

  • Returned with better constraints
  • Required hardware and bandwidth to catch up
  • Needed standards bodies to mature

IE was not always *wrong* — it was often *early*.

Lessons for Modern Developers

Key takeaways:

  • Context matters when judging technical decisions
  • “Non-standard” does not mean “bad idea”
  • Backwards compatibility is a feature, not a flaw
  • The browser has always been an application runtime

Understanding these quirks helps explain why modern web platforms look the way they do.

Related Topics

References

  • ECMAScript history and specifications
  • Microsoft Internet Explorer developer documentation
  • W3C DOM and HTML specifications
  • Early web application architecture case studies
Retrieved from "http://knowledgebase.pirho.net/index.php?title=JScript_and_Other_Interesting_Quirks_of_Internet_Explorer&oldid=283"