Change Details

The Drawer hide event removes a few CSS classes from the Drawer’s DOM element, but it never removes the Drawer’s actual HTML, and it also doesn’t remove the CSS classes on the HTML element. == Steps to reproduce Open a reference, close a reference. Open the web inspector. == Expected results The reference drawer element should no longer exist in the DOM == Actual results The reference is still in the DOM, just below the <body/> closing tag, but hidden. {F27924858} This leads to bugs like T211691 where the `.has-drawer` class on the HTML element clashes with other classes. However, **One Does Not Simply** remove a class from the HTML element. The Drawer features a fade-in and fade-out animation, and to preserve this animation, the element must be removed after the animation finishes. This means adding a timer to the hide method (which means we should also guard against multiple calls to that timer). A timer is also prone to breakage if the CSS animation duration changes. It should be determined if we can somehow keep the CSS animation duration and the duration of the timer in sync (maybe with `window.getComputedStyle`)? **Bonus round** The Drawer is animated with a `.drawer-visible` class on the HTML element. This can //probably// be replaced with a CSS animation on the drawer itself, which will be executed when the Drawer is appended to the DOM. A CSS class would still be required to reverse the animation before the element is detached from the DOM., but at least this effect would be contained entirely in a keyframe animation, instead of in opacity, display and transition css rules. == AC - [ ] All Drawer html and CSS classes should be removed from the DOM after a drawer closes. == QA Steps Click on a reference. Close the reference. Is the Drawer element removed from the DOM? Does it still fade-in and out correctly? Repeat for CTA Drawers.

The Drawer hide event removes a few CSS classes from the Drawer’s DOM element, but it never removes the Drawer’s actual HTML, and it also doesn’t remove the CSS classes on the HTML element. == Steps to reproduce Open a reference, close a reference. Open the web inspector. == Expected results The reference drawer element should no longer exist in the DOM == Actual results The reference is still in the DOM, just below the <body/> closing tag, but hidden. {F27924858} This leads to bugs like T211691 where the `.has-drawer` class on the HTML element clashes with other classes. However, **One Does Not Simply** remove a class from the HTML element. The Drawer features a fade-in and fade-out animation, and to preserve this animation, the element must be removed after the animation finishes. This means adding a timer to the hide method (which means we should also guard against multiple calls to that timer). A timer is also prone to breakage if the CSS animation duration changes. It should be determined if we can somehow keep the CSS animation duration and the duration of the timer in sync (maybe with `window.getComputedStyle`)? **Bonus round** The Drawer is animated with a `.drawer-visible` class on the HTML element. This can //probably// be replaced with a CSS animation on the drawer itself, which will be executed when the Drawer is appended to the DOM. A CSS class would still be required to reverse the animation before the element is detached from the DOM., but at least this effect would be contained entirely in a keyframe animation, instead of in opacity, display and transition css rules. == AC - [ ] All Drawer html and CSS classes should be removed from the DOM after a drawer closes. == QA Steps [] ReferenceDrawer: Click on a reference. Close the reference. Is the Drawer element removed from the DOM? Doe s it still fade-in and out correctly [] Repeat for CTA Drawers: click the watch star while anonymously [] Repeat for RedLinkDrawer: Find a page with a red link. Click the red link.

The Drawer hide event removes a few CSS classes from the Drawer’s DOM element, but it never removes the Drawer’s actual HTML, and it also doesn’t remove the CSS classes on the HTML element. == Steps to reproduce Open a reference, close a reference. Open the web inspector. == Expected results The reference drawer element should no longer exist in the DOM == Actual results The reference is still in the DOM, just below the <body/> closing tag, but hidden. {F27924858} This leads to bugs like T211691 where the `.has-drawer` class on the HTML element clashes with other classes. However, **One Does Not Simply** remove a class from the HTML element. The Drawer features a fade-in and fade-out animation, and to preserve this animation, the element must be removed after the animation finishes. This means adding a timer to the hide method (which means we should also guard against multiple calls to that timer). A timer is also prone to breakage if the CSS animation duration changes. It should be determined if we can somehow keep the CSS animation duration and the duration of the timer in sync (maybe with `window.getComputedStyle`)? **Bonus round** The Drawer is animated with a `.drawer-visible` class on the HTML element. This can //probably// be replaced with a CSS animation on the drawer itself, which will be executed when the Drawer is appended to the DOM. A CSS class would still be required to reverse the animation before the element is detached from the DOM., but at least this effect would be contained entirely in a keyframe animation, instead of in opacity, display and transition css rules. == AC - [ ] All Drawer html and CSS classes should be removed from the DOM after a drawer closes. == QA Steps [] ReferenceDrawer: Click on a reference. Close the reference. Is the Drawer element removed from the DOM? Doe s it still fade-in and out correctly? [] Repeat for CTA Drawers: click the watch star while anonymously [] Repeat for RedLinkDrawer: Find a page with a red link. Repeat for CTA Drawers. Click the red link.