Issue status update for http://drupal.org/node/28044 Post a follow up: http://drupal.org/project/comments/add/28044 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: jjeff Reported by: jjeff Updated by: drumm Status: patch (code needs review) 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. drumm Previous comments: ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:13:29 +0000 : jjeff Attachment: http://drupal.org/files/issues/common.wide.patch (5.33 KB) 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. ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:45:46 +0000 : Prometheus6 Actually, I use this rule in my style.css: form { width: 95% }

Issue status update for http://drupal.org/node/28044 Post a follow up: http://drupal.org/project/comments/add/28044 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: jjeff Reported by: jjeff Updated by: Bèr Kessels Status: patch (code needs review) 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. Bèr Kessels Previous comments: ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:13:29 +0000 : jjeff Attachment: http://drupal.org/files/issues/common.wide.patch (5.33 KB) 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. ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:45:46 +0000 : Prometheus6 Actually, I use this rule in my style.css: form { width: 95% } ------------------------------------------------------------------------ Tue, 02 Aug 2005 18:12:25 +0000 : drumm 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. ------------------------------------------------------------------------ Wed, 03 Aug 2005 01:09:29 +0000 : jjeff 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): <?php 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

Issue status update for http://drupal.org/node/28044 Post a follow up: http://drupal.org/project/comments/add/28044 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: jjeff Reported by: jjeff Updated by: drumm Status: patch (code needs review) 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. drumm Previous comments: ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:13:29 +0000 : jjeff Attachment: http://drupal.org/files/issues/common.wide.patch (5.33 KB) 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. ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:45:46 +0000 : Prometheus6 Actually, I use this rule in my style.css: form { width: 95% } ------------------------------------------------------------------------ Tue, 02 Aug 2005 18:12:25 +0000 : drumm 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. ------------------------------------------------------------------------ Wed, 03 Aug 2005 01:09:29 +0000 : jjeff 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): <?php 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 ------------------------------------------------------------------------ Wed, 03 Aug 2005 10:18:33 +0000 : Bèr Kessels 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. ------------------------------------------------------------------------ Wed, 03 Aug 2005 15:30:34 +0000 : Dries 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.

Issue status update for http://drupal.org/node/28044 Post a follow up: http://drupal.org/project/comments/add/28044 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: jjeff Reported by: jjeff Updated by: moshe weitzman Status: patch (code needs review) perhaps Steven or Chris will chime in here. Would be nice to resolve this. moshe weitzman Previous comments: ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:13:29 +0000 : jjeff Attachment: http://drupal.org/files/issues/common.wide.patch (5.33 KB) 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. ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:45:46 +0000 : Prometheus6 Actually, I use this rule in my style.css: form { width: 95% } ------------------------------------------------------------------------ Tue, 02 Aug 2005 18:12:25 +0000 : drumm 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. ------------------------------------------------------------------------ Wed, 03 Aug 2005 01:09:29 +0000 : jjeff 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): <?php 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 ------------------------------------------------------------------------ Wed, 03 Aug 2005 10:18:33 +0000 : Bèr Kessels 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. ------------------------------------------------------------------------ Wed, 03 Aug 2005 15:30:34 +0000 : Dries 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. ------------------------------------------------------------------------ Wed, 03 Aug 2005 18:29:16 +0000 : drumm 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. ------------------------------------------------------------------------ Fri, 05 Aug 2005 18:55:45 +0000 : jjeff 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]

Issue status update for http://drupal.org/node/28044 Post a follow up: http://drupal.org/project/comments/add/28044 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: jjeff Reported by: jjeff Updated by: Dublin Drupaller Status: patch (code needs review) +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. Dublin Drupaller Previous comments: ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:13:29 +0000 : jjeff Attachment: http://drupal.org/files/issues/common.wide.patch (5.33 KB) 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. ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:45:46 +0000 : Prometheus6 Actually, I use this rule in my style.css: form { width: 95% } ------------------------------------------------------------------------ Tue, 02 Aug 2005 18:12:25 +0000 : drumm 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. ------------------------------------------------------------------------ Wed, 03 Aug 2005 01:09:29 +0000 : jjeff 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): <?php 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 ------------------------------------------------------------------------ Wed, 03 Aug 2005 10:18:33 +0000 : Bèr Kessels 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. ------------------------------------------------------------------------ Wed, 03 Aug 2005 15:30:34 +0000 : Dries 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. ------------------------------------------------------------------------ Wed, 03 Aug 2005 18:29:16 +0000 : drumm 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. ------------------------------------------------------------------------ Fri, 05 Aug 2005 18:55:45 +0000 : jjeff 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] ------------------------------------------------------------------------ Fri, 02 Sep 2005 15:41:05 +0000 : moshe weitzman perhaps Steven or Chris will chime in here. Would be nice to resolve this. ------------------------------------------------------------------------ Fri, 02 Sep 2005 16:34:56 +0000 : m3avrck +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!