Problem

The use of icon to add visual improvement to menus is becoming more common on the web and especially in cms's. I know this can be and has been done by contrib modules in various fashions. But it would be much easier if it was a standard part of drupal's menu systems. In particular, it would be better if a themer could implement iconic menus without doing any php coding but with with css alone. There are 2 techniques in common use:
(A) A combination of class definitions in the markup and css to define and style iconic menus.
(B) Use of the html data-* in the markup plus css to style the iconic menus.
Each method has their advantages and disadvantages. But both require some additional markup to achieve their purpose. The problem then is how the additional markup is achieved in drupal.

Proposed Solution

I propose method (B) here. By taking advantage of the existing admin menu management system, a 'data-*' attribute could be added to every menu item in drupal. A themer would have to add the appropriate css to use the attribute but would not have to write any php to use it. It offers a dynamic and flexible system for implementing iconic menus. It would also be easily 'localized'. A set of drupal 'standard' css files could be provided to establish a drupal standard 'look and feel'.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jwilson3’s picture

YesCT’s picture

Issue tags: +admin toolbar

related #1848552: Toolbar icons disappear with translated menu

Forgive, I'm on an issue summary template kick. contributor task doc for updating with issue summary template http://drupal.org/node/1427826

Is the classification on this right? How does it relate to feature freeze? Maybe it's not "that" kind of feature?

YesCT’s picture

I'm guessing that posting a patch to help implement #1849712: Add theming template and prepare logic for rendering icons might be the way to go. If it's well received (or if someone just says to) then close this as a duplicate. (note that issue explicitly wont add icons, just the support for icon fonts)

dcrocks’s picture

I'm not I'm the one to decide if it is a feature request or not but some might consider it a bug that drupal's menu system does NOT support iconic menus as an administrative option. #1849712: Add theming template and prepare logic for rendering icons provides example markup and css to show how a given menu item should be modified to utilize icon fonts, but not a method so that any menu item could utilize icon fonts administratively. This issue would provide a means to generate the markup to add an icon to any menu item, as needed by the themer, from the administrative forms. It does not add any icon fonts, nor any css, to drupal. In any case I'm not sure I should work on this until #1814916: Convert menus into entities and maybe others happen.

dcrocks’s picture

Before I post a patch a couple of questions:

1) Should I restrict the value to the unicode PUA("Private Use Area") area for accessibility.
2) Should I add 'aria-hidden=true', though not uniformly supported, for accessibility.
3) Should I also add the ability to specify classes per link item on the menu-item form, since that is frequently asked for.
4) Should I differentiate for links that are/have 'span' elements.
5) Are there any validations recommended for the data input?

I hope to post a patch tonight whatever the responses

dcrocks’s picture

Well, there are a number of places that assume the only 'attribute' a menu will have is the 'title' attribute. And 'attributes' is the natural place to store the data-icon value. And so the 'options' field id being forced to only have one attribute(title) in a number of places.

dcrocks’s picture

I really can't confirm the last comment but am currently stumped. I modified the form in "MenuLinkFormController.php" and it displays correctly on the 'Edit menu link' page. I enter a value, hit save, and it returns green with 'The menu link has been saved.'. But the data isn't really saved. All I'm doing is adding a value to the 'options' property, But I cannot find out why it isn't being saved. Any pointer would be appreciated.

klonos’s picture

I really want to see this in D8, but unfortunately I cannot provide answers to your questions David. Lets hope that somebody with more insight replies soon.

dcrocks’s picture

FileSize
80.71 KB

I've attached a quick look at a simple changed form. I could use some input on that in any case. One thing that has always bothered me about these forms is the labeling. The 'title' field is actually the anchor text field and the 'description' is really the 'Title attribute'. There is some effort ([#1874353]) to correct the terminology. I think it would be better to have an 'attribute' form with multiple subitems(title, data-icon,..) as being more representative with what is being built. But I understand that a menu item is not conceptually a html anchor element' to everyone.

dcrocks’s picture

FileSize
105.28 KB

Well I finally figured it out. Now to work on the theming side. I made someappearance changes so input is greatly desired.

dcrocks’s picture

This works auto-magically just by adding it to the form but I could use some input:

This only adds the markup. Themers have to do the rest of the work.

It only is available for menu items managed by the admin forms. Menus generated by modules will have to handle it themselves(toolbar?). And no one can assume/enforce 'attributes' has only one value.

data-* is a global attribute and can be added to any element. Where else would it be worthwhile: buttons, menus, blocks? And how would you implement it?

Is some validation needed? Should I enforce range, as I mentioned in #5?

I'll add a patch soon, and I was thinking of modifying garland to show its use, since nothing is actually happening to garland.

dcrocks’s picture

Bummer. To use markup to specify the unicode character to be printed by the icon font I need to enter a "numeric character reference", ie,. a string that starts with '&#', (eg. '&#xe000' is the first character if the unicode PUA). But checkplain runs htmlspecialchars and changes the '&' to the equivalent html special character, which means html no longer considers the value as a numeric character reference. Don't know if I can get around this.

dcrocks’s picture

The basic problem is that attributes are treated as though every key/value pair is the same kind of data, ie it will be printed to the page. On anchor elements this doesn't make a big deal for the kinds of attributes typical in the past('title' and 'class' attributes) or for the new aria attributes. But it does make a difference when you want to specify other kinds of html entities, such as I am trying to do here.
The toolbar and views use classes and css to add iconic menus. I am trying to use html and css. There are lots of arguments for either choice but I think there are definite advantages for the latter in drupal menus. My choices seem to be:

1) Restrict font characters the first 128 unicode characters. This has serious accessibility problems plus obvious selection conflicts.
2) Add a test somewhere so that data-* attributes aren't subject to checkplain. Is the extra processing worth the feature?
3) Try to implement the class/css technique. In which case why not provide a generic ability to add class names to menu items through admin forms.

I like 2 of course, because I think there may be other uses for data-* attributes in drupal. Again, input would be helpful.

dcrocks’s picture

It seems to me the right place to do this in l(). But that will be changed by #1922454: Gut l(), fix theme('link'), have a working framework for consistently generated links inside and outside of Twig and maybe by others. Hmm..

dcrocks’s picture

Title: Support icon fonts in menus » Support icon fonts in menu links

Make the title a little more specific.

dcrocks’s picture

dcrocks’s picture

Here is a 1st patch. This patch only generates the markup, the css has to be done elsewhere. It works but doesn't. The icon selector is properly saved but when the html is generated the value is modified by check_plain and is unusable.

The generated markup for the menu is :

<header id="header" class="with-secondary-menu" role="banner"><div class="section clearfix">
          <nav id="secondary-menu" class="navigation" role="navigation">
        <h2 class="element-invisible">Secondary menu</h2><ul id="secondary-menu-links" class="links inline clearfix"><li class="menu-3 odd first"><a href="/~rocks/drupal8/user">My account</a></li><li class="menu-19 even last"><a href="/~rocks/drupal8/user/logout" title="" data_menu_item_icon="&amp;#xe000">Log out</a></li></ul>      </nav> <!-- /#secondary-menu -->
dcrocks’s picture

Status: Active » Needs review

needs review

dcrocks’s picture

FileSize
17.39 KB

To show the affect of check_plain, in the image from a test file below:
the button on the left shows the result of:
<a class="icon button blue sheild" href="#" title="test" data-icon="&#x27">recent content</a>
and on the right the result of
<a class="icon button blue sheild" href="#" title="test" data-icon="&amp;#x27">recent content</a>

On the left the value is treated as a numeric character reference, and on the right as a string of characters.

Damien Tournoud’s picture

Status: Needs review » Needs work

I suppose you meant data-menu-item-icon instead of data_menu_item_icon.

It seems really weird from a usability point of view to specify an HTML-encoded code point, instead of let's say a class name or similar. If you really want to purse this in this way, just run the HTML-encoded code point through decode_entities() before putting it in $menu_link->options['attributes']['data-menu-item-icon']. The change in l() is unnecessary and unwelcome.

sun’s picture

Issue tags: -admin toolbar

I agree with Damien.

Normally, you specify .icon-actionname in your HTML markup. The CSS performs the mapping from class names to icon font characters.

See #1849712: Add theming template and prepare logic for rendering icons for more info.

dcrocks’s picture

Issue tags: +admin toolbar

The data is saved correctly, but modified when rendered. The 'menu links' table in the database has the correct value. decode_entities() doesn't help at that point.

What this technique for icon fonts allows is specifying(and modifying) the code point thru the admin system rather than thru hard coding each code point in css. I can write less and more generic css as well as build flexibility thru my icon font. The research I have done show a design choice between (1)the class attribute/css or (2)the data attribute/css techniques. The toolbar module uses the 1st technique. Think about doing that for every menu in drupal. The technique I am trying to implement here is more dynamic and flexible. I don't think either technique is for novice users.

ps. A mod to AttributeString.php is all that is needed to make this work.

dcrocks’s picture

Please note that the 1st patch is minimal and meant to prove the capability. I still need to address aria concerns and provide other, more advanced, capabilities. As I said, I have a fix, though it will probably be considered a 'hack'. 'Numeric character references' are valid and completely legal html markup. I think check_plain goes too far in preventing them, for the sake of processing markup that is often never displayed on the screen.

dcrocks’s picture

FileSize
4.46 KB

As a trial, I added this code to bartik:

@font-face {
	font-family: 'fontawesome';
	src:url('../fonts/fontawesome.eot');
	src:url('../fonts/fontawesome.eot?#iefix') format('embedded-opentype'),
		url('../fonts/fontawesome.woff') format('woff'),
		url('../fonts/fontawesome.ttf') format('truetype'),
		url('../fonts/fontawesome.svg#fontawesome') format('svg');
	font-weight: normal;
	font-style: normal;
}
[data_menu_item_icon]:before {
	font-family: 'fontawesome';
	content: attr(data_menu_item_icon);
	speak: none;
	font-weight: normal;
	line-height: 1;
	-webkit-font-smoothing: antialiased;
}

It allows me to add an icon to any menu tsimpy by going to the admin pages. I've attached a sample where I entered icon code points to the User Account Menu.

dcrocks’s picture

FileSize
55.46 KB

In this image I've also added an icon to a link in the Tools menu, and removed one from the User Account menu. 10 seconds maybe.

dcrocks’s picture

I updated the issue summary to better distinguish this issue from #1849712: Add theming template and prepare logic for rendering icons. It might be better to enable both techniques but the issue still remains as to how the necessary markup is to be generated.

dcrocks’s picture

Issue summary: View changes

Update summary

markhalliwell’s picture

I'm not proposing anything for core at the moment, just thought I'd give a heads up here so you know I'm going to be tackling a solution for D7. Referencing:
#1948240: [icon] Request re-purpose/ownership change
#1929416-4: [Duplicate] Mark Fonticon module unsupported and obsolete and a duplicate of Icon API/Icomoon modules
http://dgo.to/fontello

markhalliwell’s picture

.

dcrocks’s picture

I haven't looked at back porting my stuff yet. It might be easier in d7. But right now I am hung up by #1930322: Character references should not be double encoded while rendering HTML element attributes.. You can't store data-* attributes in the menu system if they are going to be mangled when loaded.
I am a fan of the icomoon stuff. I intend to keep an eye on what you are doing.

dcrocks’s picture

#1930322: Character references should not be double encoded while rendering HTML element attributes. has been resolved, in a manner of speaking. I do have a working patch but I still want to improve the UI to make it easier for administrators. I want to provide a 'pick list' so that it is easy to select an icon without having to know the technical details. It should be done dynamically to allow easy swapping of icon fonts. There are also issues of where the font and some other things should go. At this point, no markup changes are required within drupal but some basic css has to be located somewhere. One or more 'unique' class names probably should be added to the markup drupal generates for menu links to make things easier but they aren't absolutely necessary.

klonos’s picture

If menus were entities that held references to menu item references, then we could have the menu item entities be fieldable and simply attach files to them. Everything would then come into place during display to show menus, menu items and icons attached to them as an actual menu (with icons for the menu items that had one).

webchick’s picture

Hm... that seems like it would prevent the theme from the ability to specify what admin icons should look like, which doesn't really seem like a good idea.

klonos’s picture

...that seems like it would prevent the theme from the ability to specify what admin icons should look like...

I honestly wouldn't know that. I have no idea which gears turn in order to make magic happen - I simply thought I'd through this idea on the table because:

- we now have links in core (the basis for creating a menu item - an entity with only a link field)
- we already had image and derivatives (so we could define icon sizes and attach an extra image/icon field to the menu item entity)
- we have entity reference in too (so we can reference menu items from their "parent" menu entity)

So, I just put 2 and 2 together...

dcrocks’s picture

I intend to develop using an icon font that is consistent with the toolbar overlay and other icon usage in drupal core. But it would be very useful if there were a 'drupal standard' icon collection to provide a consistent ui for drupal core. For example, the toolbar project has developed icons to visually represent the drupal concepts of 'appearance', 'extend', 'configuration', etc. But what about the drupal concepts of 'add content, 'recent content', 'forum', book', blog', etc..

This should have a home, basic css, and contain a font, a sprite file, and a directory of png and svg objects. Plus some standards on dimensions, colors, coverage(mobile ?), etc. .

This should be done in such a way that themers could override everything. And it will be important to them that standards exist for them to base their own designs on. There are multiple icon projects in contrib, as well as some issues focused on icons. But I still don't sense that a standard exists yet. This should be its own project, as it will have to be maintained through future changes to drupal and the internet environment. Perhaps there already is one project to focus this effort on?

dcrocks’s picture

At present the design applies a single icon font to the menu system. Individual menu items may or may not take advantage of it but they all see the same font and configuration. There are 4 things I need to create to support this:
(1) a font directory where the drupal standard icon font would be kept.
(2) a corresponding .info.yml mapping file used as a pick list in the menu link admin forms so that administrators don't have to know what the actual character reference codes for a given icon is.
(3) A new or modified existing configuration file allowing an administrator to change pointers for (1) and/or (2)
(4) some basic css so that this will work out of the box.

I have already implemented all of this but I didn't pay too much attention as to where things were located. I just wanted to get it to work. My 1st thought is that (3) belongs to the 'menu' module file space but the rest to the 'system' module file space. And that any overrides would be taken from either the 'sites' file space or the individual theme file space. I could use some input on this.

sun’s picture

As mentioned in #20 + #22, this issue should be retitled and fully re-purposed to:

Allow users to specify a custom CSS class for each menu link.

That's literally all about it and all you need for the most basic implementation of CSS icons, regardless of whether you're using an icon font, vector graphics, or icon images.

That said, as the extensive research and discussion in #1849712: Add theming template and prepare logic for rendering icons already clarifies, merely adding a CSS class on a wrapping element is not sufficient to achieve cross-browser-compatible and most importantly, accessible icons. For that, you need to use dedicated empty icon DOM elements instead (typically <i>). If you happen to aim for that, then we need to move forward on aforementioned issue first.

dcrocks’s picture

I agree with the usefulness of per item classes for menus. And the addition of an empty DOM element to address accessibility issues on menu items that are not 'simple' links(e.g., have an icon added). I also feel that the ability to store a icon character in the link itself, rather than in css, adds flexibility and ease of use.
I think I can do this in a way to support a variety of icon implementations while adding generic custom class support to menu items. Unless the consensus is to separate these to different issues.

dcrocks’s picture

FileSize
119.1 KB

I am about 90% complete on a patch that I hope will meet everyone's needs. Whether you want to store your icon characters in css or in the link itself, this should provide all you need but the css. This may not be in the correct order but it goes as follows.

1) add a directory in core/misc to keep resources necessary to support iconic menus: fonts, sprites, etc.

2) Add a setting in menu.settings.yml with a path to those resources.
3) Modify the forms built in MenuLinkFormController.php to do the following things:

     a) Create a collapsed 'Advanced' section to the form to keep the form simple for ordinary menu changes.

     b) Place the 'Description' part of the form in the advanced section. I've read previous comments that this wasn't in widespread use anyways and it is bit confusing perhaps as to what it really is.

     c) Add a textfield to add classes to a menu link. This is a generic  addition, again because it seems to be a wide spread practice in themes to add classes to menu links, so why not do it administratively. These classes are added to the anchor attributes.

     d) Add a checkbox to enable icons for this menu link, via an 'icon' attribute.

     e) Add a pick list to allow selection of a character from an icon font for this menu link. This 'select' form item is only visible if  (d) is enabled. It also can be ignored even if (d) is enabled.

4) Added code to test if icons are enabled on the menu link being rendered and if so do:

      a) Build an empty <i> element to be added to the link, containing an 'aria' attribute, a class with the value 'menu-link-%name', and moved the data-* font character attribute, if set, from the anchor attributes to the <i>  attributes. I think just the one class is sufficient to completely identify the link.

      b) Unset the 'icon' attribute and the data-* attribute from the anchor elements attribute before output as they would only cause confusion when read by screen readers.

5) Added minimal code to system.base.css to support icon fonts out of the box. This allows all the core themes to use icon fonts without change if they want.

I am using the icomoon site to build the icon fonts as it will also provide an equivalent sprite file as well as png and svg files. The collection should satisfy anyone's needs, no matter what technique they use to support iconic menus. I've attached an image of the expanded form page. I hope to have a patch to be reviewed soon, but input would be greatly appreciated.

dcrocks’s picture

ps. One thing I considered was whether to make the ability to add classes to a menu conditional on some flag set in menu.settings.yml. Wordpress makes class assignment conditional but it seems like any one can do it, so why do it in the 1st place?

klonos’s picture

This looks great!

markhalliwell’s picture

@dcrocks: to kind of re-emphasize what webchick is saying. To me, it sounds like you're saying that icons should be supported in core. Which yes, I agree, however where I probably disagree is that it should assume what these icons are and where they live. This make it an absolute nightmare to deal with on a theming level. Especially if the admin theme isn't going to be using these "core" icons and instead their own.

Ideally, what core really should have is some sort of Icon API, which I have been working on for D7. In fact, a lot of what you've been mentioning has been implemented or thought of. I already have icon support for blocks. Menu items, files and WYSIWYG are next. In theory, a [multi-]site could have many icon bundles, not just one. It would be a lot easier for core to simply provide an API that allows modules/themes to hook into providing icon bundles or icon render callbacks. The theming process would be handed by whatever the icon in that bundle says is the render callback: single image, sprite, webfont, etc.

I really like that you're enthusiastic about this, however might I suggest you take a look at what I'm trying to accomplish over at http://drupalcode.org/project/icon.git/blob/refs/heads/7.x-1.x:/icon.api.php.

I also added an icon selector element for forms (to make it easier for populating an icon selector on available bundles): http://drupalcode.org/project/icon.git/blob/refs/heads/7.x-1.x:/modules/icon_block/icon_block.module#l53

On a side note: I doubt this will get added to D8 anytime soon. It's unfortunately, but there are a LOT of unsolved problems with (and personal opinions about) implementing icons in a system like Drupal. This issue should instead, probably rely on a contrib module like Icon API to become a little more fully developed and then it be added in D9. If you'd like, I'd be more than happy to get your feedback over at that project to develop a more systematic approach to common and frustrating problem :)

dcrocks’s picture

There is no question that what I am doing is a hack and does not compare to your project, which really is the addition of a complete new feature to drupal. Also one, that I think, is way overdue.
The source of my interest is my desire a ways back to build a theme that provided an iconic menu. It was also a goal, actually the primary goal, of this theme to NOT rely an any contrib modules but function properly with just the standard install. And I found a way to do it. But it was a terrible hack, extremely inflexible, and not very performant(though no worse than the current toolbar).

What I felt was necessary was a way to assist this thru drupal's administrative system. I needed some way to specify that an icon would be used on a particular menu item and I, at most, would just have to add some css to my theme. Currently, in Wordpress, one goes to an administrative menu, adds some classes to a menu, writes some css and markup, and the result is an iconic menu. I thought it should be just as easy in drupal. I also discovered iconic fonts and felt, that for certain problems, they were an excellent solution because they could be easily integrated into the administrative system(though it turned out not as easy as I thought).

So I constructed this solution(hack), which is limited to menus administered by the menu/menulink modules. It will, hopefully, allow themers to specify their own set of resources, though not on a per link basis. Being able to specify different resources on a menu basis rather than the entire menu system would be very nice but I haven't figured that out yet. And I still have other problems to solve, which is why I haven't put forth a patch yet. A major one is to where everything should go. It is difficult to add new resources to drupal core.

If this is pushed out to D9, it would be best to drop my hack and focus on your solution. But the primary goal for my theme hasn't changed. It would be possible to reduce the coverage of my hack and still achieve my goal. I am really desperate for some input and would be happy to provide a less intrusive hack if It meant getting something done for D8.

dcrocks’s picture

In my mind, a minimum solution is selectively adding an empty <i> element to a target menu link with enough embedded information to uniquely style it.

markhalliwell’s picture

I understand the desire for icons to be in menu items (believe me I do), but no "hack" should really ever go in core. Albeit, it has happened in the past, but we should really avoid this for future commits. It causes more headaches down the road than they're really worth.

You can accomplish what you're needing to do on a theming (only) level. One solution would be to add a theming hook similar to what Bootstrap does to add icons to the local tasks:
http://drupalcode.org/project/bootstrap.git/blob/refs/heads/7.x-2.x:/template.php#l178

Granted, there we're adding a simple icon for every link. You would probably want to override theme_menu_link() instead and also probably do some sort of logic (probably on the href to keep it theme only dependent) to determine which icon to throw in. But as far as a dynamic UI approach, that really isn't feasible unless some sort of module is involved (see below).

I would also like for themes to declare dependencies on modules: (#474684: Allow themes to declare dependencies on modules). I'm hoping this issue gets resolved and into D8. This would certainly help bridge the gap until D9 for this type of issue. Regardless, it doesn't take much to document that a theme requires a module, both on the project page and in the README files.

I don't know if Icon API will be included in core or not. Yes, it is my ultimate goal, however I was really just saying I think it would benefit everyone to provide a contrib solution first. There are already a lot of solutions out there for adding icons to menu item. Actually figuring out how it should be done and who's responsible... that's what this issue is currently. By decoupling and building an API out of core (instead of trying to build one in core) would allow us to focus our efforts, provide more flexibility in what we do and ultimately let us get a solid API before trying to throw it in core. Only then I think would something like this issue truly be resolved.

PS, I'm not sure (because I can't find an actual issue), but I think some sort of equivalent to Menu Attributes went into D8 already. Which would help alleviate some of the UI aspects on how to specify icons. For instance, you could reserve the "rel" attribute for icons and use that in your theme_menu_link() override for your "logic". You in theory could do that now in D7.

+1 for marking this issue as D9 and postponed.

markhalliwell’s picture

Please read my comment in the Bootstrap issue queue #1940604-9: Add Icon API support for glyphicons

dcrocks’s picture

Took a look. Admit I was confused a little bit because I'm not familiar with the form. But a few comments:

1) I always get confused by drupal's nomenclature. For a menu the 'Title' is actually the anchor Text and 'Description' is the anchor Title Attribute. All the discussions I've seen on iconic menus just refer to placing the icon 'before' the menu item or 'after' it. Maybe that would be more intuitive wording.

2) Where does one place the resources and how are they identified to the code?

3) Are you really providing a wrapper for the anchor text? Isn't it best practice to just place an empty element before or after the text? One of the recommended practices is to add an 'aria-hidden="true"' to the element used to place and style the icon. You don't want that attribute to be applied to the anchor text. The form I see is:

<a href="?"><i class='icon-?  icon' aria-hidden="true"></i>text</a>

4) One of my goals was that the basic icon collection(font, sprite, etc) be consistent with other drupal iconic menus, most prominently the toolbar. Do you provide such a collection in your project?

5) How does the icon pick list get built?

markhalliwell’s picture

Version: 8.x-dev » 9.x-dev
Status: Needs work » Postponed

These are great questions (many of which have been already addressed via committed code). Instead of continuing to lengthen this issue, we should probably reserve this for actually integrating icons into core (when we get to that point). I broke off your questions into a separate issue in the Icon API: #1979088: Discussion of standards

dcrocks’s picture

Version: 9.x-dev » 8.x-dev
Status: Postponed » Active

Sorry, I'm not quite ready to quit. There are a lot of changes pending in the menu area which I think makes large changes undesirable. I also don't think waiting 4 or 5 years for this is desirable. I small enhancement now might be a better course.

markhalliwell’s picture

Quite frankly and not to sound crass, but a "small enhancement now" is not the better course. I'm not going to play status ping-pong with you, so I'll leave that up to those who actually maintain core.

If you're referring to #916388: Convert menu links into entities, then yes I agree that any further changes to the menu system in core would probably be undesirable at this point. That being said, that is exactly the point I am trying to get across:

We shouldn't put something in core that isn't yet fully realized. I say that, but I've already made significant progress in helping squash a lot of these logistical issues in Icon API.

The concept of icons in core has already spanned years of discussions and attempts. Each with their own ideas and thoughts on the matter. Many of which aren't really focused on actually putting icons in core, but rather figuring out a way to make it (for lack of better words here) an API:

http://groups.drupal.org/node/6422
http://groups.drupal.org/node/9836
#606490: Drupal GPL icons - a softfacade initiative

You're proposing a "quick" solution to ease your development process (which again, believe me I really do understand the desire to see this in core). It is, however, ultimately futile to put in existing solutions as a "hotfix" in core. It will come back to bite us in the booty (as many of us witnessed over and over). I've been putting icons in for years, granted it isn't pleasant, but that's why I'm attempting to form a fully realized API for this problem.

I also don't think waiting 4 or 5 years for this is desirable.

Just because it isn't in core, doesn't mean that you still won't have a contrib module to make it seem like it is. There are some fundamental contrib modules that I think that should be in core, but they haven't been fully flushed out yet. Nonetheless, you sometimes you have to settle with contrib until it becomes solid and widely accepted before you just "throw it in core". You're asking for out-of-the-box core capability.

Again, not to sound crass, but do you really think that given everything else they're trying to tackle with D8, menu icons is high on their priority list?

Feel free to submit patches, but I seriously doubt this issue will go very far right now given all the points I have made. There is just too many logistical issues to solve first. I instead highly recommend you help solve these issues with the Icon API. Only then can we truly present a solid approach for integrating icons with Drupal, something that has plagued us all for years.

markhalliwell’s picture

Icon API - 7.x-1.0-beta1 has been released.
Fontello - 7.x-1.0-beta4 has been released.

markhalliwell’s picture

Please read my comment on #1849712-30: Add theming template and prepare logic for rendering icons (it is a bit lengthy, sorry just a lot to say).

markhalliwell’s picture

Version: 8.x-dev » 9.x-dev
Status: Active » Postponed
  1. D8 is has been in feature freeze for a while and is now in code cleanup, please read Drupal core release cycle. The nature of this issue is a new feature. Period. This entire concept has not been fully flushed out.
  2. If Dries (or another core maintainer) wants to make this an effort (which I seriously doubt they will), then I will gladly defer to their judgement. Until then, this issue is postponed for D9.

Don't change it back, leave that to core maintainers... it's not like I'm closing the issue, I'm just saying wait.

dcrocks’s picture

Version: 9.x-dev » 8.x-dev
Status: Postponed » Active

I would rather it be reviewed with a patch in hand. I have a patch almost ready. If the decision then is to postpone or close in favor of something else, then that would be fine.

markhalliwell’s picture

Version: 8.x-dev » 9.x-dev
Status: Active » Postponed

Oh for the love of all things decent, please READ.

Core maintainers cannot always comment on EVERY issue, which is why we have documentation on how to proceed without them: Drupal core release cycle.

The issue should not be closed, it should be postponed.... for the many, many, many, many reasons I have given you.

Just stop.

markhalliwell’s picture

Issue summary: View changes

Update again. Trivial changes

dibadt’s picture

Demo for webfont icon used in drupal.

Similar photos
https://drupal.org/files/new-menu-link-form.jpg

username: demo
password: demo
http://testmenu.dibadt.ir/

klonos’s picture

This looks very promising! The "Menu Item attributes" drop-down could use more length to fit each icon+text set in a single line. Perhaps also bring the icons size a bit down to match their text. What I missed while testing it was an option to put the icon to the left/right of the text.

Thanx Morteza!!!

dcrocks’s picture

#56 What code were you using to achieve this?

dibadt’s picture

#58 Getting help from Menu attributes and used Select2 jQuery in select icon, and my javascript code for add span tag by icon class to menu!
But I think Icon API is best module for icon font, if use Select2 for UI select icon.
----------------------------
http://ivaynberg.github.io/select2/

catch’s picture

Version: 9.x-dev » 8.1.x-dev
Issue summary: View changes

Features can be added to minor releases, so moving back for now.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.