CSS/markup fixes to make issue UI much more compact

here's a patch that fixes the straight-up bug in project's div output that makes consistent themeing of issues and followups impossible.

and here's the patch that provides the work-around for safari so that if you use the CSS in the original post, all the elements stay inside their appropriate fieldsets.

i was thinking that it'd be safer to wrap the whole project_issue form in a div, so that the float CSS magic doesn't accidentally touch anything other than this form. here's a patch that accomplishes this. i'm not sure if this is the best way to do it, but the following didn't appear to work:

$form['#prefix'] = '<div class="project-issue">';
$form['#suffix'] = '</div>';

therefore, the attached patch rips out a commented-out version of something similar, since it appears to be a failed attempt from the past. if there's a more elegant, better way to accomplish this, please let me know. with this patch, the sort of CSS you'd want to add to your theme's style.css would be like this:

.project-issue .options fieldset .form-item {
  float: left;
  padding-right: 0.8em;
  margin: 0.05em 0.1em;
}

tee hee, i just noticed project.css exists. ;) so, we can make this change without even having to tell people to modifiy their own themes. cool.

now that i've gotten this all figured out (sort of), here's 1 giant patch that includes the 4 patches i've previous posted... hopefully this will make it easier for folks to review and test this issue.

thanks!
-derek

i'm a total novice when it comes to CSS -- i'm just doing what steven (unconed) told me to do. ;) if there's a better solution, i'm all ears. however, if it involves CSS/theming, just speak slowly, and use small words, so i'll be sure to understand. ;)

i tried changing this:

'#value' => '<br class="clear" />'

to this:

'#value' => '<div class="container-inline clear"></div>',

and it didn't work. :( the form elements still float all the way out of the fieldset in this case.

dries, sorry if i'm not understanding what you're proposing.

ugh, so far, no luck. :( i tried wrapping the fieldset definitions with the container-inline (and clear) div, like so:

    $form['project_info'] = array(
      '#type' => 'fieldset',
      '#title' => t('Project information'),
      '#prefix' => '<div class="options"><div class="container-inline clear">',
      '#suffix' => '</div></div>',
    );

i tried manually stuffing the <div> inside the fieldset by using form elements:

    $form['project_info']['pre_clear'] = array(
      '#value' => '<div class="container-inline clear">',
      '#weight' => -10,
    );
    $form['project_info']['post_clear'] = array(
      '#value' => '</div>',
      '#weight' => 10,
    );

all 4 combinations (both code blocks, with and without the "clear" in there) generated the expected HTML. the upper approach had the <div> outside the fieldset, the lower one had it inside the fieldset. however, none of them prevented the form elements from floating outside of the fieldset. :( i think we're stuck with the <br/> solution, unless someone more CSS clueful than i can come up with a better approach. given that this was steven's suggestion originally, and that we already do this in core (see node.module and help.module), i'm guessing this really is the only way. i don't think the theme_ function approach will work, since we need these clear elements *inside* each fieldset.

i'm not going to commit just yet. i'll wait for more input from the CSS gods among us. if i can, i'll get steven to take another look at this and enlighten us. ;)

m3avrck has saved the day with a new approach that requires no markup in project.module at all, only additional CSS:

.project-issue .options fieldset:after {
  content: ".";
  display: block;
  height: 0;
  clear: both;
  visibility: hidden;
}

.project-issue .options fieldset {display: inline-table;}

with that (and a clear cache), everything works fine, even in safari. 3 cheers for m3avrck! i'll make a new patch to clean this all up and post a new screenshot for further review. stay tuned...

steven wrote in email to me:

Hmm, this is a CSS2 property... combined with fieldsets (one of the bigger pieces of voodoo magic in styling HTML), this could result in some nasty browser bugs. If it works, all the better, but we need to verify this in all browsers, including IE5 and Konqueror.

i tried in IE5 (not that anyone on earth should actually care about that browswer anymore *grin*), and it appears to "degrade" nicely. basically, none of the float stuff seems to work, and everything looks much like it does without the patch at all. in old firefox (1.0.6), the floating stuff works, but the 2nd part of the CSS to get the fieldset to wrap more closely around the form elements doesn't work. in safari 2.0.3, everything works perfectly. i'll attach screenshots of each as separate followups in a few moments. meanwhile, here's the updated patch that doesn't require any new markup in project's code. i think this is RTBC. can i get an 'amen'? ;)

IE 5.2 screenshot

whoops, screenshot malfunction. try again: IE 5.2 screenshot, take 2.

firefox 1.0.6

and finally, a modern browser: safari 2.0.3.

further simplications to the div generation (and CSS) code. for consistency with the rest of project.css, i just added a class "project" around the issue-related forms (and cleaned up the #prefix #suffix stuff in the process). then, i can use ".node-form .project .options fieldset", everything works fine, and there's no extra special cases. the issue forms are the only ones that use class="options", so this behavior still only effects these forms. now, the CSS can just be like this: ".node-form .project .options fieldset". dries said in email he was ok with this new CSS approach, and that i should "feel free to commit". so i'll apply this simplified patch on monday unless anyone objects.

thanks, m3avrck. new patch.

Dries confirmed in email i should commit. applied to HEAD. patch doesn't apply cleanly against 4.6, so i probably won't try to backport this. changing the title of the issue to be a little more descriptive. ;)