Extending Internet Explorer 6+: A Technical Retrospective

Don't think for a moment that I am advocating the use of Internet Explorer or building systems for it.
DO NOT DO AS I HAVE DONE

This article documents a practical and deliberately engineered approach to extending compatibility for Internet Explorer 6 and later, running on Windows 2000-class systems and above. By combining conditional targeting, JScript-based execution paths, hybrid Server-Side Rendering (SSR) and Client-Side Rendering (CSR), custom polyfills, and IE-specific technologies such as Filters, VML, VRML, and plug-in hosted engines, it is possible to deliver surprisingly rich and usable web applications within severe legacy constraints. This article records what was built, how it was structured, and what it demonstrated about the underlying capabilities of the platform.

Scope and target environment

The compatibility work described here targets:

Internet Explorer 6 and later
Windows 2000 and later
Long-lived desktop environments
Controlled or semi-controlled deployments (intranet, industrial, embedded, or fixed-purpose systems)

The goal was not feature parity with modern browsers, but meaningful participation in modern application patterns through careful layering and fallthrough design.

Architectural mindset

Rather than treating legacy browsers as a liability, this work approaches them as a constrained but well-defined execution environment.

The core architectural principles were:

Explicit capability tiers rather than vague “legacy support”
Hybrid SSR / CSR to shift complexity away from weak clients
Deliberate fallthrough chains for rendering and interaction
Small, purpose-built polyfills instead of broad emulation layers

This mindset keeps the system understandable, debuggable, and maintainable — even when supporting very old platforms.

Targeting Internet Explorer 6+

Conditional Comments as a first-class routing mechanism

IE conditional comments are used intentionally as part of the application bootstrap process to:

Load IE-specific stylesheets
Load legacy script bundles
Introduce alternative markup structures
Register legacy rendering primitives

Rather than being scattered fixes, conditional comments form a clean and explicit fork in the delivery pipeline.

Typical uses include:

Adjusting layout for legacy box models
Providing alternative containers for vector and media content
Preventing unsupported syntax from being parsed by older engines

JScript execution paths

Internet Explorer 6+ executes Microsoft’s JScript engine. Where appropriate, this is treated as a distinct runtime with its own characteristics.

Key traits of the JScript path:

Conservative syntax
Explicit event handling models
Careful DOM interaction
Predictable, well-understood behaviour

Existing third-party polyfills were evaluated, but in practice many were either too broad or insufficiently aligned with real usage. As a result, several custom polyfills were implemented, tailored precisely to the application’s needs.

This produced smaller, clearer compatibility layers with fewer unintended side effects.

Hybrid Server-Side and Client-Side Rendering

A major enabler for IE 6+ compatibility is hybrid rendering.

Server-Side Rendering as the stability layer

When SSR is available, older clients receive:

Fully rendered HTML views
Pre-resolved layout and structure
Server-generated visual assets
Minimal reliance on client-side layout logic

In this model, IE functions reliably as a document renderer and interaction surface, while the server performs the heavy lifting.

This significantly reduces client fragility while preserving application intent.

Client-Side Enhancement where appropriate

Where IE capabilities allow:

Progressive enhancement is applied using JScript
Behaviour is layered onto SSR output
Feature detection governs activation

This avoids brittle assumptions and allows the same application to scale smoothly from IE6 through to modern browsers.

Feature fallthrough strategies

Audio and Video

IE 6+ lacks native HTML5 media support, but content delivery remains achievable.

The implemented fallthrough chain:

Native HTML5 media in capable browsers
Plug-in or object-based playback where available
Direct access to media files as a baseline

The emphasis is on access to content, not uniform playback mechanics.

Canvas

Canvas functionality is addressed using a tiered approach:

Native Canvas for capable browsers
Plug-in-based Canvas support for IE
Server-rendered raster output for complex or static scenes

In practice, SSR-integrated image generation provides excellent results for charts, diagrams, and previews in legacy clients.

SVG and vector graphics

Vector graphics follow a structured fallback path:

Native SVG rendering
VML-based rendering in IE 6+
Static raster images as a final fallback

VML proves effective for:

Icons
Simple diagrams
Structured UI elements

Complex SVG interactions are flattened where necessary, preserving meaning even when interactivity is reduced.

Filters as visual enhancement

IE Filters are used selectively to approximate effects provided by modern CSS, such as:

Opacity-style effects
Visual emphasis
Transitional polish

Filters are treated as optional enhancements, never as structural dependencies.

VRML and 3D-style representations

Where spatial or 3D-style visualisation is required, VRML is used as a fallthrough mechanism via plug-ins.

This approach is limited to:

Known client configurations
Controlled environments
Non-critical visual components

VRML serves as a pragmatic representational bridge rather than a direct analogue to modern WebGL.

Plug-in style extension model

Advanced capabilities are exposed using a modular, plug-in style architecture.

Key characteristics:

Optional capabilities
Clean separation from core functionality
Graceful degradation when absent
Clear capability discovery

This model also allows alternative rendering engines (such as Gecko-based components) to be hosted alongside IE, extending what the environment can do without replacing it entirely.

Managing complexity with discipline

To keep legacy support sustainable:

IE-specific logic is isolated
Rendering decisions are centralised
Capability detection is preferred over version branching
Each fallthrough path is intentional and documented

This prevents legacy support from becoming accidental or chaotic.

What this demonstrates about IE 6+

Within a well-structured system, Internet Explorer 6 and later are capable of:

Supporting structured, multi-step applications
Rendering complex interfaces via SSR
Participating in rich workflows
Displaying media and graphics through alternative primitives
Benefiting from progressive enhancement within defined limits

While IE lacks many modern native standards, a significant portion of modern application behaviour can still be expressed through careful engineering.

Closing observation

Extending compatibility to IE 6+ on Windows 2000+ is less about forcing modern standards onto an old browser, and more about understanding the browser’s actual strengths, limitations, and extension points.

When treated with respect and architectural clarity, even very old platforms can participate meaningfully in systems far newer than themselves.