[New sniff] Discourage CSS rules for images setting width:auto

[joyously]

Rule type:

Warning

Rule:

Flag CSS rules for images that have the property width:auto.
There is no rule in the Handbook for this, but it falls under the general guideline to honor the user's choices.

The default value for CSS width is auto, so there is no need to specify it. When it is specified, it will override the HTML width attribute. So an img tag with a different width attribute than the source image is would be affected, and it will display as the size of the source image instead of the size the user requested.

Decision needed:

Good wording for something that is not a requirement. This is more of admonition to "play nice".

Notes for implementation:

• I think bootstrap has one of these, but I have not investigated if it affects user content.
• This should be limited to images, although it's conceivable that it would have the same problem for a div.

To do:

• Add the rule in the Theme Review handbook to the Recommended page.
• Create unit tests
• Create new sniff

[joyously]

In case you would like real-world examples of themes with this type of CSS rule, here are some theme Trac tickets that I found it on while running the Theme Unit Test on them:
#39702
#40489
#40665
#40856
#41115
#41305

[joyously]

This should be amended to include width:100% also. I've seen several of these lately, whether targeting just the widgets or gallery or all of the user content area, it messes up icons and thumbnails or any image less than full width. Here is one I just found with the rule
.entry-content img, .comment-content img, .widget img {width: 100%}
affecting the RSS icon in a footer widget:

Other similar rules have affected the author avatar in the bio box, and thumbnails I put in a widget or in my page. The user should be able to get the image size he chooses, not what the theme chooses.

[pattonwebz]

This issue is problematic to sniff for automatically in a reliable way as rules are applied with .classes and #IDsand we can't know for certain if they would be applied to images.

[joyously]

The rules to check end with img.

[khacoder]

We are just talking images in the post area?

[joyously]

No, we are talking about CSS rules that affect images. See screenshot above for an example of how an icon can get totally messed up using width:100%.

[khacoder]

I saw that, but I think theme authors need to test their css and act accordingly.

[dingo-d]

The problem with checking this is that some images can have certain classes on them, and then they would have width: 100% on them, but how do you differentiate between a case where 100% width is warranted and when it's not (in the sniff)? You need to activate the theme, load test data and see if anything breaks.

Looks like more of a visual regression test than code sniff to me.

[joyously]

The purpose of the sniff is to find the cases it can find and issue a warning. Obviously, it can't find all cases. But I have seen a lot of themes that have done this, and it is always with img as the last part of the selector. If you think about it, it is pretty clear that styling images with 100% or auto width makes no sense. Classes yes, images no. (Besides, it's just a warning.)

[justintadlock]

Here's some sample code pulled from some gallery-specific code used in nearly every one of my themes:

.gallery-icon img {
	width:      auto;
	max-width:  100%;
	height:     auto;
	margin:     0 auto;
	box-sizing: border-box;
}

Because you're missing the context of the rest of the CSS code as well as no visual check, you have no way of knowing whether that code is doing what it should be doing. It works as it should, by the way.

That's just one use case that I pulled up in a matter of minutes. I'm sure I can find many, many more.

There are far too many legit use cases where setting width: auto and width: 100% on an img element for this to be a worthwhile pursuit.

I do agree that seeing width: 100% applied to the img element often creates issues. I've seen it tons of times. I just don't think this is appropriate for a code check and is better handled as a visual check.

[joyously]

I think you would find that removing the width:auto, the CSS would work just fine because auto is the default. The biggest problem for the use of auto is where it overrides the user requested width, which won't be there in something like a gallery, which is a shortcode.

I suggest this sniff, as a warning, to catch the cases that can be caught, and to educate authors that haven't ever tested with user defined widths (for width:auto) or icons (for width:100%). If we could make sure these types of tests are done, there would be no need for a warning, but since we can't, I think a sniff for this is valuable.

[justintadlock]

I think you would find that removing the width:auto, the CSS would work just fine because auto is the default.

I can guarantee you that it won't be fine in some scenarios. That's why I specifically wrote the code and have been refining it over the course of 10 years now.

[joyously]

I don't understand the resistance to having a sniff that gives a warning on a visual thing. We can't automate the unit test, but we can suggest that certain things are potential visual problems, just like other warnings that must be checked manually. What is the big deal if authors actually learn something, and have fewer support tickets? It makes better themes.

[dingo-d]

That would fall under visual regression test then.

[dingo-d]

Any idea what should we do with this?

[joyously]

I stand by the fact that if the sniff can be written, it will help the author catch some problems they might not notice in their limited testing.
The case for width:auto is when an image has a width attribute in the HTML that is different from its actual size. Since CSS overrides attributes, the user doesn't get what they wrote. I have sites where this is done a lot, so I'm sure there are a lot of sites out there with this markup.
The case for width:100% is obviously for the image that is small and is blown up by the browser to meet the parent container. This has happened in my test cases with icons and other small images that I have used, such as thumbnails.
If the author doesn't have the right test data, they don't notice these problems. A warning would be great to educate them and prevent support issues later.

[jrfnl]

Two points about this:

• The CSS tokenizer is proposed to be removed in PHPCS 4.0, so while we can still sniff CSS files at this time, there's no guarantee this can still be done in the future.
• CSS within inline HTML in PHP files can be checked, though if the value for width is set in a variable or constant, it will not be possible to sniff this in a reliable manner.

Having said that, to even attempt to write sniffs for this, we'd need a lot of code samples, so please add any and all code samples to this issue.

[dingo-d]

To me this seems like it would maybe be better to include in Theme Sniffer. We could see if this can be linted using stylelint which can be included in the plugin.

The Removal of CSS tokenizer in PHPCS 4.0 is one more reason why I'm against writing sniff for this (no long term gain imo).

[jrfnl]

Let's not forget that, while probably not as high priority as checking CSS files, a sniff for checking inline HTML within PHP files for this should probably still be written.

[carolinan]

I don't think this should be included, we do not review design unless the page is broken / unreadable. To me this would fall under "not pretty".

[joyously]

It really is not about design at all. It's about the user being able to get the size as coded in the HTML, and the browser blowing up small images like icons.

[dingo-d]

Triage resolution: we'll leave this for the sniffer. Sniffing CSS is super hard without context, and CSS in either PHP or HTML can be tricky to sniff if the value is in the variable.