Opened 11 years ago
Closed 11 years ago
#22667 closed defect (bug) (fixed)
3.5 Media: Compat Meta can float wrap around to the right
Reported by: | Viper007Bond | Owned by: | nacin |
---|---|---|---|
Milestone: | 3.5 | Priority: | normal |
Severity: | normal | Version: | 3.5 |
Component: | Media | Keywords: | has-patch commit |
Focuses: | Cc: |
Description (last modified by )
The compat-meta
div which adds extra stuff to the meta data in the new media UI is floated to the left. However it also needs a clear, otherwise it can end up looking weird depending on the image size (a narrow image seems to be required to set it off).
Screenshots attached of me adding an "Advanced Edit" link using the following:
add_filter( 'media_meta', function( $media_meta, $attachment ) { // Abort when actually editing this media item // We only want to modify this outside of the media edit screen if ( ! empty( $_GET['post'] ) && $attachment->ID == $_GET['post'] ) return $media_meta; $media_meta .= '<a href="' . esc_url( get_edit_post_link( $attachment->ID ) ) . '" target="_blank">Advanced Edit</a>'; return $media_meta; }, 10, 2 );
Attachments (15)
Change History (31)
#1
@
11 years ago
- Description modified (diff)
- Keywords needs-patch added; has-patch removed
- Summary changed from 3.5 Meida: Compat Meta needs to clear: left; to 3.5 Meida: Compat Meta can float wrap around to the right
#2
@
11 years ago
- Keywords needs-body added
- Milestone changed from Awaiting Review to 3.5
- Summary changed from 3.5 Meida: Compat Meta can float wrap around to the right to 3.5 Media: Compat Meta can float wrap around to the right
Needs a patch!
#3
@
11 years ago
More obvious example: 22667.png.
Could we perhaps move .compat-meta
inside .details
? 22667.patch does that. Also adds nowrap for "Delete Permanently" link.
Screenshot: 22667.after.png.
#5
@
11 years ago
attachment:22667.diff fixes the bugs illustrated in: attachment:22667.jpg (the left column is before and the right column is after applying the patch).
I've added 10 more px to the media-sidebar to make space for longer strings (e.g. September 28, 2012). Lowering the image size should also save some space but it would affect the page consistency.
#6
@
11 years ago
- Keywords has-patch needs-testing added; needs-patch needs-body removed
Let's go with SergeyBiryukov's attachment:22667.patch. Grouping the two works well. +1.
cdog, with the combination of translated strings and browser/OS settings, tuning widths is particularly difficult. For example, 'September 28, 2012' easily fits on the line (with a max-width image), with about 20-30px to spare. Also, we shouldn't fix the width on the details and compat containers, as their contents can easily be wider than the column itself. The UI should handle these situations gracefully.
#7
follow-up:
↓ 8
@
11 years ago
I agree with you, grouping the two helps.
I've also made some tests with attachment:22667.patch and noticed some issues. A longer date or filename is pulling the details below the thumbnail as shown in attachment:22667-issues.jpg.
A possible solution is to set a fixed width for the details element (attachment-info.width - thumbnail.max-width should be fine) the overflow to hidden for the details element to establish a new block formatting context. This should make the details to remain aligned with the thumbnail while longer strings will be wrapped or clipped inside the available space.
Edit: It's just a suggestion. If the details should always stay aligned with the thumbnail setting nowrap to delete-attachment is not sufficient. Else, SergeyBiryukov's patch does the trick.
#8
in reply to:
↑ 7
@
11 years ago
Replying to cdog:
I've also made some tests with attachment:22667.patch and noticed some issues. A longer date or filename is pulling the details below the thumbnail as shown in attachment:22667-issues.jpg.
This is intentional — the intended behavior is that if the details do not fit within the space to the right of the thumbnail, they all are moved below it. Save the space if we can, but display things nicely if we can't.
#9
follow-up:
↓ 10
@
11 years ago
attachment:22667.3.diff builds off of 22667.patch, allowing extra long filenames to break properly.
#10
in reply to:
↑ 9
@
11 years ago
Replying to koopersmith:
attachment:22667.3.diff builds off of 22667.patch, allowing extra long filenames to break properly.
Just tested attachment:22667.3.diff. Good idea on using word-wrap but for narrow images and long strings I've got a lot of unused space and a long scrollbar as shown in attachment:22667.3.jpg (left).
Take a look at attachment:22667.4.diff. All the available space is filled and the scrollbar is shorter as shown in attachment:22667.3.jpg (right). And the code is smaller too.
Again, this is just a suggestion. Feel free to use the most suitable solution.
#11
@
11 years ago
One issue would be that word-wrap could break something like "Delete Permanently" in an odd way. (And when strings are translated, they can additionally grow in length up to 2x.) It is better to let details decide to wherever it can fit, without shoving it into a too-narrow area.
#12
@
11 years ago
- Owner set to nacin
- Resolution set to fixed
- Status changed from new to closed
In 22983:
#13
@
11 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Was the omission of nowrap for "Delete Permanently" link in [22983] intentional?
It still wraps to a second line, which doesn't look nice on hover: 22667.delete-permanently.png.
A
clear: left;
just always puts it below the image. Needs a better fix than that.