D
P
0
← All articles Baca dalam Bahasa Indonesia

Elementor: Under the Page Builder's Hood

Elementor's Icon Widget Turns Outline SVGs Into Solid Blobs, `primary_color` Paints the Circle, and `icon-list` Has No Typography

Written by · · 6 min read
Elementor's Icon Widget Turns Outline SVGs Into Solid Blobs, `primary_color` Paints the Circle, and `icon-list` Has No Typography

While rebuilding a long page for a client site, I ran into three surprises in a row from the widget I had always treated as trivial: the icon widget. All three showed up in the same session, and all three sent me back into the editor convinced I had misconfigured something. In the end none of them were my settings. They were all built-in behaviour that nothing in the UI warns you about.

I am writing them up together because they share a pattern. The icon widget makes assumptions about what your icon looks like, and when your icon does not match those assumptions it does not complain. It just quietly breaks things.

Surprise one: outline SVGs render as solid blobs

The first component I built was a row of step cards, each with a line icon on top. The icons were outline style, meaning the SVG looked like this inside:

<path stroke="white" fill="none" stroke-width="1.5" d="..." />

Skeleton shapes. No fill, just strokes. The moment I dropped them into the icon widget, they stopped being skeletons. What rendered on the page was a solid blob, a strange silhouette of the original icon. My first thought was that the SVG files were corrupt, so I opened them in a vector editor. They were perfectly fine, strokes clean.

What confused me more: some other icons on the same page rendered correctly. Once I compared them, the difference was obvious. The good ones were filled icons, the kind that carry their own fill="#hex" inside. Every broken one was outline style.

The cause is CSS the icon widget applies to itself. The widget wants you to be able to recolour icons from the panel, so it pushes fill: var(--icon-color) onto every path inside your SVG. For a filled icon that is exactly what you want, since it makes the colour controllable. For an outline icon it is destructive. The fill="none" that made your icon a skeleton gets overridden with a full colour, and all the empty space inside the strokes becomes a coloured block. Your stroke is still being painted, it just stops reading as an outline once the space it used to enclose is a solid colour.

So neither the SVG nor my settings were wrong. The icon widget is simply written on the assumption that icons are solid shapes.

The fix: stop using the icon widget for outline SVGs. Replace it with a container plus an image widget. The container handles the background circle (background plus border-radius at 50%), and the image widget displays the SVG. The important part is that the image widget renders an SVG as an <img>, and an <img> cannot be reached by outside CSS. Your stroke and fill="none" survive intact, and the icon looks exactly like it did in the design file.

The rule I have carried since: the icon widget is safe for filled SVGs and unsafe for outline SVGs.

Surprise two: primary_color paints the circle, not the icon

The second one came from another component on the same page, a small pill with an icon sitting inside a circle. For that I used the icon widget with view: "stacked", which gives you a shape behind the icon.

I wanted a white icon on an accent-coloured circle. My reasoning was simple: the icon is the main element, so the icon colour goes into primary_color, and the circle is supporting, so it goes into secondary_color. The result came out exactly inverted. White circle, accent-coloured icon.

In stacked view the semantics are the reverse of what intuition suggests:

Once that clicked, the combination was obvious. A white icon on an accent circle means primary_color gets the accent and secondary_color gets #FFFFFF.

One more thing on the same component ate a chunk of my time: sizing. I set icon_size to the circle size I wanted and kept getting something much larger. In stacked view, icon_size is the size of the icon alone, not the shape around it. The total works out as:

total = icon_size + (2 × icon_padding)

So a 48px circle with a 24px icon inside means icon_size 24 and icon_padding 12. For the pill I was building the target was a 64px circle with a 20px icon, which puts the padding at 22:

{
  "view": "stacked",
  "shape": "circle",
  "icon_size": 20,
  "icon_padding": 22,
  "primary_color": "<accent hex, low alpha for a soft tint>",
  "secondary_color": "<icon colour hex>"
}

I set primary_color to the accent colour at a very low alpha, around 0.02, so the circle reads as a faint tint rather than a solid swatch.

Surprise three: icon-list has no typography at all

This third one briefly made me question my sanity. I built a few bullets with the icon-list widget, then opened the Style tab to set the text font. Family, size, weight, all configured. Refresh, and the text still rendered in the theme default, Inter at 16px. Not a pixel of movement.

My reflex was the usual one: some theme CSS must be winning on specificity. So I inspected the element, ready to hunt down the offending selector. There was none. What I actually found was that no typography declarations were coming out of that widget in the first place.

That turned out to be literally true. The icon-list widget schema has no text_typography_* fields at all. The only thing exposed for the bullet text is text_color. There is an icon_typography_* group, which is the misleading part because the name sounds relevant, but it only affects the Font Awesome glyph, not the text beside it. The settings I thought I was changing never existed.

So this was not a specificity bug, not a cache issue, not the wrong panel. The control simply is not there.

The fix: drop icon-list the moment you need font control. I rebuilt each bullet out of three pieces:

More nodes in the structure? Yes. But every property is actually controllable, and the result stays consistent with the rest of the page.

What I took away