The jQuery Validation plugin works by examining the CSS classes assigned to an element, and will then apply preset validations (it's really awesome). I specifically wanted to validate an email form component, and the only way I could get it to work was to use jQuery to add the 'email' class to the element once the page had loaded.

Attached is a patch (webform_css_class_patch.diff) which implements the desired behaviour by allowing an Admin to specify CSS classes for the element in the form component edit interface.

It stores the CSS classes in the extra DB column, under the array key 'css_classes' (this could be changed I guess to perhaps it's own column, but it worked well for me).

Hope it proves useful!

Comments

gpk’s picture

Status:Active» Needs review

Marked #343264: css markup / suffix per field as duplicate.

I could also use something like this, though my immediate use case is more a workaround for #264181: Creating a single checkbox (the way I'm doing it is just to hide containing label of the single checkbox, which is probably not ideal).

quicksketch’s picture

Version:6.x-2.7»

Thanks gpk. Since this is a new feature, it'll only be added to the 3.x version. I wonder if #711300: Distinguish between the different types of webform-select when adding #prefix to form elements would suffice? All elements are already given a unique ID. Adding a separate class (that will probably be the same as the unique ID) doesn't seem necessary. If the jQuery Validation module only works with classes and not other selectors, sounds like a patch that could be added to that module.

gpk’s picture

IMO #711300: Distinguish between the different types of webform-select when adding #prefix to form elements is not sufficient on its own. I'm not using the jQuery validation module, but am thinking more in terms of a situation like I have now, where I want 2 different types of "checkboxes" control, though the same could be true of textfields or any other component. The idea being that I can set up the CSS to style the 2 types differently, and a user can then generate a webform and get their checkboxes styled as they want (think - 2 "house styles"). The themer (that's me!) can't know in advance what id's will be needed in CSS selectors since the users (our clients) haven't even dreamed up their form(s) yet.

It's a bit like the question of custom blocks created via the blocks.module UI in 6.x and earlier (not sure yet if 7.x takes things further forward) .. we had one site which had some blocks with border and image at the top and others with neither. If there had been an option to set a class on the block then we could just have used that in CSS selectors. Even the blocktheme module (which barely existed back then) isn't quite what's need here since blocktheme works with templates, not directly with CSS classes (you'd have to create templates with different CSS classes in the various tags). I prefer to stick with just CSS for simplicity's sake! Possibly a convoluted workaround with Views + CCK would be possible. In the end I worked round it but the solution was a little indecipherable by the time I'd finished (thankfully I never had to go back and change it).

For nodes we can do all this via ... node type.

It did occur to me that the feature addressed in this issue might belong better in a (vanishingly) small contrib module (of around 8 lines!).

Apols for the essay..

quicksketch’s picture

Hm, still seems esoteric to me. I'm betting less than a 1% usage here. It's rare enough that Webforms receive ANY theming, adding a custom class would require not only custom CSS, but also for the user building the form to actually know what the class is. Have you ever tried to make a user use classes in a WYSIWYG editor like TinyMCE or FCKeditor? Even when the list is right there in a list, classes are not intuitive to users.

gpk’s picture

>seems esoteric to me. I'm betting less than a 1% usage here. It's rare enough that Webforms receive ANY theming
I guess it depends on the sort of site you are working on. I always end up theming webforms (though this is only the 3rd site I've used it on). The more "esoteric" stuff (in 2 out of 2 cases) has been required on sites for professional services companies (in the IT sector as it happens), so they have staff on-hand who are able and sufficiently motivated to use such a "class" appropriately. Agree that many users might simply be confused by an additional form element in the UI.

For my own particular use case, I could actually work around using #310195: Make field labels optional since I could then use markup (which sets a class :P) in place of the label to get the styling done in the right way, though that is not ideal since a label "for", with different styling options, would be better (I think) for accessibility.

Maybe let's wait and see if anyone else wants this.

John Pitcairn’s picture

Version:» 6.x-3.x-dev

Count me in. I always need to style forms, and I'd have considerable use for being able to give any component a specific class in the webform UI, allowing very easy css modification without regard to where that component is or what webform thinks its ID should be. Additionally, when cloning a component or fieldset, the class would already be set appropriately, whereas an ID has to be changed so it is unique.

That's the problem with unique IDs - they have to be unique. Currently it's usually necessary to manually add ALL the unique id attributes as selectors for a css rule, it would be great to do that with a single class selector and not have to edit the stylesheet at all when components are added or cloned.

Kind of like the Block Class module does for blocks, and that's VERY handy.

quicksketch’s picture

Thanks for your input johnpitcairn. Your response gave me a potential idea.

What if we continued to generate unique IDs for each component (actually I think this is not actually the case, since Webform does not take into consideration parentage as it should when creating IDs), but then we converted the form_key to a class name? Then cloned elements within different fieldsets would have the same class name. It's not as flexible as a straight-up class textfield of course, but as I said above, I'm a little leery of adding what would be an esoteric option for most users.

John Pitcairn’s picture

Yes, form_key as css class rather than css id would be useful in many situations. I've noticed that form_key doesn't have to be unique if the parent fieldset is different, so css class would be w3c-compliant, whereas css id is not compliant if elements in different fieldsets wind up with the same id.

I'd still have a desire for the "advanced" ability to add a custom class, especially when cloning within the same fieldset, where the field_key presumably does have to be unique. Resorting to wrapping things in non-semantic fieldsets just to get a fresh namespace is not my cup of tea.

How about something like this:

The field_key does not have to be unique in the UI, even within the same parent.

CSS class attribute is added corresponding to the field_key.

Webform appends a numeric identifier, or array index, or such.

CSS id attribute is created based on that.

quicksketch’s picture

The field_key does not have to be unique in the UI, even within the same parent.

The entire purpose of the form key is to provide a unique "name" attribute. If we start auto-appending numbers then there's no point in asking for a form_key at all all and we could just switch to using numeric IDs (Webform already keeps numeric IDs for all fields internally). I'm not a fan of this particular route, though it certainly would simplify the interface, because we wouldn't have to ask for any machine name at all.

What you've described is basically get rid of the form_key field and replace it with a CSS class.

John Pitcairn’s picture

I see your point. OK, still a big yes to css class from form_key.

adeb’s picture

Subscribing.
At the moment I have to write CSS for every form element ID, it would be so much easier if I could supply a CSS class.
This option could go in a collapsible "Advanced Options" area perhaps?

hass’s picture

Need this functionality, too.

AlbinoFlea’s picture

I agree, would find this extremely useful.

thijsvdanker’s picture

subscribing, would help me alot

thijsvdanker’s picture

StatusFileSize
new1.75 KB

Updated the patch from TS to the current webform release (6.x-3.6), works like a charm for me. Maybe we can show/hide the class field with a setting somewhere so the interface would not get cluttered for normal users?

thijsvdanker’s picture

I'd like to write a custom module to add this class behavior to webforms (see #15 patch). Adding the class form field to the webform_edit_form is easy, but is there a proper way to hook into the rendering of the components?
@quicksketch: If you could give me a pointer I'd really appreciate it!

scottrigby’s picture

Status:Needs review» Needs work

@quicksketch: re #7 I agree this is a bit of an edge case. But on a few projects we're applying the a style rule to a bunch of similar elements (until now, requiring a new selector line for each unique element ID. This patch trims my css selector list down to one line.

@thijsvdanker: re #15 one small typo, otherwise works well :) Probably need another roll against 6.x-3.x-dev tho

-    '#default_value' => isset($component['display']['css_classes']) ? $component['extra']['css_classes'] : '',
+    '#default_value' => isset($component['extra']['css_classes']) ? $component['extra']['css_classes'] : '',
robertom’s picture

Version:6.x-3.x-dev» 7.x-3.x-dev
Status:Needs work» Needs review
StatusFileSize
new2.9 KB

I need this capability on webform 7.x-3.9.

I have modified the patch released in this thread for my personal necessity (rolled on 7.x-3.x-dev). I have added also custom css classes for wrapper.

I agree with quicksketch that this is a esoteric options, but I use a theme based on 960.gs and arrange the fields only by adding a few custom classes is a pleasure

robertom’s picture

re-rolled on current git version (4cca9de)

if "custom css classes" must be implemented with external module, I think that is needed this hooks:

hook_webform_render_component_alter()
hook_webform_theme_component_alter()

#946956: Implement alter() hook to allow external module to extend existing components?

quicksketch’s picture

I'm still very hesitant about this functionality but I appreciate the effort @robertom. A few issues:

- Please "Sentence case" comments, starting with a capital letter and ending with a period.
- Generally I try to avoid using $element['#webform_component'] whenever possible and use a dedicated attribute. I'm not sure what would make a good name for a wrapper class. Maybe #wrapper_attributes['class']? Proper attributes make integration with Form Builder easier to port.

jpstrikesback’s picture

StatusFileSize
new2.73 KB

This is such a relief, being able to grid theme the wrappers and the item is speeding up my form theming big time. Big +10 to this one and here's a reroll against current master branch (with "Sentence case" fix)

jpstrikesback’s picture

StatusFileSize
new2.84 KB

oops...put the field class in the display only bit...re-reroll attached

jpstrikesback’s picture

Quick update...this is not compatible with Select - Or - Other, it knocks out the Field class and get's crazay

Bensbury’s picture

Hi,

I disagree it is an edge case.
I'm glad this is being done.
I feel it would be an edge case because people can't currently do it, which is to say, a reason that webforms are rarely styled could well be because it is rather difficult without the ability to assign classes to components.
Individual IDs are okay, but defining a class for sets, or allowing zebra striping saves having to target each component individually.
I feel that this functionality is not much different from that in menu modules which offer the functionality to add attributes to the links.

Alternatively a separate module could be created like menu attributes, but call it form attributes or something, because regarding menu styling, I always use that module and so would find it equally invaluable when having to style forms, which by comparison is a meaty task.

I think this functionality would be very welcome among themers as an inclusion or add-on module.
I hope it can be back-ported or created for D6 too (^_-)b

Thanks.

Anybody’s picture

Adding custom css classes is a really deserved feature which is being provided by several modules like panels and others already.
Separating that into a further module might also be legitimate. All in all it would help themers a lot in styling the webforms, which is surely one of the best and most used drupal modules!
+1

phKU’s picture

I stumbled on this thread while searching a doc page for this usage.

I'm very surprised that this must have Drupal module doesn't include this very useful functionality. In my present case study, I would like to give the [visibility: hidden] css propriety to a couple of component for further jquery hide/show manipulation depending on inputs configuration. I will turn around with the multiple ID selectors definition solution but this is not very smart…

I add my wishes for have it included in a very next release :)
Thank you.

hermes_costell’s picture

The ability to add a class to a form attribute would be gigantic. It means that the person doing the themeing doesn't need to put the unique ID for each webform into the style sheet, but rather can declare styles once, and then on the admin end the same style can be added for each form that's to be styled in that particular way.

Furthermore the ability to add a class to an individual form element would take this module to the next level.

Need it be said that I also don't see this at all as an "edge case". Online forms are notorious for being ugly and difficult to use. Allowing the assigning of classes to forms and form elements facilitates applying jQuery behaviors and more useful .css writing for the webform generated forms. As Bensbury alludes to above, once rolled out this is likely to become a "killer feature" of the webforms module.

hass’s picture

The requirements here sounds like a duplicate of #1114398: Form element & Form element label theming is broken or at least make this case obsolete.

CarlHinton’s picture

The webform classes module http://drupal.org/project/webform-classes allows you to add classes to components.

Nathan005’s picture

I also wish this was included.

would help style forms based on grid systems as well as assist in responsive design
some times you just need predefined specific class to save lots of time (I'm talkin' to you "grid-3 alpha")

and like hermes said it will reduce a buttload of CSS

although deeper views integration may be better
if you can pull form elements into views that would allow custom layout per display, and they already have "wrapper" classes

can you currently do this in with CCK and webform?

Thanks For the class Carl

nlambert’s picture

+1

My users would never be able to create a webform anyway. I personally use the webform module so my users can easily download the data. Along with form builder it's also a quick way to build forms.

In my use case, it would be great to add grid classes to the form items.

Guess I'll try the webform classes module.

nlambert’s picture

Tried the webform classes module. It applies its classes on the actual form element, not the field item (wrapper).

#22 above works great.

nlambert’s picture

Should apply cleanly on webform 3.18

neofelis1985’s picture

I work with Zurb Foundation responsive theme and i need such functions to add custom css classes.

Anybody’s picture

#33 works great!

If we can get some more voices I think we can set the status reviewed & tested? Is there a module maintainer involved who supports the bring this into the next release?

ckrina’s picture

#33 worked for me too. Thanks!

Summit’s picture

Status:Needs review» Reviewed & tested by the community

#33 works great! would love to also see this in version 4!
Greetings, Martijn

yannickoo’s picture

Status:Reviewed & tested by the community» Needs work
+++ b/webform.moduleundefined
@@ -2699,6 +2703,12 @@ function theme_webform_element($variables) {
+  ¶

Whitespaces

+++ b/webform.moduleundefined
@@ -2699,6 +2703,12 @@ function theme_webform_element($variables) {
+  ¶

Whitespaces

meichr’s picture

Thanks for this patch - very useful to me. This is needed for theming individual components in the grid of the Omega theme (i.e. for applying grid-5 alpha classes) and for using the Rounded Corners module which also needs a new class for specifying where to set the rounded corners css by jQuery.

I've removed the whitespaces from the #33 patch and rerolled it for the current 7.x-3.x-dev version (2012-Sep-15) and for webform-7.x-3.18.

hass’s picture

Status:Needs review» Needs work

We inject css classes with theme_preprocess functions. If this is not possible webform/core may need some theme functions, but not a new setting. This patch is not the propper way of solving this issue.

meichr’s picture

Yes, it seems plausible that css classes, including those for supporting grid theming, should not be part of the webform core module and so this specific patch is not exactly what properly solves the issue. There is a module out there, webform-classes which would help with the issue and not blow up the webform core module.

But, in my opinion, moving this functionality only to coding (preprocess or new theme functions), is not helping to improve the usability, especially with grid theming. I value your experienced opinion that certain things are best handled in code, but I also think that we should think on improving usability for the future, and webform is a very popular module, it would deserve a sub module helping with theming.

E.g. why the Omega 3.x has have such a big success story in terms of number of drupal sites? Because it put popular settings into user interface, not code, making it easier to create a site to Drupal site builders without deep knowledge of coding. Despite the correct critique of being slower than coding the same functionality a lot of sitebuilders/themers have chosen to use Omega because of its ease of use for common use cases and valued that higher than the performance.
And then there is the Rules module, which brings a wide range of functionality to the user interface which before could just be solved by coding with much more efforts. There has also been critique on that module by developers, it hits the performance, one can do this much faster by code. True, but Rules has become that popular for providing the functionality to site builders that major contributed modules like commerce depend on it for ease of use and better adoption, favoring the easiness over the performance hit.

And then we have popular modules like Views, Field Group, Display Suite which try to improve its usability by providing class functionality to the user interface saving one to learn coding for common class functionality. They received their popularity partly also by providing this class functionality.

Again, yes, this patch, which helped me on the short run, would have been solved much better by a separate module like an improved webform-classes, or an imagined webform grid integration contributed module. I have tremendous respect for longtime contributors like hass for their work on Drupal and contributed modules, but I also ask you to be open for community members unlike you which are not so much into coding and would love to have ease of use for common use cases.

So, no, not everybody loves to use preprocess functions to inject classes for common use cases. Many would sure love to use a module provided user interface for classes. A well thought out user interface for classes, provided by a webform submodule, would make webform even more popular as it is today.

hass’s picture

I'm confused. Never seen modules that allow me adding css classes without theming or touching css files. If you need to change a css file you are already "programming". I know views allow this in some edge cases you cannot theme in any other way, but 99% of all modules don't allow this. Programming wise it's horror to have it once in code and once in config. Config in UIs is a lot harder to maintain and upgrade.

Recolorable themes are something different and they make also sure all css is consistent.

yannickoo’s picture

ver seen modules that allow me adding css classes without theming or touching css files.

Field Group? Display Suite? Views? Context?

quicksketch’s picture

Status:Needs work» Needs review
StatusFileSize
new3.71 KB

Although I was opposed to these options in the past, I'm taking the side that setting custom classes in site-building features is a common feature these days. Even though Webform does a pretty good job of giving individual components unique IDs and repeating classes based on their field type, there are situations where custom classes are still needed, such as when a class has a special meaning that is only applied to some fields within the form, or when dealing with layout (like some have said here).

I've rerolled the current patch to move the options just right into the "Display" section, instead of making a new fieldset for classes. In order to make these options work better with Form Builder module, I've also moved these to dedicated attributes rather than reading directly out of $element['#webform_component'].

quicksketch’s picture

+  if (isset($element['#webform_wrapper_class'])) {
+    $wrapper_classes = array_merge($wrapper_classes, $element['#webform_wrapper_class']);
+  }

Rather than making up our own FAPI property here, it would probably be better to adopt the same property "#wrapper_attributes" that was introduced into Drupal 8 as part of #1838114: Change node form’s vertical tabs into details elements. Although this attribute doesn't exist in D7, because we're already using theme_webform_element() instead of theme_form_element(), we can build this into our own backport.

quicksketch’s picture

StatusFileSize
new4.42 KB

Same patch but using $element['#wrapper_attributes']['class'] now instead of $element['#webform_wrapper_class'].

yannickoo’s picture

+++ b/includes/webform.components.incundefined
@@ -453,6 +453,23 @@ function webform_component_edit_form($form, $form_state, $node, $component, $clo
+    '#title' => t('CSS classes'),

"CSS classes" waaaah!

quicksketch’s picture

"CSS classes" waaaah!

Could you clarify your comment? Good, bad? Redundant? Just excited?

quicksketch’s picture

Version:7.x-3.x-dev» 7.x-4.x-dev
Status:Needs review» Fixed

Well barring #47's mysterious comment, I think this set of changes is good to go. Any followups or suggestions for the next few weeks, please add them here, or if significant changes are needed, open a new issue. I've committed #46 to the 4.x branch only, since 3.x is no longer receiving feature updates.

quicksketch’s picture

StatusFileSize
new4.17 KB

I found that with several components (markup, date, time, fieldsets), either the "wrapper class" or "css class" (or both) options were not applicable. For example a fieldset *is* a wrapper so it doesn't have a wrapper class. Date and time fields are combo elements, and only have a wrapper class. Markup doesn't have any wrappers at all, so neither is needed.

This followup patch makes components selectively support one or both options by providing 'wrapper_classes' and 'css_classes' feature keys in hook_webform_component_info().

yannickoo’s picture

I just don't like "CSS classes", see #1723446: Avoid the term 'CSS class'. I think that this is wrong, there aren't "CSS classes" but everyone knows what it means.

quicksketch’s picture

I think that this is wrong, there aren't "CSS classes" but everyone knows what it means.

Maybe classes indeed are used for more than CSS, but it's the primary purpose. From the HTML4 spec:

The class attribute has several roles in HTML:

- As a style sheet selector (when an author wishes to assign style information to a set of elements).
- For general purpose processing by user agents.

In addition to that is both common and (most importantly) everyone knows what you mean when you say "CSS class". If #1723446: Avoid the term 'CSS class' decides the Views/Core should change the name then we'll follow suit.

penone’s picture

I installed the patch in post 46 but my field is not choosing the style that I am applying to it and is defaulting to the standard .form-text, .form-textarea style.

When I inspect the field with firebug I do see both classes on the html side but on the style side I see the following under the style I want to use:

.nopieces {
width: 20px;
}

What am I doing wrong?

quicksketch’s picture

@penone: Your CSS is getting overridden by a later CSS file. In Firebug, check for another file that is setting a width that is not getting crossed out. You may need to move your CSS to a file that is loaded later, or move the rule to a lower place in the same file, or you may need a more specific CSS selector.

penone’s picture

Thanks quicksketch for your quick reply. That did the trick.

penone’s picture

Looks like with 7.x-4.x-dev the fields to add css classes no longer shows up for markups.

quicksketch’s picture

Looks like with 7.x-4.x-dev the fields to add css classes no longer shows up for markups.

That's right, because there's no wrapper at all around markup components at all. If you want HTML classes in a markup field, you just type it in the value textarea.

Status:Fixed» Closed (fixed)
Issue tags:-CSS class form components

Automatically closed -- issue fixed for 2 weeks with no activity.

scotself’s picture

Issue summary:View changes

Just updated to Webform4 and just wanted to say that the custom classes and placeholders make this already indispensable module that much more awesome.

That being said, I was wondering (and maybe should open another issue for this, but since it's so close to the OP)...what about a custom class for the form itself? Maybe could just set in the settings sub-tab? Just a thought.