1

I'm trying to get this content loader to work and I've managed to get it to get new content, once the content is loaded it isn't styled correctly. Also the character "é" becomes a questionmark. Doctype problem? As well as the h2 tag normally having Cufon applied to it is not triggering.

So basically, this content loader require me to have a bunch of pages being essentially the same, except for the content I want to retreice. This way, users can use the actual URL as you'd normally exect. Only when a link is clicked on an already loaded page, it's only the content from the #content div that's realle being replaced.

I can post code here, but I think it's better to just watch it happen on the testpage. It's very low on graphics btw ;)

http://www.matkalenderen.no

Just click the blue text link and you'll see it. Also, the red button on the second loaded content is supposed to revert the content back to previous. But it's not being triggered or something. What's happening?

Improve this question

2 Answers 2

Reset to default
2

The � is because new_user.php is an ISO-8859-1 file.

XMLHttpRequest, which is used to fetch the page, defaults to UTF-8. Since XMLHttpRequest doesn't know about HTML, it will ignore the <meta> tag you have used to declare that encoding, and continue to use UTF-8, resulting in the failure to read the é encoded as a single non-UTF-8 byte.

You should either have your script send back a real header('Content-Type: text/html; charset=ISO-8859-1');, which both the browser's HTML parser and XMLHttpRequest can understand, or — probably better — just use UTF-8 for your entire site. Then you can send any Unicode character back and forth, not just a few accented letters from Latin-1.

The styling looks OK to me. The only difference I can see is the lack of font replacement on the newly-loaded content. That happens because the font replacement stuff is only run at page load time. You could call Cufon.replace('h2'); after loading the new page to do the replacement again on the new heading, or maybe consider @font-face embedding, which is starting to take over this kind of thing.

Improve this answer
Sign up to request clarification or add additional context in comments.

8 Comments

Hmm, is there any possibility I can just call Cufon.now() as part of the whole content fetcher routine? It's not just as easy as adding Cufon.now() to the js portion that does the fetchin? Can these functions be called from one another in js like that? Not that familiar with js to be honest..
But also, notice that after clicking the first link "registrer ny" that clicking the newly loaded red button doesn't do any animation to replace the content. It's just a plain old href link. It's supposed to do the same thing, fade out existing content, then load new content.
Well yes, that's because you're not binding any scripting behaviour to the button. The <script> element that controls that behaviour is in part of the new_user.php page that never gets loaded. And even if you did include it in the content div, it's highly unreliable cross-browser to load <script> elements into pages. You would be better off writing all the controls stuff in a single, static .js file, shared across all pages. You could use jQuery's live method to ask it to automatically bind to matching new elements as they are added to the page.
Am I not binding any scripting behaviour to the button? It's supposed to. I mean, the script is still activated in the page isn't it? Both the main page and the new_user.php page has the script in them.
No, the ‘js.js’ script that does binding is outside the #content div which is the one you're loading. (Actually it's even outside <body> for some reason.) Even if you put it inside the #content, loading <script> elements into the page via innerHTML is highly unreliable and to be avoided. jQuery tries to make it work cross-browser using some hacks, but it is not successful in all cases. Better: use $('#container a').live('click', function() { ... }); in js.js so that it automatically picks up newly-added links in the container as and when they are loaded.
|
1

You don't have a doctype problem you have a character encoding problem.

Improve this answer

2 Comments

Actually, changing to utf-8 didn't really change anything. Am I missing something?
You will have to actually save your PHP files in UTF-8 encoding, not merely change the meta tag. (If your text editor can't give you that option, then you could write &#233;, but in that case you really need a better text editor.)

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.