alloy-editor
alloy-editor copied to clipboard
liferay
Resizing an image in IE11 results sets different attributes than resizing an image in Chrome or Firefox
Do you want to request a feature or report a bug? bug
What is the current behavior?
- resizing an image in IE11 sets the style, height, and width attributes
- resizing an image in Chrome or Firefox sets only the style attribute
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
- Open Chrome, resize the image in the demo site
fullmoon.thumbnail.jpgand inspect the element, noticing there are no width and height attributes - Open Firefox, resize the image in the demo site
fullmoon.thumbnail.jpgand inspect the element, noticing there are no width and height attributes - Open Firefox, resize the image in the demo site
fullmoon.thumbnail.jpgand inspect the element, noticing there are width and height attributes
What is the expected behavior?
- Open Chrome, resize the image in the demo site
fullmoon.thumbnail.jpgand inspect the element, noticing there are width and height attributes - Open Firefox, resize the image in the demo site
fullmoon.thumbnail.jpgand inspect the element, noticing there are width and height attributes - Open Firefox, resize the image in the demo site
fullmoon.thumbnail.jpgand inspect the element, noticing there are width and height attributes
Which versions of alloy-editor, and which browser / OS are affected by this issue? Did this work in previous versions?
- Chrome and Firefox are affected by this issue.
- This did not work in previous versions.
- We attempted to fix this by making IE11 not have width and height attributes in https://github.com/liferay/alloy-editor/pull/923 but it was reverted in order to resolve https://github.com/liferay/alloy-editor/pull/1060
Perspective from the outside here. It's not so much that it's element vs inline style ... It could have both. What's actually happening is that the width for example is being set as 150px AND 75px at the same time. As an example.
What needs to happen if both width= and style=width: is used then both of those numbers need to match and both numbers need to be updated.
What's happening is that certain browsers are only acting on one thing, it should be both numbers being updated. This situation has been occuring for many years and our users HTML is full of dimensions that aren't matching.
It would be ideal also if particularly in DXP if we could know an audit of the edit, not just date modified but what environment was the user in when editing. Was it IE/Win, Chrome/Mac or Firefox/Linux and that could be set as a class on the content editable div with that user agent stored alongside the edit in the database.
That then gives me a good chance of using a class to attack the HTML with jQuery and fix the mismatch in dimensions in the DOM while Liferay nail this problem.
If I ever get a chance to write an Alloy Editor code content clean up script, I'll post it for consideration. The problem would be what size should the image be, if the width is 75px and 150px would the script choose the larger number? Which user was correct Sarah on IE or Terry on Chrome.
A "remove formatting" feature would at least give a user (or a support member fixing the issue for the user) the potential to clear the HTML and rebuild the content.
The problem would be what size should the image be, if the width is 75px and 150px would the script choose the larger number? Which user was correct Sarah on IE or Terry on Chrome.
@duracell80 : My understanding is that the inline style should always have higher precedence, so regardless of the browser, a user would only see the changes if they update the inline style (attaching attributes when there is already an inline style would do nothing).
Viewing the following HTML file in different browsers consistently results in a very large empty image followed by a very small one.
<html><body>
<img border=5 width=5 height=5 style="width: 500px; height: 500px" />
<img border=5 width=500 height=500 style="width: 5px; height: 5px" />
</body></html>
The following Stackoverflow post also contains a useful link and explanation, since the specificity for the attribute value being zero means that any style (inline or not) would override the attribute.
- https://stackoverflow.com/questions/20742675/whats-the-difference-between-htmls-and-csss-width-attribute
As a result, even though the current behavior is inconsistent, it shouldn't have any actual end user impact, unless that end user is a developer inspecting the page.
Unfortunately there have been end user impacts between different users using different browsers to edit the same content. Sometimes causing different sizes in the saved content, sometimes causing the image resize plugin to refuse to work.
I've run into the opinion before that the "browser default" behaviour is correct ... But that can't be right because there are no web standards on this.
I think TinyMCE uses the HTML attributes and stays away from the inline styles but they do use inline styles for "image padding".
CKEditor ... I wasn't able to find any developer standards on how to output HTML when writing plugins, so the danger in relying on plugins is that fragmentation of standards. Developers have different styles, that's ok but there really needs to be a best practice understanding in in the developer community and a focus on code standards.
I would think a way forward would be for Liferay to lay down internal standards on how HTML should be created by the editor and test against that standard rather than defer to how the browser handles it. Maybe AntiSammy could enforce a HTML standard within DXP.
Having that standard could also help write a HTML clean up script. To be fair we have content created in Liferay 6 5+ years in the past, that content would still be edited in DXP 7 today.
It's not an easy task, some standards could help and considering "tag soup" just takes me back to the dangers of deferring to plugins and how browsers do things by default.
But yeah width=50px and width=75px at the same time can't be considered ok.