[wp-trac] [WordPress Trac] #20052: Support sprites for admin menu icons in register_post_type and add_menu_page

[WordPress Trac]

#20052: Support sprites for admin menu icons in register_post_type and
add_menu_page
----------------------------+-----------------------------
 Reporter:  helenyhou       |       Owner:
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Future Release
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |
----------------------------+-----------------------------

Comment (by bradyvercher):

 Perhaps I'm complicating this (that tends to happen sometimes), but this
 appears to be the amount of CSS required to get menu icons and screen
 icons with a standard state, hover/active states, and retina support when
 you call `register_post_type()` and `add_menu_page()`, in essence,
 matching the current default styles and behavior:

 {{{
 <style type="text/css">
 #icon-edit.icon32-posts-my_post_type { background: transparent
 url(../images/icons32.png) no-repeat -133px -14px;}

 #adminmenu #menu-posts-my_post_type div.wp-menu-image { background:
 transparent url(images/icons16.png) 0 0 no-repeat;}
 #adminmenu #menu-posts-my_post_type div.wp-menu-image { background-
 position: 0 -16px;}
 #adminmenu #menu-posts-my_post_type:hover div.wp-menu-image,
 #adminmenu #menu-posts-my_post_type.wp-has-current-submenu div.wp-menu-
 image { background-position: 0 -16px;}

 @media only screen and (-webkit-min-device-pixel-ratio: 1.5) {
         #icon-edit.icon32-posts-my_post_type { background-image:
 url(images/icons64.png); background-size: 32px 32px;}
         #adminmenu #menu-posts-my_post_type div.wp-menu-image {
 background-image: url(images/icons32.png); background-size: 16px 16px;}
 }


 #icon-my-plugin-page { background: transparent url(images/icons32.png) no-
 repeat 0 0;}

 #adminmenu #toplevel_page_my-plugin-page div.wp-menu-image { background:
 transparent url(images/icons16.png) 0 0 no-repeat;}
 #adminmenu #toplevel_page_my-plugin-page:hover div.wp-menu-image,
 #adminmenu #toplevel_page_my-plugin-page.wp-has-current-submenu div.wp-
 menu-image { background-position: 0 -16px;}
 #adminmenu #toplevel_page_my-plugin-page div.wp-menu-image img { display:
 none;}

 @media only screen and (-webkit-min-device-pixel-ratio: 1.5) {
         #icon-my-plugin-page { background-image: url(images/icons64.png);
 background-size: 32px 32px;}
         #adminmenu #menu-posts-my_post_type div.wp-menu-image {
 background-image: url(images/icons32.png); background-size: 16px 16px;}
 }
 </style>
 }}}

 Of course you can combine the media queries, but the specificity is
 required to override the default styles (not sure if an ID on the icon
 element would address this), the ID on the menu item isn't consistent due
 to the items being registered different ways, and the default
 'generic.png' has to be hidden when using `add_menu_page()`. That's a
 whole lot of CSS that is easy to get wrong and can be fairly complicated
 to decipher, especially for only two menu icons. In my opinion, it's a
 prime candidate for generation.

 This is how it'd work in the approach I'm advocating and I'm totally
 willing to admit it has room for improvement (named arguments?):

 {{{
 <?php
 add_menu_page(
         $page_title,
         $menu_title,
         $capability,
         $menu_slug,
         $function,
         array(
                 $image_url,
                 'x,y', // standard coordinates
                 'x,y', // hover/active coordinates
                 'x,y', // retina coordinates
                 'x,y' // retina hover/active coordinates
         )
 );

 register_post_type( 'my_post_type', array(
         'menu_icon' => array( $image_url, 'x,y', 'x,y', 'x,y', 'x,y' ), //
 same arguments as 'add_menu_page()'
         'screen_icon' => array( $image_url, 'x,y', 'x,y' ), // standard,
 retina
 ) );
 ?>
 }}}

 I'd argue that's much cleaner than the CSS approach and what exactly is
 limiting about it? For any scenario that it doesn't account for,
 `admin_head` will continue to provide the ability to overload the styles.

 So I don't see any harm in creating a simple, consistent API that does
 most everything any developer is going to need and that's also backwards
 compatible--unless I'm missing something obvious (which might be likely).

 Basically an approach similar to this would allow for devs to keep their
 code cleaner, provide a consistent API to implement new icons more easily
 and quickly, is backwards compatible, and it can be overridden in
 `admin_head`.

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