Conditional form fields without drag-and-drop

A follow-up question should appear only when the answer makes it relevant. Core Forms can handle that with HTML data attributes.

You can keep simple show/hide rules beside the fields they control, or use the visual editor when that is easier to maintain.

The pattern

In Core Forms, every field can have a data-show-if or data-hide-if attribute. Use one field-name=value rule, such as inquiry=other. A colon also works as the separator, and | separates alternative values for the same field. The form watches the named fields and toggles visibility automatically.

Here’s a real example. A contact form where the “Tell me more” textarea only shows up when the user picks “Other” as their inquiry type:

<p>
  <label for="inquiry">What's this about?</label>
  <select name="inquiry" id="inquiry" required>
    <option value="">Pick one</option>
    <option value="quote">Quote request</option>
    <option value="support">Support question</option>
    <option value="other">Other</option>
  </select>
</p>

<p data-show-if="inquiry=other">
  <label for="details">Tell me more</label>
  <textarea name="details" id="details" rows="4"></textarea>
</p>

Choose “Other” in the dropdown, the textarea appears. Pick anything else, it hides.

That’s the whole feature.

Multiple conditions

Use data-cf-conditions for rules that must all match. Each rule has an action and a field/value expression:

<p data-cf-conditions='[{"action":"show","rule":"country=US"},{"action":"show","rule":"state=CA"}]'>
  <label for="ca-disclosure">California-specific consent</label>
  <input type="checkbox" name="ca-disclosure" id="ca-disclosure" />
</p>

This assumes the form has fields named country and state, with values US and CA. Both must match. Commas separate the JSON objects; a comma inside a single data-show-if string does not combine conditions.

For alternative values of one field, use a pipe:

<p data-show-if="country=US|CA">
  <label for="region">State or province</label>
  <input type="text" name="region" id="region" />
</p>

That field appears for either US or CA.

Hide-if (the inverse)

Use data-hide-if when it’s clearer. Use the same field/value syntax, including pipe-separated alternatives.

<p data-hide-if="anonymous=yes">
  <label for="name">Your name</label>
  <input type="text" name="name" id="name" required />
</p>

Anonymous checkbox checked, name field hides. Unchecked, name shows.

Checkbox and radio handling

For checkboxes, the value matches what the field would submit. An unchecked checkbox doesn’t submit, so use data-show-if="newsletter=yes" paired with a value="yes" on the checkbox.

For radios, match the value of the chosen option. Same pattern.

<label><input type="radio" name="contact" value="email" checked /> Email me</label>
<label><input type="radio" name="contact" value="phone" /> Call me</label>

<p data-show-if="contact=phone">
  <label for="phone">Phone number</label>
  <input type="tel" name="phone" id="phone" />
</p>

Required fields

Hidden fields skip required validation automatically. So if details has required and the field is hidden because inquiry isn’t other, the form will submit fine. Show the field, the requirement comes back.

You don’t have to wire that up. It’s the default in Core Forms because anything else is a UX bug.

Where this falls short

Three honest limits:

1. Alternatives apply within one rule. country=US|CA matches either value. Separate objects in data-cf-conditions must all match; this is not an arbitrary nested AND/OR expression language.

2. No nested conditions. The data attribute only watches first-level field values. If you want “show field B when field A is shown” (cascade), you need to write the conditions for both at the leaf level.

3. No live “min/max” comparisons. The match is exact-equality on string value. You can’t write “show this field when amount > 1000.” For that, write a change handler.

Use attributes for straightforward show/hide rules. Test more complex dependencies against the exact answers and field order your form permits.

How I actually use this

On client sites, my pattern is:

• Rough out the form in the Core Forms HTML editor with all fields visible.
• Wire conditional fields with data-show-if once the form is structurally right.
• Test the show/hide logic in the preview.
• Ship.

Test each matching and non-matching answer, including changing an earlier answer after filling a dependent field.

The next step

Pick one form on your site that has a “tell me more” field. Wire it with data-show-if. Watch the form get cleaner immediately.

Conditional logic is bundled with Core Forms at every plan level. It’s a string in an attribute, not a feature flag. The pricing page covers it, and the conditional logic guide shows the same rules set from the builder, plus action conditions and recipient routes.