Manipulate DOM elements

Manipulate DOM elements in JavaScript — with the four heights of help laid out: do it now, make it easier for the next person to accept, work out the right move when you are stuck, and learn the pattern so it stops coming back.

4prompt heights
Open it in the interactive atlas →

The four heights

The same task, four distances: today's deadline, the next reviewer, the stuck moment, the pattern.

Execute — do the immediate task

+
The marketing page needs the promo banner text updated and the close button to hide the banner.…
The marketing page needs the promo banner text updated and the close button to hide the banner. Find the banner element by id promo-banner, set its innerText to the new copy, and attach a click handler to the close button with id promo-close that sets display none on the banner. Do this and test in Chrome before pushing.

Improve — make it easier to accept

+
Before I hand the DOM changes to QA, make the banner easier to review: put the updated text near…
Before I hand the DOM changes to QA, make the banner easier to review: put the updated text near the top of the module, ensure the close handler also removes the aria-hidden attribute for screen readers, and flag any code that directly manipulates innerHTML instead of textContent.

Decide — diagnose the stuck moment

+
I changed the close handler to set element.style.display = 'none', but testers report the banner…

Close button doesn’t hide banner in Safari

I changed the close handler to set element.style.display = 'none', but testers report the banner still occupies space in Safari and VoiceOver still announces it. I can’t tell if the handler isn’t running or if CSS/ARIA is blocking it. What is the most likely cause and the quickest fix to both visually hide the banner and remove it from accessibility trees now?

Become — change the pattern

+
Over several sprints small DOM tweaks—innerHTML edits, style toggles, appendChild calls—keep…

Tiny DOM fixes keep regressing accessibility and layout

Over several sprints small DOM tweaks—innerHTML edits, style toggles, appendChild calls—keep causing layout regressions and accessibility failures. I patch one and another breaks elsewhere. Which coding habit and review practice should I adopt to stop these regressions, and what lightweight tests or lint rules would catch the usual culprits before they ship?

Next to this one

Other programming language work people do in JavaScript.

Every task here came from the work, not from a feature list — which is why the prompts name what you want done and never the button that does it. The tool changes; the work does not.
Copyright © LLOS.ai · 2026 — original pedagogy, voice, and design — all rights reserved.

The rest of the map

Same library, five ways in.