[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