I think it would be helpful to predefine the classes that are going to be available to the CMS admin.

A radio button in the module config could offer a free form input area or the creation of a select box. This would be very strong when the person managing the site wasn't involved in the theming.

Defaults could be the same as they are currently.

Comments

Todd Nienkerk’s picture

Assigned: Unassigned » Todd Nienkerk

My colleagues and I discussed this request at length yesterday. While we understand why you would want this feature, we concluded implementing predefined classes results in all kinds of complicated and weird behavior. Here are the problems we came across:

(1) Anybody with the access to "administer blocks" should, theoretically, understand enough about site design to handle typing in a few CSS classes into a text field. Of course, many users hate the idea of working with anything resembling "code" -- even if it's just a CSS class -- so we didn't let this stall our brainstorming.

(2) If a site admin switches from "text input" mode to "predefined class selection," there's a very good chance the predefined classes won't include all of the classes added by hand in the text field. How, then, would we handle "importing" the extraneous classes? Would they be added to the predefined list? And if not, would the be stripped out? If we don't "import" them or strip them out, the block would be stuck with a class that cannot be edited or removed until "text input" mode is turned back on.

(3) What happens when a predefined class is deleted from the list of allowed classes? Would it remove the class from all blocks that have it assigned? This is potentially destructive, and not stripping the class leads to the same problem illustrated in item (2): an invisible "phantom" class that can't be changed until the admin switches to "text input" once again.

The logic and UI necessary to elegantly handle this request is pretty big considering the relatively small stature of this module. It's not a matter of laziness on our part: Learning how to use this module -- defining classes, removing classes, knowing how one action affects other blocks, etc. -- would be complicated for nontechnical users, who just so happen to be the very same users we would be trying to help.

Instead, how do you feel about a delicious-style input of classes already used with other blocks? That is, after some classes have been added, they would appear in a "cloud" of classes. Clicking on a class would add it to the text field. Does this sound useful?

Todd Nienkerk’s picture

Status: Active » Postponed (maintainer needs more info)

I'll need some information from sperks before moving forward.

sperks’s picture

Sorry for the LOOOONG delay in responding. I've been on another none-Drupal project and neglected my duties to the community.

In answer to your question, I think that's an excellent idea. Would this cloud be currently in use or previously used? I think the themer should be able to come into the CMS, and do a clean up of the cloud at some point by adjusting the current block classes.

stephthegeek’s picture

Version: 5.x-1.0-rc » 6.x-1.1
Status: Postponed (maintainer needs more info) » Active

What about allowing a theme to define the list of classes, which would set Block Class to "predefined mode" and then show the options in a dropdown?

We are looking into doing this and would rather work with an existing module than create something new.

vince.rowe’s picture

Hi there,

I agree this would be a great addition to the module, although I do understand that this may not be required by most of the hard core users this module would attract.

When we were running Drupal 5 sites I looked into this module and decided to create my own that allowed this very thing, I'm not saying it would suit everyone or indeed that it has be integrated into this module. The reason for this is simply because I believe they are aimed at different markets (end users).

While a site developer would be running happy, I think we can agree a content publisher is not going to know what to input on an empty css class box when they are creating their latest offer block. All they want is a new thing on the home page styled like that other thing they had... fair enough I would say. They would, and do understand selecting one of three from an option list etc. options of things like, special offer, important announcement.

I would think the ultimate aim is to create some core really useful modules for people to add additional ease of styling to the current block system. So to that end I would recommend adding a small admin that allowed you to enter pre-defined class names and have that appear as an option below the free entry text field that you currently have.

For the meanwhile I'm more than willing to post to anyone that asks, the tiny module I made, in fact although it was a year ago it may well have been born directly out of looking at this module. It is 5.x though please note but its so basic I'm sure it wouldn't take more than a few minutes to update to 6.x, but does do exactly what is being discussed for future searchers reference.

Vince

Todd Nienkerk’s picture

Version: 6.x-1.1 » 6.x-2.x-dev
Assigned: Todd Nienkerk » Unassigned

This kind of functionality is included in the 6.x-2.x branch of the module. Reassigning.

berenddeboer’s picture

DYdave’s picture

Issue summary: View changes
Status: Active » Closed (duplicate)
Related issues: +#665012: Add ability to pre-define classes and choose them from a drop-down

Hi guys,

No feedback on this Feature request for more than 4 years.
Additionally, it's the last open 6.x-2.x-dev issue in the tracker... largely outdated (no maintenance anymore).
Lastly, I would agree with #7: There is already another existing issue that discusses the same feature (much more in-depth, for D7 and has code/patches) and I'm relating it to this one, so we can still keep track.

Therefore, I allowed myself to mark this issue as Closed (duplicate) for now, but feel free to re-open it, or post a new ticket, at any time if you have any further objections with the approach suggested in this ticket (we would surely be happy to hear your feedback).

Please let us know if you would have any further comments, feedback, questions, issues, objections, suggestions or concerns on the suggested solution, this comment or this ticket in general, we would be glad to provide more information or explain in more details.

Many thanks to everyone for your great help, reviews, testing, reporting and participation in this module's issue tracker.
Cheers!