Hi Sandy,

Firstly, thanks for the idea of loading the image, the creating a new
element with the src as null, then injecting, then setting the src as
the correct src. This makes IE work correctly.

"With  respect,  I don't know if I would call it a lot of trouble. As
I
mentioned,  any time you are doing back-end image processing, you have
the  ability, I would say the obligation, to manage cacheability based
on the way images are embedded in the pages you serve up. If you do it
right, you get ultimate cacheability *plus* real-time changes. "

I couldn't disagree more with this. It seems unnessacery to have a
server set up where every css/js/xml file has a name change to the
file when it is edited. We (almost)always edit css files and leave the
filename the same. (ok there are some exceptions, but for 95% of
websites that are not amazon.com this works). We assume the browser
will correctly read the file correctly when the page is refreshed.

Images are just another asset to a webpage like js/css/xml. Changing
the name of a css file becuase it has been edited is not a "do it
right" method, and I can't see any reason why images should be viewed
differently.


On Feb 3, 9:33 am, Sanford Whiteman <[email protected]>
wrote:
> > Do you know if there any documentation for this bug?
>
> I  don't  think  so. But there are a few components/CMSes that attempt
> workarounds for it, and I reproduced it here on a couple of machines.
>
> Here  is  your client-side workaround, if you must: insert the Element
> with null `src`. Then set the `src` afterward. Clears it up for me.
>
> > The server side way of looking at it is interesting, I never thought
> > of it from that perspective. I could change my php resize function to
> > add in the string '800x600' onto the end of the filename when it
> > remakes the image.
>
> I  would  not  recommend  using  only that string. You are most likely
> using  lossy  resampling to get the image to new dimensions, right? So
> if somebody downsizes, and upsizes, the image, it is a different image
> from the original. You should still add 800x600-<versionnumber>.
>
> > That would be a more elegant solution, although it seems a lot of
> > trouble for a browser that simply won't read the size of an image in
> > it's cache when I call up the getSize() function, even after a dozen
> > refreshes.
>
> With  respect,  I don't know if I would call it a lot of trouble. As I
> mentioned,  any time you are doing back-end image processing, you have
> the  ability, I would say the obligation, to manage cacheability based
> on the way images are embedded in the pages you serve up. If you do it
> right, you get ultimate cacheability *plus* real-time changes.
>
> --Sandy
>
> ------------------------------------
> Sanford Whiteman, Chief Technologist
> Broadleaf Systems, a division of
> Cypress Integrated Systems, Inc.
> e-mail: [email protected]
> ------------------------------------

Reply via email to