why you should do it
how to do it
templates.pl:
replace &thread= with &thread=
replace text/html with application/xhtml+xml
replace document.threadform with document.forms.threadform
kareha.pl:
replace text/html with application/xhtml+xml
kareha.js:
replace document.threadform with document.forms.threadform
replace nodeName=="A" with nodeName.toLowerCase()=="a"
.htaccess:
add AddType application/xhtml+xml html
The first is already done. For the second, I was thinking of using that hack you cooked up in PerlHP to send application/xhtml+xml to browsers that support it. I'd like to figure out how to make Apache do that too, though. Got any ideas?
Hmm, a problem is that the filetype is hardcoded in the HTML file itself, and there's really no way to make that intellgently select the right kind of file. However, I think browsers generally ignore the filetype given in the HTML, because they've already have to have decided that the file is HTML before they can even see it. So maybe I could hardcode that as application/xhtml+xml...
>>2
you could make the script write out PerlHP or php files instead of normal html files... all you'd have to change is GLOBAL_HEAD_INCLUDE in templates.pl and HTML_SELF, HTML_BACKLOG, and PAGE_EXT in config.pl...
>>3
all 19 browsers that i have on this machine ignore the type given in the html file itself, so you could probably hardcode it as whatever you want without anyone noticing...
also, <nobr> does not work in xhtml...
Writing out dynamic pages is a bit too ineffecient. I'm sure you can use if statements and stuff in the Apache config to get the same effect, I just don't know how.
Does the browser complain outright about <nobr>, or just ignore it? Because I can easily put in the correct styles in addition to the <nobr>, it's really just there to make IE behave.
Ah, this appears to do the trick:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
RewriteRule \.html$ - [T=application/xhtml+xml]
</IfModule>It works fine for me with <nobr> left in, actually. I did find a typo though that was causing problems ("cibst" instead of "const"), but I'm not sure if that's in any released version.
Ok, I essentially have this working now. The thread views that go through the script sniff HTTP_ACCEPT to figure out if they can send application/xhtml+xml, I applied your fixes to make the code properly compliant, but I could leave in <nobr> without problems. Also, I'm putting the HTTP_ACCEPT sniffing code into example.htaccess. If the server doesn't have mod_rewrite, I'd definitely suggest sending text/html instead, but if you want, you can send application/xhtml+xml and break IE.
> break IE
IE is already broken.
>>11
Indeed. Only cater to it if it doesn't affect anything else.
> replace document.threadform with document.forms.threadform
Actually, I've found out this isn't correct, either. document.forms is supposedly not valid in strict XHTML mode. Firefox supports it to some point, but it is sort of broken. I ended up changing all <form name= into <form id=, and used document.getElementsById() instead. I should have done so from the start, I suppose, since it is The Way.
you can add a key to mime types in your registry for the application/xhtml+xml type, and IE will figure it out without any server-side intervention.
Key: HKCR\Mime\Database\Content Type\application/xhtml+xml
Values:
CLSID: {25336920-03F9-11cf-8FD0-00AA00686F13}
Encoding: 0x8000000
Extension: .xhtm
{25336920-03F9-11cf-8FD0-00AA00686F13} is mshtml.dll
>CLSID: {48123bc4-99d9-11d1-a6b3-00c04fd91555}
Fixed.
{48123bc4-99d9-11d1-a6b3-00c04fd91555} is msxml3.dll
>>15
doesn't that make it display as raw XML? i haven't tried it
>>16
yes. making it display it as raw xml is more correct than making it parse it as html.
<font color=red><b>:(</font></b>
bad html for life!
why you shouldn't use forced XHTML/XML
> Message boards allow for users to add characters that break XML
Untrue. Only admins can add characters that break XML, and then only by editing the config files. If there is a way for users to do this, report it as a bug.
> It takes only 1 error to render a page non-usable
Both a blessing and a curse - this makes it easier to find errors which would make a simpler browser break if it was served to it. For instance, mobile phones. Essentially, it forces the programmer and admin to get their acts together.
> As much as IE is bad, refusing to support the majority browser without modification is one way to loose visitors.
Kareha checks if the browser supports application/xhtml+xml before sending it. IE is thus unaffected, and gets served text/html.
I meant to bump this, really.