Live forms

A page can also collect free-text intake, not just poll votes. Drop an <smp-form> block into your HTML with one or more <smp-field> children and it renders as a small form with a submit button. Submissions are stored for you, the same way poll votes are, so a shared page can double as a feedback form, an RSVP, or a short survey, not just a static document.

You do not need a backend, an API key, or any JavaScript of your own. The block is the whole contract.

Submissions are never shown back on the page. There is no results view for a form, unlike a poll's live bar. Every answer is private intake for the page owner, who reads it via CSV export (see Reading submissions).

A basic form

<smp-form id="feedback" submit-label="Send feedback" success="Thanks for the note!">
  <smp-field name="name" label="Your name"></smp-field>
  <smp-field name="comment" label="What's on your mind?" type="textarea" required></smp-field>
</smp-form>

• id (required) is a stable key for this form. Keep it unique on the page and do not change it later, it is what submissions are filed under.
• submit-label (optional) is the text on the submit button. Defaults to "Submit".
• success (optional) is the message shown after a submission goes through. Defaults to "Thanks!".
• multiple (optional, boolean attribute) controls whether a person can submit more than once. See One submission vs many below.

Each <smp-field> becomes one input:

• name (required) is the key the answer is stored under, and becomes its column header in the CSV export. Keep it unique within the form.
• label (optional) is the visible caption. Falls back to name if omitted.
• type (optional) is text (the default) or one of textarea, select, radio, checkbox, number, email. See Field types below.
• required (optional, boolean attribute) blocks submission until the field is filled.
• maxlength (optional) caps the answer length. Defaults to 1000 characters for text, 4000 for textarea.

Field types

A field is type="text" by default, a single-line input. The other types:

• textarea is a multi-line answer.
• select renders a dropdown. The person picks one option.
• radio renders a set of radio buttons. The person picks one option.
• checkbox renders a set of checkboxes. The person can pick several options.
• number renders a numeric input. Add min, max, and/or step attributes to constrain it, for example min="1" max="10" step="1". A value outside min/max, or one that is not a valid number, is treated as invalid.
• email renders an email input and is validated as a plausible email address (something@something.something) before the form can submit.

select, radio, and checkbox need their choices listed as <smp-option value="...">Label</smp-option> children:

<smp-field name="attending" label="Will you attend?" type="radio" required>
  <smp-option value="yes">Yes</smp-option>
  <smp-option value="no">No</smp-option>
</smp-field>

<smp-field name="meal" label="Meal choice" type="select">
  <smp-option value="veg">Vegetarian</smp-option>
  <smp-option value="meat">Meat</smp-option>
  <smp-option value="vegan">Vegan</smp-option>
</smp-field>

<smp-field name="sides" label="Sides you'd like" type="checkbox">
  <smp-option value="bread">Bread</smp-option>
  <smp-option value="salad">Salad</smp-option>
  <smp-option value="fries">Fries</smp-option>
</smp-field>

A <smp-option>'s value (required) is what gets stored; its text content is the visible label, and falls back to the value if omitted. A choice field with no <smp-option> children is malformed and is skipped, the rest of the form still renders.

checkbox is the one type that can store more than one value per submission. In the CSV export its column holds every checked option's value joined into a single cell with ; between them, for example bread; fries, rather than one column per option.

One submission vs many

By default a form is one submission per person (per browser). Submitting again overwrites their previous answers rather than adding a second row, the same shape as a poll vote.

Add multiple to collect many submissions from the same person, useful for a guestbook, a running log, or anything that is not a one-time intake:

<smp-form id="guestbook" multiple submit-label="Sign the guestbook">
  <smp-field name="name" label="Your name" required></smp-field>
  <smp-field name="note" label="Leave a note" type="textarea"></smp-field>
</smp-form>

With multiple, each submit clears the fields and starts a fresh entry, so the same visitor can add several rows over time.

Reading submissions

Open the page's settings, under Responses you get, per form:

• the submission count (there is no bucketed tally like a poll, since answers are free text),
• Close, Pause, and Reset, the same controls a poll gets,
• Export CSV of the individual submissions.

The CSV has one column per field, named after each <smp-field>'s name, plus id, visitorId, and createdAt. This is the only way anyone, including the page owner, sees an individual answer, nothing is rendered back into the page itself.

Email notifications

The page owner gets an email when submissions come in, the first one right away and then at most once an hour, with a running count of new submissions since the last email. The email links straight to this Responses view; it never includes the submitted content itself, so read the answers from Export CSV. This is on by default, and every email has a one-click unsubscribe link.

Styling a form

Like the poll block, a form ships with no styles of its own and renders into the page's own DOM (there is no shadow root), so your page CSS fully controls how it looks.

Style the rendered structure, not the authoring tags. When the page loads, each <smp-field> is replaced by a <label> wrapping its control: an <input> or <textarea> for text, textarea, number, and email, a <select> for select, or a <div data-smp-choices> of checkbox/radio <label>s for radio and checkbox. CSS that targets smp-field has no effect. This is what a live form expands to:

<smp-form id="feedback">
  <div data-smp-form="feedback">
    <label data-smp-field="name">
      <span>Your name</span>
      <input type="text" maxlength="1000" />
    </label>
    <label data-smp-field="comment">
      <span>What's on your mind?</span>
      <textarea maxlength="4000" data-smp-required></textarea>
    </label>
    <p data-smp-form-status></p>
    <button type="button" data-smp-form-submit>Submit</button>
  </div>
</smp-form>

The stable hooks you can style and select against:

An input carries data-smp-required when its field is required, and data-smp-invalid while it is blocking submission (cleared once filled). The container carries data-smp-need-fields when a submit attempt was blocked by a missing required field.

Notes and limits

• Storage is per page. Submissions are tied to the page and its block ids. If you change a form's id (or remove it), its old submissions stay filed under the old id, reset them from the Responses panel if you no longer want them.
• Fair-use caps apply. Each page has a shared response cap plus per-visitor and per-IP rate limits, and you can pause a form instantly. These protect against abuse, they are not tuned for high-frequency or high-volume data collection. The cap is shared across every live block on the page, so a multiple form burns through it faster than a one-per-person form.
• Malformed form markup (a missing id, or no fields) is left as plain text rather than upgraded, so a typo never breaks the page.
• Live forms and polls are available on Living Pages workspaces.