Peeve Farm

g r o t t o 1 1

Peeve Farm
Breeding peeves for show, not just to keep as pets

  Blog \Blôg\, n. [Jrg, fr. Jrg. "Web-log".
     See {Blogger, BlogSpot, LiveJournal}.]
     A stream-of-consciousness Web journal, containing
     links, commentary, and pointless drivel.

On My Blog Menu:

InstaPundit
USS Clueless
James Lileks
Little Green Footballs
As the Apple Turns
Entropicana
Cold Fury
Capitalist Lion
Red Letter Day
Eric S. Raymond
Tal G in Jerusalem
Secular Islam
Aziz Poonawalla
Corsair the Rational Pirate
.clue

« ? Blogging Brians # »

Book Plug:

Buy it and I get
money. I think.
BSD Mall

10/6/2003 -  10/8/2003
9/29/2003 -  10/5/2003
9/22/2003 -  9/28/2003
9/15/2003 -  9/21/2003
  9/8/2003 -  9/14/2003
  9/1/2003 -   9/7/2003
8/25/2003 -  8/31/2003
8/18/2003 -  8/24/2003
8/11/2003 -  8/17/2003
  8/4/2003 -  8/10/2003
7/28/2003 -   8/3/2003
7/21/2003 -  7/27/2003
7/14/2003 -  7/20/2003
  7/7/2003 -  7/13/2003
6/30/2003 -   7/6/2003
6/23/2003 -  6/29/2003
6/16/2003 -  6/22/2003
  6/9/2003 -  6/15/2003
  6/2/2003 -   6/8/2003
5/26/2003 -   6/1/2003
5/19/2003 -  5/25/2003
5/12/2003 -  5/18/2003
  5/5/2003 -  5/11/2003
4/28/2003 -   5/4/2003
4/21/2003 -  4/27/2003
4/14/2003 -  4/20/2003
  4/7/2003 -  4/13/2003
3/31/2003 -   4/6/2003
3/24/2003 -  3/30/2003
3/17/2003 -  3/23/2003
3/10/2003 -  3/16/2003
  3/3/2003 -   3/9/2003
2/24/2003 -   3/2/2003
2/17/2003 -  2/23/2003
2/10/2003 -  2/16/2003
  2/3/2003 -   2/9/2003
1/27/2003 -   2/2/2003
1/20/2003 -  1/26/2003
1/13/2003 -  1/19/2003
  1/6/2003 -  1/12/2003
12/30/2002 -   1/5/2003
12/23/2002 - 12/29/2002
12/16/2002 - 12/22/2002
12/9/2002 - 12/15/2002
12/2/2002 -  12/8/2002
11/25/2002 -  12/1/2002
11/18/2002 - 11/24/2002
11/11/2002 - 11/17/2002
11/4/2002 - 11/10/2002
10/28/2002 -  11/3/2002
10/21/2002 - 10/27/2002
10/14/2002 - 10/20/2002
10/7/2002 - 10/13/2002
9/30/2002 -  10/6/2002
9/23/2002 -  9/29/2002
9/16/2002 -  9/22/2002
  9/9/2002 -  9/15/2002
  9/2/2002 -   9/8/2002
8/26/2002 -   9/1/2002
8/19/2002 -  8/25/2002
8/12/2002 -  8/18/2002
  8/5/2002 -  8/11/2002
7/29/2002 -   8/4/2002
7/22/2002 -  7/28/2002
7/15/2002 -  7/21/2002
  7/8/2002 -  7/14/2002
  7/1/2002 -   7/7/2002
6/24/2002 -  6/30/2002
6/17/2002 -  6/23/2002
6/10/2002 -  6/16/2002
  6/3/2002 -   6/9/2002
5/27/2002 -   6/2/2002
5/20/2002 -  5/26/2002
5/13/2002 -  5/19/2002
  5/6/2002 -  5/12/2002
4/29/2002 -   5/5/2002
4/22/2002 -  4/28/2002
4/15/2002 -  4/21/2002
  4/8/2002 -  4/14/2002
  4/1/2002 -   4/7/2002
3/25/2002 -  3/31/2002
3/18/2002 -  3/24/2002
3/11/2002 -  3/17/2002
  3/4/2002 -  3/10/2002
2/25/2002 -   3/3/2002
2/18/2002 -  2/24/2002
2/11/2002 -  2/17/2002
  2/4/2002 -  2/10/2002
1/28/2002 -   2/3/2002
1/21/2002 -  1/27/2002
1/14/2002 -  1/20/2002
  1/7/2002 -  1/13/2002
12/31/2001 -   1/6/2002
12/24/2001 - 12/30/2001
12/17/2001 - 12/23/2001

Sunday, December 30, 2001
00:43 - Graceful Handling of Human Error	(top)
Lileks says: Apologies for last week's odd truncated pages; once again I found my backside hard up against the bandsaw of my own ignorance, and neglected to adjust a key variable in the page's width attribute. Internet Explorer could handle it, but Netscape choked. I don't like Netscape. It's an argument as old as software design: How tolerant of human fault should software be? Netscape has always been more strict than IE when it comes to HTML parsing. It won't render a <TABLE> that doesn't have a </TABLE>; it will choke on unbalanced quote marks; it will only handle those things that it is designed to handle, not extending a helpful hand to fill in for mistakes that a user might make. Internet Explorer is much more forgiving. You can use open-ended <TABLE> and <TD> tags. It will make a game attempt at rendering a page when the inputs are ambiguous. The HTML spec says that you can't render a table without a </TABLE> tag because you can't know for sure what the complete table specification is; but while Netscape's attitude is to show "correct content or nothing", IE's attitude is "Do the best you can with what you have." And therefore it renders a table that may or may not be correct, but at least you can see it. It's actually admirable, very arguably, to build in the kind of fault-tolerance that IE has. It encourages sloppy code, whether produced by humans or by buggy HTML authoring software, but it is a more human-centric design. I think the benefits of people being able to get away with being sloppy (and not having to expend the extra time or brain power to do it right) have resulted in more overall contentment and accomplishment than are offset by the problems caused by sloppy code that slips through the cracks. But being too aggressive in human-fault-tolerance can lead to real trouble. IE has shown a propensity for this in many areas. One is the fact that it handles BMP images-- encouraging users to fill their websites with uncompressed 24-bit images, ungodly huge in file-size as they are, just because it eliminates the need for anyone to know anything about image file formats or proper web design. Just scribble in Paint and slap it into FrontPage. This is definitely a bad idea, and I think they've come to their senses and removed BMP support from IE lately. But it's a perfect example of user-friendliness gone terribly wrong. This attitude extends to other parts of IE as well, though. It ignores Content-type headers and handles files based on content, which is a BIG no-no-- thinking it's helping out users who simply manage to leave off the .html extension on HTML files, it will render as HTML any text file that has HTML tags in it. Likewise, it will open in Word anything that it determines is a Word file, regardless of whether the site designer may have specifically set an `application/octet-stream` MIME type so as to prevent the browser from opening the file automatically. "Microsoft knows best," it says. "Let us help you." Even if the designer wants no help, and if the people it might actually help are negligible in number. It's an ongoing debate in software design: literalism, or revisionism? Do you stick to the letter of the law, even if it isn't necessarily the most applicable interpretation? Or do you bend the rules to fit the current application, ignoring the intentions and safeguards of the specification? There is no clear answer as to which approach is better. But remember: it's always easier to start strict and get less so, than to start sloppy and then tighten up.