add a slot to customize email helper text

[RandomEtc]

Description

Allow overriding the helper text on the email field using a slot, if needed. This allows partners using advanced functionality (show-email="true" and event handlers to facilitate signing up users to their own email list) to customize the email label so it explains what's going on. This could be used in conjunction with customizing the footer as well to further clarify which terms and privacy policy apply.

This is a prototype - seeking feedback to see if this makes sense to others, pending legal input on the approach as well.

Test Plan

I'm running yarn cypress:open and inspecting that the calculator looks reasonable when the last of the new email tests runs. The preview build for this PR should be unchanged from production.

This is a screenshot from the Cypress test:

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
embed-rewiringamerica-org	✅ Ready (Inspect)	Visit Preview	Jul 19, 2024 11:33pm

[oyamauchi]

This is the only approach that immediately comes to mind for me, and it seems generally OK on a technical level.

One potential wrinkle is styling. The way styles apply to a slotted element are very confusing to me, but I tried it out and found that if you put e.g. a link in this slot, it gets a mix of styling from outer and shadow DOMs. The text-xsm etc. Tailwind classes apply, but also the link is blue and underlined as it is in the default user-agent styles — meaning the Tailwind preflight that de-styles <a> tags is not in effect. I don't know what the logic here is, but the point is it could be confusing and/or strange-looking.

I'm not sure what we should tell clients to do, given all that. Maybe we don't need to worry about it until we know what we expect clients to put in there?

[RandomEtc]

Maybe we don't need to worry about it until we know what we expect clients to put in there?

I think we probably should have a minimally supported set of expected markup that goes in here. It seems reasonable to limit it to text with links.

It looks like CSS ::slotted pseudo selector would allow the shadow DOM’s styles to apply to the slot contents provided by the parent document. I think? https://developer.mozilla.org/en-US/docs/Web/CSS/::slotted

Tailwind doesn’t seem to support this pseudoselector out of the box but I think we can add the necessary styles and use Tailwind’s @apply to make the content the same as our other helper text sections. Will try to find a few mins to take a look.

[RandomEtc]

We are clear from a legal perspective to proceed with this approach. If we're comfortable with this as an undocumented "API" for modifying the helper text in the form, I think it's safe to merge. Shifted out of Draft mode for final review @oyamauchi