[wp-trac] [WordPress Trac] #27355: Customizer: Add framework for partial preview refreshes

[WordPress Trac]

#27355: Customizer: Add framework for partial preview refreshes
-------------------------+-----------------------------
 Reporter:  westonruter  |       Owner:  westonruter
     Type:  enhancement  |      Status:  assigned
 Priority:  normal       |   Milestone:  4.1
Component:  Customize    |     Version:  3.4
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  ui, javascript
-------------------------+-----------------------------

Comment (by westonruter):

 Just wanted to jot down this idea I had regarding this: when a partial is
 in the process of being refreshing, we could apply a 0.5 opacity with a
 CSS transition (by default) to indicate that it is in the process of
 refreshing. A theme could override this with different behavior if they
 wanted.

 Also wanted to share the idea whereby partial refresh will nicely make
 possible inline editing. If each partial registered has an associated CSS
 selector for the element inside the preview that should be refreshed when
 the associated setting is changed from the Customizer pane, we can use
 this in the opposite direction as well: when clicking on an element in the
 preview, any controls that are associated with that element by the
 partials' selectors can be identified, and the entire list of controls
 relevant to that context can be filtered down. What's more is that these
 controls could be loaded up on the frontend outside the context of the
 traditional Customizer at all. You could be on a page and shift-click an
 element (for example), to trigger the Customizer control related to that
 element to be dynamically created and presented as a floating box next to
 the element. Or the control could slide up from the bottom of the window
 if on mobile.

 For settings registered with `transport=postMessage`, we should also let
 these be eligible for inclusion in the frontend in the same way, even
 though there is no specific partial that they are associated with. Perhaps
 the CSS selector shouldn't be a property of a new “Partial” object at all,
 but rather a property on the Customizer Setting object. This would allow
 any setting to be associated with one (or more) CSS selectors. The
 “postMessage” transport would then be synonymous with just a “js”
 transport. And actually, “transport” becomes somewhat of a poor name since
 there is no cross-frame communication at all if these interactions are
 happening on the front-end.

 Anyway, I wanted to dump out these ideas here, even though they should get
 a separate ticket, so that the ideas can help guide the implementation of
 partial preview refreshes as a first step.

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