{"id":5917,"date":"2025-05-22T13:27:26","date_gmt":"2025-05-22T18:27:26","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=5917"},"modified":"2025-06-04T06:05:52","modified_gmt":"2025-06-04T11:05:52","slug":"move-modal-in-on-a-shape","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/move-modal-in-on-a-shape\/","title":{"rendered":"Move Modal in on a… shape()"},"content":{"rendered":"\n

Years ago<\/a> I did a demo<\/a> where a modal was triggered open and it came flying in on a curved path. I always thought that was kinda cool. Time has chugged on, and I thought I’d revisit that with a variety of improved web platform technology.<\/p>\n\n\n\n

    \n
  1. Instead of a <div><\/code> it’ll be a proper <dialog><\/code>.<\/li>\n\n\n\n
  2. We’ll set it up to work with no JavaScript at all. But we’ll fall back to using the JavaScript methods .showModal()<\/code> and .close()<\/code> to support browsers that don’t support the invoker<\/a> command stuff.<\/li>\n\n\n\n
  3. We’ll use @starting-style<\/code>, which is arguably more verbose, but allows for opening and closing animations while allowing the <dialog><\/code> to be display: none;<\/code> when closed which is better than it was before where the dialog was always in the accessibility tree.<\/li>\n\n\n\n
  4. Instead of path()<\/code> for the offset-path<\/code>, which forced us into pixels, we’ll use shape()<\/code> which allows us to use the viewport better. But we’ll still fall back to path()<\/code>. <\/li>\n\n\n\n
  5. We’ll continue accounting for prefers-reduced-motion<\/code> however we need to.<\/li>\n<\/ol>\n\n\n\n

    Here’s where the refactor ends up:<\/p>\n\n\n\n