Coexistence by design

Sercrod is designed to coexist with browsers, servers, static generators, content pipelines, external helpers, and other UI tools.

This coexistence is not only a matter of size. It comes from the way Sercrod keeps ownership boundaries narrow and responsibilities separated.

Attribute conveyor

Sercrod reads intent from HTML attributes and passes that intent to the layer that should own the behavior.

• DOM attributes are written back to real DOM attributes.
• DOM events remain browser events.
• HTTP requests use browser fetch.
• WebSocket connections use browser WebSocket.
• Shadow DOM uses browser attachShadow, scoped CSS, and standard slots.
• Complex logic can be moved into external methods.
• Generated or AI-produced data can remain JSON and be connected to HTML through attributes.

Sercrod should be understood as a conveyor between these layers, not as a page-level controller that replaces them.

No global page takeover

Each Sercrod host is a Custom Element, normally <serc-rod>.

A host owns its own subtree. Normal HTML outside the host remains normal HTML. Sercrod does not need to own the whole document to be useful.

Sercrod does not rely on global MutationObserver-based page control. It relies on Web Components lifecycle and browser-native attribute reactions at the host boundary.

Sercrod also does not use Proxy observation as the automatic rendering trigger. Rendering is scheduled by Custom Elements lifecycle and Sercrod-owned update entry points.

This is the main reason Sercrod can be embedded in existing pages or generated content without turning the whole page into a Sercrod application.

Custom Element boundary

Sercrod follows the browser's Custom Elements model:

• connectedCallback initializes a host.
• attributeChangedCallback receives selected host attribute changes.
• disconnectedCallback releases resources registered by the host.

The host boundary matters. Sercrod should be added where attribute-driven behavior is useful, not wrapped around unrelated content by default.

Nested Sercrod hosts are separate units. A parent host does not render through a child host's template as if it owned that child. For practical parent/child examples, read Nested Sercrod.

Separated responsibilities

Sercrod keeps internal roles separated:

• Sercrod-owned update entry points change host data and schedule rendering.
• sercrod-change is a notification and inspection event for users and external code; it is not the render scheduler.
• sercrod-change may help explain what value changed, where it changed, and how it changed, but Sercrod intentionally keeps that inspection path separate from render scheduling.
• Known non-structural data changes may route to registered DOM commands without requiring DOM diff, Proxy-based observation, or MutationObserver-based change detection.
• Lifecycle code observes host connection and disconnection.
• Rendering rebuilds from the stored host template.
• Event handling connects DOM events to expressions.
• Network directives pass request work to browser APIs.
• WebSocket helpers pass connection and send work to browser WebSocket.
• Shadow DOM bridge connects templates to hosts without reimplementing slots.
• Release logic cleans up only resources the host registered.

This separation reduces cross-feature coupling. A debugging hook should not own rendering. A lifecycle hook should not become a global DOM watcher. A release step should not search the whole document for resources it did not register.

Resource release

Sercrod records resources it registers and releases them through the host lifecycle.

For example, window-level keyboard handlers are stored when registered. On host disconnect, Sercrod removes only those recorded handlers. WebSocket connections owned by the host are closed through the same lifecycle path.

This model avoids broad cleanup passes over unrelated DOM or application state.

Shadow and Light DOM together

Sercrod's Shadow DOM bridge is also a coexistence feature.

It lets the shadow-side template and light-side usage appear in the same HTML surface:

<template *shadow="messagebox">
	<style>
		:host { display: block; }
		.box { border: 1px solid #ccc; padding: 1rem; }
	</style>

	<section class="box">
		<header><slot name="title"></slot></header>
		<div><slot name="message"></slot></div>
	</section>
</template>

<message-box *host="messagebox">
	<h2 slot="title">Notice</h2>
	<p slot="message">Maintenance will be performed soon.</p>
</message-box>

Sercrod connects the template to the host. The browser owns slot assignment, Light DOM placement, Shadow DOM scoping, and rendering behavior.

Sercrod does not move Light DOM children into Shadow DOM and does not reimplement slot assignment.

AI and JSON data assets

Sercrod is also useful in AI-assisted content workflows.

AI-generated results can be stored as JSON, treated as data assets, and connected to HTML through visible attributes. The same page can then be inspected in a browser: data-change notifications can be inspected through sercrod-change, DOM output can be inspected directly, and request logs can be compared with the template paths that read the data.

This makes Sercrod pages readable by humans and editable by AI without requiring the whole site to become a framework-owned surface.

Integration rule

Use Sercrod where an HTML island benefits from visible attribute-driven behavior.

Do not use Sercrod to compete for ownership of the same DOM subtree or the same state model that another tool already owns.

The intended integration style is:

• add Sercrod to selected HTML islands
• keep the surrounding page unchanged
• pass data through explicit attributes, properties, JSON endpoints, or helper functions
• let each layer keep its own responsibility

See Integration notes for practical embedding patterns.