[wp-trac] [WordPress Trac] #25580: Twenty Fourteen: Custom Accent Color Variants are Published Too Soon

[WordPress Trac]

#25580: Twenty Fourteen: Custom Accent Color Variants are Published Too Soon
------------------------------+------------------
 Reporter:  celloexpressions  |       Owner:
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  3.8
Component:  Bundled Theme     |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  needs-patch       |
------------------------------+------------------

Comment (by celloexpressions):

 [https://irclogs.wordpress.org/chanlog.php?channel=wordpress-
 themes&day=2013-10-15&sort=asc#m71418 Discussed this at length in
 Tuesday's IRC office hours].

 The custom accent color feature is drifting into the too-complicated-for-a
 -default-theme territory, especially with what's necessary to fix this bug
 ([attachment:25580.diff]). We need to find a way to simplify the code or
 may need to remove the feature entirely. (Sidenote: #25563 is by all means
 an enhancement and shouldn't influence our decision on the feature, as it
 should only be done if we can do it simply.)

 In terms of the usefulness of the feature, I'll again point to the value
 of subtlety. It's all about details: from the link and search icon colors
 to the text highlight color (which many people use a lot) to nav hover
 colors and the media element players. It really allows Twenty Fourteen to
 feel much different on different sites, and also reduces the need/desire
 to create a child theme for trivial design changes (ie, a valuable use of
 the customizer). I'll also point out that this feature isn't going to be
 as powerful in demonstration as it will be in practice because it effects
 more things that require interaction than visually changing the site
 (between link color and background color in immediately obvious changes).

 The general concern with the feature is complexity; particularly for
 potentially new coders who are trying to modify and/or extend Twenty
 Fourteen (the first theme they'll probably look at). While the good news
 is that this isn't going directly in functions.php (first place people
 look, and where the least experienced will go), once people get to wanting
 to use the customizer and add theme options, we make it look way more
 complicated than it needs to be.

 I would argue that having a lot of functions makes it seem more
 complicated than having fewer, well-documented functions that may be more
 complex in themselves. Lots of functions can get particularly confusing
 for newer developers if there's a lot of complicated filtering happening.
 Here are some notes on the different sources of complexity:
 - '''Visual Complexity -- file/code length''': this is largely the result
 of 85 lines of css. If we want to improve on this complexity we could
 minify the css (probably makes things worse) or do some refactoring of it
 and related code in `style.css` to make it more succinct. But at the end
 of the day, this isn't a deal-breaker by any means and should probably be
 ignored in analysis of complexity; it makes the file look much worse that
 it is, but those that know css should be able to recognize what it is and
 those that know absolutely nothing about any code are less likely to poke
 into this file.
 - '''Function Complexity -- `twentyfourteen_adjust_color`''': this
 function is undoubtedly complicated and difficult to understand even for
 many WordPress themers. However, it is well commented and is a helper
 function, nothing that anyone should need to modify or necessarily
 understand when child-theming or starter-theming. As a relatively new
 developer  myself (I started poking around in WordPress themes barely two
 years ago, and had no prior coding knowledge), I quickly learned to ignore
 the content of helper-type functions and try to understand what they did
 instead. Thus, I'm not worried about including this function because it
 does one thing: generate a variant of a given color. In fact, I think this
 function opens a lot of doors for new developers who may have a use for
 this type of a function and/or see new possibilities as a result of it.
 - '''Tons of Functions and Filters''': this is where we run into trouble.
 There's really no way that we can justify all of the filtering and
 trickery in [attachment:25580.diff] and the existing (broken)
 implementation is borderline, even with strong documentation. The concepts
 of actions and filters, and even sanitization callbacks, take a while to
 grasp, so their extensive use in this file could get us into trouble. On
 the other hand, many developers may appreciate a demonstration of the
 color generation process. If we want to make the current implementation
 simpler without removing capabilities, ''maybe'' we should look at making
 what we're trying to do (in terms of [attachment:25580.diff]) easier in
 core.

 Ultimately, my biggest concern is that people will be deterred by our
 implementation, thinking that all of its intricacies are necessary for
 doing anything with the customizer. That's where we need to simplify
 things. I'll come up with a couple of proposals for varying degrees of
 simplification soon.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25580#comment:2>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software