Surfaces, Not Pages

Introduction

One of the recurring questions in Elonn is how we should interact with the existing web.

At first glance, the answer appears simple. If a user searches for coffee, restaurants, events, products, or businesses, many of the results will ultimately be web pages. The obvious solution is to open those pages in a browser.

The problem is that Elonn is not being designed around browsers. Today we have web, Android, and iPad runtimes. Tomorrow we may have XR headsets, vehicle displays, voice interfaces, wall displays, and devices that do not yet exist. Requiring every runtime to become a browser would force the entire platform to inherit the assumptions of the web rather than defining its own.

The opposite extreme is equally unattractive. We could strip away all presentation, extract the text, and reduce every website to a plain content object. While technically simpler, that approach discards much of the value created by publishers and designers.

The goal should not be to preserve pages. The goal should be to preserve intent.

The Wrong Question

The traditional question is:

“How do we display a web page?”

That question assumes the page is the fundamental unit of the web.

Increasingly, that assumption is false.

Modern websites are rarely authored as monolithic documents. They are assembled from components, sections, blocks, widgets, modules, and reusable content structures. WordPress, Shopify, Webflow, React, Vue, Elementor, Gutenberg, Divi, and countless other systems already treat pages as compositions rather than indivisible artifacts.

A coffee shop website may contain:

• A hero section
• A location section
• An hours section
• A menu section
• An events section
• A gallery section
• A contact section

The browser presents these as a single page because that is the browser’s only presentation model.

The underlying structure is already much richer.

The more useful question becomes:

“What meaningful objects exist within this resource?”

From Pages to Surfaces

Elonn should treat web pages as containers rather than destinations.

When Find discovers a web resource, it should not immediately become a runtime object. Instead, the resource should pass through a translation layer.

The translator examines the resource and identifies meaningful surfaces.

A restaurant page might produce:

• Business Surface
• Hours Surface
• Menu Surface
• Events Surface
• Gallery Surface
• Contact Surface

A news article might produce:

• Article Surface
• Author Surface
• Related Resources Surface

A conference website might produce:

• Event Surface
• Venue Surface
• Schedule Surface
• Registration Surface

These surfaces become first-class objects within the platform.

The page is no longer the object.

The page is a source of objects.

Preserving Design Without Preserving HTML

A common objection is that this approach appears to discard the work of web designers.

In reality, the opposite may be true.

Much of a modern website exists to satisfy browser requirements rather than user requirements.

Navigation systems, cookie banners, advertising containers, analytics scripts, SEO structures, responsive layout systems, framework scaffolding, and numerous other elements are necessary because the browser requires them.

Users rarely seek those things.

What users value are:

• Branding
• Visual identity
• Photography
• Information hierarchy
• Tone and voice
• Content
• Functionality

Those elements can survive translation.

A Business Surface might preserve:

• Logo
• Brand colors
• Hero image
• Business name
• Description
• Contact information
• Hours
• Links

An Article Surface might preserve:

• Publisher attribution
• Author attribution
• Hero imagery
• Typography preferences
• Content hierarchy
• Citations
• Provenance

The exact HTML implementation disappears.

The publisher’s intent remains.

This distinction is critical.

We are not preserving browser implementation.

We are preserving publisher intent.

The Evolutionary Path

The most promising aspect of this model is that it does not require the web to change overnight.

Initially, Elonn can infer surfaces through translation.

HTML becomes source material.

Structured data, schema.org metadata, OpenGraph information, accessibility landmarks, content hierarchy, and component patterns provide clues about the meaningful objects contained within a resource.

Over time, publishers can assist the process.

A WordPress plugin could allow site owners to explicitly identify surfaces.

A Gutenberg block might be marked as:

• Hours Surface
• Menu Surface
• Event Surface

A Shopify section might be marked as:

• Product Surface
• Store Surface

A Webflow component might be marked as:

• Contact Surface
• Gallery Surface

Eventually, publishers may provide Surface Manifests directly.

At that point the website itself becomes only one possible rendering of a collection of surfaces.

The relationship reverses.

Today:

Surface is derived from Page.

Tomorrow:

Page is derived from Surface.

Implications for Elonn

This approach aligns naturally with the broader Elonn architecture.

Find discovers resources.

Surface translates resources.

Runtimes consume surfaces.

The runtime never needs to understand HTML.

The runtime never needs to execute arbitrary JavaScript.

The runtime never needs to become a browser.

Instead, every runtime consumes the same set of portable objects.

A menu can appear in a mobile application, a field view, an XR headset, a vehicle display, or a future device without modification.

An event can be attached to a conversation, placed in a field, shared with a community, or surfaced through discovery.

A business can exist as an object rather than as a page.

This transforms the web from a collection of destinations into a collection of reusable components.

Conclusion

The future opportunity is not to replace websites.

It is to expose the structure that already exists within them.

The modern web has spent years moving from documents toward components. WordPress blocks, Shopify sections, React components, and countless other systems have already decomposed pages into meaningful parts.

Elonn can build on that evolution rather than fighting it.

The platform does not need to destroy the web developer profession. It can extend it.

Instead of designing pages for browsers, creators can gradually design surfaces for a network of runtimes.

Pages become one presentation layer among many.

Surfaces become the primary unit of information.

The result is a system that respects the work already invested in the web while creating a path toward a more portable, reusable, and device-independent future.