Problem/Motivation
The classes applied to fields follow this pattern: field-type-[type]
and field-name-[name]
This allows a theme to easily style a particular field or to style a particular type of field.
Unfortunately, the node edit form uses the exact same class names for the field form widgets. Completely different HTML (rendered field vs. form widget), but the exact same class. This is super problematic as any moderately complex field styling can break the corresponding field widget when adding or editing a node.
The classes on the node edit form's field widget containers are to "aid in theming", but they do the opposite. In order to style the field widgets, you first have to undo the styling for the rendered field and then apply the desired widget styling. Even if you don't want special widget styling, you still have to undo the rendered field styling. :-p
Proposed resolution
Change the classes used on the field widget containers created in field_default_form(). There's no reason to use the same class. The easiest way is to prepend form-
to the class names, so on the node edit form, they'd be: form-field-type-[type]
and form-field-name-[name]
.
API changes
This will change the class names on field widget containers. But that's the point. They are currently "broken" by anyone's definition.
Comment | File | Size | Author |
---|---|---|---|
#20 | 1245218-drupal7.patch | 1.27 KB | Pol |
#12 | 1245218-12-field-form-bleeding.patch | 828 bytes | markconroy |
Comments
Comment #1
JohnAlbinAlso, "field-label" is used for the rendered field label and for the field widget's label.
Comment #2
tim.plunkettMakes sense to me.
Comment #3
Dries CreditAttribution: Dries commentedWould "form-" work, or does that clash with other classes?
Comment #4
yched CreditAttribution: yched commentedWorks for me too.
@Dries, the patch does 'form-field-type-FIELDTYPE' and 'form-field-name-FIELDNAME', so I don't think I get your proposal.
(Although, for consistency I'd move the classname representing the widget type to 'form-' too)
Comment #5
JacineI support this. It's definitely broken right now and the proposed fix looks reasonable to me.
Comment #6
JacineComment #7
sunI'm heavily confused by the repetition of "node" in this issue - whereas the patch changes CSS classes for all field widgets everywhere.
Can we get a better title?
I agree with that.
Additionally, I believe that almost everywhere we're using "form" in classes, it is a suffix, not a prefix.
At least, "field-hubba-bubba-form" sounds more natural to me than "form-field-hubba-bubba".
Comment #7.0
sunAdded note about API changes and expanded the problem definition.
Comment #12
markconroy CreditAttribution: markconroy at Annertech commentedAdding new patch which I think sorts this.
Sample classes before and after:
frontend (before patch)
field field-node--field-test-text-field field-name-field-test-text-field field-type-string-long field-label-above quickedit-field
frontend (after patch) - no change
field field-node--field-test-text-field field-name-field-test-text-field field-type-string-long field-label-above quickedit-field
backend (before patch)
field-type-string-long field-name-field-test-text-field field-widget-string-textarea form-wrapper
backend (after patch) - has form- class
form-field-type-string-long form-field-name-field-test-text-field field-widget-string-textarea form-wrapper
Comment #13
markconroy CreditAttribution: markconroy at Annertech commentedComment #14
andypostComment #17
markconroy CreditAttribution: markconroy at Annertech commentedClosing this as fixed. Backend form elements are outputting classes like the following, which seems to solve the issue.
js-form-item form-item js-form-type-tel form-type-tel js-form-item-field-fax-number-0-value form-item-field-fax-number-0-value
Comment #19
PolI think we should backport this to Drupal 7 as well.
Comment #20
PolHere's the D7 patch.
Comment #21
andypost@Pol better to file separate issue for D7 - this way it supposed to work now
Comment #22
PolYou're absolutely right, sorry for the noise!