[wp-trac] [WordPress Trac] #29988: Twenty Fifteen: Use JS/postMessage to update the color scheme instead of triggering a page refresh

WordPress Trac noreply at wordpress.org
Thu Oct 16 04:50:53 UTC 2014


#29988: Twenty Fifteen: Use JS/postMessage to update the color scheme instead of
triggering a page refresh
---------------------------+-------------------------
 Reporter:  avryl          |       Owner:
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  4.1
Component:  Bundled Theme  |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:  needs-patch    |     Focuses:  javascript
---------------------------+-------------------------

Comment (by celloexpressions):

 Replying to [comment:4 avryl]:
 > Why would you take a trip to the server just for this? Even a partial
 refresh would be slow. If duplicating the CSS is the problem, then add it
 with PHP and parse it as a template?
 Try justifying doing something like that in a bundled theme to nacin :)

 One of the things with bundled themes is that they should be reasonably
 straightforward, and as simple as possible for new "developers" to dig
 into the code. And we should also be doing it in the best-practice way.
 When it comes down to it, duplicating code in PHP and JS is not a good
 idea. Parsing the php as a template might be good, but if we were to do
 that we would want to have some sort of a core API to facilitate it.

 In terms of a core API that helps developers leverage postMessage in the
 Customizer more easily/without duplicating code, partial preview refreshes
 are the best solution we've come up with that should work for most
 theme/plugin options that have a chance of working without doing a full
 preview refresh. We've been tossing that idea around for nearly a year
 now, and have yet to come up with anything better or as accessible and
 compatible with different scenarios. It comes down to that trip up to the
 server to grab a bit of output being significantly faster than a complete
 loading of the front-end of the site as well as images, etc., even if it
 isn't as instant as a full-JS solution.

 For Twenty Fifteen, this also goes back to the two different UIs for
 colorschemes. When working with color pickers, the delay is fine, and
 maybe even better as it can be overly distracting (see the background
 color control). When working with a selector there's a straightforward
 best-practice way to implement postMessage support. With the combination,
 we don't have as many options there. Also, looking at the way the CSS is
 currently implemented, I doubt that it would convert well to JS,
 considering that it's pretty messy in PHP. I also have some suggestions
 for accessibility improvements that would increase the code complexity
 there, thinking along the lines of how [http://wordpress.org/plugins
 /fourteen-colors/ Fourteen Colors] works; that would almost certainly
 prevent a php-template-type solution from working.

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


More information about the wp-trac mailing list