LWP Elementor Pro Mastery·3 - Mastering the Container, Layout and Positioning·2:18:17

Section 3: The Container — Layout, Wrapping Math, and Custom Positioning

Reno Instructor — teaches Elementor's Flexbox container from first principles: direction and nesting, the boxed-width mathematics, alignment and grow, the safe wrap percentages, responsive overrides, and a four-tier custom-positioning hierarchy — closing with best practices sourced directly from an Elementor product manager

▶no platform link on file · 16 more lessons in this section

Session map

The primitiveThe systemsThe judgment

click a node — its card pops up (drag it anywhere, × to close)

Concept

The map reads left to right — the primitive flow into the systems, then into the judgment. Click any node to open that idea here; every timestamp jumps into the recording.

The short version

The container replaces sections/columns with one primitive: every box is a container with a direction, nestable to infinity, and widgets can sit directly beside containers — the structural freedom the old system never had.
The width doctrine has actual math: 1140 = 12 columns × 75px + the 20px gap system; designs built on Figma's 12-column grid measure 1120, so the site-settings width becomes 1120 — and tablet/mobile switch to percentages (80% / 85–90%).
Height is padding, full stop: margin creates dead 'nobody's land,' min-height breaks when content grows, and the spacer widget is 'an amateur widget' — the chapter's hardest refusals.
Responsive grids run on three memorized numbers + grow: 35% is always two columns, 25% three, 20% four — 'whatever device' — because width past 100% (gaps included) is what forces the wrap.
Custom positioning is a hierarchy, cheapest first: background-overlay SVG → margin (pulls siblings along) → transform offset (keeps widget space, hover-animatable) → absolute (removes from layout; Elementor itself warns) — plus z-index for stacking.
Speed truth from an Elementor PM: a container + two simple widgets ships LESS code than one heavy widget — so reduce containers via wrap, but never by swapping in fat widgets.

At a glance, three clicks deep

Skim here first: the closed row is the glance, open is the study card with the key points and timestamps, and the ↓ link drops to that concept's full write-up below.

01Everything is a container: one primitive, infinite depth, widgets as equalsThe container is Elementor's single Flexbox primitive: directional (vertical default), infinitely nestable,…›

The container is Elementor's single Flexbox primitive: directional (vertical default), infinitely nestable, with widgets allowed as direct children beside other containers. Sections/columns are legacy; 'section' in course usage means a visual region, not the old element.

Direction: vertical default; horizontal on demand; row/column-reverse exist but 'I almost never use these' — better mobile tricks exist (l1425137 00:00)

'You can keep adding containers inside of other containers until infinity' (l1425137 00:00)

Widgets beside containers: dragging one out saves a container and 'keeps the website a little bit faster' (l1425137 02:01)

Container stability: 'release candidate... stable enough now'; the Grid variant is beta and deferred (l1425136 00:00)

Widget-as-card: icon-box + background replaces a container for simple cards (l1425136 02:00)

↓ Full write-up of this concept

02The 1140/1120 doctrine: why the numbers are what they areBoxed containers fix content width (default 1140 = 12×75px columns + 20px gap system);›

Boxed containers fix content width (default 1140 = 12×75px columns + 20px gap system); grid-aligned designs measure 1120 and set that globally in Site Settings → Layout. Desktop keeps pixels; tablet/mobile switch to percentage widths (80% / 85–90%). Inner containers must be full-width or they nest a second box.

Background containers: boxed; containers inside them: full width — 'it's a bit annoying that Elementor by default puts it on box' for new containers (l1425138 14:09)

The width slider means the INNER box when boxed, the whole container when full width (l1425138 04:05)

4K objection dispatched: pixel scaling + windowed ultra-wides — '1140 is a great size for most websites' (l1425138 02:03)

Percentages on small screens replace left/right padding entirely (l1425138 04:05)

The math is flagged honestly as reconstruction: 'this is an assumption... but mathematically it makes a lot of sense' (l1425138 06:06)

↓ Full write-up of this concept

03The safe wrap numbers: 35 / 25 / 20 + growResponsive multi-row grids: set wrap on the container, width per item at the safe number (2-col=35%, 3-col=…›

Responsive multi-row grids: set wrap on the container, width per item at the safe number (2-col=35%, 3-col=25%, 4-col=20%), add grow. Percentage+gap overflow forces wraps; grow fills rows to the grid. Mobile goes 100%. Empty filler containers with matching properties preserve incomplete grids. Only needed for STATIC content — loop grids set columns directly.

Gap counts toward the 100%: 'once the items exceed the 100 percent then it will go to the next row' (l1425148 02:00)

Safe-number logic: 25×4 + gaps can never fit → guaranteed 3 columns even as screens resize (l1425148 04:00)

'2 columns, whatever device, is always 35... 3 columns is always 25 and 4 columns is always 20' (l1425148 08:03)

1-row designs with ≤3 items skip wrap entirely — 'let Elementor do the hard work' (l1425147 02:01, l1425155 06:01)

Uneven rows: the 12-col→percent table (5 columns = 41%) + one item on width-then-grow (l1425147 06:03)

Dynamic content opt-out: loop grids take a columns setting — no percentages needed (l1425155 04:01)

↓ Full write-up of this concept

04The code economy: fewer containers, but never via heavy widgetsSpeed economics: minimize containers (wrap-as-vertical-space, widgets-beside-containers, padding-as-break)…›

Speed economics: minimize containers (wrap-as-vertical-space, widgets-beside-containers, padding-as-break) but never replace simple container+widget structures with option-heavy widgets — the widget's code outweighs the container's. Containers are cheap; heavy widgets are not; vendor templates are not a quality bar.

Wrap creates vertical space inside one container — 100%-width items force the break (l1425149 00:00)

Padding-as-width-break: keep an item at 100% and pad right, instead of adding divider widgets (l1425149 06:01)

The 9→2 demonstration: 'I have reduced this whole section with 7 containers' (l1425149 10:03)

The PM ruling: icon-box style widgets carry more code than container+heading+text (l1425155 00:00)

'You already can build more efficiently than what the Elementor templates provide' — shown on their current library (l1425155 08:01)

Spacer widget verdict from the height lesson: 'an amateur widget... I don't know why Elementor still has this' (l1425139 02:02)

↓ Full write-up of this concept

05Custom positioning: a four-tier hierarchy, cheapest firstPositioning tiers, cheapest first: (1) background-overlay SVG for decoration;›

Positioning tiers, cheapest first: (1) background-overlay SVG for decoration; (2) margin — pulls siblings along, negative margin pulls sections/elements together; (3) transform offset — keeps layout space, hover-animatable, flip mirrors padding; (4) absolute — removes layout presence, corner-anchored, Elementor-warned, combined with z-index and sometimes negative margin/scale for outside-the-container art.

Tier 1 first: the circles are one exported SVG on the background overlay — 'make your life easy' (l1425152 00:00)

Margin drags what follows: 'it basically drags everything with it' — the section-pull-up tool (l1425152 06:02)

Offset keeps space; absolute deletes it — the deciding question is whether siblings should notice (l1425152 10:05)

Absolute is corner-anchored and warned-against by Elementor itself; 'not best practice... but for this situation, I think it's great' (l1425152 12:05)

z-index = visual layer order; transform hover states animate offset/scale/rotate (l1425152 14:05)

Flip flips padding sides — the trap inside the convenience (l1425152 18:08)

↓ Full write-up of this concept

The concepts in full

Everything is a container: one primitive, infinite depth, widgets as equals

The old system made you choose between sections, columns, and inner-sections — and stopped you one level deep. The container just says: box, direction, repeat forever.

Each container is vertical or horizontal (the direction feature); containers nest without limit — the old inner-section-inside-inner-section wall is gone. The subtler liberation: widgets no longer require a wrapping column. A widget can live directly beside a container inside the background container, which 'sees this container also as one widget' — equals in the layout. Every wrapper you delete is code the page doesn't ship.

Two corollaries shape practice: widgets have their own box (an icon-box with a background reads as a 'card' without any container), and anything that looks outside every container is actually inside one with custom positioning applied.

Worked example · from the session

The image-beside-container demo: dragging the image widget out of its wrapper (via the navigator — 'it's kind of buggy'), deleting the wrapper, and showing the background container treating image and sibling container identically.

Why it matters

This is the mental model the whole chapter builds on — direction plus nesting plus widget-equality generates every layout that follows.

People get this wrong

Every widget needs a container of its own.

Widgets only need SOME ancestor container — the background container suffices, and the layout treats widget and sibling container as equals.

One primitive, infinite depth, with the 1140/1120 and 35/25/20+grow numbers

You can keep adding containers inside of other containers until infinity.

For your projects

["The container/widget equality maps to HTML semantics — useful grounding for judging any page builder's output, including Lovable's."]

Try it now

Open any page you've built and count wrappers that hold exactly one widget — each is a deletion candidate via this principle.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What could the old system not do that the container does trivially?

Nest beyond one inner-section level, and place widgets directly beside containers — both now unlimited, both container-count savers.

The 1140/1120 doctrine: why the numbers are what they are

1140 'feels random. Right? But it's actually not' — it's 12 columns of 75 pixels wearing 20-pixel gaps.

The boxed container keeps content inside a fixed-width box (default 1140) while backgrounds stretch; the box does NOT scale on desktop, and that's fine — even 4K screens scale pixels, and ultra-wide users don't maximize windows. The history: 960-era boxes were 12×60px columns with the 20px gap system (implemented as 10px on each side of every column — resolving the 11-vs-12-gaps objection); bigger screens moved columns to 75px, hence 1140.

The practical consequence: designs aligned to Figma's 12-column grid measure 1120 (columns only, no outer half-gaps), so pixel-perfect builders set Site Settings → Layout → width to 1120 once, globally. On tablet and mobile, pixels stop making sense: switch the box width to percentages — 80% tablet, 85–90% mobile — which also kills the old add-side-padding-everywhere ritual. The box can also shrink for narrow editorial layouts: type any value (the slider stops at 500, typing doesn't).

Worked example · from the session

Live measurement with the screenshot tool: the box holds 1140 as the window shrinks; then the 12-column arithmetic on the whiteboard — 12×75 + 12×20 = 1140, with the 10-left/10-right gap resolution.

Why it matters

Knowing WHY the number exists is what lets you change it confidently to 1120 — or ignore it for percentage-based designs — instead of cargo-culting the default.

People get this wrong

Fixed pixel widths are obsolete on modern screens.

Desktop pixel boxes survive 4K fine (pixels scale); it's TABLET and MOBILE where pixels break and percentages take over.

For your projects

["Your course site's 1080px kb-main is the same doctrine, different grid — the transferable idea is width-from-grid, not the number."]

Try it now

Check your Figma frame: if your design hugs the 12-column grid, measure it — you'll find 1120, and your site settings should say so.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Why 1120 and not 1140 for Figma-grid designs?

The 12-column grid spans column edges — 12×75 + 11 internal 20px gaps + nothing outside = 1120; 1140 includes the outer half-gaps designs don't use.

The safe wrap numbers: 35 / 25 / 20 + grow

Three numbers replace all responsive grid math: 35 is always two columns, 25 always three, 20 always four — on any device.

Wrap moves items to the next row when widths exceed 100% — and the gap counts. So 33.3%×3 + gaps already overflows, and naive thirds break. The safe system: give items the percentage ONE COLUMN SMALLER than naive division (three columns → 25%, i.e. 100/4), then add GROW. The percentage forces the wrap point (since one more item plus gaps can never fit); grow stretches the row's survivors to the grid edges. Elementor 'will ignore the grow... it will just look at the percentage width to define what wraps.'

Device switching is the same three numbers: desktop 3-col = 25, tablet 2-col = 35, mobile = 100%. Content shortfalls get the filler trick: an empty container with identical width+grow properties holds the grid shape and disappears in preview.

Worked example · from the session

The build-out: 33.3 fails; 30 works but misaligns; 25+grow lands the 3-column layout; 20 makes four; 35 makes tablet's two; duplicating items shows the wrap point holding through row after row.

Why it matters

This is the section's signature transferable system — his Flex Grow resource sheet exists because these numbers ARE the method.

People get this wrong

Grow decides the layout.

The percentage decides where rows break; grow only stretches what's left. Items also need SOME width for grow to behave — growing from nothing overgrows.

2 columns, whatever device, is always 35 and 3 columns is always 25 and 4 columns is always 20.

This is the whole idea of the Flexbox basically. You want to make sure that Elementor makes a lot of the calculations, so that you don't have to set up a lot of things manually.

For your projects

['Directly usable in HUDDLE/SEO-o-matic layout work regardless of stack — this is CSS flex-wrap arithmetic in course clothing.']

Try it now

Rebuild any 3-column section with 25%+grow and resize the window — watch the wrap hold where naive 33% breaks.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Why 25% for a three-column layout instead of 33%?

Because gaps count: 33.3×3+gaps overflows unpredictably as screens change. 25×4+gaps can NEVER fit four, so exactly three survive per row — and grow stretches them to the edges.

The code economy: fewer containers, but never via heavy widgets

The obvious optimization — replace container+heading+text with one icon-box widget — is wrong, 'and I asked this directly to a product manager at Elementor.'

Container reduction is real speed: wrap lets one container do horizontal AND vertical duty (100%-width items force row breaks), widgets sit beside containers, padding-as-width-break replaces divider hacks — his showcase reduced a nine-container section to two. But the counter-rule matters just as much: a container plus simple widgets (heading, text editor) ships LESS code than one option-rich widget, because heavy widgets load their whole settings surface. So reduce wrappers, never by swapping simple structures for fat widgets.

The calibration: containers are cheap, not free; heavy widgets are expensive; and Elementor's own template library fails this test — 'even Elementor templates themselves are not so efficient,' demonstrated live on their newly-shipped templates.

Worked example · from the session

The 9→2 container rebuild (widgets dragged to the background container, wrap + widths doing the layout); then the icon-box-vs-container verdict from the PM conversation; then the template-library audit finding removable containers in Elementor's own showcase.

Why it matters

It converts 'site speed' from vague virtue into two concrete counting rules you can apply while building.

People get this wrong

Fewer elements always means faster.

Fewer WRAPPERS means faster; fewer-but-fatter elements can mean slower. Count shipped code, not tree nodes.

The worst of the worst you can do is to use the spacer widget... I think it's like an amateur widget.

You already can build more efficiently than what the Elementor templates provide.

For your projects

["'Vendor templates are not a quality bar' generalizes to every ecosystem — the same reason your KB extracts practice, not marketing."]

Try it now

Take one section and run both counts: wrappers you can delete via wrap, and heavy widgets you could decompose into container+simple widgets.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

When does removing a container make the page SLOWER?

When the removal works by consolidating into a heavy widget — its option surface ships more code than the container plus simple widgets did.

Custom positioning: a four-tier hierarchy, cheapest first

Anything that looks like it's floating outside the layout is inside a container wearing one of exactly four tricks — and they're ranked.

Tier 1, background overlay: decorative shapes exported as one SVG and set as the container's background overlay — 'if you can fix it with the background overlay feature, then please do it.' Tier 2, margin: pushes or (negative) pulls, and drags every following sibling along — right for pulling whole sections up, fixing icon bottom-space, squeezing elements together; wrong when siblings must stay put, and it has honest quirks ('sometimes margin and padding seem like they're living their own life... maybe I just don't understand CSS code enough'). Tier 3, transform offset: slider-positioned, keeps the widget's layout space, and its hover state animates (offset/scale/rotate on hover) — but that kept space is exactly why it can't tighten layouts. Tier 4, absolute: removes the element from layout entirely, corner-anchored (a CSS property, not Elementor's fault), with Elementor's own warning attached — reach for it only when the space-removal IS the goal, then stack with z-index.

Bonus quirk worth knowing: transform's flip mirrors the element AND its padding sides — pad left, see it right.

Worked example · from the session

The scooter hero assembled live: decorative circles via overlay SVG; the floating step-cards via absolute + z-index (design says 3-2-1, z-index says so too); the too-big element rescued by absolute + negative margin + scale; hover offset/scale animations added at the end.

Why it matters

Choosing the wrong tier is why 'floating' designs break on resize — the hierarchy encodes which costs each trick carries.

People get this wrong

Absolute positioning is the easy general-purpose tool it looks like.

It's the LAST resort — layout-blind elements create resize problems, which is why Elementor warns and why the three cheaper tiers come first.

If you can fix it with the background overlay feature, then please do it. Make your life easy because custom positioning is a bit harder.

For your projects

['The overlay-SVG-first rule is exactly your figures discipline: decoration as one asset, not structure.']

Try it now

Recreate one floating element four ways — overlay, margin, offset, absolute — and resize the window after each; the differences teach the hierarchy faster than any description.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

An image must overlap the section above without disturbing anything around it. Which tier and why?

Absolute — it's the only tier that removes the element's layout space so siblings don't react; then z-index sets the stacking.

Tools referenced

Tool	Coverage	Context
Elementor	demonstrated	The container in full: direction, boxed widths, align/justify/grow, wrap, responsive overrides, transforms, absolute, z-index, 100vh, site layout settings
Figma	demonstrated	12-column grid as the design-side source of the 1120 doctrine and the percent sheet
WordPress	mentioned	Admin bar fakes hero overflow — incognito checks

Session materials

Archived locally on V: — click to open. Companion pages link to the LMS.

lms

The Direction Feature

companion page on the platform

lms

Boxed Container

companion page on the platform

lms

The right way to create height

companion page on the platform

lms

Align items & Align self

companion page on the platform

lms

Justify content & Space between

companion page on the platform

lms

Grow for alignment

companion page on the platform

lms

Element gap usage in px

companion page on the platform

lms

Auto padding disadvantage

companion page on the platform

lms

Single row designs

companion page on the platform

lms

Multiple rows designs

companion page on the platform

lms

Using wrap for using less containers

companion page on the platform

lms

How to fix responsive issues that aren’t related to layout

companion page on the platform

lms

Custom Positioning for widgets or containers

companion page on the platform

lms

Full width & full height container designs

companion page on the platform

lms

Rounding up containers & best practices

companion page on the platform

lms

Introduction

companion page on the platform

Action items

Set the three globals now: width 1120, gap 20, container padding 0 — and pin the layers panel (l1425138, l1425144, l1425145)
Memorize 35/25/20 + grow; save the Flex Grow sheet next to your design tool (l1425148)
Purge spacer widgets and margin-spacing from an existing site; replace with padding (l1425139)
Rebuild one section counting containers before/after using wrap-reduction (l1425149)
Route every floating element through the four-tier hierarchy once, deliberately (l1425152)
Put a struggling layout on the Discord — 'maybe we can build it together in the course' (l1425152)

Resources mentioned

Resources

docResource: Flex Grow (the 12-column → percentage sheet with the safe wrap numbers)
docHis sections-and-columns YouTube video (~500k views) — the old-system predecessor
docDemo builds referenced throughout (scooter site, Volkswagen concept, course sales page)

Extraction notes

This page was built from an auto-generated transcript, which garbles product and people's names. Those were corrected silently in everything above and logged here for transparency. The warnings flag claims that were true on the recording day but change fast.

Transcript corrections applied

The transcript says	The trainer actually means
panning (throughout)	padding
WIF settings / Wish settings / with settings	width settings
skill (in transform contexts)	scale (transform property)
the I over here / X and the I	the Y (X and Y offsets)
miney 8 is pixels	minus 80 pixels (negative margin)
9 20 pixels by a thousand 80	1920 by 1080 (full HD)
13 66	1366 (laptop width)
11 40 / 11 20 / 9 60	1140 / 1120 / 960 (px widths)
view height / view heights	vh (viewport height units)
Korsh website	(client/demo site name as heard — unverified)
stealth app	(upcoming Elementor feature name as heard — likely 'Style Kit' or similar; unverified)
Physually	Visually
unwrap (when enabling)	wrap (the toggle)

True on recording day — verify before relying

Container status was 'release candidate' at recording with full rollout expected — the stability caveats and default-boxed annoyance may both be resolved for later viewers.
The Grid (CSS grid) container was beta and explicitly deferred — 'the next version of the container which is coming'; grid-based episodes were promised as updates.
The responsive-shadow gap and icon bottom-space gap are vendor-fixable any release — both workarounds should be rechecked.
An unnamed upcoming Elementor feature ('part of the stealth app', as heard) was said to add fit-to-icon sizing.
Breakpoints: 3 default, up to 6 available, his setup runs 4 — counts are configuration- and version-dependent.
The rem-based responsive padding system is teased for a later chapter — this chapter's pixel padding is transitional.