A One-Line CSS Fix That Wasn’t

Browsing the Svelte docs on an iPhone, a UI glitch in the REPL knob’s notch was hard to miss. It looked like a trivial open-source contribution—just one line of CSS. The reality was a multi-step investigation spanning rendering engines, local environment setup, and misdirected source maps.

Why It Only Broke on iOS

DevTools in desktop Chrome showed nothing wrong, even in mobile view. That absence was the first real clue: Chrome on iOS doesn’t render with Chrome. It uses Apple’s WebKit engine, same as Safari, which means CSS can behave differently than on desktop Chrome.

Chrome uses the iOS WebKit – which is Apple’s own mobile rendering engine and components, developed for their Safari browser – therefore it is restricted from using Google’s own V8 JavaScript engine.

iOS Safari has known rendering differences—something to keep in mind whenever a bug is visible on a phone but not on desktop Chrome.

Reproducing the Bug

After cloning the Svelte repository and running it locally, the issue still didn’t appear. Testing required an iOS simulator and an actual iPhone, with Safari’s DevTools attached to each. That gave full console and inspector access for mobile Safari.

The UI and SVG components in the Svelte site weren’t in the main repo. They lived in a separate package, @sveltejs/site-kit. To debug the CSS, local changes to site-kit needed to be visible in the running Svelte project.

That required pointing the node_modules entry in Svelte’s package.json at a local copy of site-kit. The solution was npm-link, which connects a local package directory to the project’s node_modules.

The Fix Was Still One Line

The actual correction was a single CSS rule, but finding its location took longer than expected. The project’s source maps pointed at Nav.svelte when the style actually belonged to a different component. That mapping issue is already tracked upstream—another possible contribution for someone.

Once the right file was found, the one-line change rendered correctly on both mobile and desktop.

The Real Takeaway

What looked like a small fix turned into a sequence of unfamiliar skills:

  • Running a project and linked component repository
  • Using system symlinks via npm-link
  • Understanding renderer differences between desktop Chrome and iOS WebKit
  • Emulating iOS Safari and attaching its debugger
  • Working around broken source maps

What also helped was contributing documentation for linking local site-kit development, since the process wasn’t well-covered. Small documentation fixes like that are valuable too—especially when they prevent others from rediscovering the same setup steps.

None of that depth comes up in typical day-to-day work. Open source offers problems that force you to learn the parts of a system you wouldn’t otherwise see. It’s worthwhile to keep pulling at those threads. Another Svelte issue has already led to digging into CSSStyleSheet and Safari’s handling of keyframe animations. When something breaks, tracing through the system tends to teach more than finding a quick workaround.