Distinguish between the different types of webform-select when adding #prefix to form elements [#711300]

The #prefix property added by webform to form elements usually looks something like

<div class="webform-component-TYPE" id="webform-component-FIELD_KEY">

This is really useful for applying CSS to the form.

However webform's select component covers a multitude of sins ... dropdowns, radios, checkboxes. It would be really useful if webform added an additional class to distinguish between these ... webform-component-select-select, webform-component-select-radios, webform-component-select-checkboxes.

My use case is applying CSS to the form labels and unless I do additional theming I can't distinguish between the labels of selects and checkboxes, which need different CSS. Currently I'm working round this by re-implementing theme_form_element() in my theme, grabbing $element['#type'] and using that to add a class to the label tag.

Comment	File	Size	Author
#11	webform-select-distinguish_0.patch	903 bytes	mrfelton
#11
#6	webform_select_classes.patch	1.1 KB	quicksketch
#6
#5	webform-select-distinguish.patch	1.05 KB	gpk
#5
#3	webform-select-distinguish.patch	942 bytes	gpk
#3
#1	webform-select-distinguish.patch	985 bytes	gpk
#1

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

gpk CreditAttribution: gpk commented 11 February 2010 at 12:39

Version:	6.x-2.7	» 6.x-2.x-dev
Status:	Active	» Needs review

File	Size
webform-select-distinguish.patch	985 bytes

Here's a little patch.

Comment #2

quicksketch

he/him

CreditAttribution: quicksketch commented 11 February 2010 at 20:06

This sounds good to me, but I think we could probably drop the word "select" from all of the class names (except for the select element type of course).

webform-component-select
webform-component-radios
webform-component-checkboxes

I don't think there's any practical reason for applying a single class (webform-component-select) to radios, checkboxes, and select lists, since each of them have rather different markup that needs to be targeted anyway. However, if we did make this change, it should probably only be done in the 3.x branch, since it may break existing CSS implementations, which is why I suspect that you kept the original classes intact in this patch.

Comment #3

gpk CreditAttribution: gpk commented 11 February 2010 at 22:35

File	Size
webform-select-distinguish.patch	942 bytes

>I don't think there's any practical reason for applying a single class (webform-component-select) to radios, checkboxes, and select lists...
> if we did make this change ... it may break existing CSS implementations, which is why I suspect that you kept the original classes intact in this patch
Well yes, there you have it!

The only other reason for retaining the single class to all 3 types might be that the connection with the webform component type as it appears in the UI would be retained. Currently (in 2.7 at least) radios are a webform select which is not a listbox and doesn't allow multiple values; checkboxes are a webform select which is not a listbox and does allow multiple values; and a select is a webform select that is a listbox .. this one can, of course, cope with a single value constraint or allow multiple values. Obvious, eh? ;)

Although in one sense the functional description in the webform UI is "better", I do find myself thinking in terms of "I want some checkboxes here" when putting a form together and then it's a question of reverse-engineering the options available in the UI in order to manufacture the right type of form element. Not a problem now I've put a few forms together but took a while at first.

Would sorting this out just be a matter of tidying up the UI text I wonder, or is more needed?

Anyway, I've updated the patch, though I should probably own up to not having actually tested either this one or the original. Patch originally rolled from the 2.x branch, but looks like it will work equally well on 3.x.

Comment #4

quicksketch

he/him

CreditAttribution: quicksketch commented 11 February 2010 at 22:49

Version:	6.x-2.x-dev	»
Status:	Needs review	» Needs work

You're right that having "select" as a single option is confusing. Unfortunately this hasn't changed much in 3.x, but it's a separate problem than this issue is trying to address.

I don't think there's any valid reason why you'd need to know that the component type is "select" even if it's displaying as radios or checkboxes, so I think the plan will be to make the class be just "webform-component-radios" and only make the change in the 3.x branch. No new features are being added to the 2.x branch at this point.

Comment #5

gpk CreditAttribution: gpk commented 12 February 2010 at 08:54

Status:

Needs work

» Needs review

File	Size
webform-select-distinguish.patch	1.05 KB

Agreed.

Rerolled against 3.x.

Comment #6

quicksketch

he/him

CreditAttribution: quicksketch commented 12 February 2010 at 09:18

File	Size
webform_select_classes.patch	1.1 KB

So it looks like you've still got both "select" and "radios/checkboxes/select" in the class name. Were you agreeing that omitting "select" would be fine? Here's a patch for 3.x with what I'm suggesting.

Comment #7

gpk CreditAttribution: gpk commented 12 February 2010 at 09:20

Doh! My bad..!

Thanks.

Comment #8

quicksketch

he/him

CreditAttribution: quicksketch commented 12 February 2010 at 09:35

Status:

Needs review

» Fixed

Super. Committed to 3.x.

Comment #9

26 February 2010 at 09:40

Status:

Fixed

» Closed (fixed)

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

Comment #10

thechanceg CreditAttribution: thechanceg commented 10 May 2010 at 20:50

Version:

» 6.x-3.0-beta5

Great Stuff. If I could make one recommendation it would be to have separate classes for multiple selects, and for drop down selects. The current setup makes it difficult to theme one over the other.