PHP freelancer, web developer, mobile web enthusiast

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?