C3: An Experimental, Extensible, Reconfigurable Platform for HTML-based Applications

Benjamin Lerner

Brian Burg, Herman Venter, and Wolfram Schulte

UW Computer Science & Engineering, and Microsoft Research

Abstract

Outline

  • What are web applications?
    • ...and what could they be?
  • Composability and compatibility:
    • The what and why of extensions
    • Extension design tradeoffs
  • C3: A platform for web-app research
  • A bottom-up tour of C3
    • DOM implementation
    • JS/C# Language bindings
    • Extending the DOM
    • Extending the UI
    • Writing a webapp
  • Future work

What is a web application?

  • WordPress
  • Outlook Web Access
  • Google Docs
  • Firefox
  • WebOS?
  • Chrome?

What makes a web app “webby”?

  • Deployment: Always up to date
  • Development: Client-side code split between
    • HTML for structure
    • CSS for appearance
    • JS for behavior
  • View source: Can examine how page is constructed
  • “Remixability”: can be combined, extended, customized, mashed up, ...

Outline

  • What are web applications?
    • ...and what could they be?
  • Composability and compatibility:
    • The what and why of extensions
    • Extension design tradeoffs
  • C3: A platform for web-app research
  • A bottom-up tour of C3
    • DOM implementation
    • JS/C# Language bindings
    • Extending the DOM
    • Extending the UI
    • Writing a webapp
  • Future work

What are extensions?

  • Third-party code
  • Modify websites or the platform itself

Why Extensions?

A closed system cannot be all things to all people

  • Experiment with new features
    • Provide new features after products ship
  • User-specific customization
    • Without bloating the main application for everyone
  • Wildly popular:
    • 6,000+ Firefox extensions
    • Over 2 Billion downloads

What can extensions do?

Three main approaches:

  • Powerful but brittle
    • Modify all existing UI
    • Interact with all other extensions
  • Ad-hoc and sandboxed
    • Modify few limited UI elements
    • Message-passing between extensions
  • Widgets
    • “Chromeless” mini-apps
    • Like web pages, isolated from one another

Extensions in a post-browser world

  • The web browser is evaporating
    • App tabs: removing the address bar for special tabs
    • Google Chrome: removing the address bar for all tabs
    • Mozilla Labs Chromeless: removing the tab bar too!
  • All that remains is the HTML platform
  • If extending the browser was good, what do we do when the browser is gone?

What could platform-level extensions do?

Example: prototyping HTML5 concepts

  • Key challenge in HTML5: understanding the interactions between parts of the spec
    • DOMCrypt API: new JS APIs for webapps to use
    • <device>, <canvas>: new tags to build with
  • Common implementation approaches:
  • Alternative: write a self-contained extension
    • No need to rebuild browser
    • Can easily define/limit interactions
    • Still can get the corner cases right

Extension design tradeoffs

Competing design goals:

  • Familiarity: make extension authoring easy
  • Power & flexibility
    • Vendor can simplify base system
    • User can personalize base system
    • Extension authors can build on other extensions
  • Security & stability
    • Extensions can break the base system...or each other!
    • Less control over the platform

How to support all of these?

Outline

  • What are web applications?
    • ...and what could they be?
  • Composability and compatibility:
    • The what and why of extensions
    • Extension design tradeoffs
  • C3: A platform for web-app research
  • A bottom-up tour of C3
    • DOM implementation
    • JS/C# Language bindings
    • Extending the DOM
    • Extending the UI
    • Writing a webapp
  • Future work

This is a webpage!

Everything within the arrows is HTML

Demos!

The C3 architecture

Components of an HTML platform

  • HTML Parser
  • DOM implementation
  • JS engine
  • Layout engine
  • Event loops
  • Network/filesystem stack
  • User interface

Design goals for C3

  • Reconfigurable: Easy to replace browser components with new implementations
  • Extensible: Enhance default components without breaking or hacking them
  • Experimental: Lower the entry barrier to platform-level research

Extensible Components of an HTML platform

  • HTML Parser: recognize new tag names & new AST nodes
  • DOM implementation: inject new content into the DOM
  • JS engine: modify existing scripts
  • Layout engine
  • Event loops
  • Network/filesystem stack
  • User interface: can be done entirely in HTML

Example: Where did the bullets come from?

We don't have generated content yet…
but maybe we can use other mechanisms?

<overlay>
  <modify selector="head" where="after">
    <self>
      <style>
        li > span { margin-right: 1em; }
        li > span { color: red; }
        li li > span { color: blue; }
      </style>
    </self>
  </modify>
  <modify selector="li" where="before">
    <self>
      <span>&bull;</span>
    </self>
  </modify>
</overlay>

Outline

  • What are web applications?
    • ...and what could they be?
  • Composability and compatibility:
    • The what and why of extensions
    • Extension design tradeoffs
  • C3: A platform for web-app research
  • A bottom-up tour of C3
    • DOM implementation
    • JS/C# Language bindings
    • Extending the DOM
    • Extending the UI
    • Writing a webapp
  • Future work

Design choice #0: Use C#

Many advantages:

  • Type-safety and memory-safety
  • Lots of libraries
    • sockets and images — not HTML itself
  • Great IDE support

Design choice #1: How many trees?

  • The DOM exposes various JS objects and APIs for manipulating the document tree
  • The browser needs lower-level access to compute layout
  • Option 1: Keep two trees, and have JS objects "call" the internal ones
  • Option 2: Keep one tree with DOM APIs exposed to JS, and low-level APIs exposed internally

Design choice #2: Language bindings

Given our single tree for both JS and internal use, what do DOM APIs look like?

JS:

var aNode = document.getElementById("id");
document.body.appendChild(aNode);

C#:

var aNode = aDoc.GetElementById("id");
aDoc.Body.AppendChild(aNode);

Equally easy to program websites or the browser!

Extension point #1: Extensible parser

  • Observation: most HTML parsers use a node factory (TagName → Node)
  • Idea: Let extensions add to that factory
    • New nodes derive from the same class hierarchy as defaults
    • Can contribute brand new tag names
    • Can override implementations of existing tags
  • Several uses:
    • Add support for an experimental feature (e.g. XML3D)
    • Add experimental support for new HTML5 nodes
    • Override the <object> tag → FlashBlock
    • Create support for another extension point ☺

Extension point #2: Overlays

  • Similar in spirit to Firefox overlays
  • Parsed using previous extension point
  • Inject new content into the document

Demonstration webapp: This browser

  • User interface is simple HTML
    • (with two hooks needed for chrome content)
  • Overlays are used to extend the UI
    • (the list bullets in this talk)

Other extension points

  • Adding new global objects to JS
    • Prototype new HTML5 APIs (e.g. window.crypto)
    • Experiment with new ideas (e.g. Maverick—tomorrow!)
  • Safely patching running JS code
    • Provide better semantics than Greasemonkey-style patches
    • ...without using eval and with better performance
  • Monitor and modify document construction
    • good for profiling, taint-tracking of individual nodes
  • Others — see the paper!

Future work

  • Conflict detection
    • Permit lots of extension interaction, but prevent destabilizing each other
  • Security monitoring
    • What fine-grained policies are useful for webapps?
    • Or extensions?
    • How can we enforce them?
  • Pushing the limits of HTML5
    • How capable can webapps be with current specs?
    • What platform-level work is needed to improve them?
  • New user interface ideas
  • ...