Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: Inspector interface for setting pixel dimensions of image #4914

Closed
jasmussen opened this issue Feb 7, 2018 · 12 comments
Closed
Assignees
Labels
[Feature] Inspector Controls The interface showing block settings and the controls available for each block [Feature] Media Anything that impacts the experience of managing media [Type] Task Issues or PRs that have been broken down into an individual action to take
Milestone

Comments

@jasmussen
Copy link
Contributor

jasmussen commented Feb 7, 2018

This would be nice to have: the ability to manually set the pixel dimensions of an image. This is especially useful if you are inserting a 2x retina image, and need to set the dimensions to half of what the image is born with.

Right now the only way to do that is to enter the code editor and adjust all the dimensions there. If you only use the "Edit HTML" on the block level, you do not get access to edit the HTML hints that need to be edited in order for the block to validate.

It would be nice to simply allow these dimensions to be edited in the inspector for images.

Mockups:

We expand the Block Settings for the Image block to have additional options:

screen shot 2018-03-07 at 13 46 41

  • You can choose the source thumbnail for the image in a dropdown.
  • When the image size is unset, the intrinsic dimensions for the image are shown as grayed. (Really nice to have, not critical.)
  • Pressing the Reset button will always return the dimensions to the intrinsic ones by the image.
  • The pill button pattern below consists of quick shortcuts to quickly set the dimensions. For example if your image is 300x200 and you press the 50% shortcut, the dimensons for the image are explicitly set to 150x100.
@jasmussen jasmussen added [Type] Enhancement A suggestion for improvement. [Feature] Inspector Controls The interface showing block settings and the controls available for each block labels Feb 7, 2018
@mtias mtias added the [Feature] Media Anything that impacts the experience of managing media label Feb 7, 2018
@mtias
Copy link
Member

mtias commented Feb 7, 2018

I was thinking it would be useful to have a row of percentage values for quickly setting images in a consistent manner.

image

We would even make this extensible so that a theme can define a specific array of values.

cc @iseulde for some of the work around floated images and @azaozz for responsive images.

@azaozz
Copy link
Contributor

azaozz commented Feb 7, 2018

Recently I've been thinking quite a bit on how to best handle images. The current behaviour: default of 100% width with 50% width for floated images makes a lot of sense and covers most user cases.

This would be nice to have: the ability to manually set the pixel dimensions of an image. This is especially useful if you are inserting a 2x retina image, and need to set the dimensions to half of what the image is born with.

With the srcset and sizes attributes this works better. Generally we don't (have to) care about 2x, 3x, etc. display densities as the browser takes care of that automatically. It chooses the best image size to download and only needs to know the width of the image when it is displayed.

Of course it would be good to have support for entering pixel values in the inspector. A quirk there will be that the editor and the theme may have different width, so results may be a bit unexpected in some cases. But the "power users" will definitely love it.

Having a row of percentage values (perhaps only for floated and centered images) would also be really nice. The ability to set several images to uniform size was one of the features many users wanted back after the last major version update of TinyMCE (yep, there used to be a "step-slider" with 10% steps for image resizing in the previous "image settings" modal).

On the other hand having percentage widths for images and not knowing the theme width brings some hard to solve problems when implementing the srcset and sizes attributes. The browser has to know how wide an image will be before the CSS is applied so it can pick the best source. Currently this is done by setting the img tag width attribute in the classic editor. I'm experimenting/considering few different approaches on what/how to do it for percentages.

@mtias mtias added [Type] Task Issues or PRs that have been broken down into an individual action to take and removed [Type] Enhancement A suggestion for improvement. labels Mar 7, 2018
@mtias mtias added this to the Merge Proposal milestone Mar 7, 2018
@noisysocks noisysocks self-assigned this Mar 26, 2018
@noisysocks
Copy link
Member

I'm going to look into this one.

This would be nice to have: the ability to manually set the pixel dimensions of an image. This is especially useful if you are inserting a 2x retina image, and need to set the dimensions to half of what the image is born with.

Responsive images were added in #4898, which I think nicely solves this retina image use case.

Still, I agree it would be nice to be able to explicitly set an image's dimensions using the inspector.

@jasmussen: With this in mind, is the mockup in the description above up to date?

I'm experimenting/considering few different approaches on what/how to do it for percentages.

@azaozz: Where did you get to with your experimenting? 🙂

@jasmussen
Copy link
Contributor Author

With this in mind, is the mockup in the description above up to date?

Yes. Though here's an additional one where the 100% is pressed, which simply inputs the intrinsic dimensions of the image.

screen shot 2018-03-26 at 08 15 11

CC: @karmatosed for sanity check.

@mtias
Copy link
Member

mtias commented Mar 26, 2018

Note that a component "ButtonGroup" was added to support the recent font size iteration, and should be used here.

@karmatosed
Copy link
Member

Looks good to me @jasmussen, this is being asked for in feedback so good to work on and get shipped.

@jcklpe
Copy link

jcklpe commented Apr 9, 2018

Hey just wanted to check in. I found this ticket through #2775

Is there a way to reset manual resizing of images and return them to a responsive state in Gutenberg?

@noisysocks
Copy link
Member

Is there a way to reset manual resizing of images and return them to a responsive state in Gutenberg?

Not yet, but pressing the Reset button that we're proposing to add as part of this issue would accomplish just that.

@jasmussen
Copy link
Contributor Author

Is there a way to reset manual resizing of images and return them to a responsive state in Gutenberg?

It's correct that there will very soon be an explicit reset button, which should be somewhat obvious.

But you can still do it today, albeit in a less discoverable way, by applying and then unapplying a wide alignment.

@jcklpe
Copy link

jcklpe commented Apr 9, 2018 via email

@azaozz
Copy link
Contributor

azaozz commented Apr 9, 2018

Been thinking about this for a long time and got a "mini-proposal" on handling images (that may be better as a new issue?).

Currently:

  • Images are inserted in the editor at full size, i.e. we force the user to download 2MB-5MB files in most cases.
  • When the user saves the post without changing image source from the inspector, there is a chance front-end visitors will have to also download the huge files. That doesn't usually happen as WP adds the srcset attribute, but the sizes attribute is pretty useless as it only refers to the full size: sizes="(max-width: 6000px) 100vw, 6000px".

To fix this in the editor:

  • Always insert the "large" size (1024px) images . If it doesn't exist (if the uploaded image is smaller), insert the "full" size.
  • Add srcset attribute that will also list 2x large size (so images are retina ready). This is a new size and will have to be added to the default WP sizes, see below.
  • Add another attribute to the <img> tag for Gutenberg images so we can recognize them easily in PHP. This is necessary as we will have to calculate the front-end srcset and sizes attributes a bit differently. Ideally that should have the attachment ID, something like data-wp-attachment-id="1234". Then perhaps can drop the "old" way of passing the ID, class="wp-image-1234" (can confirm if that would impact something else).
  • Consider special handling of the width="123" attribute. In HTML 5.0 is has to be in px, but since the width of the editor is different than the width of the theme, the results would often be unexpected. This impacts mostly images that are resized when the user drags the corners. Should probably look for a better solution for this case, perhaps recalculating the number when displaying the image on the front-end according to the theme's width.

To fix this for the front-end:

  • Add new default size 2x large, 2048px max width or height.
  • Add some logic when processing <img> tags and adding srcset, etc. that will produce usable sizes attribute. It will depend on the new data-* attribute and take into account theme's width when calculating sizes. If we are going to recalculate hard-coded width attributes (see above), this can be done here and the values used in both attributes. Alternatively we can set the width in percentage (HTML 4.0 style) in the editor, then replace them with pixels at this point.

Am I missing something? Any other ideas or suggestions?

Edit: moved this to #6177.

@karmatosed karmatosed modified the milestones: Merge Proposal, Merge Proposal: Media Apr 12, 2018
@mor10
Copy link
Contributor

mor10 commented Apr 12, 2018

Related: #6131 @azaozz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Inspector Controls The interface showing block settings and the controls available for each block [Feature] Media Anything that impacts the experience of managing media [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

No branches or pull requests

7 participants