Make WordPress Core

Opened 5 years ago

Closed 2 years ago

Last modified 21 months ago

#14380 closed defect (bug) (fixed)

Caption shortcode inserts inline style forcing width of containing div

Reported by: iandunn Owned by: nacin
Milestone: 3.7 Priority: normal
Severity: minor Version:
Component: Shortcodes Keywords: 3.2-early dev-feedback has-patch
Focuses: Cc:


This is related to #9066.

The problem is that the image caption shortcode inserts an inline style on the containing div which sets the width to an arbitrary value which cannot be overriden by the theme's stylesheet.

The proposed solution is to replace the shortcode function with a custom one which creates the markup without the inline style, but this is undesirable. It adds unnecessary complexity for beginners and is just generally annoying and shouldn't be necessary.

Creating an inline style violates web standards and contradicts the philosophy behind a theme-based architecture.

The inline style on the div should be removed so that theme developers can style the caption like they would any other element, without having to resort to inconvenient workarounds.

Attachments (3)

14380.diff (5.0 KB) - added by solarissmoke 5 years ago.
14380-filter.diff (623 bytes) - added by iandunn 3 years ago.
Adds wp-caption-width filter
14380-filter.2.diff (737 bytes) - added by iandunn 2 years ago.

Download all attachments as: .zip

Change History (21)

#1 @markjaquith
5 years ago

  • Milestone changed from Awaiting Review to Future Release

You're right. This is pretty lame.

#2 @nacin
5 years ago

  • Keywords needs-patch added; caption inline style removed
  • Owner set to nacin
  • Status changed from new to accepted

3.2 with a patch.

5 years ago

#3 @solarissmoke
5 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

First pass at a fix is attached.

Taking away the width property causes "alignnone" captions to fill the whole width of the container. I have fixed this by modifying the style in TwentyTen, but this may have unintended consequences, so needs to be tested.

I realised while doing this that SCRIPT_DEBUG does load .dev scripts for tinyMCE plugins - you have to switch them round manually, which is a bit messy. I might open another ticket to see if this can be changed.

#4 @nacin
5 years ago

  • Keywords 3.2-early added

General 3.2 consideration.

#5 @smerriman
5 years ago

The inline width is necessary. The point of using an inline width is to allow captions which are wider than the image itself to wrap. There is no way to accomplish this with CSS alone if you get rid of the inline style.

#6 @solarissmoke
5 years ago

  • Keywords dev-feedback added; has-patch needs-testing removed

Hmm. Maybe they we should add a filter to the html output so that theme/plugin authors can override the inline styles if they want to?

#7 @wonderboymusic
3 years ago

  • Keywords needs-refresh added

3 years ago

Adds wp-caption-width filter

#8 @iandunn
3 years ago

  • Keywords needs-refresh removed

I tried to get it working with CSS alone awhile back and couldn't, so I agree with smerriman that the inline width is required. I added a patch that creates a new wp-caption-width filter that themes can use to modify the width instead.

#9 @helen
3 years ago

#17044 was marked as a duplicate and has a good bit of discussion.

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

#10 @greenshady
3 years ago

  • Cc justin@… added

#11 @iandunn
3 years ago

It sounds like the main obstacle brought up in #17044 was breaking backwards compatibility. The latest patch here just adds a filter around the width, so it won't break anything by default. The filter still allows theme devs to change the width to exactly what they want (including the exact size of the image, without padding), without having to rebuild the entire shortcode output, so it's much more convenient.

#12 @iandunn
3 years ago

  • Keywords has-patch added

#13 @iandunn
2 years ago

Any opinions 14380-filter.diff? Seems like this is an easy close for 3.7 if nobody objects.

#14 @nacin
2 years ago

If we are going to add a filter, ideally should it enable the ability to remove the inline style all together?

Style note, our filters generally use underscores rather than hyphens, and wp_ only when they are filtering a return value of a function and the filter is the same name as said wp_ function.

#15 @iandunn
2 years ago

14380-filter.2.diff​ corrects the filter name, and makes it so that the style attribute isn't printed if the value is 0 or false.

#16 @SergeyBiryukov
2 years ago

  • Milestone changed from Future Release to 3.7

#17 @nacin
2 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 25444:

Introduce a img_caption_shortcode_width filter for controlling the inline style of the image caption shortcode.

props iandunn for the initial patch.
fixes #14380.

#18 @nacin
21 months ago

In 27668:

Introduce HTML5 caption support.

When a theme supports HTML5 captions via add_theme_support( 'html5', 'caption' ), figure and figcaption will be used instead of div and p.

There's a bonus. But first, some history: Captions were introduced with an inline style set for the container. This remains, as it is there to force captions to wrap. But this inline style included an extra 10 pixels, which have vexxed theme developers for years. While these pixels were designed to ensure padding around floated images, modern themes handle this with grace. The additional pixels thus feel encumbering.

As the new HTML5 gallery support avoids outputting default gallery styles (again, irking theme developers for years; see #26697), the new HTML5 caption support will also ditch these 10 pixels of unwanted hand-holding.

The 10 pixels are also removed entirely in the visual editor (and more styles may also disappear here; see #26642), giving themes the power necessary to match the frontend styles.

The filter img_caption_shortcode_width added in 3.7 to work around this madness (see #14380) is skipped entirely when the theme supports HTML5 captions.

props obenland, azaozz.
see #26642. also fixes #9066.

Note: See TracTickets for help on using tickets.