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

Hard coded width for center, right, and left aligned images #9302

Closed
ghost opened this issue Aug 24, 2018 · 10 comments · Fixed by #11846
Closed

Hard coded width for center, right, and left aligned images #9302

ghost opened this issue Aug 24, 2018 · 10 comments · Fixed by #11846
Labels
[Feature] Media Anything that impacts the experience of managing media Needs Testing Needs further testing to be confirmed.

Comments

@ghost
Copy link

ghost commented Aug 24, 2018

Describe the bug
If an image is left, centred, or right aligned, it cannot be resized beyond 580 pixels within the Gutenberg editor regardless of the dimensions of the actual image file. This makes it impossible to predict what it will look like on the front end as it will likely display as the actual size specified as opposed to how it shows in the Gutenberg editor.

To Reproduce
Steps to reproduce the behavior:
Add and image
Leave it centered or set it to left or right alined.
Try to display is larger that 580px.

Expected behavior
You should be able to drag-resize the image up to the actual pixel dimensions of the file, whether it's the original, large, medium-large, etc., or at the very least to the content width of the theme.

The culprit is this line of code in /editor/index.js

line 4778: maxWidth: 580,

Desktop (please complete the following information):

  • All
  • All

Gutenberg version 3.6.2

@designsimply designsimply added [Feature] Media Anything that impacts the experience of managing media Needs Testing Needs further testing to be confirmed. labels Aug 24, 2018
@samikeijonen
Copy link
Contributor

I noticed the same issue when you change content width in the editor via CSS.

In the editor image block block-library-image__resizer have inline styles which set the width: 580px;. If I change editor width to something else via CSS this doesn’t match anymore.

  1. Can those inline values be off before user start resizing the image?
  2. If not, can that hard coded width: 580px; be changed somehow?

@chrisvanpatten
Copy link
Contributor

I noticed this on an un-aligned image as well, not just left/right/center.

@samikeijonen
Copy link
Contributor

I noticed this on an un-aligned image as well, not just left/right/center.

Yep.

@azaozz
Copy link
Contributor

azaozz commented Oct 8, 2018

... [an image] will likely display as the actual size specified as opposed to how it shows in the Gutenberg editor.

This will (should) be fixed in #6177. It adds a scale attribute to the image block that will be used to scale images according to the block width on the front-end. This ensures images will displayed on the front-end exactly as they are displayed in the editor. (By default all images will have scale = 1, i.e. 100% width.)

@azaozz
Copy link
Contributor

azaozz commented Oct 16, 2018

Updated the image block branch: https://github.com/WordPress/gutenberg/tree/update/image-block, please test :)

@azaozz
Copy link
Contributor

azaozz commented Oct 18, 2018

Updated the branch again, please re-test :)

How are you trying to resize the image? The only way to set "hard coded" size is to use the sidebar width or height fields, otherwise the size is set on the front-end automatically (some fixes there in the update).

When using srcset (as this branch implements) it is not necessary to pick a specific image file. It will be overridden by the srcset and sizes attributes on the front-end, the browser "decides" which file to download.

@timhibberd
Copy link

@gutterberg - I feel your pain and agree that this issue should be fixed but the people in charge of the core code and the core contributors are working hard at the moment tackling a large number of issues in a short amount of time. Patience. Something this obvious will get fixed. Also it's open source...you can always fork it and delete that one constant. A fairly small effort to achieve your goal :-)

I speak to you as another issue creator waiting patiently and optimistically that Gutenberg will slow down long enough to take a deep breath and solve issues such as this one before shipping.

@timhibberd
Copy link

You have to remind yourself that these are, in many cases, people like you and I working for free using our spare time to give back to open source. Patience and optimism are a must in open source :-)

@timhibberd
Copy link

Gutenberg is a big change. Big changes are sometimes messy. WordPress needs to stay relevant in a Wix / Squarespace world. That's the reality. If you do, really, believe that Gutenberg is not the destiny you believe in, perhaps ClassicPress is your better future path. Just a thought...do not mean to be presumptuous or rain on your rant :-)

@timhibberd
Copy link

You underestimate the Darwinism of the technology market and technology consumers. There is a long list of corpses of dominant technology companies with a stronger market share than WordPress that were pushed aside by competitors: Sperry Univac, Honeywell, Control Data, Digital Equipment Corp., Wang, Data General, Prime, Kodak, Polaroid, Lucent, Nortel, Compaq, Gateway, Lotus, Borland, Novell, Nokia, etc.

Though a PR in Gutenberg is probably not the most productive environment for you and I to debate the topic.

Let's get back to the issue at hand...."If an image is left, centred, or right aligned, it cannot be resized beyond 580 pixels within the Gutenberg editor regardless of the dimensions of the actual image file." That's at least something we can agree needs fixing :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Media Anything that impacts the experience of managing media Needs Testing Needs further testing to be confirmed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants