Enable users to add a CSS class name to a view
Attached you find a patch to add a specific class name to a view. The Views module already adds lots of class names, eg view-test view-id-test view-display-id-page_1 view-dom-id-1, but sometimes they still are not specific enough. Or not clear enough.
Example: When I need multiple more-or-less related listings (eg galleries) I create a View called galleries. In this View I create a page for every listing and change (for example) only the content type associated with that page. Currently all these pages get the same classnames. The only thing that changes is the display_id (view-display-id-page_1 into view-display-id-page_2 and view-display-id-page_3), but that is not very descriptive in the theme CSS code.
It was requested earlier (#108805: Capability to add custom class attributes to a view) but although merlinofchaos agreed that it was very useful, it is still not implemented.
I can definitely see your problem, and I can see where applying a CSS tag to the view could be VERY handy. Such a feature is going to have to wait for a time; I'm avoiding making database changes until I do Views 2, which is still a couple of months off.
I discussed this feature during the D7UX Code Sprint with yoroy and he agreed this would please lots of users.
So, let me know what you think!
| Attachment | Size |
|---|---|
| screenshot-with-css_class.png | 38.33 KB |
| add_css_class_to_views.patch | 4.9 KB |
#1
shouldn't you escape this
<?php$vars['css_class'] = $view->display_handler->get_option('css_class');
?>
like this
<?php$vars['css_class'] = views_css_safe($view->display_handler->get_option('css_class'));
?>
or not?
#2
I don't think so. views_css_safe is only used to replace _ with - and it is needed becauses it is extracted from the view name.
The css_class is entered manually and the user should be able to use underscores in its class names.
By the way, none of the settings in Views are checked on validation. Try entering *&^(*^*& as path for example. No problemo. But that's another discussion.. :p
#3
Oh, ok
My bad :)
#4
Guys, anyone interested in this? Reviews would be great!
#5
Come on guys, comments please!
#6
This would be a really. really helpfull addition!
Is the patch allready integrated in the latest dev-version of Views?
Or will it be?
#7
It will be integrated if
The maintainer thinks, its a valuable and good implemented feature
You can review the patch by using http://drupal.org/patch/apply
I totally agree with the idea of the patch. Adding a template each time for every view is hard.
My review:
The patch itself was not easy to apply because the patch was created out of root of drupal anyway. i updated this.
I moved the css configuration unders style settings and before theme, i think this is a good place, any opinions about this, see screenshot.
#8
Before we go this route (and I am not against going this route) I would like to do some Big Picture Thinking on the whole process. If we add classes here, will we need to add classes everywhere? How does this interact with the semantic views module, which I believe lets you add classes per field?
Should we automatically let all fields and all styles have a class variable? Should we then integrate that similarly to how we integrate grouping?
If we do classes, is that opening the door for something else?
As a sidenote, and would we then want to extend this to use something like CTools' CSS caching to allow users to add custom CSS on a per view/display/style basis?
#9
subscribing
#10
No, I don't think we should add classes to groups and fields. Right now themers have a valid problem. If I use Views to create specific views of related content I cannot use classes in a nice way to seperate the blocks in my CSS.
So when I have a view called Frontpage, which has, apart from the Frontpage node listing, some blocks with the latest news items, the latest comments, etc, I cannot make clear in my CSS what my layout code is about. I only can use stuff like
#views-frontpage-block1or something like that. But I want to use#sidebar .latest_newsor so.When it is possible to add a classname to my block, I can uniquely identify other fields, like title, as in .view .latest_news .title
So, it would be a simple addition with great value, especially for themers!
#11
Agree on that.
#12
... Agree with #10, we only need to add this on the view level. Once that is done, then the styling becomes much more clear because of the natural hierarchies used in CSS.
.view-name-of-my-view-block-1 .field-lead-image-fid{ ...}is MUCH more confusing (especially to a team of themers) than
.descriptive-class .field-lead-image-fid{ ...}@merlinofchaos: How does this interact with the semantic views module, which I believe lets you add classes per field?
Yes, semantic views lets you add classes per field (awsome) but not for the view's outermost wrapper
@merlinofchaos: If we do classes, is that opening the door for something else?
I think it opens the door to including "id" as well as "class" but I think that's a good thing
I think this patch (with IDs, but I can live without - however if this patch gets committed and people agree that we need ID I'll write the patch myself!) paired with semantic views would be life-changing for themers.
#13
After re-reading my comment in #12 .. an equally good solution would be to add this functionality directly to semantic views... as I see it, this would be just as good and may assuage some of the hesitancy on merlinofchaos' part.
I'm happy either way.
#14
I agree with bleen18 about this, put it in semantic views. I would love this function, but lets keep basic views ui clean! :)
#15
This cannot be accomplished in Semantic Views in a simple way because the outermost div is handled by the display plugin (page, block, attachment, node content [from views attach], etc.) and Semantic Views only wants to provide style and row style plugins.
This needs to be done for display plugins, so Views is the appropriate place for this feature request.
#16
@bangpond ... thanks for clarifying.
In that case I think this is definitely needed so we should move forward with it here. As a side note, seutje and I were debating this earlier on IRC and it is worth noting that in teh last 2 days at least three people in #drupal-support have asked for this exact functionality...
#17
The patch in #7 is worth testing, because my reading of it is that it's targeting the right spot.
Default, page and attachment displays can also be hard to target. A class attribute might make this easier in all cases, but an ID attribute also would. For blocks, it could be of limited value.
This could also be an opportunity to avoid adding classes that exist only for AJAX attachment. I wonder if this could be done in this patch, too?
#18
I have applied this patch and used it on my sandbox site and it works great except my screen looks a bit different than the screenshot in #7... see attached.
I like #7 much better, but my options are not categorized like that... thoughts?