This one resizes on the client using JavaScript appended to each image tag, whereas the other one (the one you quoted) uses server fetch requests to get the image and check the size and adjusts the tag as applicable.
This hack will still load pages slowly for the client, but the layout will be fine. It will be fast for the server, slow for the browser.
That hack will still load pages slowly for the client, and the layout will be fine. But it will be slow for the server, fast for the browser.
May I make a suggestion about this hack though? Perhaps another method?
Instead of adding JavaScript to every IMG tag within every post, and firing that many onloads... why not just add javascript to your headinclude template that parses all images onload?
Example... Put this in your headinclude... and don't bother hacking any vBulletin files:
HTML Code:
<script type="text/javascript">
function resizeImages() {
if (document.images) {
var mw = 800;
var mh = 800;
for (var ii = 0; ii < document.images.length; ii++) {
var i = document.images[ii];
var iw = i.width;
var ih = i.height;
if (ih > iw && ih > mh) {
i.style.height = mh + 'px';
} else if (iw > mw) {
i.style.width = mw + 'px';
}
}
}
}
if (window.addEventListener) {
window.addEventListener('load', resizeImages, false);
} else if (window.attachEvent) {
window.attachEvent('onload', resizeImages);
} else {
window.onload = resizeImages;
}
//-->
</script>
mw = maximum width in pixels.
mh = maximum height in pixels.
I've got mine set to 800 x 800, but you could put what you want in there.
Any img on the page will be resized to fit that area.
Of course, the end user still has to download them, but this resolves the problem with the script part going through to edits and quotes, and is also an easier install.
You don't have to use this version, but it's simpler methinks.