![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Changes between Initial Version and Version 1 of Ticket #50909, comment 22
- Timestamp:
- 09/13/2020 06:46:37 AM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #50909, comment 22
initial v1 7 7 In WordPress, the old (classic) editor always included width and height for img tags. In the early days of Gutenberg that was dropped for some reason (I'm pretty sure there was/is an old PR to always add width and height to all img tags, unfortunately it was never merged). Currently images in the image block do not have width and height attributes when they are inserted, but get them when they are resized by the user. 8 8 9 In that terms the defects (skewed images on the front-end) described here can be considered "bugs" in the theme. Before WP 5.5 some img hags had width and height, others did not. This was corrected in WP 5.5 and now all img tags (for local images) get width and height added, to comply with the best practices and enhance the website visitors experience. Themes that do not handle img tags with width and height attributes were "buggy" before WP 5.5 too, although that was less noticeable as authors do not resize images in the editor often.9 In that terms the defects (skewed images on the front-end) described here can be considered "bugs" in the theme. Before WP 5.5 some img tags had width and height, others did not. This was corrected in WP 5.5 and now all img tags (for local images) get width and height added, to comply with the best practices and enhance the website visitors experience. Themes that do not handle img tags with width and height attributes were "buggy" before WP 5.5 too, although that was less noticeable as authors do not resize images in the editor often. 10 10 11 11 Looking at the (proposed) fixes here: It may make sense to add
