[wp-trac] [WordPress Trac] #51631: Refactor Layout of the Menu screens to avoid dual-buttons and responsive issues.

WordPress Trac noreply at wordpress.org
Mon Oct 26 16:54:49 UTC 2020


#51631: Refactor Layout of the Menu screens to avoid dual-buttons and responsive
issues.
-------------------------+-------------------------------------------------
 Reporter:  garrett-     |       Owner:  (none)
  eclipse                |
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Menus        |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  ui, accessibility, css,
                         |  administration
-------------------------+-------------------------------------------------

Comment (by kburgoine):

 During last weeks #core-css triage, we discussed this issue briefly again
 in relation to #49576 and there was a question raised around whether we
 could do something purely with CSS that could fix this

 > Question for CSS gurus, is there a css way to stick the bottom one at
 the bottom of the container until the container bottom is out of view then
 have it at bottom of view. Or is JS the only route for that stuff still

 https://wordpress.slack.com/archives/CQ7V4966Q/p1603398632334500

 I've spent some time looking into this and can't find a way to do this
 purely with CSS (maybe someone else can? if so please share, I would love
 to know!). CSS doesn't have a way to calculate the height of a given
 container. You could use 100vh for the height of the viewport but, to know
 if the container displays entirely on the screen you would also have to
 know the height of the header area and the height of the container itself.

 For example, if you knew the exact height of the page header area (in this
 case, shows the edit menu's and menu location tabs as well as the select
 box to choose a menu to edit) was 35vh and you also knew that the specific
 container for the menu items was 75vh then you could use something along
 the lines of a SASS function to add those two heights together and if the
 total is greater than 100, set a specific behaviour.

 However, we can't determine any of those values because the header area
 height will change responsively and could have a larger height on smaller
 screens, where items have to stack. The size of the container also depends
 on the number of menu items added to it. We would need Javascript to
 determine those values for us, and once you start using javascript there
 is probably a much more elegant solution.

 We could add some javascript here, it wouldn't be too difficult, but is
 there then a question of over-engineering?

 In my mind, the simplest solution is to remove the bottom button when it
 is a `create menu` button and keep it there when it is a `save menu`
 button.

 It's not a perfect solution because when you have first created your menu
 until you start adding menu items there are still two buttons in close
 proximity, but as you add menu items it does at least make sense as to why
 the bottom button is also there. Thoughts?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51631#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list