Java webapp: where/how to automatically set each picture's width/height

Question

For several reasons, a lot of "webmaster guides" (like Google and Yahoo!'s webmaster guides/guidelines) repeats several times that it is better to always put the width and height attribute of the img tag.

One of the most obvious reason is that the elements in the page won't seem to be "jumping around" to a new location after every picture is loaded (always setting the correct width/height sure gets rid of this behavior). And there are other reasons to follow these guidelines / best practices.

So:

• if we consider that these are indeed good practices
• if there are a lot of pictures and they are changing often
• if pictures aren't changing between two .war re-deploy (that is: there's no user-contributed picture)
• if we don't want to manually edit all these width/height attributes

How do we automatically/programmatically serve HTML pages where every img tag have their width/height attribute correctly set as the best practice recommend?

Answer 1

When the webapp starts up, we're recursively crawling the entire exploded .war looking for every single picture file and determining their width/height.

We're saving these infos as a mapping in "file-to-width/height" map. Later on, every single time we're generating an img tag we're calling a method that gives up back that picture's width/height.

The only "drawback" is that the map lookup and width/height attributes generation are performed at runtime.

Answer 2

We have a more complicated build process, where all the .jsp, .css, .html, etc. are optimized.

• .css files with lots of includes are collapsed in a single file (another major one if you're into website optimization, just use Chrome's developer tools or YSlow! and check the difference with and without .css collapsing)

• .jsp and .html files have all their image width/height set at build time

• images are given unique names and are set as foreover cacheable (not unlike what GWT is doing for the JavaScript it generates, where unique identifiers are used). On the next build, they'll get new unique names and will be once again forever cacheable.

• etc.

There a lot of reason to have a build process more advanced than just "compile and zip all your files".

To answer your question: we do a lot of Un*x shell scripting in our build process. We process the .jsp, .css, .html etc. using some Un*x shell power. And I can tell you that people would have a very hard time replicating what we're doing without having the possibility to combine the power of all those shiny shell commands :)