Make WordPress Core

Opened 5 years ago

Last modified 5 years ago

#48336 new defect (bug)

Global block editor image styles causing problems

Reported by: dennis_f's profile dennis_f Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.3
Component: Editor Keywords:
Focuses: ui Cc:

Description

I was just testing WordPress 5.3 RC1 on my site and I noticed that the images layout was broken in one of the elements. The element is a custom theme element that is outside the main content area (it is not added from the editor). Then I noticed the following global CSS that is added globally for all images on the front-end in the /wp-includes/css/dist/block-library/style.css:

img {
  max-width: 100%;
  height: auto; }

I think that there will be many others affected by this global CSS, especially the max-width: 100%; property. Some more dynamic elements (like sliders) that assume the default image max-width being none, and need the image to overflow its parent will now look broken with this global rule.

I'm not very familiar with the block editor internals, but I believe that those styles should be somehow scoped to the block editor elements only and not applied globally to all elements on the front-end.

Change History (5)

#1 @SergeyBiryukov
5 years ago

  • Component changed from General to Editor

#2 follow-up: @joyously
5 years ago

That CSS is best practice and not very specific. If there are plugins or themes that need something else, they would make it more specific and easily override that rule.

#3 in reply to: ↑ 2 @dennis_f
5 years ago

Replying to joyously:

That CSS is best practice and not very specific. If there are plugins or themes that need something else, they would make it more specific and easily override that rule.

While I agree that max-width:100% is a good practice for simple images added to the content of pages/posts, I think it's false to assume that every single image on the website will have to follow this rule. Websites often contain various dynamic elements, such as sliders, galleries, etc., and those elements may rely on the browser's default image max-width, which is "none".

In my particular case I have a header image slider with a fixed height. When the slider contains an image that is wider than the slider container, it overflows the container so we can keep the slider's height static (the image gets centered in its container). With the new max-width:100% rule, the image now looks squished.

The editor styles should be scoped to the editor elements only and not enforced globally to all elements on the front-end. Images are too widely used in various setups to assume that max-width:100% will work for all of them.

#4 follow-up: @joyously
5 years ago

Your particular case is very rare, and relies on some nebulous default. If it needs max-width: none, then it should specify that for that particular case, because it is non-standard.
The best case globally is the very rules you are complaining about.

#5 in reply to: ↑ 4 @dennis_f
5 years ago

Replying to joyously:

Your particular case is very rare, and relies on some nebulous default. If it needs max-width: none, then it should specify that for that particular case, because it is non-standard.
The best case globally is the very rules you are complaining about.

max-width: none is the default browser behavior - we're not supposed to repeat the browser default rules. I know very well that max-width:100% is a general standard these days (and I do have it applied to my simple content images), but I'm pretty sure that there are still many sites/themes that are not up to date with the standards. Probably there are also many sites that are not responsive yet.

This shouldn't be a game of overriding each other's rules and regardless of how stardard or not my case is, my point is that it is not good practice for one element (the editor) to be enforcing styles outside of its scope. I know that the WordPress team cares about backwards compatibility and I only opened this ticket because I believe that there will be many more affected by this (it's not for my personal gain, it will take me a couple of minutes to override this rule for my slider).

Note: See TracTickets for help on using tickets.