Electronic voting voter fraud?

The Blue Lemur blog has some interesting stuff about the variance in exit polls and actual results in states that use electronic voting machines and those that do not (or those that have them but with paper trails).

Exit polling accurately predicted the results in most states with very little error. Where there were discrepancies, they were significant in the +5 percent range, and always favored Bush.

No paper trails mean no way to contest this. Also interesting is how the AP ‘adjusted’ their exit poll data after they realized they were off by so much. I wonder how past exit poll accuracy compares to this year.

UPDATE (11-09-2004): More details just keep coming:

Why it’s OK to send XHTML as text/html

I was recently dragged in to an argument about whether or not it’s ok to send XHTML files with a mime type of text/html instead of application/xhtml+xml.

It seems that there are a few people spreading the word that sending XHTML documents as text/html is not only improper, but downright bad for you (gasp!). The basic argument goes something like this:

Dude[ette] sends XHTML document as text/html instead of application/xhtml+xml and therefore is gaining no advantage over plain old HTML 4.01. Since XHTML ‘should’ be sent as application/xhtml+xml, doing it any other way is wrong and you will burn in hell. Instead you should use HTML 4.01 because more browsers understand it, and when the time comes to switch, you can just use HTML tidy or make the small changes your pages need by hand.

Ok, I added the ‘burn in hell’ part, but you get the general idea.

Now I’m not going to go into why you should use application/xhtml+xml or all the benefits and differences between that and text/html. Instead, I’m going to let you read up on the subject yourself, and then tell you why it’s quite acceptable to keep on using text/html for the time being.

All of these links are full of excellent information and everyone building XHTML websites should know this whether they agree with them or not. Go ahead and take a few moments to read them. I’ll wait here.

Ok. Wasn’t that fun? Now here are some reasons why sending your XHTML pages as text/html is just fine. It is important to realize that the real argument here is not whether they should be sent as application/xhtml+xml or not, but what to serve as an alternative to user agents that can’t support it, such as IE.

1) XHTML 1.0 is like a gateway drug. It’s not HTML, and it’s not quite XML, but it’s a nice middle ground. It teaches you to close your tags, use lowercase attributes, always quote your attributes, never ‘minimize’ your attributes, and a few more. All of these are outlined here: The difference between XHTML 1 and HTML 4. This is a great benifit in that it teaches developers to follow stricter rules when building pages, and when the time eventually comes when they need to switch to application/xhtml+xml, there will be fewer changes to worry about than with HTML 4.

2) The XHTML standard allows you to use text/html. A short excerpt:

XHTML Documents which follow the guidelines set forth in Appendix C, “HTML Compatibility Guidelines” may be labeled with the Internet Media Type “text/html” [RFC2854], as they are compatible with most HTML browsers.

So the way I see things is that sending XHTML as text/html isn’t a bad thing at all. Using XHTML teaches developers to write well-formed documents, and teaches them the basics of XML, which will be more and more valuable as we progress from HTML to XML documents on the web. I think it’s important that people know the differences when sending documents with different mime types, but discouraging the use of XHTML sent as text/html doesn’t help anyone, and telling them there are no advantages at all is misleading.

Other reading:

UPDATE (11-10-2004): I just came across this post about content negotiation and saw an excellent conversation in the comments about converting your XHTML to HTML and the issues you will encounter.

One of the readers makes this point:

Your situation is different, though. I totally agree that XHTML should be served as application/xhtml+xml to browsers that support it. With respect to IE, you have some choices.

You could just serve it the XHTML content as text/html. Provided you’ve authored it in HTML-compatibility mode, IE will handle that perfectly well (or, at least, no worse than it handles HTML4).

Alternatively, you could decide, as you apparently have done, to serve IE HTML4, using a conversion that

1) only works with XHTML written in compatibility mode

2) runs the risk of seriously munging your text. (This is, after all, a weblog about web design!)

What’s the benefit of doing this instead of just sending IE the unaltered XHTML document (as text/html)?

And the response:

Nothing, probably. I’m reworking the “CMS” at the moment, and if I ever finish it, I will use a better system for converting to HTML. In fact, since XHTML is currently useless unless you actually need it (like your blog), I’m thinking about serving HTML 4.01 Strict to all. I’ll still store the posts as XML, though, for various reasons, so some kind of rewriting will be necessary.

So it seems to me that the optimal solution for most websites these days would be this:

  1. Author your pages as XHTML 1.0 strict or transitional in ‘compatibility mode
  2. Use content negotiation to send application/xhtml+xml pages to user agents that favor XHTML content
  3. For user agents that don’t like application/xhtml+xml, send them ‘compatible’ XHTML 1.0 as text/html

This way user agents that can handle XHTML get it, and if the user agent doesn’t understand application/xhtml+xml, you will have a very minimal amount of work on the server side to convert your XML content to ‘compatible’ XHTML.