Form Block
Use Form to collect a focused set of responses with clear labels, predictable validation, an explicit consent choice, and a useful success state. The live block above is the same standard Luna form documented below.
Properties

Properties controls the form identity, ordered fields, visual rows, button, consent, delivery, and post-submission feedback. Build and test the data contract before styling.
Form identity and description
Form Name identifies the form in submissions and should be specific enough to distinguish it from other forms. Description is optional rich text shown above the fields; use it to set expectations, not to repeat every label.
Fields and layout rows
Every field needs a stable unique ID, a unique submission name, a supported type, and a visible label. layoutRows is the canonical visual layout: reference every field exactly once and use only the supported 12-column spans. Field order should match the intended keyboard and reading order.
Field types
Form supports text, email, telephone, textarea, checkbox, radio, select, number, date, date range, time, range, URL, file, hidden, address, name, divider, currency, survey, and display fields. Configure type-specific options such as choices, date limits, time step, file acceptance, and textarea rows only when they are relevant.
Button
Button Text should describe the action. Button Alignment positions the control, and Full Width Button expands it across the form. Keep the label concise and preserve a minimum touch target in the rendered View.
Consent
Show Consent adds the checkbox and privacy link. Configure the text before the link, link label, destination, and whether consent is required. Use a real privacy-policy URL and do not preselect an agreement.
After submission
Success Message replaces the form after a successful submission. Notification Email controls the internal recipient; leaving it empty uses the site admin. Confirmation emails require the site’s own Mail sender and SMTP settings, and their subject and body can reference submitted field names such as {name} or {email}.
Connect SMTP before sending confirmation emails
Send Confirmation Email works only after the site owner configures Email / SMTP. In Dashboard, open the site’s Settings and complete the SMTP configuration, then return to Form Properties and enable the confirmation email. See SMTP & Email Delivery for the complete setup.

Container and input controls
Container Style, Surface Color, Input Style, Input Size, Label Style, Corner Radius, Padding, Field Gap, and Shadow establish the baseline before Style Panel overrides. Choose a visible surface and keep labels, fields, focus, and validation states readable against it.
Layout
Form uses a 12-column internal row system and a content-driven section frame. Keep related fields on the same row only when their labels and inputs remain usable; stack fields on narrower widths before reducing text or touch targets.
Behavior
Required fields participate in native and Luna validation. Submission uses the configured payload names, displays the Success Message when accepted, and can trigger internal and confirmation email workflows. Test validation, consent, error, success, and duplicate-submit behavior without relying on placeholder text.
Style Panel
Style Panel areas include Body, Label, Button, Text Input, Textarea, Select, Checkbox, Radio, Survey, Range, File Upload, and Privacy Policy. Style the stable default state first, then add a clear Button hover state and preserve visible keyboard focus.

Body controls the bounded form surface; each field-area target controls its matching input type. Keep consistent borders, padding, font size, and contrast across field types so the form reads as one system.
Motion
Form supports standard entrance effects, while Button hover feedback belongs in the Style Panel. Avoid repeated or large entrance motion on a task-focused form, and verify reduced-motion behavior before enabling any effect.
Property summary
Fields and layoutRows — submission data contract and 12-column visual order.
Container Style and Surface Color — form surface treatment.
Input Style, Input Size, and Label Style — shared field presentation.
Corner Radius, Padding, Field Gap, and Shadow — container geometry.
Button Text, Alignment, and Full Width — primary action.
Consent settings — checkbox copy, privacy link, and required state.
Success Message and notification settings — post-submission feedback and delivery.
Confirmation email settings — optional sender-dependent reply to the submitter.
Responsive behavior
Form is content-driven and starts from a 16-column by 10-row grid frame. Its rendered height follows field count, textarea rows, consent, button size, padding, and wrapping.
On tablet and mobile, verify every label and message, stack internal rows when needed, keep fields inside the surface, preserve touch targets, and shrink only unused grid rows after the complete form remains visible.
Accessibility
• Give every visible control a persistent label; placeholders are supplementary hints, not replacements.
• Keep DOM, keyboard, and visual order aligned with layoutRows.
• Associate errors with their fields and make the error summary understandable without color alone.
• Preserve visible focus and comfortable touch targets for inputs, consent, links, and the submit button.
• Announce success and failure clearly, and move focus deliberately when the form is replaced by the Success Message.
Best practices
• Ask only for information needed for the stated purpose.
• Use stable field names before configuring notifications or email templates.
• Link to the real privacy policy and explain how the response will be used.
• Test required, invalid, long, mobile, success, and delivery states.
Common mistakes
• Using placeholders as the only labels.
• Leaving a field out of layoutRows or referencing one field more than once.
• Enabling confirmation email without configuring the site Mail sender and SMTP settings.
• Keeping a generic Success Message that gives no next step.
• Saving an oversized grid frame after fields have been removed.
Quick recipe
Name the form, define each field and submission key, mirror every field once in layoutRows, configure the button and consent, write the success state, verify notification delivery, style the default and focus states, then test the complete flow at desktop, tablet, and mobile widths.
Questions, ideas, or bugs?
Explore what we’re building next, ask the Luna team for help, or send a focused bug report.