Tabs

The Tabs field organizes a widget’s controls into panel tabs, the same structure Elementor’s own widgets use for Normal and Hover state styling. Inside the Master Addons Widget Builder, you define the tabs, place child controls in each, and the Elementor panel renders them as a compact tab strip instead of one long scroll of fields.

Tabs is a structural field. It holds no value of its own; the values belong to the children, and your template reads each one through a nested path that names the tabs field, the tab, and the field inside it. No loops, no tricks, just addresses.

What the Tabs field does #

• Renders a tab strip in the widget’s panel, built on Elementor’s control tabs mechanism.
• Holds a set of tabs, each with its own name, label, and list of child controls.
• Keeps related states together, the classic pairing being Normal and Hover versions of the same settings.
• Exposes child values through nested paths in your template: the tabs field’s name, then the tab, then the field.
• Allows the same child names across tabs, so Normal and Hover can mirror each other cleanly.

If you are just getting started with the builder, read the Widget Builder overview before this one.

Before you start #

• WordPress with Elementor installed and active.
• Master Addons for Elementor installed and active. New to the plugin? See the installation guide.
• A custom widget open in the Widget Builder editor. Our example is a button widget with a Tabs field named states holding a Normal tab and a Hover tab, each with a color field named bg.

How to add a Tabs field #

In the Widget Builder editor, scroll the fields panel on the left until you find the Tabs field, listed with the other structural fields such as Popover Toggle and Repeater.

Drag it into a section under the Style tab, where state styling lives, then define the tabs and drop child controls into each one. The field’s options open on the left as soon as it lands.

Tabs field options explained #

• Label: the heading shown above the tab strip in Elementor.
• Name: the unique identifier for the whole tabs group, letters, numbers, and underscores only, for example states. It is the first segment of every child’s template path.
• Tabs: the list of tabs. Each tab carries a name (used in template paths, for example normal), a label (shown on the strip, for example “Normal”), and its own set of child controls.
• Child controls: the fields inside each tab. Value field types work here, and each keeps its own options and value shape.
• Description, Show Label, Separator, and Conditions are the same display options as everywhere else.

Read tab values through nested paths #

Children of a Tabs field are addressed with a three-part dot path: the tabs field’s name, the tab’s name, then the child field’s name.

{{ tabsname.tabname.fieldname }}

There is no looping over tabs. Each value gets read exactly where you need it. For the button example, a states tabs field with Normal and Hover tabs, each holding a bg color field, wires into the CSS panel like this:

.ma-btn {
  background: {{ states.normal.bg }};
}
.ma-btn:hover {
  background: {{ states.hover.bg }};
}

Naming the child the same in both tabs is deliberate and supported. Internally the builder dedupes duplicate keys with a counter, but the template path stays per-tab, so bg in Normal and bg in Hover remain two distinct, cleanly addressed values. Mirrored names are the pattern to aim for: whoever reads the template sees the Normal and Hover rules differ by one path segment only.

Watch out: the flat token {{ bg }} resolves to nothing, and so does the two-part {{ normal.bg }}. The path always starts with the Tabs field’s own name. When a tab value prints empty, count the segments first. Renaming a tab breaks paths the same silent way; the CSS keeps compiling, the value just stops arriving, so settle on tab names before you write the rules.

Use the Tabs control in Elementor #

Add your custom widget to a page in Elementor (or reload the editor if the page was already open). The tab strip renders in the panel with your tab labels, and clicking a tab reveals its child controls.

An editor sets the Normal background on the first tab, switches to Hover, and sets the second color. Hovering the button in the preview shows the transition immediately, since both values already sit in the widget’s CSS rules.

Common use cases #

• Normal and Hover styling for buttons, cards, and links, the classic pairing.
• Active and inactive states for toggles, filters, and nav items.
• Before and after settings in comparison or reveal widgets.
• Light and dark variants, letting editors tune both schemes from one section.
• Odd and even row styling in list and table widgets.

Tips for working with the Tabs field #

• Address values with the full three-part path. {{ states.hover.bg }} works; {{ bg }} and {{ hover.bg }} do not.
• Mirror child names across tabs. Same fields, same names, one differing path segment; the template stays readable and the tabs stay comparable.
• Keep tab names short and lowercase. They are template identifiers, so normal and hover beat “Tab 1” and “Tab 2”.
• Use tabs for states, sections for topics. Two variants of the same settings belong in tabs; unrelated settings belong in separate sections.
• Remember each child keeps its type’s value shape. A slider inside a tab still reads as {{ states.normal.gap.size }}{{ states.normal.gap.unit }}.

Frequently Asked Questions #

Wrapping up #

The Widget Builder Tabs field turns state styling into a tidy panel pattern: define normal and hover once, mirror the child names, and your CSS reads {{ states.normal.bg }} against {{ states.hover.bg }} with nothing else changing. For repeating content rather than paired states, the Repeater field is the structural sibling to reach for. Explore the rest of the Master Addons widgets and extensions, and see the pricing page for what each plan includes.