Logic behind forcing addition of width/height attributes still valid? How to handle for responsive designs

I was wondering the same thing. A quick search brought me to this issue. There has to be another filter we can run after image_resize_filter to actually remove the width and height attributes from an image tag. How exactly does Panopoly strip out those attributes from TinyMCE? Another filter? I haven't looked into it too much yet. Otherwise, yeah, this filter is useless for sites that use responsive web design. But I'm not convinced that it is within this module's scope to provide the functionality necessary to make inline wysiwyg images work for responsive web design.

Wouldn't it be better to allow an option to remove these attributes, so images can still be resized in the editor but conforms to the theme specifications on output?

To be clear, Image Resize Filter only sets the height and width *attributes*, it does not use inline styles. Actually in the case that you're using CKEditor, Image Resize Filter replaces height/width inline styles with attributes instead, which allows a theme to provide specific CSS that changes the image. The typical way of handling image resizing is by setting a CSS style of width: 100%; height: auto;. CSS will always take precedence over height/width attributes, so I'm not sure why Panopoly would bother removing these attributes. In fact keeping the attributes is beneficial because the browser can render the page faster because it doesn't have to wait for the image to load to find its dimensions. Given an image that has set dimensions, the browser can do the math adjustments based on available size before the image is retrieved.

So in short, I think this module still has a place in preventing end-users from embedding giant 10MB images inline that are displayed as 100x100 thumbnails, but in today's world of responsive design, any use of inline images needs careful consideration.

The typical way of handling image resizing is by setting a CSS style of width: 100%; height: auto;.

Do you mean max-width: 100%; height: auto;?

So in short, I think this module still has a place in preventing end-users from embedding giant 10MB images inline that are displayed as 100x100 thumbnails...

Isn't this an edge case? This module would only help in that case if the user actually resized the giant 10MB image in the wysiwyg editor. If I'm working on a $5k-$10k site, trying to address this type of edge case seems like very little bang for the buck. Even with training, I still don't trust non-technical content editors. :)

...in today's world of responsive design, any use of inline images needs careful consideration.

Completely agree. I don't think people realize all the nuances and details that are involved with getting a good editor-proof responsive design in place. Seems like a lot of trade-offs between what is editable in the CMS and what needs to be under tighter developer/designer control.

What do you use for inline wysiwyg images? TinyMCE, CKEditor, IMCE, Media, Insert?

Isn't this an edge case?

Depends on who your end-users are. It's the exact reason why I wrote this module because I had a site in which users didn't understand how big their images were. I could have forced users to use an image style or resized their images on upload, but both those solutions have other problems too.

What do you use for inline wysiwyg images? TinyMCE, CKEditor, IMCE, Media, Insert?

I typically use Insert module for inline images (I wrote that module also). I flip regularly between TinyMCE and CKEditor, but I'm also heavily involved in integrating CKEditor into D8 so these days I'd probably recommend you use CKEditor as that's where Drupal is heading. See #1932652: Add image uploading to WYSIWYGs through editor.module.

I just think that appending the height/width attributes is superfluous and prevents some standard responsive design practices from being implemented. Why add the height/width when the image is already that size?

As I just said: it's not superfluous because it helps the browser render the page faster. And it doesn't prevent standard responsive design practices: CSS takes precedence over the specified height/width attributes.