Reading over the spec this may well seem the intention – till you get to the issue of telling apart XHTML and HTML, including non-conforming documents. This mailing-list post addresses this.
I ran down a hilly field and fell over this morning. I landed in cow shite.
David Hyatt has written a far better description of the FOUC problem than I ever could… I suck at explaining things…
Here's a list of things that you have no problem doing with standard text, yet are often not doable when some method of using non-standard fonts in a web page is in place.
After each stage, copy and paste it before checking the content is what you started with on the web page.
sIFR unquestionably has it's problems, for one it's dependent on Flash and Javascript; however, it is well tested, and has many advantages over other methods. That said, I have my doubts as to how well it'll do. So, onto the testing (which is being done on the sIFR home page).
2 out of 5.
Mike Rundle of Phark offered a solution that uses text-indent to hide the text, by moving it waaayyyy off to the left of the page, moving it off the canvas, and therefore invisible.
1 out of 5.
What are, in my opinion, the two most used image replacement methods, did not do all that well in what is, for me at least, an in important usability test.
All I can say is watch this space, for my suggestion for an accessible and usable (or at least, in browsers that support certain parts of CSS3 ;)) image replacement method.
As Eric Meyer posted this a couple of hours ago, and I find this funny, I'm going to post this as well. Call me a copycat at free will.
Here's a fascinating little tidbit: on some users' machines, attempts to print out Joe Clark's ALA article "Facts and Opinions About PDF Accessibility" would crash Internet Explorer. The error message mentioned a script error in line 1401: "Object doesn't support this property or method." Funny thing: we weren't doing any scripting. The error was actually occurring
shdoclc.dll/preview.dlg, which is of course a piece of the operating system.Jason did some sleuthing and traced the crash to this line of markup:
<h2 id="tags">Tags and structure</h2>Honestly, that was it. So Jeffrey renamed the ID to read:
<h2 id="structure">Tags and structure</h2>So far as we know, no more crashing in Explorer.
Ain't browsers a slice?
This means that IE thinks "tags" is a reserved keyword, despite the fact there is no such thing as reserved keywords in either XHTML and HTML. Brilliant Browser. :roll:.
First off, to anyone new around here, I recommend you go read the original XHTML/HTML post and all the comments.
Having read several hundred lines more, I have come to the conclusion that converting XHTML 1.1 to HTML 4.01 Strict is an unnecessary complication. While sending the slightly modified XHTML 1.1 as HTML 4.01 is a complex and debatable topic that I'll try and stay out of in this post, we will, however, need to occasionally touch it.
To start off with, let's quote Steven Pemberton, the chair of the W3C HTML Working Group from the W3C mailing list in 2000:
David,
The HTML WG has discussed this issue: the intention was to allow old (HTML-only) browsers to accept XHTML 1.0 documents by following the guidelines, and serving them as text/html. Therefore, documents served as text/html should be treated as HTML and not as XHTML. There should be no sniffing of text/html documents to see if they are really XHTML.
Note that there are some semantic differences between HTML documents and XHTML documents: there are specific CSS rules that only apply to HTML (and not XHTML), and the DOM has different effects (for instance, the element names are returned in uppercase for HTML, and lower case for XHTML).
Best wishes,
Steven Pemberton
Chair, W3C HTML WG
This clearly lays out the fact that sending XHTML as text/html was what was intended for legacy support, however, the W3C note on XHTML Media Types make it plain and obvious that XHTML 1.1 should not be sent as text/html - this leaves us in a dilemma, we're meant to send XHTML as text/html for legacy support, but not send XHTML 1.1 as text/html.
So, taking our conclusion as we're meant to use a doctype switcher to switch between XHTML 1.1 served as application/xhtml+xml for browsers that allow it, as well as the validator, and serve everything else XHTML 1.0 Strict served as text/html, as long as we meet the HTML Compatibility Guidelines (appendix C of the XHTML 1.0 specification).
So, as ever, I'm going to post a PHP version, and ask anyone who can to port this to other serverside languages, and send it to me, so I can post it here giving them credit.
<?phpif ((stristr($_SERVER["HTTP_ACCEPT"], 'application/xhtml+xml')) || (stristr($_SERVER["HTTP_USER_AGENT"], 'W3C_Validator')) || (stristr($_SERVER["HTTP_USER_AGENT"], 'WDG_Validator'))) {$mime = 'application/xhtml+xml';} else {$mime = 'text/html';}header ("Content-type: $mime");if ($mime == "application/xhtml+xml") {echo '<?xml version="1.0" encoding="utf-8"?><!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">';} else {echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">';}?> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"><head> <meta http-equiv="content-type" content="<?php echo $mime; ?>; charset=utf-8" />