-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Images: Try moving responsive rule to common.scss. #38399
Conversation
Size Change: +298 B (0%) Total Size: 1.14 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense conceptually. I tested in a few themes (classic + block), and they all worked as expected. Might be good to get one more theme dev's 👀 just to be sure.
Co-authored-by: Kjell Reigstad <kjell.reigstad@automattic.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this works as expected with other blocks too and I think it's a great default to have.
Excellent, thanks all for testing. I'm going to let this sit overnight and merge in the morning unless someone comments their concern. |
Cool, let's try this, it's a small change and easy to revert if we need to. |
Marking this one for backport since it solves a glaring issue with older content. |
* Images: Try moving responsive rule to common.scss. * Update packages/block-library/src/common.scss Co-authored-by: Kjell Reigstad <kjell.reigstad@automattic.com>
gutenberg/packages/block-library/src/common.scss Lines 129 to 132 in f111f0c
Is this rule meant to be making it to the frontend globally? |
Yes, with low specificity. Is it causing trouble for you? |
Yes unfortunately. Because it applies to all images, it is also applied to images on the site that don't come directly from the block or classic editor. In my specific case I had draggable slider driven by images that do not have explicit width definitions that broke. If the goal is to achieve the same responsive treatment to images that came out of the original classic editor, could this be achieved with a more specific rule? Or because we don't know what div that the post content is getting dumped in, there is no way to make it more specific apart from html/body. Sidenote: I've never seen a :where in SASS before and have been unable to find documentation on it, could you please refer me? |
@MaggieCabrera do you have any ideas on how we might scope this rule to be content specific? @carlaiau |
Yeah
Thanks very much! |
As long as it covers images that can be inserted via the editor, that would be fine (image blocks, images inserted in the classic editor, etc). Any other kind I think it would be fine to be handled by the theme or a plugin instead. |
I just saw a similar issue report - #39021. |
This is happening to me as well, which unfortunately means I would have to check which images in my themes don't have How about a more specific rule that selects images by the dynamic
Don't know about the css performance implications of using a regex css selector in huge sites though, but I think it is a better solution to avoid the problems of a more general rule. Maybe we could keep the
What do you think? @jasmussen |
adding the regex to the :where could be a go-er! |
Just confirming here that this change broke our 15+ year old site with spacer gifs and such 🙂 |
Description
Fixes #38384. We have CSS in place to provide a default responsive behavior for Image blocks (
max-width: 100%; height: auto;
), but this doesn't affect images inserted in the classic block. Before:This PR moves that responsive baseline to the
common.scss
file so it becomes boilerplate CSS rather than CSS specifically for the Image block. After:I'm unsure whether this is good practice. There's an argument to be made that the responsive behavior is a feature of the image block, and that when you're inserting a non-block image, it can be a sign that you want the freeform behavior. Also, the less boilerplate CSS, arguably, the better.
Nevertheless this does fix the issue, even if this PR needs testing across every single element in the canvas that uses Images, if we want to land it.
Testing Instructions
Insert test content, such as from this comment, and observe as in the screenshot above that the classic image is bounded by the main column.
Checklist:
*.native.js
files for terms that need renaming or removal).