Skip to content

Home

Jump to bottom
Oxford Harrison edited this page May 3, 2023 · 21 revisions

Introducing Object-Oriented HTML!

Object-Oriented HTML (OOHTML) is a set of language features for authoring modular, reusable markup, and translating that to functional DOM-level objects! Everything comes together as a delightful holistic component architecture for the modern UI!

OOHTML is an upcoming proposal!

An Overview

The first set of features covers authoring objects with self-contained structure, styling and scripting! This simply gets identifiers, style sheets and scripts to serve at the object level exactly as they do at the document (object) level.

└ Object concepts

The next set of features covers templating and reusing objects - in both declarative and programmatic terms! It extends the <template> element with export semantics, and introduces a complementary new <import> element; and everything fits together as a real-time module system.

└ Templating concepts

The last set of features covers the concept of "state", "bindings", and "reactivity" for those DOM-level objects - in the most exciting form of the terms and as an upgrade path! This comes factored into the design as something intrinsic to the problem.

└ Dynamic concepts

Now, given modern UI development paradigms at the platform level, much of what has been tool-dependent becomes possible out of the box! For example, the following is how something you could call a Single Page Application (SPA) could be made:

└ First, two components that are themselves analogous to a Signle File Component (SFC):

<template exportid="pages">

  <template exportid="layout">
    <header exportid="header"></header>
    <footer exportid="footer"></footer>
  </template>

  <!-- Home Page -->
  <template exportid="home" extends="layout">
    <main exportid="main" namespace>
      <h1 id="banner">Home Page</h1>
      <a id="cta" href="#/products">Go to Products</a>
      <template scoped></template>
      <style scoped></style>
      <script scoped></script>
    </main>
  </template>

  <!-- Products Page -->
  <template exportid="products" extends="layout">
    <main exportid="main" namespace>
      <h1 id="banner">Products Page</h1>
      <a id="cta" href="#/home">Go to Home</a>
      <template scoped></template>
      <style scoped></style>
      <script scoped></script>
    </main>
  </template>

</template>

└ Then a 2-line router that alternates the view based on the URL hash:

<body importscontext="/pages/home">

  <import module="#header"></import>
  <import module="#main"></import>
  <import module="#footer"></import>
  
  <script>
  const route = () => { document.body.setAttribute('importscontext', '/pages' + location.hash.substring(1)); };
  window.addEventListener('hashchange', route);
  </script>
  
</body>

Motivation

The web has generally outgrown HTML's idea of a monolith architecture which holds to the document as the unit of abstraction for scripts, style sheets, and element identifiers - which exist in the id attribute, and in some scenarios, the name attribute. You realize that while you're trying to model things in markup and are thinking in objects, components, logical building blocks, reusable units of abstraction - as we have in Vue's SFC, Svelte component format, 11ty's WebC, the language itself is posing the "per document" thinking!

Consequently, much of this oldish monolith-oriented language by design don't come any useful beyond the global scope in the modern application architecture; scripts, style sheets and standard identifiers just don't participate in UI modular architectures! But they're also not harmless! In fact, it is the sheer global forces that these things constitute that makes it extremely difficult to write even basic modular, reusable markup!

Until we move away from the global scope, the amount of precision and coordination that must happen at the global level in the typical web page is just too unrealistic without tooling! UI development may forever invite undue tooling!

Specifically, we need a new standards work that will coexist with seemingly related efforts like Web Components to address the language-level problems that cause all the community-based wizardry around naming things, containing styles, containing scripts, and reusing things to proliferate! HTML's vocabulary will need to be extended, and much of its "per document" constraints will need to be relaxed! New APIs that provide an upgrade path from markup to JavaScript will need to be factored in!

Clone this wiki locally