[wp-trac] [WordPress Trac] #44801: `image_constrain_size_for_editor()` forcing the `$content_width` messes up dimensions

[WordPress Trac]

#44801: `image_constrain_size_for_editor()` forcing the `$content_width` messes up
dimensions
--------------------------+------------------------------------------
 Reporter:  flixos90      |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Media         |    Version:
 Severity:  normal        |   Keywords:  needs-patch needs-unit-tests
  Focuses:                |
--------------------------+------------------------------------------
 The `image_constrain_size_for_editor()` currently looks at the
 `$content_width` global that themes may define. For `medium_large`,
 `large` and any custom image sizes, the actual image size's width will be
 evaluated against the `$content_width`, and the minimum will be used.

 This results in the following (example):
 * Let's say `$content_width` is 640.
 * Let's say your `large` image size constraints are 1280x1280.
 * Let's say your image in `large` size is 1280x960.
 * Instead of using the image size width (1280), it will use the
 `$content_width` since it's smaller (640), resulting in 640x480 being used
 for the dimension of the image in `large` size.

 This makes sense for the default behavior, but that computed size is used
 in many different areas, including `wp_prepare_attachment_for_js()`, where
 the `sizes` property then would show something like this for the `large`
 size (continuing the above example):

 ```js
 { width: 640, height: 480, url: '.../my-image-1280x960.jpg', orientation:
 'landscape' }
 ```

 Regarding what I want to accomplish with the custom image sizes, this
 results in unexpected behavior. For example in my case, I was looking into
 dynamically generating media queries for a background image, using the
 sizes. I was expecting for my code to generate `@media (max-width: 1280px)
 ...` for the image, but it would generate `@media (max-width: 640px) ...`
 due to the changed size.

 As I already said, the `$content_width` global makes sense to take into
 account by default. However, it is currently hardcoded into the function.
 I think it should be moved into a filter (we already have
 `editor_max_image_size` which is perfect for that), so that someone could
 temporarily unhook that behavior for custom use-cases.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/44801>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform