[wp-trac] [WordPress Trac] #25085: Twenty Fourteen: Fix Genericons Loading

[WordPress Trac]

#25085: Twenty Fourteen: Fix Genericons Loading
------------------------------+---------------------------
 Reporter:  celloexpressions  |       Owner:  lancewillett
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  3.8
Component:  Bundled Theme     |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |
------------------------------+---------------------------

Comment (by celloexpressions):

 Replying to [comment:6 lancewillett]:
 > In [changeset:"25417"]:
 > {{{
 > #!CommitTicketReference repository="" revision="25417"
 > Twenty Fourteen: prefix Genericons enqueue handle so that the theme uses
 the its own version of the font CSS. Fixes a few display issues when
 plugins like Jetpack enqueue a different version of Genericons. See
 #25085.
 > }}}
 The purpose of this ticket is specifically '''NOT''' to do that. If we use
 a different handle, then we're only trying to step around the problem
 instead of actually fixing it. Using different handles, multiple versions
 of Genericons will load (bad for performance) and they will likely
 conflict with each other. Keep in mind that it's very possible that
 multiple plugins will load Genericons; sites could quite easily get to the
 point of having three or more versions of Genericons loading, which is
 just bad all around.

 If we absolutely must load our own specific version of Genericons, the css
 and font-family name should ALL be prefixed to avoid conflicts. That's
 also a bad idea, of course, as it makes updates unwieldly.

 The only big problem with the raw Genericons css is that it adds styles to
 `.genericon` instead of `.genericon:before`, which is why Twenty Fourteen
 can get pretty nasty with that (see [attachment:twenty-fourteen-
 genericons-2.09-from-plugin.png]). @obenland, did Joen have a reason for
 doing that, or was it accidental and forgotten to be fixed (see [comment:1
 comment 1])? If that's staying, we should adjust our uses of those classes
 in Twenty Fourteen so that we can use the bundled css.

 More broadly, this is really demonstrating that we need Genericons
 packaged in core (#24864). Having a canonical version would solve all of
 the problems we're having and make it significantly easier to use them in
 plugins. There are a lot of arguments that have been made both ways (I
 summarized them in the most recent comment), but I think that needs
 serious consideration. We would look at it from the perspective that we're
 using Dashicons for wp-admin, but those are admin-specific; Genericons are
 available for front-end uses by both themes and plugins because they're
 generic and there's interest in having an easily-accessible icon font for
 WordPress.

 Otherwise, we need to figure out a better way to make Genericons tenable
 for use in both themes and plugins. We should really never load them more
 than once, but perhaps the only commonly loaded css should define the
 fonts themselves and everything else should be left to the specific
 implementation. There also needs to be some sort of a better mechanism for
 updates; the only big problem with different versions is the addition of
 new icons in new versions, but I don't think we need to worry about
 updates breaking things unless the bundled css is significantly changed.
 With that, all we need is to make `wp_enqueue_style` do a version-compare
 if multiple copies of the same item are enqueued.

 We should probably update Twenty Thirteen to Genericons 3.0 also. And note
 that it uses `wp_enqueue_style('genericons'` to play nicely.

 I'll also point out that Jetpack caused all of the issues by loading a
 different piece of css from everyone else, but since we don't have a
 standard (which could be documented on Genericons.com), that's excusable.
 But [http://plugins.trac.wordpress.org/changeset/770391 that caused the
 Genericon'd plugin to switch from doing-it-right as well].

 At the moment, if a site were to run Twenty Fourteen, Jetpack, my
 QuickShare plugin, and Genericon'd (if they wanted the shortcodes, for
 example), '''four''' different versions of Genericons would be loaded.
 That's not an unlikely set of plugins. And for the record, things still
 break in Twenty Fourteen in that scenario, even after [25417]. The only
 thing that that fixed was the fact that Jetpack didn't load the bundled
 genericons.css file with its `wp_enqueue_style` call.

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