Re: The Incompetence of Browsers
ahmoacah, on host 128.89.80.203
Thursday, October 11, 2001, at 15:33:56
Re: The Incompetence of Browsers posted by Sam on Tuesday, October 9, 2001, at 08:15:21:
> > You and ahmoacah should try building your own browser. I'm sure we'd all use it. Then you can see what the issues are in making one work correctly. > > Browsers today are written by humongous teams of people, because they have to support so many things. I'm not sure if we'd have more trouble or less, being only two people. Better coordination; less man-power.
I think it's kind of scary to see that the both of us actually put even a little bit of thought into what it would be like.
I think the fact that the HTML "standards" are moving targets is indeed a part of the problem. Would that it weren't; this is what we have standards bodies like the W3C and the IETF for. But, as web browser creators have learned already, it'd be death to *not* include, for example, some of Netscape's additions.
If this imaginary "RinkBrowser" were to choose to follow the spec to the letter, that problem would be reduced, but only somewhat. HTML is still being tinkered with, even by the W3C. And then, of course, fewer pages would work.
But I think the GUI toolkit problem is a much bigger factor. For some reason unbeknownst to me, scrolling seems to be difficult, in general. Throw in an extra wrinkle when the size of the region to be scrolled is constantly changing, and suddenly problems start appearing all over the place.
Not just that, but as I tested browsers, many other GUI-related faults appeared. For example, in Mozilla 18 (admittedly several versions old by now), it would scroll to the bottom line, but only to the top few pixels of that line. It was legible, if you can read the tops of letters. As Sam mentioned in the original post, more than one browser exhibits the bug where some lines of text randomly vanish, only to reapper when scrolled or selected.
I don't necessarily think a browser stresses the GUI any more than, say, a fancy math graphing package. Or any of a number of data-entry programs with zillions of text-entry boxes and menu widgets and so forth. But I will be first to admit I have relatively little GUI experience.
I'll take a brief tangent here, since my post is already long and rambling. One of my favorite web-browsing experiences was several years ago, when I tried to use a new browser for Unix. I can't remember for sure, but I think it may have been the very beginning of Opera. It didn't work at all. The part of the window where the web page goes was just clear, and you could see through to the desktop. When you moved the window, it took a snapshot of what was underneath it -- the background, other windows, everything. Pretty, but not terribly useful as a web browser. Surely something relatively straightforward was going wrong, but why did it go wrong at all?
Anyway, one other factor that I think contributes to browser lameness is the desire to put everything into the browser. "Creeping featuritis." If I were writing a browser and didn't care to "compete," I'd leave out the mail reader, news reader, FTP support, and whatever other extra stuff is normal these days. We have other programs to do those things already.
This would greatly reduce the amount of code by itself. The most obvious other "feature" to knock out would be the flexibility towards errors in HTML that browsers have. Of course, then the RinkBrowser would only be useful on a small set of pages. Much of the HTML out there is lousy, and the browsers have to draw the page anyway if they want to be useful... For example, run a geocities page through a validator mentioned elsewhere in this thread. Even if the page writer's HTML is fine, there are errors in the extra code geocities wraps around the page!
Maybe we've managed to list all the reasons browsers work so badly. Maybe there are more. Perhaps they work quite well, except that the hardest part of all is the most visible. I have to say, as a developer, I find that it gets harder and harder to predict how pieces of a large system will work together, while simultaneously keeping track of the details of those pieces. Maybe the practices needed for software engineers to keep track of and fix the faults haven't been developed to perfection yet. I could speculate some more, but speculation is all it would be.
ahmo"I'll keep my current job, thanks"acah
|