[wp-trac] [WordPress Trac] #42001: Active Widget Not Fully Visible
WordPress Trac
noreply at wordpress.org
Thu Jan 30 17:52:41 UTC 2020
#42001: Active Widget Not Fully Visible
-------------------------------------------------+-------------------------
Reporter: fervillz | Owner: audrasjb
Type: defect (bug) | Status: accepted
Priority: normal | Milestone: 5.4
Component: Widgets | Version:
Severity: normal | Resolution:
Keywords: has-patch has-screenshots early | Focuses: ui
commit needs-dev-note |
-------------------------------------------------+-------------------------
Comment (by SergeyBiryukov):
As noted in comment:18, ever since the introduction of widgets in [5294] /
#4169, the Text and RSS widgets have been wider than others to provide
more space for input. Others generally just have a title input and a few
checkboxes and don't require additional width.
The Custom HTML widget was added in [40893] / #40907. Being modeled after
the Text widget, it kept the same width.
Some follow-up fixes that touch wide widgets one way or another over the
years:
* [5294] / #4169
* [5301] / #4169
* [5399] / #4169
* [6556] / #5583
* [7086] / #5997
* [10912] / #9511
* [10916] / #9511
* [11160] / #9511
* [21281] / #21247
* [26277] / #26117
A related IRC discussion from #26117:
https://irclogs.wordpress.org/chanlog.php?channel=wordpress-
dev&day=2013-11-19&sort=asc#m732752
My concerns with [attachment:"42001.2.diff"] (restricting all widgets to
the sidebar width) are:
* Providing less space for input, making a narrow UI element even
narrower, which doesn't seem ideal.
* It might fix the issue for core, but not for any custom widgets.
* Removing wide widgets from core and declaring that plugins or themes
should no longer be use them seems like a regression, there could be other
use cases for this additional width.
* In general, it feels more like a workaround than really addressing the
issue.
Since the main issue here is that an active widget is not fully visible
due to overlapping with another widget, I would suggest addressing that.
The widgets on this screen currently have the following `z-index`
hierarchy:
* Wide widget, open (`z-index: 100`).
* Any widget being dragged from the Available Widgets area to a sidebar
(`z-index: 100`).
* Regular widget, open (no `z-index`).
* Any widget, closed (no `z-index`).
We could utilize the [https://developer.mozilla.org/en-US/docs/Web/CSS
/:focus-within :focus-within CSS pseudo-class] (supported by
[https://caniuse.com/#search=focus-within all major browsers]) to improve
things a bit.
In [attachment:"42001.4.diff"], the hierarchy is adjusted to make sure
widget currently being interacted with always stays on top:
* Any widget being dragged from the Available Widgets area to a sidebar
(`z-index: 101`).
* Any open widget with a current focus (`z-index: 100`)
* Any widget, open (`z-index: 99`).
* Any widget, closed (no `z-index`).
--
Ticket URL: <https://core.trac.wordpress.org/ticket/42001#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list