Download & Extend

Defining CSS classes/IDs in the UI

Project:Drupal core
Version:8.x-dev
Component:base system
Category:feature request
Priority:normal
Assigned:Unassigned
Status:active
Issue tags:CSS, Needs design review

Issue Summary

One of the tough things for themers to do without having to learn lots of PHP (theme function overrides, etc) is to add their own custom CSS classes or IDs to different object that Drupal spits out. Two of the most notorious places where this would be helpful is in the primary/secondary/other menu items and CCK/Core fields.

So, a feature that would help us all out tremendously would be to add a textfield which allows entry of custom classes/IDs on each page where menu items are added or maybe in the 'manage fields' section for fields. Some modules do this already and it makes targeting items with CSS much more themer-friendly.

Comments

#1

Oh, yeah. This is sooooo needed. I'd love the ability to give custom classes for menus, menu items, blocks, fields, and even individual nodes.

#2

I don't have much to add here except to say that I think this would be a hugely helpful feature for both menus and fields. I think it would also be great to implement this functionality for blocks.

The D4D group is currently considering a namespace for all classes, so once that exists and this feature is implemented, it would be great to have the field in the UI filled in by default with the class constructed from the namespace.

#3

I agree and think menus are most important.

I think theme_menu_tree() is the absolute worst offender. It has zero context, so even if you do know php and want to add a wrapper class or id, you have no choice but to override every single menu tree. This is the worst, when you are doing something like dropdown menus, and that override only needs to take place in the header.

There is a module that allows attributes for menu items that is a good helper, though I'm not sure if that's the direction you are looking to go in though: http://drupal.org/project/menu_attributes

#4

#5

Too many good issues to comment on. subscribing for now.

#6

Yes yes yes! Menu items and blocks in particular. This has come up especially when trying to work with icons -- how can you contribute a theme that uses icons or graphics with menu items when you don't know what the menu items are? But you *could* set up classes and have the end user then add them to those menu items or blocks.

This would open the door to much more flexible generic theming in Drupal, allowing several block styles to be defined in the theme (a la Panels) which then the user can decide what style goes where, rather than having to heavy-hand it using regions, even/odd, block-x, etc.

One thing that comes up is whether this would just be a free text field, or a dropdown/autocomplete based on preset styles defined in a theme?

#7

This feature got a lot of ooohs and aaahs in the design BoF at Drupalcon. Would love to see some code behind it.

#8

For an example of this, see the block edit module. It's already doing this and I have it installed by default. It would just need to extend this to menu items and move that whole thing into core. The only downside of block_edit right now is that you have to add a custom variable to your block.tpl....but I'm sure if it were in core this could be injected elsewhere.

In case any non-themers need to see where this is useful, just think about any grid-based theme: We must be able to add necessary classes easily to blocks or else we can't place them in the grid. For menu items, if we're doing image-oriented menu-items, we must have a unique class on each menu item's <li> or on it's <a> in order to target an item for CSS image replacement (although personally I think the li is preferable). To do this, I'm currently using the code snippet below in my template.php, which just adds the menu item's name as a class...but a cleaner/core way of doing this would be a good improvement:

/**
* Generate the HTML output for a menu item and submenu.
*
* @ingroup themeable
*/
function phptemplate_menu_item($link, $has_children, $menu = '', $in_active_trail = FALSE, $extra_class = NULL) {
    $class = ($menu ? 'expanded' : ($has_children ? 'collapsed' : 'leaf'));
  if (!empty($extra_class)) {
    $class .= ' '. $extra_class;
  }
  if ($in_active_trail) {
    $class .= ' active-trail';
  }

  if (!empty($link)) {
            // remove all HTML tags and make everything lowercase
            $css_id = strtolower(strip_tags($link));
            // remove colons and anything past colons
            if (strpos($css_id, ':')) $css_id = substr ($css_id, 0, strpos($css_id, ':'));
            // Preserve alphanumerics, everything else goes away
            $pattern = '/[^a-z]+/ ';
            $css_id = preg_replace($pattern, '', $css_id);
            $class .= ' '. $css_id;
    }
    return '<li class="'. $class .'">'. $link . $menu ."</li>\n";
}

#9

I use a very similar technique to Rob on ALL of my projects. I definitely think this is essential to my sites.

(In fact Rob, I'll grab some of your logic here because it does a bit more than mine. )

#10

@Rob_Feature: A patch just went in a few days ago so that each template gets a dynamically built $classes string (and sister $classes_array for raw stuff). So it should be possible to dynamically inject more stuff into here.

#11

I created issue 475734 to discuss fixing theme_menu_tree().

#12

Title:Defining CSS classes/IDs in the UI» Defining CSS classes/IDs in the UI, CSS

+1^9999 Themers need this. Long chained block classes are long, wordy and this would help clean up CSS themes.

I asked for this inclusion from the block class module. #438394: Add to Drupal 7 Core I was shot down. :-(

#13

Title:Defining CSS classes/IDs in the UI, CSS» Defining CSS classes/IDs in the UI
Issue tags:+CSS

Crossposted...

#14

You weren't shot down, you were basically just told that you posted it in the wrong place.

#15

Version:7.x-dev» 8.x-dev

New features go in 8.x now.

#16

Boooo ;)

#17

Sounds like something for contrib, ala Skinr, Blocktheme, Menu Attributes etc etc, not really something for core imo, sounds like a lot of UI/UX baggage for something not that many people would have a use case for, sure there will be some, but not the majority.

nobody click here