A BBC navigation bar component broke depending on the external monitor

Original Article ↗ Hacker News Discussion ↗

Heuristic Bug and Fix

  • Core issue: code tried to infer “mouse vs keyboard” from screenX > 0 || screenY > 0. Negative coordinates on some multi‑monitor setups made pointer clicks look like keyboard activations and broke the menu.
  • The “fix” to screenX !== 0 || screenY !== 0 is widely seen as trading one fragile heuristic for another, since a real click at (0,0) would again be misclassified.

Why Distinguish Mouse vs Keyboard Activation

  • Nav button intentionally behaves slightly differently:
    • Pointer: animate menu open, focus container.
    • Keyboard/screen reader: no animation, focus first menu item.
  • Goal is accessibility parity: sighted users see the animation; keyboard/screen‑reader users get immediate, predictable focus.

Better Ways to Detect Input Source

  • Many commenters argue you should not rely on coordinates at all. Suggested alternatives:
    • pointerType / pointerId === -1 on PointerEvent click.
    • event.detail (0 for keyboard, 1+ for pointer in practice), though some call this another hack.
    • Separate keydown and pointer handlers, or global flags tracking recent mousedown vs keydown.
  • General advice: don’t overload unrelated fields; avoid “unrepresentable states” created by parallel booleans like isInvokedByMouse and isInvokedByKeyboard.

Critique of Using Screen Coordinates

  • Multiple comments say absolute screen coordinates are the wrong space anyway; clientX/pageX or element‑relative positions better fit UI needs.
  • Using (0,0) as a proxy for “keyboard” conflicts with legitimate corner clicks and automated tests. Several people call this clearly bad practice.

Security/Privacy and API Design Concerns

  • Some question why the web exposes window position and screen‑space mouse coordinates at all, given fingerprinting and tracking risk.
  • Others note historical uses: multi‑window interactions, games, analytics heatmaps, legacy HTML4 “window choreography.”

Accessibility and Web Complexity

  • Accessibility is described as genuinely hard and often hacky because browsers, OSes, and screen readers interact inconsistently.
  • There’s tension between “don’t be clever, use defaults” and the reality that some disabled users need non‑standard behaviors or custom focus management.
  • Broader critique appears of heavy custom JS for simple UI like menus and search boxes, versus simpler, more robust HTML/CSS approaches.