Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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
Comment | File | Size | Author |
---|---|---|---|
#31 | fields-body-nofloat.png | 92.02 KB | lunk rat |
#22 | field-clearfix-622330-22.patch | 1.05 KB | JohnAlbin |
#17 | field-clearfix-622330-17.patch | 946 bytes | JohnAlbin |
#16 | field-clearfix-622330_v1.patch | 1.98 KB | Jeff Burnz |
Comments
Comment #1
artatac CreditAttribution: artatac commentedor perhaps now you have to somehow float the whole div right??
Comment #2
seutje CreditAttribution: seutje commentedthis 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
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedI'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.Comment #4
artatac CreditAttribution: artatac commentedI shall leave this important request in your hands - thanks
Comment #5
seutje CreditAttribution: seutje commentedI 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
Comment #6
yched CreditAttribution: yched commentedThe '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:
IMO the benefits of a cleaner template outweight the drawbacks mentioned here, but suggestions are welcome on how to improve this.
Comment #7
seutje CreditAttribution: seutje commentedo 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...
Comment #8
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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.
Comment #9
artatac CreditAttribution: artatac commentedSo is there a simple way of being able to float an image to the right of a piece of body text??
Comment #10
artatac CreditAttribution: artatac commentedI 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:
you float its container field-type-image - like so
seems to work - http://venturacottage.homedns.org/dev7a/node/1 (temporary test area)
Comment #11
Alan D. CreditAttribution: Alan D. commentedI 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
.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!]
Comment #12
Jeff Burnz CreditAttribution: Jeff Burnz commentedI'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.
Comment #13
Jeff Burnz CreditAttribution: Jeff Burnz commentedRelates to #806566: Remove clearfix from theme_field, only add when required
Comment #14
jensimmons CreditAttribution: jensimmons commentedre #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.
Comment #15
yched CreditAttribution: yched commentedre #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.
Comment #16
Jeff Burnz CreditAttribution: Jeff Burnz commentedOK, 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.
Comment #17
JohnAlbinJeff, 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:
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
Comment #18
yched CreditAttribution: yched commentedThis requires an RTBC from another theme-oriented contributor, but #17 is good for me.
Comment #19
Jeff Burnz CreditAttribution: Jeff Burnz commentedYes, #17 looks great to me, much cleaner.
Comment #20
Dries CreditAttribution: Dries commentedCan we add a code comment for the label_display part?
Comment #21
jensimmons CreditAttribution: jensimmons commentedI'm assuming that if Dries asked for something, that makes it needs work.
Comment #22
JohnAlbinI've added the following comment:
Comment #23
yched CreditAttribution: yched commentedLooks good.
Comment #24
Dries CreditAttribution: Dries commentedThanks! Committed to CVS HEAD.
Comment #26
leszek.hanusz CreditAttribution: leszek.hanusz commentedSo, what is the best solution now to float an image on the right of multiple fields with the label inline ?
Comment #27
artatac CreditAttribution: artatac commentedtry
Comment #28
scott.olipra CreditAttribution: scott.olipra commentedIn 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.
I can't speak for others, but this serves all my use cases fine.
Comment #29
zabelc CreditAttribution: zabelc commentedI 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.
Hope someone finds that useful...
Comment #30
aeski CreditAttribution: aeski commentedIdeal, thanks.
Comment #31
lunk rat CreditAttribution: lunk rat commentedI 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.
Comment #32
jmlavarenne CreditAttribution: jmlavarenne commentedI 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?
Comment #33
muranod CreditAttribution: muranod commentedThank 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.
Comment #34
Jeff Burnz CreditAttribution: Jeff Burnz commentedFor people looking for a general bit of CSS to float image fields you can see this:
http://drupal.org/node/853800#comment-5156744
Comment #35
discipolo CreditAttribution: discipolo commentededit: wrong queue
Comment #36
drupaleye CreditAttribution: drupaleye commentedTo fix it for the full node of a single node type: