UI layout refactor, various UI bug fixes, improvements

[dkent600]

Resolves: https://daostack.tpondemand.com/RestUI/Board.aspx#page=board/5209716961861964288&appConfig=eyJhY2lkIjoiQjgzMTMzNDczNzlCMUI5QUE0RUE1NUVEOUQyQzdFNkIifQ==&boardPopup=bug/1807/silent

Resolves: part of https://daostack.tpondemand.com/RestUI/Board.aspx#page=board/5209716961861964288&appConfig=eyJhY2lkIjoiQjgzMTMzNDczNzlCMUI5QUE0RUE1NUVEOUQyQzdFNkIifQ==&boardPopup=bug/1419/silent

• promote new proposals message shown only on scheme page (adds inSchemes property to DaoSideBar)
• better fit for large DAO names in daosidebar (less prone to clipping)
• cleaner html/css structure for daosidebar. Less reliance on float and fixed or absolute positioning, instead using flex CSS (or a table in one case).
• nicer "Loading..." on AccountProfilePage
• entirely removes reliance on Sticky component (no more .js, only .css there)
• cleaner scrolling on all the pages that were using Sticky
• better positioning of "+ New Proposal" button on SchemeContainer
• make dropdown menu (sidebar) scrollable on mobile (was clipped off the bottom on my iPhone)
• improve position of Redeem All button on Redemptions page.
• removed AccountProfile.scss, which wasn't being used
• created DaoSideBar.scss
• increases the width breakpoint when we collapse the header controls and hide sidebar (reduces chance of collision between the controls and the breadcrumb)
• vertical scrollbars are now scoped more specifically to the content they are scrolling (proposal cards, for example), rather than relying on a scrollbar scoped higher in the component hierarchy.

[tibetsprague]

oof yeah this will be painful to reconcile with my complete refactoring of the sidebar. hopefully you can take whats still important from this and build on my refactor

[dkent600]

oof yeah this will be painful to reconcile with my complete refactoring of the sidebar. hopefully you can take whats still important from this and build on my refactor

It's not as bad as it might seem, especially if you're viewing the diff with whitespace changes. I am confident I can apply what I did to whatever you've done.

[jellegerbrandy]

Some UX issues are re-introduced though :-(

This is in Ubuntu, in both Chrome and Firefox, https://alchemy-staging-rinkeb-pr-1270.herokuapp.com/dao/0x72939947e7a1c4ac94bb840e3304b322237ad1a8/scheme/0x16b81c56297ae81ffa32ed128f17dbf7b108eb9200d2c8110a9ff2e05e095995, scrollbar in proposals list:

• Also on the details page:
  

[jellegerbrandy]

ah PR that reoves a dependency is a pleasure to see :-)

[dkent600]

@jellegerbrandy I don't understand what is the problem with either of the two screenshots you gave. Looks like the scrollbar is needed in both cases. Note the comment from this PR's description:

vertical scrollbars are now scoped more specifically to the content they are scrolling (proposal cards, for example), rather than relying on a scrollbar scoped higher in the component hierarchy.

[jellegerbrandy]

Ok, I missed that in the description.

That makes thsi PR implies a rather big UI change, Did you discusss this with alex?

These "in-component" scrollbars are difficutlt to get right: they introduce new edge cases to take care of (as in the first screenshot below, where the scrollbar is outside of the window, or int he second, where we have no scrollbar at all). Also, we get a new styling problem, as the components have to look good both with and without the scrollbar and the scrollbar itself is difficult to style...)

So this is not a good idea imho.

[dkent600]

@jellegerbrandy

Did you discusss this with alex?

No, but I can't imagine a problem because what I'm doing here is a best practice and seems to me to improve the UX. When scrollbars appear they scroll exactly what one expects to be scrolled.

(as in the first screenshot below, where the scrollbar is outside of the window,

The scrollbar you're seeing is part of the sidebar (I think this is clear from the picture and you can just try scrolling it to confirm). It looks correct to me.

the second, where we have no scrollbar at all

When I go to that page I do see a scrollbar. Your screenshot is clipped off on the right and is not showing the scrollbar. However, I do see a problem which is that padding-bottom of the page should be accounting for the disclaimer box (scrollbar or not). I have corrected this.

So this is not a good idea imho.

I humbly disagree. First, we're not going from "not in-component" to "in-component". We're going from scrollbars at a higher-level component (where the coded behavior needs to capture all possibilities, something a higher-level component is less qualified to do), to the actual components that actually need the scrolling behavior. The coding becomes easier, not harder, because the scrollable component knows best what needs to be scrolled and how to do it, and the code will be orthogonal to other components.

[Addendum] There are other UI tickets outstanding that I believe may benefit from more localized handling of scrolling. One reason: by handling scrolling more locally we can avoid the hacks that are used when scrolling is managed by an external component, hacks such as using fixed positioning to prevent an entire component from scrolling, such as titles that want to remain at the top of a component.

[dkent600]

My #1 comment on this PR would be about places where a component uses "100vh" to compute its height. Such a calculation requires that the component have knowledge of where they exist in their containing UI layout. This can be OK for certain components, but not for others. Ideally we avoid it.
So I would like to like to review those calculations to see if they can be improved.

[jellegerbrandy]

• re the scrollbars: this is a break with the current design, and so not something we shoudl just change. I find this solution not very pretty, and so not an improvment, but that's just me. Looking at @A-Zak here for a final say

[jellegerbrandy]

hey @dkent600 the "in-component" scrollbars are not going to production, so i will not merge this PR as is.

there is of course lots of other good stuff in here that we would like to incude. idea on the best way to salvage that?

[dkent600]

I'm reducing this to two PRs:

#1399
#1398