[wp-trac] [WordPress Trac] #31195: Add a user-friendly way to preview site responsiveness in the Customizer

WordPress Trac noreply at wordpress.org
Tue Feb 2 06:46:06 UTC 2016


#31195: Add a user-friendly way to preview site responsiveness in the Customizer
-------------------------------------+-------------------------------------
 Reporter:  celloexpressions         |       Owner:  celloexpressions
     Type:  feature request          |      Status:  assigned
 Priority:  normal                   |   Milestone:  4.5
Component:  Customize                |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, accessibility,
  patch                              |  administration
-------------------------------------+-------------------------------------

Comment (by westonruter):

 In [attachment:31195.5.diff] ([https://github.com/xwp/wordpress-
 develop/compare/6c224c8...7d97f11 diff]):

 * Refresh patch against `trunk`
 * Call `WP_Customize_Manager::get_previewable_devices()` only once instead
 of twice (reduces filter calls)
 * Simplify PHP template logic for preview buttons; use `esc_attr()` for
 escaping (instead of translation function `esc_attr_e()`)
 * Remove unused variable; de-duplicate jQuery selector queries; rework
 indentation for chained jQuery

 There are two remaining issues I see before this is ready for committing:

 1. If I filter `customize_previewable_devices` to make `tablet` or
 `mobile` have the `default` flag, then the iframe is not initially sized
 accordingly.
 2. When previewing tablet or mobile and the preview iframe is not 100%
 height, there is a momentary doubling of the iframe when navigating around
 the site. This is the same issue discussed above in
 [https://core.trac.wordpress.org/ticket/31195#comment:43 comment 43].

 In regards to the doubling issue during navigating, the culprit can be
 found in this line of `customize-controls.js`:

 {{{#!js
 self.iframe = $( '<iframe />', { 'title': api.l10n.previewIframeTitle }
 ).appendTo( self.container );
 }}}

 This is called when the Ajax request to fetch the preview's contents
 finishes, but before the refreshed iframe's `load` event is triggered,
 which is when the old iframe is removed. Notice how the iframe is
 ''appended'' to `#customize-preview` as opposed to replacing the DOM
 element of the existing preview. I believe this is intentional, as if the
 new iframe fails to load, then the old one can remain in place. Ultimate
 the problem is that there is momentarily 2 iframes in the document, during
 the time between the Ajax request returning and the new iframe window
 triggering `load`. The quickest fix I see is to just make sure the
 `iframe` is absolutely-positioned so that the two iframes can momentarily
 overlap each other instead of momentarily stacking on top of each other:

 {{{#!diff
 --- src/wp-admin/css/customize-controls.css
 +++ src/wp-admin/css/customize-controls.css
 @@ -610,6 +610,7 @@ p.customize-section-description {
  #customize-preview iframe {
         width: 100%;
         height: 100%;
 +       position: absolute;
  }

  .wp-full-overlay-sidebar {
 }}}

 Note that the WordPress.com plugin ([attachment:customizer-device-
 preview.zip]) doesn't seem to have this issue, so perhaps its CSS could be
 more closely examined to see how it handles that issue.

 Aside: With transactions (#30937), the iframe won't get torn down and re-
 built with each request, so this issue won't be relevant when that lands.
 I'm not confident that it will land in 4.5, however.

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


More information about the wp-trac mailing list