feat: propagate <f-template> host attributes onto rendered host element

[janechu]

Pull Request

📖 Description

Adds support for propagating host attributes declared on the inner <template> of an <f-template> definition onto the rendered host element opening tag during SSR.

Today the build-time renderer drops every attribute on the source <template>, so authors cannot pre-declare host attributes (e.g. tabindex, role, aria-*) on a component's declarative template. After this change, the following template:

<f-template name="host-autofocus">
    <template tabindex="0">
        <span>{{text}}</span>
    </template>
</f-template>

Now renders as <host-autofocus autofocus tabindex="0">…</host-autofocus> when the author writes <host-autofocus autofocus></host-autofocus> — both the author-provided autofocus and the template-provided tabindex="0" survive SSR.

Resolution rules:

• Static name="value", dynamic name="{{expr}}", and boolean ?name="{{expr}}" bindings on the template's <template> are propagated.
• Author-provided host attributes win on conflict (dedupe on lowercased name; ?name dedupes against bare name).
• Client-only attribute prefixes are skipped: @event, :property, f-ref, f-slotted, f-children.
• {{expr}} resolves against the same state used to render the shadow root; non-primitive / null values are stripped.

Breaking change (prerelease): Locator::add_template_with_shadowroot_attrs was renamed and widened to add_template_with_attrs(name, content, shadowroot_attrs, host_attrs). Locator::from_template_definitions is now pub and accepts a 3-tuple metadata value (content, shadowroot_attrs, host_attrs). The WASM/JSON shape templatesMap[name] now includes a hostAttributes array. No external callers existed inside the monorepo.

👩‍💻 Reviewer Notes

• crates/microsoft-fast-build/src/directive.rs is where the actual splice happens. merge_template_host_attrs formats and joins filtered attrs before the rightmost > of the host opening tag.
• The skip list is intentionally hand-rolled (no shared constant with the existing client-side dispatch in fast-html); see the is_client_only_attr helper for the canonical list.
• The host-bindings fixture (packages/fast-html/test/fixtures/host-bindings) gained an intentional autofocus usage; a biome-ignore lint/a11y/noAutofocus HTML comment documents the rationale and survives npm run build:fixtures regeneration of index.html.

📑 Test Plan

• 16 new Rust unit/integration tests in crates/microsoft-fast-build (tests/host_attributes.rs + locator.rs unit tests + 2 WASM tests) — all 87 cargo tests pass.
• 1 new Playwright assertion in packages/fast-html/test/fixtures/host-bindings/host-bindings.spec.ts verifying both autofocus (author) and tabindex="0" (propagated) survive SSR + hydration.
• Full repo acceptance: npm run build ✓, npm run test ✓ (301/301 fast-html chromium, no regressions in other fixtures), npm run biome:check ✓, npm run checkchange ✓.

✅ Checklist

General

• I have included a change request file using $ npm run change
• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

[mohamedmansour]

This doesn't make sense why we want this magic:

<f-template name="host-autofocus">
    <template tabindex="0">
        <span>{{text}}</span>
    </template>
</f-template>

to propagate to:

<host-autofocus tabindex="0">

Why do we want component devs to propagate attributes? This doesn't follow the w3c spec, if they want tabindex they should do that in JS to enforce it, not automatically bring all the attributes the component itself. This would become very messy where now we have to add an allow list of attributes NOT to propagte.

So I am not fan doing this approach.

[janechu]

This doesn't make sense why we want this magic:

<f-template name="host-autofocus">
    <template tabindex="0">
        <span>{{text}}</span>
    </template>
</f-template>

to propagate to:

<host-autofocus tabindex="0">

Why do we want component devs to propagate attributes? This doesn't follow the w3c spec, if they want tabindex they should do that in JS to enforce it, not automatically bring all the attributes the component itself. This would become very messy where now we have to add an allow list of attributes NOT to propagte.

So I am not fan doing this approach.

Commented in the other implementation, this is basically our current method on CSR (Client Side Rendering), we take static attributes from the template and reflect them onto the host. This is supported in FAST v2 out of the box. We're mirroring that ability, in the case that an attribute should not propagate that is up to the component author. They can choose to set an attribute on the template, and in this case the DSD will have it since this is a declarative solution, or they can choose to set it in the connectedCallback.

The specific use case in which it is very awkward on the platform is use of autofocus. Right now a custom element must have tabindex="0" for that to work, otherwise when the page is initially loaded it won't. It is not preferrable IMO for an item that should be tabbed to out of the box and it can be assumed will potentially have autofocus on it that a developer must know that it also needs tabindex. They should just be able to set autofocus.

Component authors can choose not to use it, but since it is already an aspect of FASTElement I'm merely reaching parity with our test renderer. We are considering a new approach for v4.