We've all seen wide Drupal forms break a fixed width theme by "blowing out" the right side of the theme. Here's a solution to the problem.

This patch adds a "wide" class tag to any textfield, password, textarea, or autocomplete form item with a width (size) of more than 40 characters. By also adding a css rule in drupal.css that sets any "wide" form-items to width:100%, we keep these form items under control. Of course the assumption is that any form items with a width greater than 40 are intended to be full width. Opposing viewpoints are welcome.

Here's the css rule:

.form-item .wide {
  width: 100%;
}

patch for common.inc is attached.

CommentFileSizeAuthor
common.wide.patch5.33 KBjjeff

Comments

Prometheus6’s picture

Prometheus6 commented

Actually, I use this rule in my style.css:

form {
width: 95%
}

drumm’s picture

drumm
he/him
Location NY, US
commented

I think this is greatly needed.

I do not think making any form element with a size greater than 40 into a wide field is a good idea. For forms in blocks a wide field might have a smaller size.

A better way to implement this would be using a special value of the $size argument to mean 'wide'. This could be 0 and may have an associated constant such as FORM_WIDE. When the size is 0 then that attribute may be omitted and the class added. This is a lot more to patch since that requires finding every call to form_* which has a large width, but I think the result will be worth it.

jjeff’s picture

jjeff commented

Hmm... that brings this from simple to complicated very quickly.

But I can understand the need for some for smaller fields to respect their parent's width as in blocks or other side content.

How about this solution (notice last argument):

function form_textfield($title, $name, $value, $size, $maxlength, $description = NULL, $attributes = NULL, $required = FALSE, $fullwidth = FALSE) {

This would be backward compatible with all existing modules, but it would give developers a chance to make their intentions about the width rendering of a form field completely clear. If fullwidth is set to TRUE, then "fullwidth" is added to the item's class.

And we'd be looking at this in drupal.css:

.form-item .wide {
  width: 100%;
}

And then all textfield, password, textarea, or autocomplete form items in the core should probably be examined for intent and patched appropriately.

I realize that it's a little confusing to have both a 'size' argument in addition to 'fullwidth' when you really just want to have your field be the width of the block, but remember that 'size' is an html tag and the 'fullwidth' class is a css tag. In the interest of compliance, we should probably keep both.

-Jeff

Bèr Kessels’s picture

Bèr Kessels commented

IMO you can determine that $maxwith from $size. No needfor an extra parameter.

But this issue isn't as simple as adding a width=100% more often than not padding/margins and that awfull borderbox model break this completely. Often I have to go for a em siize or even 86% or so.

It is greatly needed, but really needs to be implemented in a solid way. not a hacked up parameter, please.

dries’s picture

dries commented

I think forms in blocks are a rare exception. If this is much wanted, I'd prefer to keep this really simple and not go with extra parameter mambo jambo.

drumm’s picture

drumm
he/him
Location NY, US
commented

size is an optional attribute as far as I can tell. I don't think we need to include it. Although it could be useful in environments with different levels of CSS support. We can always have the theme put in the ideal size value to for the theme (or ~60 for the default, it seems to be the most common now) when the size argument is 0 or FORM_WIDE.

jjeff’s picture

jjeff commented

Let's not let this issue die due to indecision.

Anyone else want to weigh in on this?

What's the 'right' way to keep form fields from blowing out their parents?

[giggle]

moshe weitzman’s picture

moshe weitzman commented

perhaps Steven or Chris will chime in here. Would be nice to resolve this.

m3avrck’s picture

m3avrck commented

+1 on concept haven't tried patch seems like there isn't a unanimous approach yet but i'd love to see this as well!

Dublin Drupaller’s picture

Dublin Drupaller commented

+1 on concept here too..like the previous poster..I haven't tried the patch yet. But I have noticed that problem and would be a great to solve it in the core.

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Needs review » Needs work

I bet the new form API completely destroyed this patch.

LAsan’s picture

LAsan commented
Version: x.y.z » 7.x-dev

Bringing this issue back to debate.

Does is still applies to maintained versions?

casey’s picture

casey commented

D7 is in alpha fase already.

I think the size attribute should only be used when you are sure you only want to show a certain number of characters (so only on the text and password type input elements).

Specific widths of other input elements should be set using css. Those elements will probably have a container with a special class (e.g. date input) so styling won't be a problem.

I'd go for a won't fix for this issue (instead of pushing this to D8).

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Version: 7.x-dev » 8.x-dev
Status: Needs work » Closed (won't fix)

Agreed. To both.