Make WordPress Core

Opened 11 years ago

Closed 9 years ago

#24968 closed defect (bug) (wontfix)

$content_width not constraining images in fullscreen editor

Reported by: saltcod's profile saltcod Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.2
Component: TinyMCE Keywords:
Focuses: Cc:

Description (last modified by DrewAPicture)

In 3.6, I've got $content_width set in my theme, but it isn't affecting the fullscreen width for images. It would be really handy if it did.

I'm wondering if this is a bug, or if it just ties into #21256 as a feature request.

Reproduce: Edit a post, enter fullscreen mode in the editor, insert an image. $content_width should constrain content, but not images.

Attachments (1)

2013-08-06 at 11.14 AM.png (48.1 KB) - added by saltcod 11 years ago.

Download all attachments as: .zip

Change History (10)

#1 @saltcod
11 years ago

< I can't edit my own issues? >

By "but it isn't affecting the fullscreen width for images", i mean in the fullscreen editor.

#2 @DrewAPicture
11 years ago

#20641 was wontfixed before for what I think may be the same issue described here.

After testing in multiple browsers, I was only able to reproduce this consistently when inserting a captioned image, and that unfortunately goes for both inserting into DFW and the visual editor.

If we're constraining uncaptioned images inserted into either DFW or the visual editor with $content_width, we should do the same for captioned images.

What's holding us back it seems, are that inline width styles are being injected into the <dl> caption element allowing the image to push beyond the boundaries of the TinyMCE <body> element — the width of which is defined via $content_width. So maybe an issue in our implementation of TinyMCE?

#3 @DrewAPicture
11 years ago

  • Component changed from Editor to TinyMCE
  • Description modified (diff)
  • Version changed from 3.6 to 3.2

#4 @azaozz
11 years ago

So maybe an issue in our implementation of TinyMCE?

Don't think so, it's a simple css issue. Most themes' editor-style.css already have .wp-caption { max-width: 100%; } which constrains the caption wrapper width. Perhaps we finally should add that to the default editor css.

#5 @saltcod
11 years ago

What if the image isn't captioned? The screenshot posted above isn't captioned. Seems like the width: 100%, height: auto would fix it. I'll have a look at that now.

#6 @saltcod
11 years ago

When in fullscreen mode in the Visual tab, if you insert an image via the Media box, it will automatically get the size-auto, size-full, etc classes, and have the size constrained:

img.size-auto, img.size-large, img.size-full, img.size-medium {
max-width: 100%;
height: auto;

If you strip out the classes or enter it manually <img src="" /> the size won't be constrained. This feels like an edge case even as I type this, but I run into it all the time, and it should be easy to fix.

Wouldn't this fix the issue?

#wp-fullscreen-editor img {
max-width: 100%;
height: auto;

Thanks guys!

Last edited 11 years ago by saltcod (previous) (diff)

#7 follow-up: @helen
11 years ago

Editor styles can also do the max-width thing. I guess we can do it, but then what if the theme doesn't do that on the front? Then it's not representing what it might look like. Seems like a nastier surprise.

Last edited 11 years ago by helen (previous) (diff)

#8 in reply to: ↑ 7 @azaozz
11 years ago

Replying to helen:

Yes, that is the reason the img and .wp-caption don't have max-width set in the default editor css. This was left for the theme's editor-style.css to add so it matches the front end.

There are probably few themes that don't constrain images on the front end, and themes that do may not have editor-style. But agree that it will be a "nastier surprise" if it works in the editor and fails on the front.

Last edited 11 years ago by azaozz (previous) (diff)

#9 @iseulde
9 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Let's handle related issues in #24968. The old fullscreen editor is now deprecated.

Note: See TracTickets for help on using tickets.