Field styling bleeds into node edit forms [#1245218]

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
#20
#12	1245218-12-field-form-bleeding.patch	828 bytes	markconroy
#12
#1	1245218-1-field-form-bleeding.patch	1.06 KB	JohnAlbin
#1

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

JohnAlbin

he/they/他

English

Taipei, Taiwan

CreditAttribution: JohnAlbin commented 10 August 2011 at 16:43

Status:

Active

» Needs review

File	Size
1245218-1-field-form-bleeding.patch	1.06 KB

Also, "field-label" is used for the rendered field label and for the field widget's label.

Comment #2

tim.plunkett

he/him

English

Philadelphia

CreditAttribution: tim.plunkett commented 10 August 2011 at 16:47

Status:

Needs review

» Reviewed & tested by the community

Makes sense to me.

Comment #3

Dries CreditAttribution: Dries commented 10 August 2011 at 20:55

Would "form-" work, or does that clash with other classes?

Comment #4

yched CreditAttribution: yched commented 16 August 2011 at 19:48

Works 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

Jacine

she/her

New York

CreditAttribution: Jacine commented 5 September 2011 at 05:19

I support this. It's definitely broken right now and the proposed fix looks reasonable to me.

Comment #6

Jacine

she/her

New York

CreditAttribution: Jacine commented 6 September 2011 at 05:08

Component:

field system

» CSS

Comment #7

sun

German

Karlsruhe

CreditAttribution: sun commented 7 September 2011 at 23:31

Status:

Reviewed & tested by the community

» Needs work

I'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?

for consistency I'd move the classname representing the widget type to 'form-' too

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

sun

German

Karlsruhe

CreditAttribution: sun commented 7 September 2011 at 23:31

Issue summary:

View changes

Added note about API changes and expanded the problem definition.

Comment #8

15 May 2015 at 21:00

Status:

Needs work

» Needs review

goldlilys queued 1: 1245218-1-field-form-bleeding.patch for re-testing.

Comment #9

15 May 2015 at 21:02

Status:

Needs review

» Needs work

The last submitted patch, 1: 1245218-1-field-form-bleeding.patch, failed testing.

Comment #10

28 May 2015 at 20:36

Status:

Needs work

» Needs review

markconroy queued 1: 1245218-1-field-form-bleeding.patch for re-testing.

Comment #11

28 May 2015 at 20:37

Status:

Needs review

» Needs work

The last submitted patch, 1: 1245218-1-field-form-bleeding.patch, failed testing.

Comment #12

markconroy CreditAttribution: markconroy at Annertech commented 28 May 2015 at 21:04

File	Size
1245218-12-field-form-bleeding.patch	828 bytes

Adding 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 commented 28 May 2015 at 21:05

Status:

Needs work

» Needs review

Comment #14

andypost

he/him

Russian

CreditAttribution: andypost as a volunteer and at Skilld commented 2 December 2015 at 13:26

Comment #15

2 December 2015 at 13:26

Version:

8.0.x-dev

» 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Comment #16

2 December 2015 at 13:26

Version:

8.1.x-dev

» 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.