{"id":225,"date":"2004-01-20T23:26:19","date_gmt":"2004-01-21T04:26:19","guid":{"rendered":"https:\/\/www.goer.org\/wordpress\/helpful_fascism"},"modified":"2004-01-20T23:26:19","modified_gmt":"2004-01-21T04:26:19","slug":"helpful_fascism","status":"publish","type":"post","link":"https:\/\/www.goer.org\/Journal\/2004\/01\/helpful_fascism.html","title":{"rendered":"Helpful Fascism"},"content":{"rendered":"

Quite a storm<\/a> of<\/a> activity<\/a> going on over at Dave Hyatt<\/a>‘s developer weblog.<\/p>\n

Dave is clearly annoyed with the difficulty of parsing broken HTML. It’s an extremely hard problem to solve, and not very well-defined. It must be even more frustrating to have to be judged against the quirky behavior of the dominant browser<\/a>. And Dave is exactly right about Safari’s XML parser: it must be “Draconian<\/a>“. Otherwise, by definition it’s not an XML parser. (The more interesting question is whether one should actually use<\/em> an XML parser to parse XHTML.)<\/p>\n

All of this kerfluffle has generated various proposals for solving the problem of broken XHTML. Presumably the web would be a better place if all XHTML files were well-formed and therefore parseable with a standard XML parser. But the reality is that about 75% of XHTML home pages are invalid, and over 90% of XHTML sites have at least one invalid page<\/a>.[1<\/a>]<\/sup> So how do we improve the situation?<\/p>\n

One commenter on Dave’s weblog said that he dreamed about a “fascist” browser, one that would refuse to display any page with any errors. Unfortunately, a recent weblogs.mozillazine.org server error<\/a> swallowed that comment forever. It seems that the Great Spirits of the Internet have spoken. Fascist browser: bad idea. Let us never speak of it again.<\/p>\n

A friendlier variation on this proposal is to design a browser that still displays a malformed XHTML page, but provides some sort of obtrusive error message. The basic idea is that the users will then know about the errors, the website will receive a flood of complaints, the designers will fix the page, and XHTML quality will improve. As Dave puts it:<\/a><\/p>\n

\n

“Many people suggested that there be a built-in validator in the browser that could show the errors to the developer. The validators basically break down into two types: obtrusive validators and unobtrusive validators.<\/p>\n

If the validator is unobtrusive, then I would argue that it won’t receive sufficient usage to make a difference. If the browser doesn’t impose a penalty of some kind, then there will be no incentive for the author to correct mistakes.”<\/p>\n<\/blockquote>\n

Never before has the gulf between developer and end user been more stark.<\/p>\n

I’m hoping this is simply the result of sheer frustration on Dave’s part. That at some level, he realizes how quickly this “feature” will destroy Safari. In a sense, it’s kind of reassuring. Proves he’s human.[2<\/a>]<\/sup><\/p>\n

Unfortunately, I don’t think any browser could survive pulling such a stunt. Maybe Internet Explorer could… after all, IE users have been trained for years to ignore annoying technical messages, and most of them don’t know how to change their browser anyway. It would be a close one, at least. Actually, here’s a clever evil plan. If we could somehow<\/em> convince the IE development team that the “helpful fascist” browser was a good idea, we’d be in a win-win situation. Because either:<\/p>\n