I was wrapping up a client landing page in Elementor v4, and the only thing left was one decorative detail: a small shape that had to float in the corner of a section, sitting behind the text. The plan was simple. Wrap the shape in a flex container, set position: absolute, nudge it with an offset, give it a z-index so it sits behind everything. A five-minute job, I figured.
I opened the panel, switched the container to absolute, set the offset, saved. The editor said it was saved. But in the preview, the shape sat right where it always had, still inside the flex flow, still pushing its neighbors around as if nothing had changed. I re-set it, re-saved, hard refreshed. Same thing. No error in the editor, no warning, nothing. The element simply refused to leave the flow.
Chasing CSS that never existed
My first instinct was to blame caching. The site runs an optimization layer, so I suspected stale CSS being served from cache. I purged everything, regenerated Elementor's CSS from Tools, and it made no difference at all. So I stopped guessing and went straight to what was actually being rendered.
Elementor writes per-post CSS scoped to element IDs. So I curled the page and grepped for the container's ID:
curl 'https://client-site.example/landing/' | grep 'elementor-element-a1b2c3d'I was looking for position: absolute along with the top/left offsets. What I got: the CSS rule for that element existed, with its color and its padding, but not a single position declaration anywhere. Elementor simply never wrote it. The position: absolute value sat neatly saved inside _elementor_data, but it never made it into the CSS. That was the moment it all made sense: not a cache, not overridden CSS. The rule was never born in the first place.
The root cause: the underscore prefix
After comparing against an older widget whose positioning had worked on another project, I realized the JSON keys I was sending were the wrong shape. I was building this block programmatically, writing setting keys directly into _elementor_data, and I had carried over an old habit from v3.
In Elementor, legacy v3 widgets use the advanced-prefixed positioning controls: _position and _z_index. That underscore is the old convention for properties living in the Advanced tab. My fingers wrote _position for the container out of reflex.
The problem is that Elementor v4 containers do not work that way. v4 containers use UNPREFIXED intrinsic controls: position and z_index, no underscore. The prefixed _position key is silently ignored on containers. Not an error, not a fallback, just ignored. That is exactly why position: absolute never reached the CSS: Elementor accepted a value for a key it does not recognize as a container position control, then dropped it without a word.
This is the kind of bug that eats the most time precisely because it is quiet. Nothing fails loudly. The save succeeds, _elementor_data holds a value that looks correct, and the only trace that something is wrong is the silent CSS.
The fix
Once I saw the pattern, the fix was trivial: drop the underscore for the container's intrinsic controls. Use position and z_index (no underscore) on containers; on widgets, keep _position and _z_index.
Here is the correct shape for a v4 container that I wrote into _elementor_data:
{
"position": "absolute",
"_offset_orientation_h": "start",
"_offset_x": { "unit": "px", "size": 420 },
"_offset_y": { "unit": "px", "size": 236 },
"z_index": 0
}And here is the wrong shape that was being silently ignored:
{
"_position": "absolute",
"_z_index": 0
}Note the important detail: only position and z_index lose the underscore. The offset fields keep their underscore prefix on both containers and widgets: _offset_x, _offset_y, _offset_orientation_h, and so on. So it is not a "drop all underscores" rule, but a sharper split.
The mnemonic I settled on: a property intrinsic to the element itself (where it is positioned, which layer it sits on) is unprefixed on a container. A property about how the element behaves relative to its parent (the offsets) stays underscored everywhere. After I changed _position to position and _z_index to z_index, regenerated the CSS, the same curl came back with --position: absolute and the top/left offsets I expected. The shape jumped straight out of the flow and into the corner, exactly behind the text.
How to verify
Because the failure is silent, do not trust the editor view alone. Verify against the CSS that actually ships:
curl 'https://client-site.example/landing/' | grep 'elementor-element-a1b2c3d'If --position: absolute with top/left shows up there, the rule really rendered. If it is empty, your keys are probably still the wrong shape.
The takeaway
Elementor v4 changed the control-naming contract between containers and widgets, and the change does not shout when you get it wrong. Containers use position and z_index without an underscore; widgets use the underscored versions. Offset fields stay underscored on both. A mis-shaped key produces no error, just missing CSS. So whenever I touch _elementor_data directly, I stop trusting the editor's "saved" message and start asking the honest source instead: what is actually in the rendered per-post CSS?