The platform contract
Declarative Shadow DOM uses a template with shadowrootmode so HTML can carry shadow-root content before client JavaScript loads.
<my-card>
<template shadowrootmode="open">
<style>
:host {
display: block;
}
</style>
<p>Visible before client JavaScript.</p>
</template>
</my-card>Traditional hydration
A client runtime often reconstructs the component tree before the page is fully interactive.
DSD-first rendering
The browser parses shadow roots from HTML. Custom Elements then upgrade existing hosts and attach only the needed behavior.
openElement layers
- Static DSD components for content, layout, and documentation.
- Interactive elements for local browser behavior.
- Islands for client components that need framework runtimes.
Platform standards
OpenElement relies on web-platform contracts rather than a proprietary registry product. Custom Elements, DSD, CEM, Request/Response and FormData define the direction of the public application model.
Elements + DSD
Standard Custom Elements and Declarative Shadow DOM define the durable component boundary.
Request semantics
Request, Response and FormData are the basis of the current loader/action surfaces — application interaction without a proprietary transport.
Package ownership
Element, Router, Create and the experimental UI package are the consumer surface most authors touch. Protocol and Compiler are published too, for the tools and contract types built on them: Protocol carries the cross-package contracts and Element re-exports several of them, while Compiler is consumed directly by the build layer that uses it; internal implementation stays internal.
See also
- Island Hydration — when a component crosses into client delivery: the layers and hydration strategies.
- Core Concepts — declaring a component's root mode.
- Current Architecture — where each package sits in the graph.