Posted by ershov.andrey on December 21, 2009 at 3:01pm
5 followers
Jump to:
| Project: | Block Class |
| Version: | 6.x-2.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
We propose a new process of setting classes for blocks:
- Coder define classes and rules in css files.
- Site administrator on a separate page for a module settings define
css classes for blocks and give them a human-readable names, whitch will
display on block settings form. - On block settings form site editor choose one or more classes from
class list, whitch consist of human-readable names given by site
administrator.
This process will improve the usability module by dividing css class
names for the coder and the site administrator and human names for the
site editor. Thus site editor can use only human-readable names of block
classes and knowing of css classes is not necessarily.
| Attachment | Size |
|---|---|
| block_class.patch | 4.37 KB |
Comments
#1
Greetings Todd,
Please take a look at this patch created by one of our developers. We found it quite useful and simple. In most cases clients want to be able to specify the desired class for certain block themselves. Since adding a class means changing CSS file there is no need to give them textfield where they can enter whatever they want. This also can become a reason of mistakes.
Instead, we propose to predefine classes and give a user friendly name for each class. Than a client can simply choose the desired class from a dropdown list.
Your thoughts?
#2
ershov.andrey and ardas: Thanks for all your work. This kind of improvement has been on our roadmap for a long time, but due to the release of Skinr and its promise, we decided to work on other stuff.
That said, our original plan was to include selectable classes in the theme's
.infofile (much like Skinr does). Please check out the 6.x-2.x-dev branch of the module to see our work thus far.Selectable classes is a feature we'd love to have, and I'd like to work with both of you to figure out the best way forward. Do you have some time to evaluate the
.infomethod contained in the 6.x-2.x-dev branch?Also, we found that handling subthemes was tricky. I'm pretty sure we made a lot of progress in that area, but it's not clear from my initial skimming of the patch whether your solution allows the inheritance of selectable classes from base themes.
#3
I'm against this idea for the simple reason that it makes it more difficult to find a class when searching for one in your site's source code.
IE: If I name a block myself, I can find it again easily if I need to view its source code or the CSS file. If a machine names my classes, and I am forced to use that name, I may not easily remember it to find it in 500+ lines of CSS or HTML source.
If this is implemented, let the module pick a name for me if it likes, but allow me to change it in the block settings as it is now if I choose.
#4
gregarios: Maybe I'm missing something, but I don't think ershov.andrey and ardas are proposing that the Block Class module choose a class name on behalf of the user. Rather, they seem to be suggesting what we've already started building into the 6.x-2.x branch of the module: Allowing the site maintainer to predefine certain available classes that can be chosen from a drop-down list.
Of course, the method employed in 6.x-2.x is a bit different than what ershov.andrey and ardas are suggesting. Our changes allow both predefined classes from a drop-down and a text field to add more classes on the fly. The predefined classes are found in the theme's .info file.
If you have some time, I'd love to hear anyone's feedback on these changes to the 6.x-2.x branch, which should satisfy everyone's needs.
#5
I see... As long as custom classes are still possible with a text-field, them I'm fine with a selectable drop-down list. I guess I misunderstood the #1 & #2 comments. I kinda got fuzzy after seeing "Since adding a class means changing CSS file there is no need to give them textfield where they can enter whatever they want." (-;
#6
Not sure if this is really on topic, but if we at least had the ability of giving a human-readable name to a created block, rather than being stuck with block-block-1, it would be a great help.
#7
msypes: The naming of blocks has nothing to do with this module. That's all handled by the Block module (
block.module) in Drupal core.The naming convention used for blocks is actually rather intuitive once you understand it:
block-MODULE_NAME-DELTA. Custom blocks, which are created by the block module, are therefore namedblock-block-X, whereXis the number of the block. Blocks created by the User module are namedblock-user-X, blocks created by the Twitter module are namedblock-twitter-X, and so on.#8
Guys,
Since, we did lots of websites for different clients from various countries I can tell you about our experience with this issue. All clients want to have a simple drop down list on the block configuration page to be able to switch between different styles. They don't want to have it as a textfield since they don't know what to enter. They need a human friendly names of their classes. On the other hand we don't give them permissions to change skinr classes and any other skinr settings since they afraid of big amount of different fields and many nested fieldsets.
So, we came to the following decision:
1. We need just one field to switch class for the block on the block configuration page.
2. This field must be controlled by its own permission (don't mix with other permissions in order not to give superfluous rights to the client)
3. This field must be a drop down list with human readable names (may be even multiple list to choose several classes)
4. Developers must have an ability to setup classes and their names from within admin area (to quickly install Drupal build for the website), no changes in the code.
5. Sometimes we don't use skinr because clients require maximum performance and they provide their own HTML which is better to use directly without any other heavy modules like skinr.
This is why we proposed this solution.
So, why not to keep skinr integration but still have our idea implemented for situations like I described? Let's think together.
Thanks.
#9
Just want to add that block_class functionality is not only for developers but for client admins (which are usualy site editors) also. This is why we think it must be very simple and clear for non technical people.
P.S. We have problems teaching clients to use Drupal core block and menu admin pages. When they see skinr fields they have panic :)
#10
I'm moving this request to the 2.x-dev branch, which long ago started moving in this direction. It's languished for awhile, though, so hopefully we can revive it.
#11
Todd,
I would like to propose you our help in maintaining this module.
ershov.andrey and me work in Ardas Group Inc (www.ardas.dp.ua) and have been working with Drupal for about 5 years.
Block Class module is used in all our web sites, we included it into our own Drupal build and it is quite important for us now.
If you agree to add us as maintainers we can guarantee not to do anything without your approval.
#12
Todd?
#13
Subscribing, interested in the development of this.
#14
ardas: Are you still interested in working on the 6.x-2.x (and perhaps 7.x-2.x) version of this module that includes these changes?
#15
Hi Todd,
Our clients again suffer from having no way to flexibly change styles since they don't know which styles to set... they want to just choose them from drop down list with user friendly names... so we are back to this problem. I saw a few other requests similar to this and ready to implement this feature in 7.x-2.x.
I also think it is a good idea to make either multiselect or a set of checkboxes (in most cases we don't have much classes).
A configuration form will be available to developers (low level permission) and block configuration form is available to site managers/editors (Administer blocks) as always so site managers can't manage classes since this will require attention of developers/themers.
Your thoughts?