#27292 closed enhancement (invalid)
HTML5 Captions: Apply the filter img_caption_shortcode_width
Reported by: | jond3r | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.9 |
Component: | Media | Keywords: | has-patch |
Focuses: | Cc: |
Description
Add the possibility to get HTML5 figure and figcaption elements in the output of the image caption shortcode. This would then be achieved by adding
add_theme_support( 'html5', array( 'caption' ) );
to the theme's functions.php for example.
This is a quite obvious suggestion in view of the recent addition of HTML5 to the gallery shortcode, see #26697. It also should not break any existing code (e.g. #27278) ;).
Attachments (3)
Change History (13)
#3
in reply to:
↑ 2
@
11 years ago
Replying to SergeyBiryukov:
Related: #26642
Thanks for pointing that out. Made a comment over there (ticket:26642#comment:14).
#4
@
11 years ago
Just a heads-up.
The suggested implementation of HTML5 captions in ticket 26642 (which has some high-influence backers), might result in difficulties in the styling of the captions (see that ticket for details). Notably, the 'img_caption_shortcode_width'
filter, which was introduced in 3.7.0, is suggested to not be available with HTML5 markup.
#5
@
11 years ago
The patch 27292.2.diff includes the functionality of removing the 10 px inline style width, that is added by default to the wrapping element (<figure> in the case of HTML5). This was inspired by ticket 26642.
#6
@
10 years ago
- Summary changed from HTML5 Captions to HTML5 Captions: Apply the filter img_caption_shortcode_width
#7
follow-up:
↓ 8
@
10 years ago
Now that we are officially smashed by #26642 (that title was changed to 'HTML5 captions', ouch!), we have to refocus this ticket to 'restore' the use of the img_caption_shortcode_width
filter for the case when theme support has been added for HTML5 captions. The patch .3 makes this happen, together with a unit test.
The use case of the filter is to make the inline width style of the figure element larger than the image width, in cases when the image width is narrow and/or the caption length is long.
In the meantime we have to use the filter img_caption_shortcode
, and reimplement most of the code in the img_caption_shortcode()
function to accomplish this.
As the img_caption_shortcode_width
filter is not (yet) applied for the visual editor, the appearance in the editor will not accurately reflect the appearance on the front end, when the filter is used. It would be nice if we could improve the visual editor in this regard, presumably by some Ajax magic.
#8
in reply to:
↑ 7
;
follow-up:
↓ 9
@
10 years ago
- Focuses template removed
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
Replying to jond3r:
Now that we are officially smashed by #26642 (that title was changed to 'HTML5 captions', ouch!), we have to refocus this ticket to 'restore' the use of the
img_caption_shortcode_width
filter for the case when theme support has been added for HTML5 captions.
I don't think we do. img_caption_shortcode_width
is deliberately not used when the theme supports HTML5 captions. This was also mentioned in the commit message for r27668.
The filter was introduced to give theme authors the ability to remove the added 10px, so the filter always expects width + 10px
. Since HTML5 captions don't have the added 10px, it would break backwards compatibility if we applied the filter there.
#9
in reply to:
↑ 8
;
follow-up:
↓ 10
@
10 years ago
Replying to obenland:
Since HTML5 captions don't have the added 10px, it would break backwards compatibility if we applied the filter there.
Sorry, but I have to defend myself. I think your argument is invalid. If HTML5 caption support is not added, the filter will still get width + 10px, so backwards compatibility i preserved. On the other hand, if HTML5 caption support is added, "no strings are attached", so a changed input value to the filter must be accepted. The filter documentation can be updated to reflect this.
The proposed enhancement here is not breaking backwards compatibility any more than the recently committed patch [27668]. I think this enhancement proposal is still valid.
(As a personal side note, it was unfortunate that I managed to file this ticket just a few hours before your proposal in 26642. It is not my intention to be a troublemaker, I'm just trying to defend myself and a sound opinion. I'm afraid I'm at risk of being banned from wordpress.org for this. Hopefully I'm not.)
#10
in reply to:
↑ 9
@
10 years ago
Replying to jond3r:
It is not my intention to be a troublemaker, I'm just trying to defend myself and a sound opinion. I'm afraid I'm at risk of being banned from wordpress.org for this. Hopefully I'm not.
You have a zero percent chance of being banned for contributing. On the contrary — thanks for weighing in!
Suggested patch with a unit test