>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3627946. --> Reported by: [matthand](https://www.drupal.org/user/171527) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Core's <code>#states</code> (<code>core/misc/states.js</code>) assumes native form elements, so it doesn't work when a trigger or dependent element is a web component form control such as <code>&amp;lt;cw-input&amp;gt;</code> or <code>&amp;lt;cw-checkbox&amp;gt;</code>. It fails in three places.</p> <ol> <li><strong>Selectors.</strong> <code>#states</code> conditions are usually written as <code>:input[name="foo"]</code>, which is the form used in core's own <code>FormHelper</code> documentation. jQuery's <code>:input</code> only matches <code>input</code>, <code>select</code>, <code>textarea</code> and <code>button</code>, so it never matches a custom element.</li> <li><strong>Events.</strong> Triggers listen for native events: <code>keyup</code> and <code>change</code> for <code>value</code> and <code>empty</code>, and <code>change</code> for <code>checked</code>. Web component libraries usually fire their own events instead. Cordwainer's controls fire <code>cw-change</code> and <code>cw-input</code>. The native <code>change</code> event of the <code>&amp;lt;input&amp;gt;</code> inside the shadow root isn't <code>composed</code>, so it never reaches the host element. <code>checked</code> conditions never update, and <code>value</code> conditions only update when a <code>keyup</code> happens to cross the shadow boundary, not on a programmatic change, clear button or picker selection.</li> <li><strong>Dependent elements.</strong> The <code>state:disabled</code>, <code>state:readonly</code> and <code>state:checked</code> handlers look for native tags inside the form item wrapper (<code>find('input')</code>, <code>find('input, textarea')</code>, and so on), so a custom element dependent never gets the property even when the trigger works.</li> </ol> <p>The rest of the trigger logic already works for custom elements: <code>.val()</code> reads the element's <code>value</code> property and <code>.prop('checked')</code> reads its <code>checked</code> property.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ol> <li>Render a <code>&amp;lt;cw-checkbox name="toggle"&amp;gt;</code> and a native text field in a form, with <code>#states</code> on the text field: <code>'visible' =&amp;gt; [':input[name="toggle"]' =&amp;gt; ['checked' =&amp;gt; TRUE]]</code>.</li> <li>Check the checkbox. The text field stays hidden.</li> <li>Change the condition to <code>[name="toggle"]</code>. The selector now matches, but checking the box still does nothing, because no native <code>change</code> event reaches the host element.</li> <li>Put <code>#states</code> with <code>disabled</code> on a field rendered as <code>&amp;lt;cw-input&amp;gt;</code>. The wrapper gets the <code>form-disabled</code> class but the element itself stays enabled.</li> </ol> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Add a JS behavior, attached whenever a registered library is on the page, with three parts.</p> <ol> <li><strong>Match registered form controls with <code>:input</code>.</strong> Libraries list their form-control tags in the registry file. The runtime extends jQuery's <code>:input</code> pseudo-selector to also match those tags, so existing <code>:input[name="&hellip;"]</code> conditions work unchanged. This affects every <code>:input</code> lookup on the page, so check core's other uses (form serialization, <code>ajax.js</code>, <code>form.js</code>) for side effects first. If any of them break, fall back to documenting <code>[name="&hellip;"]</code> selectors and drop this part.</li> <li><strong>Proxy library events to native events.</strong> Libraries map their custom events to native counterparts in the registry file, for example <code>cw-change: change</code> and <code>cw-input: input</code>. The behavior listens for the mapped events on <code>document</code> and dispatches the native event, bubbling, on the same host element. That's what <code>states.js</code> listens for. Mark proxied events so they're never proxied again, and skip a mapping when the library already fires the native event from the host.</li> <li><strong>Apply dependent states to registered form controls.</strong> Add <code>state:disabled</code>, <code>state:readonly</code>, <code>state:required</code> and <code>state:checked</code> handlers that set the property on registered form-control tags inside the same <code>.js-form-item</code> wrapper, the same way core's handlers do for native tags. <code>state:visible</code> already works, because it toggles the wrapper.</li> </ol> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Depends on <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/web_component_runtime/-/work_items/3627765" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/web_component_runtime/-/work_items/3627765</a></span>, which decides how web component controls are rendered in Drupal forms and whether they sit in a <code>.js-form-item</code> wrapper. Cordwainer's controls aren't form-associated custom elements: they join the parent form through a Shoelace-style controller, so <code>form.elements</code> doesn't list them.</li> <li>Add the form-control tag list and event map to the registry schema. Do this in <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/web_component_runtime/-/work_items/3627749" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/web_component_runtime/-/work_items/3627749</a></span> before the format is frozen, or bump the schema version afterward.</li> <li>File a <code>cem_sdc_generator</code> issue to write both fields. The custom elements manifest lists each element's events, but not which native event each one corresponds to, so the generator needs a per-library convention or input.</li> <li>Write FunctionalJavascript tests for <code>checked</code>, <code>value</code>, <code>empty</code>, <code>visible</code>, <code>disabled</code> and <code>required</code> with a custom element as both the trigger and the dependent.</li> <li>Check the <code>:input</code> override against core's other <code>:input</code> uses.</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <p><code>#states</code> conditions work when a trigger or dependent is a web component form control.</p> <h3 id="summary-api-changes">API changes</h3> <p>New JS behavior. Registry files can declare form-control tags and a custom-to-native event map.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>Two optional registry file fields: form-control tags and an event map.</p>