I can see your point in a perfectionist sense, I think you idea is the best way to do it. But from a pragmatic point of view I don't have any problem with my original set up in firefox/webkit etc. I have never had any problems telling people "if you change the image size then refresh the page," I have never had any problems having to refresh the page when I do any css/js/php or images(that are loaded with html) editing.
If IE didn't cache the image size, the idea of me rewriting the filenames would never had crossed my mind. I can see how pragmatically this could be useful if a I site was being changed daily, and hit thousands of times daily. In my case the img size is changed a couple of times in development, and left constant for months at a time. Your src=null method lets me make IE behave like firefox, and I am more than happy with firefox behavior, so I will leave it as it is. On Feb 3, 4:25 pm, Sanford Whiteman <[email protected]> wrote: > > 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. > > I never said anything about files that you (the developer) are > editing. We were talking about files that you allow your end-users to > edit, using an application you built for this purpose -- and it is > absolutely best practice to ensure that those changes are "committed" > not only for the user doing the editing, but for all other users who > may have viewed the file in its previous form. This is the way hosted > image editing must work, or it's not worth offering the functionality. > > > 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... > > Actually, although I never said anythng about non-image files, it is a > very good method for optimizing cacheability. We are not talking about > changing the file name on disk, we are talking about changing the URI > and/or eTag, conservatively and with a precise purpose. These *are* > "do it right" methods! They may exceed your interest in pursuing them, > or may (erroneously) smack of premature optimization, but they are > extremely effective. > > > and I can't see any reason why images should be viewed differently. > > I'll give you two reasons. > > First is size, even with images that the user her/himself can't edit. > Your images (800x600+?) are taking up the lion's share of your > bandwidth, and your users' as well. You're doing both sides a > disservice if you refuse to properly manage cacheability of these > objects. Ignoring cacheability of your markup/code/style files may be > justified, but not ignoring images. > > Second is that you are allowing the user to edit images, thus > presenting your site as being specifically image-aware, but then > refusing to build a proper back end that audits changes in image > content and builds URIs accordingly. IMO, even forcing the user to > refresh the page manually (if that happened to work around this bug) > is poor design. If you offer an online function whose offline > equivalent always works in real-time, and you have the ability to have > your changes reflected automatically as well, make it so. (Granted, if > you are trying to have people *avoid* overusing your primitive > mechanism, then not reflecting changes in real-time is good way to > make them stop!) > > You said yourself that you didn't want to break the client-side > cacheability of these images. That's good: it means you must have some > interest in caching. Then you should ready to take the next big step, > when you realize that you can't rely on the most basic/default logic > on your server side and the default behavior of common browsers to > ensure cachability. You must actively code for cacheability if you > care about it at all. > > --Sandy
