This is probably by design - but I thought I would flag it up in case it is an issue. Previously the first thing I would do with a new D6 installation is to add an image field and place it just above the body field. Then use css to float it to the right of the body text eg:

.field-name-field-image img {
float: right;
margin-left: 10px;
margin-right: 0px;
margin-top: 4px;
margin-bottom: 0px;
}

This does not appear to be as easy in D7 as everything is divided into their own seperate divs

or am I missing something??

here is an example of what I was able to achieve easily in d6 http://venturacottage.com/flowers-intro-page/daffodil-02

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

artatac’s picture

or perhaps now you have to somehow float the whole div right??

seutje’s picture

this is due to the wrapping div having the clearfix class

I'ma look into why this was added and if we are able to avoid it, I think it shouldn't be necessary unless the content of that div is floating or something

Anonymous’s picture

I'd be in favor of NOT having clearfix by default on all fields, but to have an easy way to add it if needed.
We don't want people wondering why things aren't floating, especially because clearfix is fairly hard to get for a newby. It uses the content property to add a dot, so even when looking at the code you can't see what's clearing.

artatac’s picture

I shall leave this important request in your hands - thanks

seutje’s picture

Title: Floating more difficult? » Field wrappers shouldn't use clearfix by default

I agree with #3, it's a lot easier to grasp when things are using default behaviour and then to override that (or just override the themeing and adding a clearfix) than it is to grasp why things are clearing for no obvious reason

adjusting title

yched’s picture

The 'clearfix' was added in #545662: Simplify field rendering, which resulted in a *much* cleaner and more easily overridable field.tpl.php.

IIRC, it is actually only needed if the display settings are 'label: inline' and the field has multiple values, to get the following layout and the alignment of values to the right of the label:

Label: value 1
       value 2
       value 3

IMO the benefits of a cleaner template outweight the drawbacks mentioned here, but suggestions are welcome on how to improve this.

seutje’s picture

Component: node system » field system

o sweet, thanks for linking that, couldn't manage to find it myself :x

haven't been able to properly look at this issue as I've been bumping into a few critical bugs that pretty much prevented me from properly testing multiple cases

I definitely understand the point you're trying to make and will try to see if I can find a sane middle ground without causing WTFs on either end

considering your argument, I feel the title of this issue might need to change...

Anonymous’s picture

Title: Field wrappers shouldn't use clearfix by default » CSS alternative to remove clearfix from inline field markup
Category: bug » task

I see what the problem is, I'll test around to see what we can do about this. clearfix is a nice css trick but I really think it should only be used for high level layout elements.

artatac’s picture

So is there a simple way of being able to float an image to the right of a piece of body text??

artatac’s picture

I think I have cracked it. All elements seem to be in the clearfix container, but then the image seems to be wrapped in its own seperate container. Instead of getting the image to float eg:

.field-name-field-image img {
float: right;
border: 0px solid blue;
margin-left: 10px;
margin-right: 0px;
margin-top: 4px;
margin-bottom: 0px;
}

you float its container field-type-image - like so

.field-type-image {
border: 0px solid orange;
margin-left: 10px;
margin-right: 0px;
margin-top: 4px;
margin-bottom: 0px;
float: right;
}

seems to work - http://venturacottage.homedns.org/dev7a/node/1 (temporary test area)

Alan D.’s picture

I just wondering why the simpler width / overflow CSS rule isn't being used. It seems to make life much easier, eg: you don't need to clear to wrap floating div's inside another div, and this results in issues like this disappearing.

Ref: http://www.quirksmode.org/css/clearing.html

The modules/system/default.css ref to http://www.positioniseverything.net/easyclearing.html now links to http://www.sitepoint.com/blogs/2005/02/26/simple-clearing-of-floats/ that suggests a similar method, but scroll-bars on div results from using overflow: auto.

.clearfix {
  overflow: hidden;
  width: 100%;
}

This actually seems to work better, as core Drupal 7 clearfix is leaving a bottom margin in a few themes that we have. I can not pin point the exact nature, maybe something like line-height on the :after rule. Not a CSS guru to discover the exact cause.

[edit: And this is easily overridden in CSS with the original clearfix solution IF required, while it is hard to revert the existing solution to this one, eg. overriding the default.css to replace it. There are far too many styles to safely neutralize it via CSS!]

Jeff Burnz’s picture

I'd like to raise this again, it sure is a huge pita to deal with, something as simple as floating an image in IE7 and having the body text wrap around it is *very difficult*.

If it is actually only needed if the display settings are 'label: inline' and the field has multiple values, then perhaps that's the point at which it should be added.

This was actually very easy to do in my theme, with no hacking core, adding to the $variables['classes_array'] and removing the hard coded clearfix from theme_field.

Jeff Burnz’s picture

jensimmons’s picture

re #11, we shouldn't weaken .clearfix to make it less of a pain in this situation (we need a strong clearfix!). We should just not be using clearfix on every field.

I'm curious why this happened in the first place. Is there a good reason for it? Or was the person who wrote up the html for fields just not aware of how often front-end devs float these fields?

It seems to me like we want to get this class of the html. Let's write a patch for this.

yched’s picture

re #14 :
This was introduced in #545662: Simplify field rendering, which allowed to dramatically simplify the template for fields, making it much easier to override / provide variants.

If adding the clearfix class only when it's strictly needed is an acceptable solution, then it sounds good to me.

Jeff Burnz’s picture

Status: Active » Needs review
FileSize
1.98 KB

OK, lets get something rolling here.

- adds the clearfix class to $variables['classes_array'] in template_preprocess_field
- added a trim() when they're imploded into $variables['classes'], a whitespace got added when no clearfix was in there
- finally removed the old hard coded clearfix from theme_field, since its now printing via $variables['classes']

A minor concern with this approach is that it makes it slightly harder to remove clearfix entirely if you dont want it ever, e.g. you can no longer just add field.tpl.php to your theme and take it out. I think that is a small tradeoff for the big win here. I don't think I can over-emphasize enough how bad the current situation is - it disables the normal behavior of the float property (as we know and typically use it), which is just not acceptable for themers and designers.

JohnAlbin’s picture

FileSize
946 bytes

Jeff, great start! However, the two chunks of your patch are awkward. It would be much simpler to conditionally add (or not add) a class, rather then always adding a class which conditionally might be an empty string. So I've re-written that part and got rid of the trim().

Hmm… So the decision was to style multi-value fields with an inline label in this way:

Label: value 1
       value 2
       value 3

I guess we have to assume that each value is a block-level item (and possibly multiple or nested block items) since we have no way to know the contents. Ugh. I don't like that styling, but I can't think of anything better right now as a generic default. :-p

yched’s picture

This requires an RTBC from another theme-oriented contributor, but #17 is good for me.

Jeff Burnz’s picture

Status: Needs review » Reviewed & tested by the community

Yes, #17 looks great to me, much cleaner.

Dries’s picture

Can we add a code comment for the label_display part?

jensimmons’s picture

Status: Reviewed & tested by the community » Needs work

I'm assuming that if Dries asked for something, that makes it needs work.

JohnAlbin’s picture

Status: Needs work » Needs review
FileSize
1.05 KB

I've added the following comment:

  // Add a "clearfix" class to the wrapper since we float the label and the
  // field items in field.css if the label is inline.
yched’s picture

Status: Needs review » Reviewed & tested by the community

Looks good.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Thanks! Committed to CVS HEAD.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

leszek.hanusz’s picture

So, what is the best solution now to float an image on the right of multiple fields with the label inline ?

artatac’s picture

try

.field-type-image {
border: 0px solid orange;
margin-left: 15px;
margin-right: 0px;
margin-top: 4px;
margin-bottom: 0px;
float: right;
}
scott.olipra’s picture

In response to #26...

In my user profile screens, I have the user's image float: right, and I want the user data (fields) on the left.
I need "clearfix" off of the fields in my user profile screens.
Instead, I need "clearfix" on the parent div.... the one that contains the profile image and data

So, I put this JS in a file, and add that file using context_addassets when my user pages show.

jQuery(document).ready(
  function() {
    jQuery('div.field-label-inline').removeClass("clearfix").css( { "clear" : "left" } );
    jQuery('.content div.profile').addClass("clearfix");
  }
);

I can't speak for others, but this serves all my use cases fine.

zabelc’s picture

I actually found another way to do this across the board for all my inline fields:

I simply added the function below, to pull the clearfix class out after the core prepreprocess_field method added it.

function my_theme_preprocess_field(&$variables, $hook){
	$element = $variables['element'];
	if ($element['#label_display'] == 'inline') {
		$classes_arr = &$variables['classes_array'];
		for ($i = sizeof($classes_arr)-1; $i >= 0; $i--) {
			if( $classes_arr[$i]==='clearfix' ){
				unset($classes_arr[$i]);
				$i=-1;
			}    	
    }
  }
}

Hope someone finds that useful...

aeski’s picture

Ideal, thanks.

lunk rat’s picture

FileSize
92.02 KB

I am having a heck of a time floating a simple image field in d7. I tried the css posted here, but still can only get the first field to float. See attached.

jmlavarenne’s picture

I am having the same issue.

This is making it so difficult to float a single field when there are floated labels that I can't undestand how it is an improvement. Does this mean that to achieve this seemingly basic requirement it is necessary to rewrite the way fields are themed in theme-specific hooks?

muranod’s picture

Thank you so much for this!

I was struggling with this for two hours trying to wrap text around an image in a display teaser that was output as part of a views block. # 10 solved it.

Jeff Burnz’s picture

For people looking for a general bit of CSS to float image fields you can see this:

http://drupal.org/node/853800#comment-5156744

discipolo’s picture

edit: wrong queue

drupaleye’s picture

Issue summary: View changes

To fix it for the full node of a single node type:

.node-type-mytype .node-full .field-label-inline.clearfix::after {
  clear: left;
}
.node-type-mytype .node-full .field-type-image {
   float:right;
}