WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#24864 closed enhancement (wontfix)

Genericons!

Reported by: georgestephanis Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.7
Component: External Libraries Keywords:
Focuses: Cc:
PR Number:

Description

Since both twentythirteen and twentyfourteen use Genericons, and lots of other stuff seems to want to, let's just bundle them in core, and make it easy for anyone to use.

Attachments (1)

24864.diff (17.4 KB) - added by georgestephanis 6 years ago.

Download all attachments as: .zip

Change History (14)

#1 @georgestephanis
6 years ago

24864.diff assumes the following:

mkdir wp-includes/fonts
svn add wp-includes/fonts
svn cp wp-content/themes/twentythirteen/fonts/*.* wp-includes/fonts/
svn mv wp-includes/fonts/genericons.css wp-includes/css/genericons.css
svn mv wp-includes/fonts/COPYING.txt wp-includes/css/genericons-COPYING.txt
svn mv wp-includes/fonts/LICENSE.txt wp-includes/css/genericons-LICENSE.txt

#2 @celloexpressions
6 years ago

Related: #24595. The decision there was that Genericons should be a theme/plugin component, but after working with both Genericons and Dashicons I would also like to see Genericons in core as they are distinct (Dashicons are very WP-admin-specific, Genericons are generic). Especially if they're also used in Twenty Fourteen.

Wouldn't hurt to come up with a better way to enqueue fonts than wp_enqueue_style() in the process; even though they're css files it seems a bit hacky.

#3 @melchoyce
6 years ago

  • Cc melissachoyce@… added

#4 @georgestephanis
6 years ago

Discussion in make.wordpress.org/ui

http://make.wordpress.org/ui/2013/07/29/discussing-genericons-and-dashicons-with-ipstenu-and-george/

General conclusion feels like support for bringing genericons into core, but not merging with dashicons. (but that may be my preference coloring it, please contradict me if so)

#5 @taupecat
6 years ago

The problem with including something like an icon font in core is that updates to core come along much more slowly. So if genericons got updated, it could be quite awhile before those updates made it to a release. This to me feels like it's better left in a plugin form, or baked into a theme directly.

#6 follow-up: @georgestephanis
6 years ago

Yes, but the same argument could be made against themes using the version of jQuery that is in core.

There may be a slightly newer version, and if a theme desperately needs that, it can test the core version and swap out to its own. But the point of this is guaranteeing a solid, reliable version that will be far more current than one that is hardcoded in a theme that doesn't get updated with every genericon release.

It is to avoid conflicts where a plugin depends on genericons, but the site is stuck using an old version, so the icons it needs aren't there and will never be.

We may lag behind a little bit, but by cutting off the peaks, we fill in the valleys. And the tips can be easily replaced by a plugin or a theme if they do it the right way until core catches up and passes ahead again.

#7 in reply to: ↑ 6 @nacin
6 years ago

Replying to georgestephanis:

And the tips can be easily replaced by a plugin or a theme if they do it the right way until core catches up and passes ahead again.

And just the same, if done right, two plugins that both use Genericons can co-exist peacefully. This is not core's problem to solve.

There are loads of reasons why not to have Genericons in core (more from IRC earlier), and I've yet to hear a legitimate reason for it that wouldn't result in us bundling pretty much anything any plugin or theme wants to use. The moment we bundle it in core, we are also severely locked in for all sorts of potential future changes. Even though multiple default themes may use it, themes are individually updated and installed — packaging it so it doesn't exist twice in the core download package isn't persuasive.

Joen, the creator of genericons, also indicated a strong preference for it remaining outside of core. It is not easy to see the forest from the trees on this one, but this seems like an obvious wontfix for the moment.

#8 @georgestephanis
6 years ago

How would you feel about something that would do a version_compare between the currently registered version of a given script/style and the version that is about to be registered or enqueued, and use the newer one?

Currently it's just whichever is registered first that wins. Being able to have the higher version win, regardless of the order registered/enqueued would solve most of the concerns.

#9 @celloexpressions
6 years ago

I think a lot of concerns have come from the proposal to merge Genericons with Dashicons. Since there seems to be consensus that that's a bad idea, let's just focus on the issue of whether or not Genericons should be bundled.

The discussion is a bit fragmented, so here are all of the pros/cons brought in from the various places discussion has been happening:

Pros:

  • Canonical version in core
  • Clearer "right way" to load, so less potential for conflicts/duplicate loading
  • Themes don't need to bundle and keep track of updates
  • Plugins can use them without the huge overhead of bundling them (relative to the size of most plugins). There is currently a huge barrier to using them in plugins, which may be why they're frequently seen as a theme-specific component
  • We discourage the use of Dashicons in the front end by bundling distinct front-end and back-end core icon fonts, thus avoiding issues when we want to update Dashicons for admin-specific purposes
  • Better definition and maintenance of scope for Dashicons and Genericons
  • Not in core twice (granted, this isn't significant according to Nacin since bundled themes != core)

Cons:

  • No IE7 support
  • We're bundling yet another thing with core
  • "They're specifically for themes, so why not bundle them in said themes?" - Nacin on IRC
  • Font updates would be tied to core updates, so they could be delayed
  • A theme might want to use an older or newer version than the core version (also, corresponding issues with WP versions that a theme supports)

Additional:

  • One alternative is to use a CDN like Google Fonts, although there are drawbacks to that approach (this solves the issues of bundling and version discrepancies)
  • "To be clear, I have no ideological opposition to Genericons being bundled with core, not at all. I just don’t see the benefits." - Joen, on make/UI
  • Joen's reasoning: "Icon fonts, when you have the process down, are pretty easy to create, and will only get easier as time goes by what with all the “convert your SVGs to an icon font in one click” services that are popping up these days. As much as I’m flattered by a side-project of mine being core canonized, I’m worried that we’re solving a non-issue and adding bloat in the process. I predict one year from now, creating a unique icon font for your theme or plugin is as commonplace as creating image sprites." (from the same comment on make/UI)

Did I miss anything? I'll leave my opinion of these pros/cons separately.

#10 @desrosj
6 years ago

  • Cc desrosj@… added

#11 @helen
6 years ago

  • Milestone 3.7 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I'm with Joen and nacin. Closing for now - you can reopen if you want, but don't put it in 3.7.

#12 @celloexpressions
6 years ago

See also my discussion with georgestephanis on IRC: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-themes&day=2013-09-17&sort=asc#m67669. Since there is resistance to including in core, we're fine with leaving the current setup, but with a clearly defined standard for how to load Genericons in a theme or plugin:

wp_enqueue_style( 'genericons', '[url to genericons.css as it is bundled with Genericons]', array(), '[Genericons version]' );

As a reminder to theme/plugin authors, using a handle other than genericons will cause multiple versions to load, which will NOT mean that the most recent version, or your version of the font will necessarily be loaded. So please play nicely.

Also note that Twenty Thirteen is doing it (slightly) wrong, see #25391 (there's a non-standard css selector).

#13 @SergeyBiryukov
6 years ago

  • Version changed from trunk to 3.7
Note: See TracTickets for help on using tickets.