Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.As identified and discussed in #628188: Remove #process pattern from taxo autocomplete widget, only individual form elements inside of field widgets use class names currently.
That, however, is not sufficient for themers, because we want to style the entire widget, either per field type, per field name, or per field widget.
Given those proper wrapping classes for the entire widget, I see no need for individual CSS classes on the contained form elements.
Additionally, the reasoning for the individual CSS classes on the form elements was that node.css applies some wonky width via CSS to ALL textfields in a node form, thereby overriding any text field size/width the user entered in the field configuration (the CSS width always has precedence over the HTML "size" attribute).
Anyway - since all textfields in the node form are fields now, we can remove this wonky CSS style from node.css.
Also note that the required change to theme_container() is also contained in #414424: Introduce Form API #type 'text_format', so this is required for at least two issues in the meantime.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | drupal.field-widget-classes.8.patch | 7.09 KB | sun |
| #6 | drupal.field-widget-classes.5.patch | 6.51 KB | sun |
| drupal.field-widget-classes.patch | 6.41 KB | sun | |
Comments
Comment #1
sunNote that further clean-ups to the resulting HTML markup due to this patch should be done in follow-up issues.
We have to get the fundamental markup change in first, then we can see which widgets can be streamlined and optimized regarding it's markup, stylesheet, and very potentially also JavaScript.
Comment #2
sun.
Comment #3
yched CreditAttribution: yched commentedAgreed on the approach, however:
- "since all textfields in the node form are fields now"
well, not textfields within the vertical tabs at the bottom (URL alias, author info), and not potential contrib non-field additions. We can't expect all contrib nodeapi additions to become fields in D7
- The classes need to have the '_' => '-' translation:
Comment #4
sun1) Correct. But form elements not being fields added by contributed modules will most likely have their own CSS class and own stylesheet anyway. At least it would be horribly wrong to base the styling on node's global abuse of CSS. ;)
2) Somehow, I fear that this is a bug in the current drupal_attributes(). Class names as well as HTML IDs (which also don't work) should be sanitized before building the joined HTML attribute string. At least, that was the purpose. ;) So I think that's a separate bug.
Comment #5
sunoh, and on the further text fields in the vertical tabs: I double-checked those, and they are working + looking still correct, and I'd even say that it's better for UX to have textfields in a size that maps to the expected value/content...
i.e. for which node author username do I need a textfield in a width of 600px? ;)
And lastly, that's a job for a theme, not a module.
Comment #6
sunuhm. Seems I was mistaken. I somehow thought that #464862: Add drupal_css_class() to clean class names and rename form_clean_id would have automated drupal_html_id/class() invocations. :-/
So here's a proper patch.
Comment #7
yched CreditAttribution: yched commentedAgreed on the last 3 posts :-)
Last nitpick: if we remove the 'widget-number' and 'text' classes in number.module and text.module, then we should also remove the corresponding lines in field.css
Comment #8
sunAgreed.
Comment #9
yched CreditAttribution: yched commentedSweet :-)
Comment #10
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.