USR369 reported the per-flavor print still printed the full recipe/page, not just the isolated flavor -- confirming the previous fix (D991: CSS class toggle + afterprint/matchMedia listeners) didn't actually solve the underlying problem. Root cause: hiding content via a CSS class added immediately before calling window.print() is racing the browser's own layout/paint cycle -- there's no guarantee the browser has applied the new display:none rules before it captures what to print, and this is known to be inconsistent across mobile browsers. Rather than patch the same fragile in-page-hiding technique a second time, REWROTE the approach entirely: printVariation() now opens a genuinely separate browser window/tab via window.open(), writes a minimal self-contained HTML document into it (title, ingredients, the one flavor's addition, directions), and calls print() on that new window. This is structurally immune to the previous bug -- there is no 'everything else' to accidentally show, because the new window's document contains nothing but the isolated recipe+flavor. It also eliminates the return-navigation problem entirely: recipes.html itself is never modified in any way, so there's nothing to restore -- USR369 just closes the print tab and the app is exactly as he left it. Removed the now-dead printArea div, its CSS, the printing-variation body class, and the afterprint/matchMedia listeners, since none of that machinery is needed with this approach. One known tradeoff flagged: if the browser's pop-up blocker is aggressive, window.open() could be blocked -- added a user-facing alert() if that happens, since the click handler running synchronously from a real tap should satisfy most pop-up-blocker allowlisting but isn't 100% guaranteed on every browser.