mount-observer 0.1.13 → 0.1.15

package/README.md

@@ -10,6 +10,7 @@ The following features have been implemented and tested:
 
 ### Core Functionality
 - ✅ **matching**: CSS selector-based element matching
+- ✅ **whenDefined**: Wait for custom elements to be defined before mounting
 - ✅ **whereInstanceOf**: Constructor-based element filtering (single or array)
 - ✅ **whereLocalNameMatches**: Regular expression-based localName filtering
 - ✅ **shouldMount**: Custom JavaScript check for complex mounting conditions
@@ -85,7 +86,7 @@ There is quite a bit of functionality this proposal would open up that is exceed
 
 4. Some CSS selectors, such as the [donut hole scope range](https://css-tricks.com/solved-by-css-donuts-scopes/#aa-donut-scoping-with-scope), aren't supported by oEl.querySelectorAll(...) or oEl.matches(...).
 
-5. Scoped custom element registries form natural "islands" of DOM that have many commonalities with css "donut hole scoping", and which mutation observers aren't really designed around.  The mount-observer is designed to work with scoped custom element registries as first-class citizens. 
+5. Scoped custom element registries form natural "islands" of DOM that have many commonalities with css "donut hole scoping", and which mutation observers aren't really designed around.  The mount-observer is designed to work with scoped custom element registries as first-class citizens. Learn more about [scoped custom element registries](https://developer.chrome.com/blog/scoped-registries). 
 
 
 ###  Most significant use cases
@@ -103,7 +104,7 @@ The extra flexibility this new primitive would provide could be quite useful to
 
 ## Quick Examples of the Most Common Use Cases
 
-Before getting into the weeds, let's demonstrate the two most prominent use cases:
+Before getting into the weeds, let's demonstrate a few of the most prominent use cases:
 
 ### Use Case 1:  Custom Attribute Enhancement
 
@@ -217,58 +218,136 @@ The handler:
 3. Stores the enhancement instance on `element.enh[enhKey]` if an `enhKey` is provided
 
 
-## Loading ES Modules from Script Elements
+## Exposing Module Exports from Script Elements
 
-The `builtIns.scriptNoModule` handler enables declarative module loading using `<script nomodule>` elements. This provides a way to import ES modules and JSON data directly from HTML without writing JavaScript.
+The `builtIns.scriptExport` handler solves a long-standing limitation: accessing ES module exports from script elements. It also provides a clean way to import JSON and other data formats declaratively.
+
+### Problem 1: ES Module Export Access
+
+The browser doesn't expose module exports from `<script type="module">` elements. There's been a [decade-old proposal](https://github.com/whatwg/html/issues/1013) to add this, but it remains unimplemented.
+
+**The Solution:**
 
 ```html
-<!-- Load a JavaScript module -->
+<!-- Use nomodule to prevent browser from loading it separately -->
 <script nomodule src="./config.js" id="myConfig"></script>
 
-<!-- Load JSON data with import assertion -->
-<script nomodule src="./data.json" with-type="json" id="myData"></script>
-
 <script type="module">
     import { MountObserver } from 'mount-observer/MountObserver.js';
     
-    // Handler provides matching and whereInstanceOf via static properties
     const observer = new MountObserver({
-        do: 'builtIns.scriptNoModule'
+        do: 'builtIns.scriptExport'
     });
     observer.observe(document);
     
-    // Access the imported modules
+    // Access the module's exports via element.export
     const config = document.getElementById('myConfig').export;
-    const data = document.getElementById('myData').export.default;
+    console.log(config.apiKey);
+    console.log(config.endpoints);
+</script>
+```
+
+**Why `nomodule`?**
+- Prevents the browser from loading the module separately
+- Avoids having the module loaded twice in memory
+- The handler imports it once and exposes exports via `element.export`
+
+### Problem 2: Declarative JSON Import
+
+Importing JSON typically requires `fetch()` or dynamic `import()` with assertions. This handler provides a declarative alternative.
+
+**The Solution:**
+
+```html
+<!-- Load JSON data -->
+<script src="./data.json" type="json" id="myData"></script>
+
+<!-- Also supports full MIME types -->
+<script src="./config.json" type="application/json" id="config"></script>
+<script src="./linked-data.json" type="application/ld+json" id="linkedData"></script>
+
+<script type="module">
+    import { MountObserver } from 'mount-observer/MountObserver.js';
     
-    console.log(config.mountConfig); // Access exported values
-    console.log(data); // Access JSON data
+    const observer = new MountObserver({
+        do: 'builtIns.scriptExport'
+    });
+    observer.observe(document);
+    
+    // Access the JSON data via element.export.default
+    const data = document.getElementById('myData').export.default;
+    console.log(data.items);
+    console.log(data.config);
 </script>
 ```
 
+<details>
+   <summary>Talking points</summary>
+
+**Why no `nomodule` for JSON?**
+- The browser ignores script elements with non-standard type attributes
+- No risk of double-loading since the browser won't load it at all
+- The handler imports it with the appropriate JSON assertion
+
+**Supported JSON types:**
+- `type="json"` - Simple and clean
+- `type="application/json"` - Standard MIME type
+- `type="application/ld+json"` - JSON-LD linked data
+- Any type containing "json" triggers JSON import assertion
+
 **How it works:**
-1. The handler matches `script[nomodule][src]` elements (via static properties)
-2. Reads the `src` attribute and resolves it relative to the document
-3. Checks for optional `with-type` attribute for import assertions (e.g., `"json"`)
-4. Dynamically imports the module: `import(src, { with: { type: withType } })`
-5. Stores the imported module on `element.export`
+1. Matches `script[src]` elements (via static properties)
+2. Skips `type="module"` scripts (browser-handled)
+3. Processes scripts with `nomodule` attribute OR type containing "json"
+4. Resolves the `src` relative to the document
+5. Imports with appropriate assertion (JSON if type contains "json")
+6. Stores the imported module on `element.export`
+7. Dispatches a `resolved` event with the imported module
+
+**Reusing imported modules:**
+
+The handler stores the imported module on the script element's `export` property and dispatches a `resolved` event. This allows other code to access the module without re-importing:
+
+```html
+<script src="./data.json" type="json" id="myData"></script>
+
+<script type="module">
+    const dataScript = document.getElementById('myData');
+    
+    // Listen for the resolved event
+    dataScript.addEventListener('resolved', (e) => {
+        console.log('Data loaded:', e.export);
+        // e.export contains the imported module
+        // For JSON: e.export.default contains the data
+    });
+    
+    // Or access directly after processing
+    // dataScript.export will contain the imported module
+</script>
+```
+
+This is particularly useful when multiple components need to access the same data or configuration without triggering multiple imports.
 
 **Benefits:**
-- Declarative module loading directly in HTML
-- Supports JSON imports with `with-type="json"` attribute
-- No need to specify `matching` or `whereInstanceOf` (handler provides defaults)
-- Modules are accessible via `scriptElement.export`
+- Access ES module exports from script elements (finally!)
+- Declarative JSON loading without fetch
+- Prevents double-loading of modules
+- Clean, intuitive syntax
 - Works with relative and absolute URLs
+- No need to specify `matching` or `whereInstanceOf` (handler provides defaults)
 
 **Use cases:**
-- Loading configuration files declaratively
-- Importing JSON data without fetch
+- Accessing configuration module exports in HTML
+- Loading JSON data declaratively
 - Progressive enhancement with module loading
-- Declarative dependency management in HTML
+- Declarative dependency management
+- Loading JSON-LD structured data
+
+</details>
 
 ## Mount Observer Script Elements (MOSEs)
 
-The `builtIns.mountObserverScript` handler enables fully declarative mount observer configuration using `<script type="mountobserver">` elements. This provides the ultimate in HTML-first progressive enhancement.
+Inspired by the [speculation rules api](https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API) `builtIns.mountObserverScript` handler enables fully declarative mount observer configuration using `<script type="mountobserver">` elements. This provides the ultimate in HTML-first progressive enhancement.
 
 ```html
 <!-- Inline JSON configuration -->
@@ -295,12 +374,73 @@ The `builtIns.mountObserverScript` handler enables fully declarative mount obser
 </script>
 ```
 
+<details>
+<summary>Talking points</summary>
+
 **How it works:**
 1. The handler matches `script[type="mountobserver"]` elements (via static properties)
 2. If the script has a `src` attribute, imports JSON from that URL
 3. Otherwise, parses the script's textContent as JSON
-4. Calls `scriptElement.mount(config)` with the parsed configuration
-5. The `mount()` method creates a MountObserver for that configuration
+4. Supports both single config objects and arrays of configs
+5. Stores the parsed config on `scriptElement.export` for reuse
+6. Dispatches a `resolved` event with the parsed config
+7. Calls `scriptElement.mount(config)` for each configuration
+8. The `mount()` method creates a MountObserver for that configuration
+
+**Reusing parsed configurations:**
+
+The handler optimizes performance by storing the parsed configuration on the script element's `export` property and dispatching a `resolved` event. When the same script element is observed again (e.g., after being cloned or moved), the handler reuses the existing `export` instead of re-parsing:
+
+```html
+<script type="mountobserver" id="myConfig">
+{
+    "matching": ".my-element",
+    "do": "builtIns.logToConsole"
+}
+</script>
+
+<script type="module">
+    const configScript = document.getElementById('myConfig');
+    
+    // Listen for the resolved event (fires only once on first parse)
+    configScript.addEventListener('resolved', (e) => {
+        console.log('Config loaded:', e.export);
+        // e.export contains the parsed configuration
+    });
+    
+    // Or access directly after processing
+    // configScript.export will contain the parsed config
+    
+    // If observed again, the handler will reuse configScript.export
+    // without re-parsing or firing the resolved event
+</script>
+```
+
+This is particularly useful when inheriting mount observer configurations across shadow DOM boundaries, as the parsed config can be reused without re-parsing JSON. The `resolved` event fires only once (on first parse), but the handler will still process the configuration on subsequent observations.
+
+**Multiple configs in one script:**
+
+You can define multiple mount observer configurations in a single script element using a JSON array:
+
+```html
+<script type="mountobserver">
+[
+    {
+        "do": "builtIns.hoistTemplate"
+    },
+    {
+        "do": "builtIns.HTMLInclude"
+    },
+    {
+        "matching": "my-button",
+        "import": "./my-button.js",
+        "do": "builtIns.defineCustomElement"
+    }
+]
+</script>
+```
+
+This is equivalent to having three separate `<script type="mountobserver">` elements, but more concise. Each config in the array is processed independently and creates its own MountObserver.
 
 **Benefits:**
 - Zero JavaScript required for observer configuration
@@ -347,12 +487,16 @@ The `builtIns.mountObserverScript` handler enables fully declarative mount obser
 </script>
 ```
 
+</details>
+
 ## Hoisting Templates for Performance
 
-The `builtIns.hoistTemplate` handler optimizes template usage by moving a template element's content from shadow roots to `document.head`. This is particularly useful when templates with IDs are repeated across multiple custom elements.
+The `builtIns.hoistTemplate` handler optimizes template usage by moving a template element's content from shadow roots to `document.head`. 
 
 **Why hoist templates?**
 
+Template hoisting is particularly useful when you need to share conditional or repeated templates across multiple custom element instances.
+
 When HTML-first custom elements repeat throughout a page, each instance typically contains its own copy of template content. Moving these templates to a centralized location:
 - Reduces memory usage (one template instead of many copies)
 - Improves cloning performance (single source of truth)
@@ -467,6 +611,9 @@ The `builtIns.HTMLInclude` handler enables declarative HTML fragment reuse withi
 </script>
 ```
 
+<details>
+   <summary>More discussion
+
 **What happens:**
 1. The handler finds templates with `src` attributes starting with `#`
 2. Searches for an element with that ID (across shadow boundaries)
@@ -507,6 +654,8 @@ The `builtIns.HTMLInclude` handler enables declarative HTML fragment reuse withi
 </script>
 ```
 
+</details>
+
 ### Shadow DOM Support
 
 The HTMLInclude handler supports declarative shadow DOM attachment using the `shadowrootmodeonload` attribute. This allows you to attach cloned content directly to a parent element's shadow root, similar to the platform's [declarative shadow DOM](https://web.dev/articles/declarative-shadow-dom) feature.
@@ -857,9 +1006,68 @@ The handler provides helpful error messages:
 
 - Uses WeakMap caching for repeated ID lookups
 - Efficient for scenarios like periodic tables with many repeated elements
-- Searches across shadow boundaries using `upShadowSearch`
+- Searches across shadow boundaries using `upShadowSearch` (registry-aware)
+- Respects scoped custom element registry boundaries
 - Cleans up cache entries when elements are garbage collected
 
+**MOSE Export Optimization:**
+
+When cloning live DOM elements (not templates) that contain Mount Observer Script Elements (MOSEs) across shadow DOM boundaries, the HTMLInclude handler automatically copies the parsed `export` property from source scripts to cloned scripts. This optimization avoids re-parsing JSON when the same MOSE configuration is reused in multiple shadow roots.
+
+**How it works:**
+1. Detects when cloning a live element (not a template) from a different root node
+2. Finds all `script[type="mountobserver"]` elements in both source and clone
+3. Matches scripts by their `id` attribute
+4. Copies the `export` property from source to clone (by reference)
+5. If source script hasn't been processed yet, waits for the `resolved` event
+
+**Example:**
+
+```html
+<!-- Source element with MOSE in light DOM -->
+<div id="observer-config">
+    <script type="mountobserver" id="my-config">
+    {
+        "matching": ".interactive",
+        "import": "./interactive.js",
+        "do": "builtIns.enhanceMountedElement"
+    }
+    </script>
+    <div class="interactive">Content</div>
+</div>
+
+<!-- Clone into shadow DOM -->
+<my-component>
+    #shadow
+        <template src="#observer-config"></template>
+</my-component>
+
+<script type="module">
+    import { MountObserver } from 'mount-observer/MountObserver.js';
+    
+    // Process MOSEs in light DOM
+    new MountObserver({
+        do: 'builtIns.mountObserverScript'
+    }).observe(document.body);
+    
+    // Clone into shadow roots
+    new MountObserver({
+        do: 'builtIns.HTMLInclude'
+    }).observe(document);
+</script>
+```
+
+**Benefits:**
+- **Performance**: JSON is parsed only once, not for each clone
+- **Memory efficiency**: Cloned scripts share the same export object
+- **Consistency**: All clones use identical configuration
+- **Automatic**: No manual intervention required
+
+**Requirements:**
+- Source and clone must be in different root nodes (document vs shadow root)
+- MOSE scripts must have `id` attributes for matching
+- Source script must be processed by `builtIns.mountObserverScript` or `builtIns.scriptExport` before cloning
+
 [Implemented as MatchingInsertionsAndDeletionsWithIntraDocumentHTMLIncludes requirement](requirements/Done/MatchingInsertionsAndDeletionsWithIntraDocumentHTMLIncludes.md)
 
 ## Automatic ID Generation with genIds
@@ -873,18 +1081,23 @@ The `builtIns.generateIds` handler automatically generates unique IDs for elemen
 - Automatically updates ID references in attributes (aria-labelledby, for, etc.)
 - Provides shorthand syntax for common patterns
 - Handles deferred attribute activation
+- Removes `disabled` from fieldsets after processing
 
 **Basic usage:**
 
 ```html
 <fieldset disabled>
-    <label defer-for="for: #{{username}}">Username:</label>
-    <input data-id="username" type="text">
+    <label>
+        LHS: <input data-id={{lhs}}>
+    </label>
     
-    <label defer-for="for: #{{password}}">Password:</label>
-    <input data-id="password" type="password">
+    <label for=rhs>
+        RHS: <input data-id={{rhs}}>
+    </label>
     
-    <button -id>Generate IDs</button>
+    <template -id defer-🎚️ 🎚️='on if isEqual, based on #{{lhs}} and #{{rhs}}.'>
+        <div>LHS === RHS</div>
+    </template>
 </fieldset>
 
 <script type="module">
@@ -901,23 +1114,41 @@ The `builtIns.generateIds` handler automatically generates unique IDs for elemen
 
 1. The handler watches for elements with the `-id` attribute (the trigger)
 2. Finds the nearest scope container (fieldset, [itemscope], or root)
-3. Generates unique IDs for elements with `data-id`, `#`, `@`, or `|` attributes
+3. Generates unique IDs for elements with `data-id={{name}}`, `#`, `@`, or `|` attributes
 4. Replaces `#{{name}}` references with generated IDs in attributes
 5. Removes `-id` and `defer-*` attributes after processing
 6. Removes `disabled` from fieldset containers
 
-**Shorthand attributes:**
+**Result:**
 
 ```html
 <fieldset>
+    <label>
+        LHS: <input id=gid-0 data-id=lhs>
+    </label>
+    
+    <label for=rhs>
+        RHS: <input id=gid-1 data-id=rhs>
+    </label>
+    
+    <template 🎚️='on if isEqual, based on #gid-0 and #gid-1.'>
+        <div>LHS === RHS</div>
+    </template>
+</fieldset>
+```
+
+**Shorthand attributes:**
+
+```html
+<fieldset disabled>
     <!-- # uses element's tag name -->
-    <input # type="text">  <!-- becomes data-id="input" -->
+    <my-element #></my-element>  <!-- becomes id=gid-0 data-id=my-element -->
     
     <!-- @ uses element's name attribute -->
-    <input @ name="email" type="email">  <!-- becomes data-id="email" -->
+    <input @ name="email" type="email">  <!-- becomes id=gid-1 data-id=email -->
     
     <!-- | uses element's itemprop attribute -->
-    <span | itemprop="price">$99</span>  <!-- becomes data-id="price" -->
+    <span | itemprop="price">$99</span>  <!-- becomes id=gid-2 data-id=price -->
     
     <button -id>Generate IDs</button>
 </fieldset>
@@ -928,31 +1159,55 @@ The `builtIns.generateIds` handler automatically generates unique IDs for elemen
 The `data-id` attribute supports special symbols that trigger side effects:
 
 ```html
-<fieldset>
-    <!-- @ sets name attribute -->
-    <input data-id="@ username" type="text">
-    <!-- Result: id="gid-0" name="username" data-id="username" -->
-    
-    <!-- | sets itemprop attribute -->
-    <span data-id="| price">$99</span>
-    <!-- Result: id="gid-1" itemprop="price" data-id="price" -->
-    
-    <!-- $ sets itemscope and itemprop -->
-    <div data-id="$ product">...</div>
-    <!-- Result: id="gid-2" itemscope itemprop="product" data-id="product" -->
-    
-    <!-- . adds to class attribute -->
-    <div data-id=". highlight">Content</div>
-    <!-- Result: id="gid-3" class="highlight" data-id="highlight" -->
-    
-    <!-- % adds to part attribute -->
-    <div data-id="% header">Header</div>
-    <!-- Result: id="gid-4" part="header" data-id="header" -->
-    
-    <button -id>Generate IDs</button>
-</fieldset>
+<form>
+    <fieldset disabled>
+        <label>
+            LHS: <input data-id="{{@. lhs}}">
+        </label>
+        
+        <label for=rhs>
+            RHS: <span contenteditable data-id="{{|.% rhs}}">
+        </label>
+        
+        <template -id defer-🎚️ 🎚️='on if isEqual, based on #{{lhs}} and #{{rhs}}.'>
+            <div>LHS === RHS</div>
+        </template>
+    </fieldset>
+</form>
+```
+
+**Result:**
+
+```html
+<form>
+    <fieldset>
+        <label>
+            LHS: <input name=lhs class=lhs id=gid-0 data-id=lhs>
+        </label>
+        
+        <label for=rhs>
+            RHS: <span contenteditable itemprop=rhs class=rhs part=rhs id=gid-1 data-id=rhs>
+        </label>
+        
+        <template 🎚️='on if isEqual, based on #gid-0 and #gid-1.'>
+            <div>LHS === RHS</div>
+        </template>
+    </fieldset>
+</form>
 ```
 
+**Symbol meanings:**
+
+| Symbol | Attribute         | Meaning                                                                      |
+|--------|-------------------|------------------------------------------------------------------------------|
+| @      | name              | Second letter of name, common in social media for selecting names            |
+| \|     | itemprop          | "Pipe" resembles itemprop, half of dollar sign, looks like an I              |
+| $      | itemscope+itemprop| Combination of S for Scope and Pipe                                          |
+| %      | part              | Starts with p, percent indicates proportion                                  |
+| .      | class             | CSS selector                                                                 |
+
+Multiple symbols can be combined: `data-id="{{@.% myName}}"` adds name, class, and part attributes.
+
 **Deferred attributes:**
 
 Use `defer-*` prefix to prevent attributes from being applied until IDs are generated:
@@ -961,8 +1216,7 @@ Use `defer-*` prefix to prevent attributes from being applied until IDs are gene
 <fieldset disabled>
     <!-- These attributes won't work until IDs are generated -->
     <label defer-for="for: #{{email}}">Email:</label>
-    <input data-id="email" type="email" defer-aria-describedby="aria-describedby: #{{emailHelp}}">
-    <span data-id="emailHelp">Enter your email address</span>
+    <input data-id={{email}} type="email">
     
     <button -id>Activate Form</button>
 </fieldset>
@@ -1352,6 +1606,87 @@ const observer = new MountObserver({
 
 [withMediaMatching implemented as [Requirement6](requirements/Done/Requirement6.md)]
 
+## Waiting for Custom Element Definitions
+
+The `whenDefined` property allows you to wait for custom elements to be defined before mounting elements. This ensures that elements are only processed after their custom element definitions are available, preventing issues with undefined custom elements.
+
+```javascript
+const observer = new MountObserver({
+    matching: 'my-element',
+    whenDefined: 'my-element',  // Wait for my-element to be defined
+    do: (element) => {
+        console.log('my-element is now defined and mounted');
+    }
+});
+observer.observe(document);
+
+// Later, when the custom element is defined
+customElements.define('my-element', class extends HTMLElement {
+    // ...
+});
+```
+
+**Waiting for multiple custom elements:**
+
+You can specify an array of tag names to wait for all of them to be defined:
+
+```javascript
+const observer = new MountObserver({
+    matching: 'my-element, another-element',
+    whenDefined: ['my-element', 'another-element'],  // Wait for both
+    do: (element) => {
+        console.log('Both elements are defined, mounting:', element.localName);
+    }
+});
+```
+
+**How it works:**
+
+1. The check happens first, before any other `where*` conditions
+2. Uses `customElements.whenDefined()` for each specified tag name
+3. Uses the `customElementRegistry` of the observed root node
+4. Only checks once per observer instance (doesn't re-check on subsequent mounts)
+5. The `observe()` method waits for all definitions before processing elements
+
+**Common use cases:**
+
+```javascript
+// Lazy load and wait for custom element definition
+const observer = new MountObserver({
+    matching: 'my-button',
+    whenDefined: 'my-button',
+    import: './my-button.js',
+    do: 'builtIns.defineCustomElement'
+});
+
+// Wait for dependencies before enhancing
+const observer = new MountObserver({
+    matching: '.needs-custom-elements',
+    whenDefined: ['base-element', 'helper-element'],
+    do: (element) => {
+        // Safe to interact with custom elements now
+        const base = element.querySelector('base-element');
+        const helper = element.querySelector('helper-element');
+    }
+});
+```
+
+**AND condition logic:**
+
+Like all `where*` properties, `whenDefined` forms an AND condition with other filters. However, it's checked first as a prerequisite before evaluating other conditions:
+
+```javascript
+const observer = new MountObserver({
+    matching: 'my-element',
+    whenDefined: 'my-element',           // Checked FIRST
+    whereInstanceOf: HTMLElement,        // Then checked
+    whereLocalNameMatches: /^my-/,       // Then checked
+    do: (element) => { /* ... */ }
+});
+```
+
+[whenDefined implemented as [SupportForWhenDefined](requirements/SupportForWhenDefined.md)]
+
 ## LocalName Pattern Matching
 
 The `whereLocalNameMatches` property allows filtering elements by their `localName` using regular expressions. This is useful when you need to match elements based on naming patterns rather than CSS selectors.
@@ -1492,6 +1827,8 @@ However, where this support for "whereInstanceOf" would be *most* helpful is whe
 
 MountObserver automatically respects scoped custom element registry boundaries. When observing a root node, only elements that share the same `customElementRegistry` as the root node will be mounted by default. This is an implicit AND condition that applies to all observations.
 
+Learn more about [scoped custom element registries in Chrome's blog post](https://developer.chrome.com/blog/scoped-registries).
+
 **How it works:**
 
 ```javascript
@@ -1548,7 +1885,7 @@ This ensures that when we observe a shadow root with a scoped registry, we won't
 
 ## Element Mount Extension
 
-For even more convenience, we can use the `element.mount()` method to observe elements within their scoped custom element registry context. This is particularly useful with scoped custom element registries (Chrome 146+, latest WebKit/Safari).
+For even more convenience, we can use the `element.mount()` method to observe elements within their scoped custom element registry context. This is particularly useful with [scoped custom element registries](https://developer.chrome.com/blog/scoped-registries) (Chrome 146+, latest WebKit/Safari).
 
 ```JavaScript
 import 'mount-observer/ElementMountExtension.js';
@@ -1605,13 +1942,13 @@ class MyComponent extends HTMLElement {
 }
 ```
 
-Browser support: Works in all browsers, but scoped registry features require Chrome 146+ or latest WebKit/Safari.
+Browser support: Works in all browsers, but [scoped registry features](https://developer.chrome.com/blog/scoped-registries) require Chrome 146+ or latest WebKit/Safari.
 
 [Implemented as CustomElementRegistryMounting requirement](requirements/Done/CustomElementRegistryMounting.md).
 
 ### Global Propagation with `mountGlobally()`
 
-The `mountGlobally()` method extends `mount()` to automatically propagate mount observers across custom element registry boundaries and shadow DOM scopes. This is useful for bootstrapping core handlers that should work everywhere, regardless of scoped registries.  It should be used sparingly, as a last resort, probably limited to things that should arguably be built into the platform.
+The `mountGlobally()` method extends `mount()` to automatically propagate mount observers across [custom element registry](https://developer.chrome.com/blog/scoped-registries) boundaries and shadow DOM scopes. This is useful for bootstrapping core handlers that should work everywhere, regardless of scoped registries.  It should be used sparingly, as a last resort, probably limited to things that should arguably be built into the platform.
 
 ```JavaScript
 import 'mount-observer/ElementMountExtension.js';