Problem/Motivation

Bartik's original design specified the default image (from the image field) in a node should float left. At some point (undetermined) a change was made which means the image is aligned left, at the top of the node, and the text content begins below it, rather than aligned beside it.

@couturier wrote a good summary of the discussion at #26
https://www.drupal.org/node/853800#comment-5148294

Proposed resolution

Float the image (from the image field) left, as originally intended.

Remaining tasks

Review patch in #59

@emma.maria posted a new patch at #46 with extensive screen shots
https://www.drupal.org/node/853800#comment-9469583

User interface changes

This will create a noticeable change in the UI.

API changes

None?

Original report by @eigentor

Somehow the images both preview and Full Node are not floated anymore. Is this indended? Remember seeing images always floated in Bartik....
Only local images are allowed.

I know this needs some clearfix magic to make sure the image always stays inside the post especially on teasers, but I thought we already had that.

Files: 

Comments

theresaanna’s picture

I sort of suspect that this is a feature, not a bug.

For one, it is tricky to make this look good. The line height makes it appear as if the text isn't really lined up, when in fact it is, technically. There are things we can do to correct for that, but we don't want it to apply to other paragraphs.

Here is a screenshot that shows what I'm talking about: http://img.skitch.com/20100726-858mns4bxjdqtgu5ehhuw1cgc3.jpg

I'm happy to continue to work on a patch for this, but want to make sure that we actually want to display the image alongside text before doing so.

eigentor’s picture

Yeah, it is not 100% proof for all font-sizes.
Normally I put an extra 5px margin on the image for that.
margin 5px 15px 5px 0 for float right and inverted for left has worked for me in almost all situations until now.

I'd also see the win in floated images - in News Articles on every news source they are _always_ floated, so the user just expects it IMHO - bigger than an eventual offset.
As we set the default font size and line-height for Bartik, we can control the offset for the unaltered theme, which will cover 95% of cases.

Jeff Burnz’s picture

Status:Active» Needs review
StatusFileSize
new1.65 KB
PASSED: [[SimpleTest]]: [MySQL] 23,312 pass(es).
[ View ]

something like... pretty untested, just getting the ball rolling, looks good in Firefox, uses chained selectors which might bork out in IE6...

jimmyg164’s picture

Hi Jeff

I am looking to use this patch on my test site www.plane99.com how do i apply it

cheers

Jeff Burnz’s picture

@#4 you'll need to be using the CVS version of the theme and use something like TortoiseCVS to apply the patch, or you can just copy / paste this (this is from the patch), just stick it at the end of the CSS in each file:

This goes in css/style.css

#block-system-main .node .field-type-image,
#block-system-main .node .field-type-image img {
  clear: right; /* LTR */
  float: right; /* LTR */
}
#block-system-main .node .field-type-image {
  margin: 0.5em 0 1em 1em; /* LTR */
}
#block-system-main .node .field-type-image.field-label-above {
  margin-top: 0;
}
#block-system-main .node .field-type-image .field-label {
  margin-bottom: 0.5em;
}
#block-system-main .node .field-type-image.field-label-inline .field-label {
  margin-bottom: 0;
  line-height: 1;
}

This goes in css/style-rtl.css

/* ---------- Fields RTL ----------- */
#block-system-main .node .field-type-image,
#block-system-main .node .field-type-image img {
  clear: left;
  float: left;
}
#block-system-main .node .field-type-image {
  margin: 0.5em 1em 1em 0;
}
dcrocks’s picture

StatusFileSize
new116.98 KB

Is it preferred to have the image floated right or the text? My 1st reaction would be to have the image left and text right, but when I think about it I don't know what the convention is.

ps. Mod worked in 7.x dev dated 8/14, but didn't test extensively.

eigentor’s picture

A very large majority of news sites and blogs have the image left by default. So if we keep on designing for the 80%, keep it left.

Jeff Burnz’s picture

How about some patch reviews and testing before we bother bike-sheading about left vs right - I really don't think that's important at this stage. We need some browser testing and configuration test done, such as adding many images + image fields, showing labels (patch accounts for label inline and above) and so on.

jimmyg164’s picture

Thanks, your help is much appreciated

Jeff Burnz’s picture

After much thinking about this I am very tempted to close with a wont-fix. Here's the reason - I think Display Modules will flourish in Drupal 7 - meaning that we'll see modules in contrib that add display options for fields - so it could be presumptious of us to be floating image fields?

Like to hear some ideas and feedback on this.

Should we do this or not - I'm really wondering if its a good idea or not.

tim.plunkett’s picture

Jeff Burnz, I agree with you, modules providing options will very likely be the way-of-things. However, I think it is the responsibility of a core theme to provide sensible defaults, and I think this is a good patch.

I REALLY need to get my IE testing computer back on its feet, sorry for the lack of a review.

eigentor’s picture

#3: bartik-float-images.patch queued for re-testing.

eigentor’s picture

Tested the patch with current head. Working in all modern browsers.
The div that surrounds the entire node content has a .clearfix class, so float is correctly cleared also when only teaser is shown. http://auweia.org/test/drupal-head/
Margin around image also looks good.

But for some reason the image does not get floated neither in IE6 nor IE7 when you do not give the div.field-type-image a fixed width. The Div gets extended to the full width of the node content in these browsers.
This normally works, so there must be some element within forcing the width, but, alas, could not find any.
Hints?

Jeff Burnz’s picture

StatusFileSize
new447.26 KB
new1.52 KB
PASSED: [[SimpleTest]]: [MySQL] 23,312 pass(es).
[ View ]

Good call eigentor, lets take a different approach and instead of floating both the container and the image we can just float the container, then use display: block to stack the images in one column - in the original patch I used a float + clear which is a bit old school - display block can do the same thing and much cleaner.

Screenshot shows the 3 label options - Inline, Above and Hidden.

bartik-float-image-feilds-lable-display-options.png

eigentor’s picture

StatusFileSize
new154.69 KB
new298.95 KB

The Floating works now also in IE6 and 7 for #14

Wonderful idea with the multiple value layout. I guess a lot of people that want to upload multiple images to a node, would like to see them float stacked like this. Works also when the images have different widths, since they are aligned on the left side. If we decide to float images left, we need to think of that case and make it look good.

We need to think about if to float images for full node as well. If one uploads large images, there is hardly any place left for the text

It needs to be considered, what the more likely use case is: will people resize their images to fit their needs before uploading or just throw in the images from their hard drive or digicam. If the more likely case is people using large images I opt for floating images only on the teaser.

Jeff Burnz’s picture

Well, I would hope people will use the imagecache built into D7 and the preset settings in the field UI to re-size images - so image size is not really our problem, its the end user problem.

I'm not sure we can really account for that many choices, its either one or none I think - as I said above I'm cagey about this whole idea, and would rather let contrib take care of it with display modules.

eigentor’s picture

Well we could decide if or if not to float on full nodes. So what is your experience with the group we target here (People that do not find Imagecache Settings, are new to Drupal and still like to upload images). Do they resize before they upload, or don't they? In Wordpress et al, they normally get little dragging handles to do so in the text field which is not possible in our straight-out image field solution. So in Drupal they will be more or less stuck with the size of the uploaded image.
Well probably they will be looking for a way to make that darn image on full node smaller. If this presents a major wtf to them, it has to be weighed against the wtf for having images floated on teaser but not on full node. Which one is worse?

Having floated images not at all is not an option to me, though. At least in teasers, images are always floated everywhere. You won't find a site that wants to look professional that does not do that.

Jeff Burnz’s picture

Worrying about users finding the Mange Display settings is just not within the scope of this this issue and I don't know what you are talking about with regards teasers vs full node views - the patch makes no distinction between the two - it targets the field-type-image in nodes, which is very fragile because image fields can be in taxonomy terms, or whatever else contrib comes up with. Whatever we do it will be a token effort - its simply impossible to account for every possibility, and attempting to do so imo could be a big mistake. I'm trying to think of the bigger picture here - not just a fresh install looking good, but the long term usage and wider application of the theme. WRT to Wrodpress - note they do not try to float images by default, they allow the user to leverage the tools given to them - Drupal imo should be no different - its just a much bigger toolbox and at the moment somewhat incomplete.

webchick’s picture

Version:7.x-dev» 8.x-dev

Feature requests => 8.x

eigentor’s picture

Version:8.x-dev» 7.x-dev

Yeah I am slowly beginning to see this might introduce wtfs as it tries to remove them. Hmm. This needs more opinions for sure, us two discussing it won't cut it.

But if we float it, it should be floated on teaser and full node the same for consistence, and the entire thing limited to articles, so it won't interfere with all kinds of image fields.

eigentor’s picture

Version:7.x-dev» 8.x-dev
Jeff Burnz’s picture

Oh thank god for that :)

Now lets fix some bugs!

DanielJohnston’s picture

That's a shame. It would be lovely if Drupal image display looked good out of the box. Hacking away at a theme to make pictures float right, especially one that's likely to be on an upgrade treadmill for a while, is just ugly. Possibly I need to suck less at CSS or wait until someone releases a contrib display module to do the job. Preferably one that plays nicely with image fields.

jensimmons’s picture

Images were floated left in the original design. It's frustrating to me that it was changed, and I have no memory of when they happened or why. :(

tim.plunkett’s picture

Status:Needs review» Needs work

Patch no longer applies. Also, we need to decide if we want to still fix this. And decide if this sort of change is allowed, I'm not sure of the policy on this.

couturier’s picture

StatusFileSize
new114.12 KB

To summarize:

  • Jensimmons originally coded Bartik images to float left. Someone else took this out.
  • This issue was created because some basic site designers (like myself) are interested in a default float rather than adding the weight of an extra module for display.
  • Jeff Burnz prefers no default float but rather tools added to core to allow custom manipulation of floats.
  • Webchick moved custom float manipulation tools to an 8.x-dev feature request.
  • In the meantime, Carolyn posted documentation on adding CSS to Bartik subthemes to allow floats (see screenshot attached).
  • However, after reading this issue, I'm worried Carolyn's 5 lines of code for style.css only are not sufficient, based on the suggested patch by Jeff Burnz which was more complex and included changes to style-rtl.css as well.

Questions:

  • Can I safely use Carolyn's code for floats without creating problems? According to this issue, I may have problems because Carolyn's code may be incomplete, it may interfere with image fields in "fragile" places, and it may not render well in all browsers.
  • The patch from Jeff Burnz has been declared by tim.plunkett to "no longer apply." Other than this issue being moved to D8, does this mean Jeff's code should not be applied by individual users for a D7 solution?

I suspect that we have many D7 users like myself applying Carolyn's code from her highly visible Bartik documentation post and I just want to make sure her solution is one that will work smoothly for now until we arrive at D8 with new float tools in core. Thanks!

Jeff Burnz’s picture

I can't recall right now what Carolyn's CSS actually includes, what we could/should do is document this here on d.o in a "Bartik handbook".

The patch no longer applies because other CSS or markup changed, also now its really out of date since we are using GIT and its a CVS patch. The actual CSS will still be good, but needs to be extrapolated into a usable chunk of CSS and placed in the handbooks so users can simply add it to their themes.

couturier’s picture

Carolyn's CSS in the How to Customize Bartik documentation:

Float images to the left

.field-type-image {
  float: left;
  margin-right: 10px;
  margin-top: .4em;
}

Float images to the right

.field-type-image {
  float: right;
  margin-left: 10px;
  margin-top: .4em;
}

That's all the code! That's what amateur users like me are currently adding to style.css. Would you have time, as you said, for a better version to be "extrapolated into a usable chunk of CSS"? I'll place it in the handbook myself if you would have the time to post something here.

Or, what is the most current way to insert an HTML float into an img tag for each individual post? This seems to work, but I'm not sure if it is the most current way to specify a float. Of course, you would hide the original uploaded image under "Manage Display" and then insert a tag in the body with "Full HTML" selected, with something as follows:

<img src="url" alt="description" width="300" height="300" style="float:left;margin:10px 20px 10px 0;" />

Would this be good practice?

Jeff Burnz’s picture

That CSS is fine.

I would avoid at all cost writing inline styles for anything, unless you never plan to redesign your site, ever, however I do understand the frustration of Drupal not exactly making this sort of thing easy.

couturier’s picture

Okay, I understand your point that inline styles make re-designs a nightmare. Thank you for the warning. I will not do that. Then, is Carolyn's code good, or should I add more than that to Bartik's style.css? Your patch above looked more detailed than what Carolyn wrote. If you give us something for Bartik in D7 in this thread, I will move it to the appropriate handbook location. If you are too busy and would rather wait until D8 launches with this feature request developed at that time, I understand. Thanks!

Jeff Burnz’s picture

The patch accounts for the label display, so works if you have the label showing or not, so the full CSS is actually:

/* ----------------- Image fields ----------------- */
.node .field-type-image {
  float: right; /* LTR */
  margin: 0.5em 0 1em 1em; /* LTR */
}
.node .field-type-image img {
  display: block;
  padding: 0 0 10px 0;
}
.node .field-type-image.field-label-above {
  margin-top: 0;
}
.node .field-type-image .field-label {
  margin-bottom: 0.5em;
}
.node .field-type-image.field-label-inline .field-label {
  margin-bottom: 0;
  line-height: 1;
}

And there's an additional bit for RTL:

/* ----------------- Image fields ----------------- */
.node .field-type-image {
  float: left;
  margin: 0.5em 1em 1em 0;
}

The other major difference is that the code posted in http://drupal.org/node/853800#comment-5149288 will float ALL image fields, whereas the above is targeted at nodes - in Drupal 7 node is just one type of entity - comments can have images and there are lots of modules adding new entity types - you might not want image fields in those to float, so that's something to consider.

couturier’s picture

StatusFileSize
new113.56 KB

Works beautifully! Can we add this to D7 core for the next update? Comment #25 from tim.plunkett, "Also, we need to decide if we want to still fix this. And decide if this sort of change is allowed, I'm not sure of the policy on this." I would like to see this incorporated now for the benefit of the next 2 years' worth of new Drupal users who are going to wonder why images aren't automatically floated. The professional appearance of a website is downgraded without it.

I favor the float right you provided, though I realize others who commented in this thread preferred the left. Thank you for taking time to do this, Jeff. I have updated the handbook entry and extended the code to provide both left and right float options. If you would take a moment to review that I have done this correctly, I would appreciate it: http://drupal.org/node/1114278

couturier’s picture

Status:Needs work» Needs review

I've been working with Bartik with this float code added, and I love it. May I request again, for the benefit of Bartik users, a current update to D7? I know 7.x is closed for new features, but would something this minor as far as code be considered a full feature request? It meets Criteria for evaluating proposed changes:

"Implements . . . latest thinking and best practices . . . ." - Floated images are standard across the web.

"There is demonstrated demand and support for the change. Demand is indicated by comments on the drupal.org issues system or comments in forums." - I've searched comments and found a number of people like myself who run into various issues trying to float images in Bartik. They would benefit from the support of well-written code in core.

"The change will be used by a substantial part of the installed Drupal base as opposed being relevant only to a small subset of Drupal users." - Bartik is the default, and D7 will be around for awhile.

"The benefits of the change justify additional code and resources. . . . Benefits of a change must outweigh these costs." - We have the code. It seems to me that if we will just add it, all future Bartik users would benefit.

I'm leaving this at an 8.x feature request for now but changing to "needs review" so that someone with more experience can evaluate whether 7.x might still have a chance at this improvement. Thanks.

kattekrab’s picture

I'd love for the float to be backported to D7.

Why was it was removed from Jen's original? Can anyone help find that discussion?

Would adding it back to D7 now confuse existing site owners, because the behaviour would change when they upgraded.

The sad thing is, I've actually been using old fashioned imce image upload for inline placement of images in my blog, rather than the D7 image field, because that actually lets me control where the image goes.

In some ways, I think this issue is a good example of how we need to improve the Drupal authoring experience. These days, I imagine adding images and controlling where and how they display is a pretty basic need for a majority content authors and managers. We've got the ability now to add one image, but need more options to control where and how it displays.

couturier’s picture

Agree with you about the backport to D7, kattekrab, but I've learned that the busy Drupal core developers work a version ahead of us. And yes, it would confuse current users who have probably already added their custom CSS to their themes. All the energy is going into D8 right now. You can easily add the float to D7 yourself with the code from Jeff Burnz in #31. I'm not sure that fine-grained control of images is something that would make it into D8 core right now, with all the other priorities, but there will most certainly be a D8 module you can add for that functionality. In my process of web development, I've come to a place of cutting out a lot of what I wanted and relying on Drupal core as much as possible. Life is more simple that way. Like I heard once said of Apple, they cut out features people thought they wanted rather than do them badly. Have you tried the WYSIWYG editor to insert photos? Give it an easy try at http://www.drupalgardens.com

efreedom’s picture

The patches listed here don't seem to apply to the current edition of Drupal 8. This is a very old issue and I think a number of other changes have already been applied.

At this point in the process the image properly floats left or right when you choose "right" or "left" align in the image editor. The problem is after the image is saved. In the actual published image, it no longer floats left or right.

The problem is that the image doesn't survive the Basic HTML Filter (default).

In the editor, we see:

<img src="foo" style="float:left;">

but in the published page, the style is stripped out, as is expected in a default Basic HTML filter.

Since the Basic filter can't handle attributes in the image style, this probably isn't the best solution.

If possible, an alternative solution might be to have a special filter that would convert the style into a span wrapped around the image with a default class name like .image-right or .image left. Or perhaps we could modify the output from the image editor to be able to add such a default class.

Without this, users will always be in the frustrating position of seeing the editor do the right thing and then trying to figure out later how to get the image to float properly. And the fix to float it properly even when they have access to the css will a major pain especially for a newbie.

efreedom’s picture

Status:Needs review» Needs work

Changing this from a Review to Needs Work.

kattekrab’s picture

Category:Feature request» Task
Priority:Normal» Major
Issue summary:View changes

This isn't really a feature request. Setting it back to a task.

The original design for Bartik specified the images should float to the left. #24. The fact they don't float could even be a regression, as I can't find any issue on D.O that outlines why that change was made. Someone with better git skills than me might be able to find the commit that did the deed.

Many people seek to float the images, and documentation has been created to help them do this.

Theming guide: Float images to the left or right in bartik
https://www.drupal.org/node/1114278

Theming guide: How to Customize Bartik
https://www.drupal.org/node/1114190

And Backdrop has an issue to restore this behaviour.
Add a float:left to display of image fields in nodes in Bartik
https://github.com/backdrop/backdrop-issues/issues/379

Floating the image left as originally designed, with suitable responsive behaviour would be really great for D8.

I'll follow up with an issue summary update. I wish I knew enough to roll a patch to go with this :/

kattekrab’s picture

Title:Float images in Bartik Articles» Float image left in Bartik Articles
Issue summary:View changes
kattekrab’s picture

Issue summary:View changes
tvn’s picture

Issue summary:View changes

Changing input format.

Jeff Burnz’s picture

Thanks tvn!

I cannot remember how this got removed, in hindsight we should have put it back in years ago.

However to clarify, yes i think its reasonable to float image fields, but do not float CKEditor images, the user can choose if they want them left, right or centre already.

What we should do for these CKEditor images is provide some defaults for .align-right/left/center classes, i.e. some margin/padding etc, and since core does not, perhaps some RTL styles as well (although I do think thats a system module issue), I mean such as [dir="RTL"] .align-left {float:right}

kattekrab’s picture

Oops - sorry for the issue summary text format snafu! :/

Agree with Jeff that the float should only be the image field, not for images in the body / uploaded via wysiwyg.

Jeff Burnz’s picture

Hmm, on second thought I think I am talking silliness about RTL styles for align-right etc, even if the site is RTL then they would expect the image to be on the right and not magically on the left etc. That would only work if you were doing a multilingual site and wanted the UI to flip on language change to an RTL lang, but be a bug in an a RTL only site. Ignore, brain fart. Can't see any clean way around that other than individual sites providing their own defaults for those classes.

emma.maria’s picture

Issue summary:View changes

For the ckeditor image style options in #42 a separate issue should be raised. We need to keep this issue concise and not introduce further elements.

I got a little confused on what this long standing issue needed but I can see the community still wants it fixed!

The focus and discussion here should just be about the images from the image field in Bartik :)

I will also try and scrape together a patch from previous work.

emma.maria’s picture

Status:Needs work» Needs review
Issue tags:+frontend, +CSS, +Novice
StatusFileSize
new781 bytes
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 83,351 pass(es).
[ View ]
new1.51 MB
new1.39 MB
new845.93 KB
new1.03 MB
new1018.61 KB
new598.07 KB
new397.42 KB
new395.89 KB
new282.63 KB
new1.06 MB
new1.04 MB
new627.8 KB

Updated patch for this issue working with what Drupal 8 has now.
I added the floating styles for when the browser gets to a min width of 520px (I took the width value from a media query being used a lot in Bartik and it works well for this). The images stack when viewed on mobile devices to avoid a narrow mess.

The styles have been added to .node .field-type-image so both full nodes and teasers pick up the float styles and only image fields inherit them.

Test replication steps for my screenshots below.

- Add 2 additional image fields to article content type.
- In Manage Display add them all above the body field.
- Toggle their display sizes and label display options as you please.
- Also set LTR attribute for HTML in the markup to RTL to test RTL styles.

Screenshot tests.

One large, two medium images.


One large, two medium images - RTL styles.


One large, two medium images - mobile


Three medium images.


Three medium images - RTL styles.


Three medium images - mobile


Three medium images, labels above.


Three medium images, labels above - RTL styles.


Three medium images, labels above - mobile


Teaser.


Teaser - RTL styles.


Teaser - mobile.

kattekrab’s picture

StatusFileSize
new525.13 KB
new1.34 MB

Hoooray!!

A big +1 from me. Probably still needs a code review I guess before an RTBC?

Just did a test using simplytest.me

Here's some screengrabs.

kattekrab’s picture

Issue summary:View changes
kattekrab’s picture

tadityar’s picture

Hi! I'm not an expert at css so I can't review much but,

+++ b/core/themes/bartik/css/components/content.css
@@ -175,3 +188,5 @@ ul.links {
+
+

Are these two blank lines mistakenly added?

cafuego’s picture

Status:Needs review» Reviewed & tested by the community

The new CSS looks OK to me, though I'm not sure why you chose a breakpoint of 520px. Was that just arbitrary?

The layout breakpoints are at 560px and 850px as far as I can tell, though the tabs change at 600px and the menu at 900px. 520px looks reasonable for the medium (and smaller) image styles, but it's not great for large.

Mind you, a different float breakpoint could be added for other (standard shipped) image presets in a different issue, so this can go in and the basic issue can be fixed before all the bike shedding, so I'll RTBC this :-)

DickJohnson’s picture

Remove the extra line from the end and it's RTBC. Currently the breakpoints are messed up all over the Bartik, so that's not an issue in this case.

tadityar’s picture

Status:Reviewed & tested by the community» Needs work

Let's set it to Needs Work for line-removing then :)

cafuego’s picture

Status:Needs work» Needs review
StatusFileSize
new701 bytes
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 83,375 pass(es).
[ View ]
new341 bytes

Updated patch and interdiff attached.

tadityar’s picture

Status:Needs review» Reviewed & tested by the community

Patch applies, screenshots verified, blank lines removed.

So I'll mark this RTBC :)

alexpott’s picture

Status:Reviewed & tested by the community» Needs work
+++ b/core/themes/bartik/css/components/content.css
@@ -97,6 +97,19 @@ h1#page-title {
+@media all and (min-width: 520px) {

Looking at bartik.breakpoints.yml lets do the floating at 560px to be consistent with the change from bartik.mobile to bartik.narrow.

bartik.mobile:
  label: mobile
  mediaQuery: '(min-width: 0px)'
  weight: 0
  multipliers:
    - 1x
bartik.narrow:
  label: narrow
  mediaQuery: 'all and (min-width: 560px) and (max-width: 850px)'
  weight: 1
  multipliers:
    - 1x
bartik.wide:
  label: wide
  mediaQuery: 'all and (min-width: 851px)'
  weight: 2
  multipliers:
    - 1x
emma.maria’s picture

Assigned:Unassigned» emma.maria

OK let me fix this. Sorry about the faults in my original code, I was having too much fun with the cats :)

emma.maria’s picture

Assigned:emma.maria» Unassigned
kattekrab’s picture

StatusFileSize
new701 bytes
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 83,440 pass(es).
[ View ]
new387 bytes

OK! 520 is now 560.

kattekrab’s picture

Status:Needs work» Needs review

oops

kattekrab’s picture

StatusFileSize
new116.17 KB
new484.08 KB
new484.08 KB
new484.08 KB

and screenshots from a manual test

kattekrab’s picture

Issue summary:View changes
Jeff Burnz’s picture

Status:Needs review» Reviewed & tested by the community

As a basic implementation this is sound. The overall look for image field images on nodes is vastly improved. Yes we could take this a lot further, however I tend to think this less-is-more approach or more suited to a generalist theme like Bartik. RTBC.

alexpott’s picture

Status:Reviewed & tested by the community» Fixed

CSS is not frozen in beta. Committed e40dff3 and pushed to 8.0.x. Thanks!

  • alexpott committed e40dff3 on 8.0.x
    Issue #853800 by emma.maria, kattekrab, Jeff Burnz, eigentor, couturier...

Status:Fixed» Closed (fixed)

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