PHP freelancer, web developer, mobile web enthusiast

I’m doing some freelancing for Studio9 at the moment. Nice people there, lots of interesting work too, mostly Typo3, but also jQuery, HTML/CSS. So I am going to Munich a couple days a week…boy am I glad I got a new car last year.

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?

ThickBox is a great library extension for jQuery. I use it often for showing messages and other dialogs on a page.

There are 2 things to keep in mind when you want to show inline content (that’s content on the same page/in the same DOM, e.g. in a div with display:none;) using ThickBox:

First of all, ThickBox takes an id of the container that contains the stuff you want to show in the box as an argument like this:?height=300&width=300&inlineId=myOnPageContent…here “myOnPageContent” is the id of the container. However ThickBox does not put the container element itself into the box that pops up!

Consequently you will have to surround the content of the box with another container that you then reference from your stylesheet in order to style the content of the box. Here’s an example:

This illustrates that “myOnPageContent” is the container ThickBox is looking for and we will use “#contact {}” to reference our elements from CSS.

Another problem is that the ThickBox CSS in thickbox.css already includes definitions for the box content, e.g. at line 9:

#TB_window {
font: 12px Arial, Helvetica, sans-serif;
color: #333333;
}
…and at some other places, so you either have to take this out the thickbox.css file (that’s what i do) or you overrule this with your own stylesheet definitions – watch out for the cascades!

Problem:

• you have a Typo3 site with several languages
• you are using the media field in the page setup to show a header image or similar (under “Files:” in the page setup)
• you are using levelmedia in the typo3 template setup to put this media somewhere on the page
• the header image (media in general) is not shown in languages other than the default one

Solution:

• go to the install tool of your Typo3 site
• search for “pageOverlayFields” under “All Configuration”
• take out “media” in the list of fields under [FE][pageOverlayFields]

That’s it. Please keep in mind that ALL media now will be taken from the media field of the default language.

Thanks to just2b at TYPO3.net for mentioning the solution.

Have you come across a strange error message in your Typo3 Flexible Content Elements (FCE) saying that “langChildren = 0” and it is probably a configuration error? You will probaby have looked around where to set this configuration value…and you will probably not have found it. So here’s how you can fix it:

In TemplaVoila look for your FCE’s data structure (DS) and klick on the pen next to the title, not the title, then you should see the XML of this DS starting like this:





...



There you need to add the meta section and add the langDisable and langChildren properties. For container Elements you will most likely not require different language versions, so setting the values to 1 for both properties works well. The XML of your DS should now look like this:





1
1


...




This way translations are in the “separate” mode. However, for DS in multi-language sites a good way to go is the “Inheritance” mode. There you keep the page layout and structure across multiple pages, and content is inherited from the default language, so basically the translated version looks exactly the same as the one in the default language. The cool thing is that you can now translate selected content elements to other languages and keep others the way they are. So e.g. images can stay the same, but texts can now be translated.

You should definitely have a look at section “FlexForms” in the Frontend Localization Guide , also available as PDF for further reference! Hope this helps somebody.