Loading
Every source below was fetched and read while writing the lessons that cite it. Where a source is a project documenting its own product — Module Federation, single-spa, Style Dictionary — that is named here and named again in the lesson prose.
Working inside a codebase whose rules you did not write, cannot change, and have to ship into anyway.
WhySource of the definition this course builds its first lesson on: a seam is “a place where you can alter behavior in your program without editing in that place,” with an enabling point that is “a place where you can make the decision to use one behavior or another.” Fowler attributes both to Michael Feathers’ Working Effectively with Legacy Code. Note the third listed use — “redirect program flow to new modules” — which is a graft described in displacement vocabulary. Primary source for the host-reading lesson.
WhyThe pattern that gives legacy displacement its vocabulary: begin with “small additions, often new features, that are built on top of, yet separate to the legacy code base,” accepting transitional architecture in exchange for reduced risk. The course takes the technique and explicitly rejects the ending — a strangler fig kills the host, and a graft does not, which is why nothing you install can be treated as removable scaffolding.
WhyNames the technique of using an existing technical seam to intercept events “passing from one component to another” and route them elsewhere. Included because it points a front-end reader at the seams that are not in the component tree — gateways, proxies, interceptors — which are where most of the usable ones in a real host actually live.
WhySource of the inversion the graft-contract lesson borrows: a contract “non-authoritative because derived from the union of existing consumer expectations,” whose stability is “valid for a particular set of consumer contracts.” Robinson is writing about services and never mentions UI, embedding, or component delivery — the application to a grafted surface is this course’s extension, and is labelled as such in the lesson.
WhyThe vocabulary for the breaking-change clause of the graft contract: MAJOR for “incompatible API changes,” MINOR for functionality added “in a backward compatible manner,” PATCH for “backward compatible bug fixes.” The specification says nothing about what constitutes the API of a UI component — deciding whether a renamed CSS part or a changed default density is breaking is work the contract has to do itself.
WhyDefines the two statuses this course uses for every support claim: “newly available” means all four core browser engines (Chrome, Edge, Firefox, Safari) support a feature, and “widely available” means it has been newly available for 30 months. Worth citing in a graft contract precisely because a host team can verify the claim without taking your word for it.
WhyThe conformance target a portfolio company’s enterprise contracts are usually written against, at level A, AA or AAA, organised under the four principles: perceivable, operable, understandable, robust. Relevant here because a grafted surface enters the host’s audit scope the moment it renders, which is why the contract lesson insists the accessibility gaps be written down rather than omitted.
The cascade, the boundaries that partly contain it, and the half of it nothing contains.
WhyThe single rule the cascade lesson turns on: normal styles “declared outside of any layer tak[e] precedence over normal layered styles regardless of specificity,” and !important reverses the whole ordering so that unlayered important styles rank lowest and the earliest layer wins. Together these are why wrapping graft CSS in a cascade layer inside an unlayered host is choosing to lose. Primary source for the cascade lesson.
WhyLayer order is set by order of first declaration, nested layers join with a dot, anonymous layers cannot be added to later, and @import can assign an imported sheet to a layer. Records Baseline widely-available support across browsers since March 2022 (checked 2026-09-03) — which is why a host older than that has no layers at all, and every rule in its stylesheet outranks yours.
WhyCarries the explicit negative claim the course leans on: “Despite the name, style containment does not provide scoped styles such as you would get with the Shadow DOM or @scope.” The style value scopes counters and quotes. Use contain for layout and paint — real graft problems, since it stops geometry disturbing the host in both directions — and never as an isolation boundary.
WhyResets every property “except unicode-bidi, direction, and CSS Custom Properties.” That exemption is the whole reason a host’s custom properties pass through any reset boundary you build, and the reason prefixing every custom property in a grafted bundle is the cheapest defence available.
WhyThe primary grounding for inheritance crossing the shadow boundary: slotted content inherits “from the slot they’re assigned to,” not from its light-tree parent, because inheritance is computed over the flattened tree. Also the normative definitions of :host, :host() and :host-context(). An editor’s draft, so it is the working text rather than a stable Recommendation.
WhyBaseline 2026, newly available — working across the latest browsers since March 2026 (checked 2026-09-03), so not yet a mechanism a host with an older floor can rely on. Carries the specificity trap the lesson cites: bare selectors inside a scope behave as if :where(:scope) were prepended and add nothing, while writing :scope explicitly adds class-level specificity.
WhyListed as a trap rather than a tool. The CSS Working Group removed it from the specification “due to opposition from vendors, performance considerations, and interest in alternatives,” and MDN’s compatibility data records it as unsupported in both Firefox and Safari (checked 2026-09-03). It is the obvious-looking way to theme a component from an ancestor class, and it does not work outside Chromium.
The one delivery mode that works in every host, and everything the boundary costs to get it. Grounded in MDN and the WHATWG living standard, with three sources that are not neutral and are named as such in the lessons: WebKit stating a position on its own engine, a WICG proposal written by the people who want it shipped, and Meta documenting its own library.
WhyPrimary source for the shadow-boundary lesson, and the page that states both halves of the encapsulation rule in one breath: “The page CSS does not affect nodes inside the shadow DOM,” and “none of the code inside a shadow DOM can affect anything outside it.” Selector matching is blocked in both directions — the widely repeated “styles cannot get in” is half a rule. What this page does not cover is inheritance, which is the direction that does cross, and for that the course leans on CSS Scoping Module Level 1, listed under the style module.
WhyThe options that decide what kind of boundary you get: mode, delegatesFocus, slotAssignment, clonable, serializable, customElementRegistry and referenceTarget. Cited in the shadow-boundary lesson for the constraint that only an autonomous custom element and a fixed list of built-ins may host a shadow root at all, which is the reason the customized-built-in question never becomes relevant.
WhyThe lifecycle callbacks (connectedCallback, disconnectedCallback, adoptedCallback, attributeChangedCallback, and the newer connectedMoveCallback for Element.moveBefore()), and the rule that observedAttributes does nothing without attributeChangedCallback. Also carries the flat note that decides one delivery question outright: “Safari does not plan to support customized built-in elements.” The React lesson cites connectedMoveCallback specifically, because a host moving your element should not have to cost a full React remount.
WhyThe normative text behind the form-association story: only an autonomous custom element can be form-associated, and doing so makes it “listed, labelable, submittable, and resettable.” Also defines the four form lifecycle callbacks and the disabledFeatures list that can block attachInternals() or attachShadow() at definition time. Primary source for the lesson on what the boundary costs.
WhyLabelled “oppose.” Cited so the customized-built-in question can be closed with a primary source rather than folklore: WebKit supports autonomous custom elements and has not implemented this aspect. Design around autonomous elements only.
WhyThe support figure the shadow-boundary lesson uses to call declarative shadow DOM an available technique rather than an experiment: 93.74% full support plus 1.2% partial, totalling 94.94% globally, first supported in Chrome and Edge 111, Firefox 123 and Safari 16.4. Load-bearing for the server-rendered host on the course’s list, where a shadow root attached during parsing is the difference between markup that arrives styled and markup that flashes unstyled.
WhyOne of the three doors a component opens deliberately. Baseline since July 2020 (checked 2026-09-03). The constraints matter as much as the feature: a part is visible only to the parent DOM, so a nested shadow root needs exportparts, and ::part() cannot be chained with a descendant selector. Cited in the shadow-boundary lesson as the most expensive of the three channels, because every part name published is an internal element you have promised to keep.
WhyBaseline since January 2020 (checked 2026-09-03), and constrained to a compound selector: it cannot match descendants of a slotted element and cannot match text nodes. Cited in the shadow-boundary lesson for the consequence rather than the syntax — slotted nodes never leave the host’s tree, so accepting slotted content means accepting a region of your component that the host’s stylesheet governs.
WhyHow one constructed stylesheet is shared across a document and many shadow roots, parsed once. Baseline widely available since March 2023 (checked 2026-09-03) — the same date as ElementInternals, which is why March 2023 is the browser floor the delivery-constraints lesson tests a host against. The React lesson cites it as the way to style a mounted root without a <style> element per instance.
WhyBaseline widely available since March 2023, with an asterisk noting parts of the feature vary — and the asterisk is real: Firefox shipped ElementInternals in 93 but setFormValue() only in 98, and CustomStateSet did not reach Safari until 17.4 (checked 2026-09-03). Support here is per-member, not per-feature, which is a common source of “it works in Chrome” surprises.
WhyThe three conditions under which it throws NotSupportedError: the element is not a custom element, internals were disabled for the definition through disabledFeatures, or it has already been called once on this element. The lesson on what the boundary costs cites the middle one, because it is decided at definition time and is the only one a graft cannot see coming.
WhyBaseline widely available since November 2021 (checked 2026-09-03). The nuance the lesson on what the boundary costs is built on: with delegatesFocus set, document.activeElement returns the host while shadowRoot.activeElement returns the element actually focused, so host code written before you arrived reads your tag and nothing more specific — and nested roots have to be walked.
WhyWhether an event “will propagate across the shadow DOM boundary into the standard DOM.” Read alongside the Event() constructor page, which gives both bubbles and composed a default of false — so a CustomEvent fired from inside a shadow root is invisible to the host unless you set both. This is the single most common reason a grafted component appears to emit nothing.
WhyWhat a listener can see of where an event came from once retargeting has rewritten event.target to the host element, and the documented difference between an open and a closed root: the path through a closed root does not expose the nodes inside it. Cited in the lesson on what the boundary costs as one more argument for attaching an open root.
WhyCited for one fact that settles a common confusion: focus and blur are composed while not bubbling. Bubbling and crossing the shadow boundary are independent flags, and the platform’s own events demonstrate it, which is why “my event bubbles, so the host will hear it” is a false inference.
WhyPrimary source for the accessibility lesson, and the crux of the whole problem stated plainly: ID references are “only in-scope for target elements declared in the same DOM or shadow DOM as the element,” while reflected element properties reach “the same DOM… or a parent DOM,” because “Elements in other DOMs, including shadow DOMs that are children or peers of the referring DOM, are out of scope.” Element reflection therefore works outward only — never the direction a component author needs.
WhyThe outward fix, with the dates that decide whether a host has it: Baseline 2025, newly available since April 2025 — Chrome 135, Firefox 136, Safari 16.4 (checked 2026-09-03). “Newly available” means all four core engines support it now and nothing more, so a host with an older floor does not have it. Cited in the accessibility lesson for the one direction that works.
WhyThe proposed fix for the inward direction: forward references made to a component host to elements inside its shadow DOM while preserving encapsulation. Included so the course can be precise about status rather than hopeful — Chrome has the most complete implementation, Firefox and WebKit have prototypes behind flags (dom.shadowdom.referenceTarget.enabled and ShadowRootReferenceTargetEnabled), and by the implementers’ own tracking the functionality that could not be tested through web platform tests is not implemented in those engines yet. Do not design against it.
WhyCited in the accessibility lesson for what it does not say: as of this check the issue still carries no position label. That absence is the evidence that Reference Target is not on a schedule anybody can plan a component around, and it is checkable by a host team without taking the course’s word for it.
WhyPrimary source for the React lesson. States that React 19 “adds full support for custom elements and passes all tests on Custom Elements Everywhere,” and defines the rule that decides how a React host passes data to your tag: on the client a prop becomes a property when a property of that name already exists on the element instance at construction time, and an attribute otherwise, while server rendering omits object, symbol, function and false values rather than serialising them. It says nothing about mounting a root inside a shadow root — that shape is the course’s own construction, and is labelled as such.
WhyThe correction to the folklore that “React is not a singleton” breaks hooks. React’s own words: “In general, React supports using multiple independent copies on one page (for example, if an app and a third-party widget both use it). It only breaks if require(‘react’) resolves differently between the component and the react-dom copy it was rendered with.” The React lesson and the Module Federation lesson both state the failure in those narrower terms, because the vague version predicts the wrong debugging move.
WhyWhere the specific figure behind React’s claim actually lives: 100% across its sixteen tests. Cited in the React lesson so the number is attributed to the suite that produced it rather than to the release post that summarises it.
The heavier delivery modes and the headers that decide whether any of them may run. Two of the four sources below are projects documenting their own products and are describing architectures they want you to adopt; the rest is MDN, which describes the specifications rather than being them.
WhyStates the failure mode the singleton lesson turns on, verbatim: without singleton, “if the shared dependencies between the producer and the consumer have different versions, each side will load its own dependencies.” Also documents eager and its entry-bundle cost, version and requiredVersion. It does not document strictVersion, so nothing in this course cites that field from here. Primary source for the Module Federation lesson.
WhyThe self-description the Module Federation lesson quotes for what the mechanism is for: sharing “code and resources among multiple JavaScript applications (or micro-frontends).” Useful for separating the two things bundled into that sentence — runtime remote loading, which an ordinary CDN bundle also gives you, and dependency sharing, which is the part you are actually paying the build coupling for.
WhyThe root config as the project describes it: applications registered by name with a load function and an activity function, each implementing bootstrap, mount and unmount plus an optional update, enabling “multiple frameworks on the same page without page refreshing.” This is the source for the loading-versus-orchestration distinction the module rests on. Primary source for the orchestration lesson.
WhyListed for what it does not contain. It was read directly looking for cleanup or memory-leak guidance and has none — it lists framework helper packages only. The orchestration lesson’s point about unmount being a promise you make rather than one the framework keeps is therefore labelled as this course’s own reasoning about imperative lifecycle contracts, not as something single-spa documents about itself.
WhyThe 300 by 150 CSS-pixel default that starts the iframe lesson, the full sandbox token list, and the warning that decides real security reviews: for a same-origin embedded document, combining allow-scripts and allow-same-origin “lets the embedded document remove the sandbox attribute — making it no more secure than not using the sandbox attribute at all.” Primary source for the iframe lesson.
WhyThree rules, all load-bearing, all cited in the iframe lesson: “Always provide a specific targetOrigin, not *”; always verify the sender using the origin and possibly source properties; and then always verify the syntax of the received message. The third is the one that gets dropped, and a trusted origin sending an unexpected shape is the ordinary way a handler throws inside somebody else’s page.
WhyExplains why an iframe does not size to its content, and that this is deliberate: “For security and privacy reasons, <iframe> elements do not by default expose any information to the parent document about the size of the content in the document they are embedding.” Recorded as limited availability (checked 2026-09-03), so the iframe lesson teaches it as direction of travel and ships the postMessage height shim instead.
WhyThe full directive reference, which is what you need to read a real host’s header rather than the three directives you already know to look for. Also restates the rule that decides whether a permissive-looking policy is permissive: where a directive contains a nonce and unsafe-inline, the browser ignores unsafe-inline. Primary source for the lesson on how CSP narrows the table.
WhyThe directive that breaks a graft’s appearance rather than its loading, and the asymmetry inside it that decides designs: injecting an inline <style> element is blocked without unsafe-inline or a nonce, element.style.foo = … is explicitly not blocked, and element.style.cssText = … is. The page documents insertRule() and cssText only; whether constructed stylesheets adopted into a shadow root are affected is not documented anywhere this course checked, and the lesson says so rather than guessing.
WhySpecifies “valid parents that may embed a page,” is explicitly distinct from frame-src, and carries the sentence that makes reading a repository the wrong method: the directive “is not supported in the <meta> element.” A frame-ancestors policy found in a layout template is inert, which is why both this module and the delivery-constraints lesson insist on the deployed host’s response headers.
Taking on the host’s brand and session rather than fighting them, across many hosts at once. Two of these five are projects documenting their own products, one is a draft that tells implementers not to implement it, and the browser-policy claim in the session lesson has no citable specification at all — each is named as such where it is used.
WhyPrimary source for the host-brand lesson, and the reason a graft can inherit a brand at all: a custom property declared with two dashes “always inherits the value of its parent,” the exception being one registered through @property with inherits: false. Also the precise rule for var()’s fallback — it fires when the referenced property is invalid, not merely when the host forgot to define something — and the parsing note that everything after the first comma is the fallback, which is what makes var(--brand-sans, Söhne, system-ui, sans-serif) work without escaping.
WhyPrimary source for the token-source lesson. Reserved keys $value, $type, $description and $extensions; aliasing with {group.token} or a JSON Pointer; primitive types (color, dimension, fontFamily, fontWeight, duration, cubicBezier, number) and composite types (strokeStyle, border, transition, shadow, gradient, typography). Read the status line before the syntax: the draft checked on 2026-09-03 was “Design Tokens Format Module 2025.10,” dated 30 July 2026, and carried the warning “Do not attempt to implement this version of the specification.” The lesson also uses it for a negative: the format standardises the file and not the vocabulary, so two conformant hosts can share no token names, which is why a human-written mapping per host never goes away.
WhyThe compiler in the token-source lesson: “a build-system that runs in both NodeJS and browsers (natively), to parse and transform your design tokens to then export them to any platform,” with platforms, transforms and formats as its three concepts and forward-compatibility with the Design Tokens Community Group specification documented by the project itself. Cited with a stated limit: as checked on 2026-09-03 this page shows v3, v4 and v5 without stating which is current, so the lesson names no version and has the learner record whatever npm reports on the day they install.
WhyPrimary source for the session lesson, and the mechanism that survives whatever any browser’s cookie defaults do this quarter: it exists because “cross-site resources embedded in a third-party context are not given access to the same state that they would have access to when loaded in a first-party context.” Invoked per frame through Document.requestStorageAccess() and requiring a secure context. Its own named use cases include single sign-on with a federated identity provider and utility widgets embedded across domains, which is this course’s shape described by somebody else. The iframe-and-postmessage lesson in Micro-frontends and their seams also cites it, for the same reason: it holds regardless of which way a browser vendor’s cookie policy moves next.
WhyThe attribute that decides whether a grafted surface’s own cookie travels: browsers restrict cookies sent with cross-site requests by default, and SameSite=None requires the Secure attribute. Load-bearing in the session lesson for the case that looks safest and is not — a custom element living in the host’s document is same-site with the host’s backend and cross-site with yours. Nothing on this page settles what any individual browser does with third-party cookies by default; that is vendor product policy, stated in the lesson with its date and without a citation, because no specification carries it. The iframe-and-postmessage lesson also cites it, alongside an explicit warning not to treat “third-party cookies are blocked in modern browsers” as settled — checked 2026-09-05, true of Safari and Firefox and false of Chrome.
Browser behaviour on these pages is dated on purpose — support for shadow-DOM, form-association and ARIA-reflection features has moved repeatedly, and a claim without a date is a claim that will quietly rot. If a source looks wrong or out of date, check the resource list and tell your teaching agent — the course is meant to be corrected.