DEV Community: Tarek ELzoghby

The Trigger Swap That Broke Every Downstream Reference

Tarek ELzoghby — Tue, 01 Sep 2026 11:30:24 +0000

I built this workflow — a lead intake automation for a made-up client, Ferrer Window Co. — with a Form Trigger first, even though I knew from the start it needed to end up on a Webhook. That wasn't the plan drifting. It was deliberate: I'd used webhooks before and Form Trigger less, so building with Form Trigger first let me see real data coming through without also holding webhook payload structure in my head at the same time. Get the logic right, then swap the trigger once everything else was solid.

And the logic did get solid. By the time I was ready to swap, I had a full chain working: an IF node filtering out junk leads (both phone and email empty), a Set node defaulting empty message fields to "No message provided," and Sheets and Slack both branching off that same cleaned data independently. Tested both edge cases — junk lead correctly stopped, empty message correctly defaulted. Everything passed.

Then I deleted the Form Trigger, added a Webhook node, and sent a test payload through Postman.

It broke immediately.

Not the logic — the logic was fine. What broke was every single reference to the data. With Form Trigger, the payload had come through flat:

{
  "Name": "Tarek",
  "Phone": "02-011-41104-582",
  "Email": "tarekalaaelzoghby1@gmail.com",
  "Service address": "Primary school st",
  "Message": "I want to request an order",
  "submittedAt": "2026-08-24T03:24:50.089-04:00",
  "formMode": "test"
}

With Webhook, everything I actually wanted was nested one level down, sitting alongside a pile of raw HTTP metadata I didn't need:

{
  "headers": {...},
  "body": {
    "Name": "Tarek",
    "Phone": "02-011-41104-582",
    ...
  },
  "webhookUrl": "...",
  "executionMode": "test"
}

Every reference I'd written — the IF node's condition, the Set node's field mappings — pointed at $json.Name, $json.Phone, and so on. None of it was wrong, exactly. It was just pointed at a shape of data that no longer existed. The whole workflow's reasoning was intact and now unreachable.

So I went back through it node by node — the IF node's conditions, the Set node's mappings — and repointed every one from $json.X to $json.body.X. Nothing about what the workflow decided changed. Only where it looked for the thing it was deciding about.

Once that was done, I didn't just assume it worked because the references compiled. I re-ran both edge cases through the webhook path — both phone and email empty, and an empty message field — to confirm the filter still stopped junk leads and the default still kicked in, now that the data was arriving through a different shape entirely.

The part I'd flag for anyone doing this same swap later: it's not a dramatic failure. Nothing throws a loud error that points you at the fix. The workflow just quietly stops seeing the data it expects, because the trigger node changed the shape of what "the data" even means. If you built your logic against one trigger's payload structure, swapping the trigger isn't a drop-in replacement — it's a second pass through everything downstream, checking what each node thinks it's looking at.

Two Things I Got Wrong Building a Blog Preview Card

Tarek ELzoghby — Tue, 25 Aug 2026 13:58:57 +0000

This one's a small build — a blog preview card, a Frontend Mentor challenge. Nothing about it is complicated on the surface: an image, a tag, a date, a title, a description, an author. But two small pieces of it didn't work the way I expected, and both times the reason why turned out to matter more than the fix itself.

The span that wouldn't stay small

The card has a tag on it — "Learning" — styled to look like a little yellow pill sitting above the title. I reached for a <span> for it, because a span is inline by default. Inline elements only take up as much width as their content needs. That's the whole reason to use one here: I wanted a tag-shaped box, not a bar running across the card.

Except when I built it, it didn't behave like that. The tag stretched the full width of the card.

The card is a flex container with flex-direction: column. I knew that. What I hadn't connected was that flex changes the rules for its children — inside a flex container, children stretch to fill the cross axis by default, regardless of what they'd normally do outside of one. display: inline doesn't mean anything once an element becomes a flex item. The span wasn't behaving like a span anymore; it was behaving like a flex child, and flex children stretch unless told otherwise.

The fix is one line:

.card__tag {
    align-self: flex-start;
}

align-self overrides the container's default alignment for just that one element — shrink to fit your content, ignore what everyone else is doing. Once I added it, the tag went back to looking like a tag.

The part worth remembering isn't the fix. It's that "I know what this element normally does" stopped being true the moment I put it inside a flex container. Context changes behavior, even for something as basic as inline vs block.

The heading that couldn't take a hover

The title needed a hover effect — the text should change color when you mouse over it, since it's a link to the full article. I built it the straightforward way first:

<h1 class="card__title">HTML & CSS foundations</h1>

An <h1> because it's the piece's main heading. That part wasn't in question. But once I tried to add the hover behavior to it, something felt off, and it took some reasoning to figure out why.

<h1> elements aren't interactive. They don't receive keyboard focus. A mouse user would see the color change on hover just fine — but a keyboard user tabbing through the page would get nothing, no visual signal that this thing does anything at all. A screen reader wouldn't announce it as a link either, because it isn't one. It's heading text that happens to look clickable to someone using a mouse, and that's it. Anyone not using a mouse would have no way to know.

If something responds to hover, it should be something that can actually be interacted with — which meant an <a> tag, not styling applied to a heading. But I didn't want to just wrap the whole <h1> in a link and call it done, because that changes where the hover boundary sits: hover the empty space around the text, not just the text, and it still triggers. I wanted the interactive zone to match the text itself.

So the anchor goes inside the heading, not around it:

<h1 class="card__title"><a href="#">HTML & CSS foundations</a></h1>

.card__title a {
    color: inherit;
    text-decoration: none;
}

.card__title a:hover {
    color: var(--color-bg);
}

color: inherit on the anchor matters here too — browsers apply their own default link styling (blue, underlined), which would override whatever color the heading was supposed to have. Setting it back to inherit cancels that out, so the link reads as the same color as the rest of the heading until you hover it.

What changed my approach wasn't "add an anchor somewhere." It was realizing the hover target and the semantic structure needed to line up exactly — the thing that looks clickable, is clickable, exactly where it looks clickable, and nowhere else.

What both of these actually have in common

Neither one was a hard bug. Nothing crashed, nothing broke visibly in a way that demanded urgent fixing. Both were cases where something looked fine and worked almost right, and the "almost" was doing a lot of quiet work — an element not shrinking the way it should, an interaction that only half the people looking at the page would ever know existed. Small card, small build, and still two places where the obvious approach wasn't the correct one until I asked why it wasn't behaving the way I expected.

The Card That Leaned

Tarek ELzoghby — Tue, 18 Aug 2026 15:06:59 +0000

This was my first project — a small QR code card, built from a Frontend Mentor challenge. Nothing complicated: a white card centered on a colored background, with an image and two lines of text stacked inside it. I thought I was done.

Then I resized the browser to a smaller width, and the card started leaning to one side.

That was confusing on its own, because nothing in my CSS should have cared about screen width in a way that would push the card sideways. I hadn't written anything asymmetric. So the first question wasn't "how do I fix this" — it was "what is even causing this."

I reached for the debugging trick I'd read about: outline everything.

* {
    outline: 1px solid red;
}

This draws a visible border around every element on the page, whether or not it normally has one. The idea is simple — if you can't tell where an element's boundaries are, make the boundaries visible.

What I saw didn't make sense at first. The background color was filling the entire screen, the way it should. But the outlined box sitting on top of it was small — and it wasn't even centered. It had extra space on one side and almost none on the other.

That was the part that stopped me. How can the background fill the whole screen, but the body only take up a small, off-center chunk of it? The background color was set on body. If the body were really that small, the color shouldn't be filling the screen at all.

So my assumption was wrong. I was looking at the wrong element.

It took a second to place it, because the actual culprit had no visual presence anywhere in my styles — I hadn't given it a color, a border, anything. It was <main>. I'd added it early on for semantic structure and then more or less forgotten it existed, because it never looked like anything. But it was still there in the HTML, still taking up space in the layout, and the browser's default styling for it was enough to throw the whole thing off-center.

That's the part I hadn't internalized yet: every element in HTML takes up layout space, even the ones you can't see. Invisibility isn't the same as absence.

The fix was one line:

main {
    display: contents;
}

display: contents removes an element from the layout entirely — visually, it's as if <main>'s children became direct children of <body>. But the element itself stays in the HTML, which matters, because screen readers and search engines still read <main> as a landmark for page structure. So I got to keep the semantic meaning without it interfering with the layout.

The card centered correctly after that, at every width.

What I actually took from this wasn't the fix itself — display: contents is a one-line answer I could have just been told. It was the order of operations that got me there: when something about spacing or alignment looks wrong and the CSS doesn't explain it, the problem is often not in the CSS at all. It's in an element you forgot was in the HTML.