[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