.
Created attachment 373340 [details] [Video] 200ms ease-in-out
Created attachment 373341 [details] Patch
Comment on attachment 373341 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=373341&action=review This is really neat! > Source/WebInspectorUI/UserInterface/Views/DOMTreeContentView.css:32 > + transition: padding 200ms ease-in-out; Nit: I'd prefer to be more explicit: `transition: -webkit-padding-start 200ms ease-in-out`
Comment on attachment 373341 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=373341&action=review >> Source/WebInspectorUI/UserInterface/Views/DOMTreeContentView.css:32 >> + transition: padding 200ms ease-in-out; > > Nit: I'd prefer to be more explicit: `transition: -webkit-padding-start 200ms ease-in-out` I agree. Unfortunately while `padding-left` works as a transition property, `-webkit-padding-start` does not. We could revert to the bad ol' days of body[dir=ltr/rtl], and provide a more narrowly scoped CSS transition, but that feels like overkill.
I'm on the fence as to whether I like adding these kinds of `transition`s. On one hand, it makes it nice and smooth and feels less jarring (like the content is "added" instead of just "appearing"). On the other hand, if I'm constantly adding/removing DOM breakpoints, seeing that animation over and over may get annoying or too "slow". I'm inclined to lean towards the former, but I'd like to hear if anyone else has an opinion before r+ing.
I like it.
Comment on attachment 373341 [details] Patch (In reply to Timothy Hatcher from comment #6) > I like it. Ok, then r=me :P
Comment on attachment 373341 [details] Patch Clearing flags on attachment: 373341 Committed r247169: <https://trac.webkit.org/changeset/247169>
All reviewed patches have been landed. Closing bug.