-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't focus close button on modal open/Try a modal appear animation #9900
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -278,12 +278,3 @@ body.gutenberg-editor-page { | |
.ephox-snooker-resizer-bar-dragging { | ||
background: $blue-medium-500; | ||
} | ||
|
||
// This style is defined here instead of the modal component | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not exactly sure what this means — the height of the modal is defined at responsive breakpoints already, this did not seem to account for that. But regardless of that, I may have been able to refactor this out by removing the need for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It means we shouldn't assume we're in the context of the WP Admin page when tweaking the style of the modal in the
And as far as I can tell, this PR rewrites the modal component to be shown in the same way regardless of the pagee it's used in (editor or not), so I think we're probably fine removing those. |
||
// because the modal should be context agnostic. | ||
.components-modal__content { | ||
height: calc(100% - #{ $header-height } - #{ $admin-bar-height }); | ||
body.is-fullscreen-mode & { | ||
height: calc(100% - #{ $header-height }); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Animating the margin is potentially not as performant as translate, but we can't use translate as we use that for responsive positioning at responsive breakpoints. @kjellr do you have any insights as to whether we can make this more performant? Can we use
will-change: transform;
yet? Or are we still usingtranslateZ(0)
for this?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I see what you mean — we're sort of backed into animating the margin here because of the other
transform
properties we're using. As far as I can tell, we could theoretically use translate if we declared separate, super-specific animations for each of the two breakpoints:And then declarations like these in
/modal/style.css
:... but that feels like a bit of a hack (and a longwinded one at that), and I'm not 100% sure that it gains us a lot in terms of performance. So maybe we just stick to animating the margin?
Regarding
will-change
: I'm not totally familiar with that property, but I'm getting mixed signals about its usefulness when reading the MDN page. Browser support aside, they list a lot of caveats — based on what I'm reading there, I'm not sure an animation this small actually merits the use of it.