PHP freelancer, web developer, mobile web enthusiast

I was attending the Ext JS user group in Frankfurt the other night and thought it might be a good thing to write a blog post again: it was a nice event and I didn’t blog in about a year or so (at least not here).

If you are unfamiliar with Ext JS, make sure you bring yourself up to date! In short it is a JavaScript library providing a set of nicely styled and very functional widgets, such as grids and tree structures that you can use  to create rich, desktop-like web applications.

This user group was the first in Germany. Attendees were mostly freelancers, but also employees. 6 of the 15 attendees were fellow consultants from T-Home where I am currently doing some contracting/consulting work; and Ext JS happens to be one of my main topics there. Barcampy as we were we didn’t have an agenda. Yet 3 people were giving presentations and they were all worth the trip to the d.k.d offices in Frankfurt where the UG was held. I am a bad name rememberer so sorry for not giving credits here to the presenters, but honestly you all did a great job guys and I gained some good insight.

We also had some thought-provoking discussions about memory management and -leaks and about our experiences switching over to the brand-new Ext JS version 3.0. I can just encourage anybody interested in the topic to join us next time – we’re not sure when the next session will be, but watch this space or the Ext JS forum for updates.

A big thank you goes out to d.k.d, Germany’s leading TYPO3 agency, for hosting the user group and especially to Nils Dehl for organizing the whole thing and getting the crowd together. Till next time!

Here’s what happened: I was working on the Frost Ajax Library and using Safari Version 3.0.4 (523.12) for testing things.

The document, index.php, was serverd to the browser using this content-type header: “application/xhtml+xml” and the DOCTYPE was “-//WAPFORUM//DTD XHTML Mobile 1.0//EN”.

Now in Frost here’s a simple function that can put some text or HTML to a container, basically using simple innerHTML like this:

//id and cont are passed to the function
var ob = document.getElementById(id);
ob.innerHTML = cont;

The strange behavior appeared when cont was empty. In this case Safari throws an exception: NO_MODIFICATION_ALLOWED_ERR: DOM Exception 7.
There is no exception thrown if cont is not empty though.

If you serve the document with content-type headers as “text/html” there is no exception and everything works as it should.

The consclusion so far is that Safari has a bug and rejects to see an empty string as a valid value for a container, apparently only when the document is pure XML.

A quick search produces some similar issues floating around the web since a couple of years.

As a workaround my current solution is to encapsulate cont with proper tags like this:

//id and cont are passed to the function
var ob = document.getElementById(id);
cont = "<_span_>"+cont+"<_/span_>";
ob.innerHTML = cont;(<_span_> should be <span> really – needed for showing this code)

Could make sense in one way, because documents served as real XML should be handled more restrictive and modifications should produce valid XML documents again. However if I just want to put some text in a tag and if this text happens to be empty this should work too. So why is Safari making a difference if the value filled into a tag with innerHTML is empty or not – is this a bug?