- 🇦🇺Australia pameeela
I think that this is effectively resolved by Navigation → module which is now in core.
When I worked on the #2542050: Toolbar implementation creates super annoying re-rendering. → , I found the JavaScript in Toolbar is not so maintainable. And the CSS is a whole mess.
JavaScript:
- The backbone is almost useless over there. It's just used as a simple event system. It increases the code complexity and affected the start up performance. Other CORE module interactive with the Toolbar just using jQuery.html like methods. It's not so backbone as I learned and used 3 ~ 5+ years ago in other Backbone based projects. (And no one understands Backbone now)
- Some unused Drupal.toolbar.*-model vars.
- Some code logic are unclear and rely on few events or models.
- mediaQueryChangeHandler is a broken design. It's tricky. Our code just designed to make it looks like workable. Actually, it's not...perfect.
HTML / CSS:
- Over complicated.
- Not followed Drupal CSS Standard.
DESIGN:
- The 2 rows designs still create flicking on other usages. For example, Setting Tray turn on / off.. Enabled / Disabled Sub Toolbar by default became a difficult job. e.g.:
🐛
When there's non-zero latency, saving the Settings Tray causes the plain Toolbar to be visible first
Postponed: needs info
- Taking too many spaces.
- Require few clicks and page reload to perform a simple action. For example. Create a new NODE. If we adding a dropdown, no extra page loading.
- Code a new module. (Patching current module and make it back compatible seems like a huuuge job and impossible. And the amount of code changes equal to write a new module I think...)
Closed: outdated
Idea
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I think that this is effectively resolved by Navigation → module which is now in core.