More job offers from those who sponsor my bills right now:

• Web Developer – Product Quality Support Team

Quote moi and if you get the job I’ll sponsor the first sandwich.

It took me a while to find a tool to put my pictures on the web that does not create horrible HTML code and isn’t clunky to use. Most picture packages have outgrown their usefulness over the years and have become bloated media browsers with proprietary formats.

Then I discovered Google’s Picasa and was instantly taken by its simplicity and slick interface.

I now discovered that you can “Pimp your Picasa” with own templates and created one myself.

You can download the template as a zip and unpack it to the template folder of your Picasa installation (on my PC this is c->Program Files->Picasa2->webtemplates). The template zip contains all the files in a folder called “dompreview”.

To export images, all you need to do is highlight them, press ctrl+w, choose the template and the image size and Picasa will do the rest.

The template features

• HTML standard compliant output
• Display of the big images in a layer above the thumbnails instead of a new page if the visitor has JavaScript enabled
• Normal “new page” display when JavaScript is not available.

You can tweak the styles.css to your needs.

For a demo check the Santorini Picture Gallery .

The only thing I am missing a lot is that you cannot define alternative text for the images in Picasa, or am I missing something?

Update Following several requests, the large picture will now always stay in the visible area when you have to scroll the page, and not stay glued to the top. All you need to replace in already existing galleries in the dynpreview.js file.

I just deleted my old PHP script EasyLetter from the server. EasyLetter was meant as an easy way to offer a newsletter for your web site and send out emails. It got some good recognition after once being featured on ScreenSavers, but I chose to discontinue it for several reasons:

• It is not spam safe and can easily be abused
• If you want to offer newsletters, get professionals to deal with the sending and data protection – there is just too much to keep up with
• I don’t have the time to answer problems with people’s server configurations any longer
• RSS feeds are dead easy to offer and are voluntary, not enforced data

So please don’t bother asking me for support for EasyLetter, I will not be able to answer, sorry. I might make it open source if there is interest, but I am not at all proud of it and email spam is too annoying a subject not to leave it to professionals.

I just had a lot of complaints telling me my free script DOMcollapse is crap (I sometimes wonder why I bother to offer these things as all you get is complaints, half of which caused by bad implementation /rant) as it doesn’t work in Safari in a certain situation.

The problem reproduction sounds like an old school text adventure:

For Safari only, it works in other browsers

• Load the page http://www.onlinetools.org/tools/domcollapse/

• collapse the open item
• make the browser window small enough to show a vertical scrollbar
• expand the element again.
• the scrollbar changes, but the section is not shown – unless you resize the window a bit once more

Is there any workaround? I don’t want to do things like window.resizeTo to force a refresh… And if I have to, is there a safe object detection that only targets Safari?

Following four days of AFN (Away From Network – I did use a keyboard though), I realised that digg.com dugg me and AJAXian once again linked me. Well, not me but the From DHTML to DOM Scripting article.
Notice the title: from DHTML to DOM. Not “why innerHTML is rubbish and you should not use it, never, really, don’t, never ever!”

I also realised that AJAXian had the unfortunate wording in their post that I might have meant that with the article and the comments on the AJAXian post were an interesting read indeed.

However, digging deeper (oh dear), I found that this is an no-barriers-handbags-out-geek-fight topic at the moment as many AJAX enthusiasts and heavy load web application developers (the applications are heavy load, not the developers) rightfully like innerHTML and consider it a necessary and good solution for a re-occuring problem.

Jeremy Keith started it, daring to call innerHTML proprietary in the painless code creation with DOM builder post at the DOM scripting task force blog.
Jonathan Snook responded quickly and wondered what’s wrong with innerHTML.
We all know that Jeremy had been in a painful love/hate relationship with innerHTML for a long time, as he outed himself in December talking about his innerHTML dilemma.
He is not the only one with this problem, as Ryan Campbell of Particletree also considered different methods than innerHTML in April calling it Changing the DOM.

This is all well and good, but is it really that much of a problem?

My “I like to chime in but I really just want to keep the fight going and not get involved myself as I forgot my handbag” award goes to Dustin Diaz who kept the comments closed on his blog entry on the subject called innerHTML and DOM Methods. So why post at all then? Why not just comment on Jeremy’s blog?

I liked the quote:

Well, for what it’s worth. It’s about the user. innerHTML is plain and simply faster. Yes, it’s non-standard, but so is xmlHttpRequest. Sure, I know the W3 is developing a working draft on xmlHttpRequest… I say, let’s standardize innerHTML. Not to mention, it would be easy. Everyone already knows how it works, it’s simple to use. It’s fast. It’s already supported across major browsers. Hey, just so we feel better, why not call it innerXML. That way it’s future compatible when xml becomes more of a standard and better supported.

This is exactly the problem with innerHTML – it is not innerXML. It is a browser/web/html only property, and the DOM is not only for browsers, web and HTML. You can use JavaScript and the DOM to convert XML, you can even script applications with it (check the Adobe site for great Illustrator and Adobe Bridge examples), and the idea is not to keep DOM scripting to the browser or even to HTML as a means of structure. I especially chuckled at the notion that XML will be supported in the future. I know the idea was supporting XML in browsers, but talking about web standards and considering XML a technology of the future is simply missing the mark.

So, here are my ideas about this subject:

innerHTML is pot noodles – Anyone can use it quickly, you put the kettle on and after the water boiled and you let it rest for a minute or so and then it is feeding time. It is:

• very fast and convenient
• cheap and easy to prepare
• well known and available in a lot of stores

The problems are:

• You have no clue what is in the pot noodles
• You have no way of telling someone how to make own pot noodles when there is no shop around their area that stores them.

DOM scripting and using the DOM methods to create a real XML construct instead of a string of HTML is cooking your own pasta sauce:

• You know the ingredients and you measure them properly before applying them
• It is harder and takes longer to prepare, but the outcome is normally del.ici.o.us
• While you cook you learn about different spices, tricks to prepare the ingredients and mix and match them to make the perfect sauce
• You follow a recipe or invent your own – but you do follow a structured method of creating it
• You can explain how to create the sauce to someone on the phone step by step

So by all means: Use innerHTML when speed or ease of use is an issue, but don’t forget that the DOM offers a lot more than just changing HTML documents in a browser.