Browser Abuse Syndrome

BrowserAbuseSyndrome is when a person or company abuses a Web browser by stretching it beyond its intended use. HTML, the language that browsers currently parse, is a scripting language for documents, not applications. People could be far better off using real applications, or a browser that is not so HTML-centric (ComponentBrowser, RemoteGuiProtocol).

Examples: Why are any of these uses considered "abuse"?[duh] [It's abuse because Web browsers are neither general enough nor powerful enough. It's abuse because HtmlSucks; it's not a pure transport protocol as described in HtmlSucks, let alone a general or powerful protocol. It's abuse because Java craplets suck; distributed applications with no meaningful security whatsoever. And so on and so forth.

Having said that, applications suck. Not just the applications mentioned above, but all applications everywhere. See NoApplication. The default UI should be an ObjectBrowser framework that calls specialized code for handling specific classes (eg, class movie, class musicFile)].


The Web has made it easy to share stuff. Unfortunately, there is not a decent real HTTP-friendly GUI standard yet, so people end up pushing HTML to its limits to achieve what the customer envisions. (RemoteGuiProtocols)

<rolleyes> There isn't a decent text standard yet! HtmlSucks


HTML browsers should be kept for reading simple documents, similar to an RTF program.

Alternatives to HTML could also be developed for reading simple documents with hyperlinks, but not much more.. such as an RTF-like design where we always use a WYSIWYG design (no one ever hacks their RTF files in a text editor, do they? Even advanced programmers who use RTF never hack their RTF files in a text editor... so think about that hard now, why do we still use text editors to edit HTML? because HTML is slow to parse and no software is available, other than bloated applications like DreamWeaver?.)


Real world example section please contribute your real world examples which (would) reduce Browser Abuse

Emule: Almost an example of what a web browser needs to be like. Emule connects to the internet but does not use HTML. It is a client with listboxes, menus, etc.

Client like "Emule" has basically NOTHING to do with HTML. HTML or a Web browser (topic at hand) does not need to be used in order to "use the Internet in a useful manner".

Emule is for file sharing, but my point is this could be a shopping cart application too.. NO HTML, NO BROWSER - still connected to the Web, but NO HTML, NO BROWSER. The reason I pick Emule is because it has so many intelligent features.. a shopping cart application that looked like Emule would make Web shoppers go crazy. People would never visit these obsolete 'HTML' Web sites again.

Even Google is an example of browser abuse. When I look up information for programming tips or source code I use Google. However I constantly find myself wishing to have a software application that connects me to only software servers developed for programming, like an Emule program (not the P2P part, just the design of the application and lack of browser/HTML). All the server load that Google takes in just for me to find information about some simple programming question is ridiculous, compared to say some software application designed like Emule that only connected to servers related to programming, and displayed the search results appropriately (in a proper ListView? or Grid, not HTML).


One problem with browsers is their heavy mouse reliance. In order to go to a homepage on a Web site I should be able to hit CTRL-H or META-H. With current browser-abuse-syndrome developers (asexually reproducing worldwide), we'll never end up seeing Web sites that can be controlled by the keyboard optionally. Come in here with a VBscript and I'll hurt you, think on a deeper level please. Just for the record, this post (and all navigation leading up to it) was made entirely from the keyboard. Mozilla is a wonderful thing.

On a more serious note, I find myself using the keyboard very frequently to navigate all sorts of Web sites. I usually only drop back to the mouse for text selection, and random access browsing from a long list (RecentChanges, for instance). In the first case, pointing just seems to make more sense (a search and replace would involve typing in most of the text I wanted to avoid typing in the first place), although good cursor/arrow key support would be nice. In the second, again the 'random access' nature seems to be a better fit.

One gripe I do have about Mozilla's incremental find is that although it will find text in a text box, the only way to keep the cursor there is to click... escape loses the focus; tab, shift+tab sends you back to the previous cursor position.

-- WilliamUnderwood

But you can browse Google via the keyboard in the Opera browser too. And you can turn images off with the G key, etc. You can write a keyboard tool that hacks into the IE6 API that lets you navigate sites 'properly' according to how you want it done too if you really put your mind to it. But really putting your mind to it just to do something simple and tedious indicates lack of proper upfront design in the first place. We can all use RoboForm? to manage our passwords (sigh), but look at the bloat needed to hack into the document and IE6 API. Not proper upfront design. Specify the accesskey attribute for each important link when writing the HTML. The user can hit Alt-H, for example, to jump to the home page. See "Day 15" of MarkPilgrim's "Dive into Accessibility" tutorial (http://diveintoaccessibility.org/). The access key trick works in MozillaFirefox and InternetExplorer but not SafariBrowser. As far as I'm concerned Safari sucks. HtmlSucks as well, but what suck more are the HTML-generating IDE's and libraries and inadequate education about HTML. Hence the importance of LearningHtmlAndCss if, for some reason, HTML is what you want or have to use. Some standardization of accesskey shortcuts would help as well.

There is some controversy, however, about the accesskey attribute. As of July 2004 the XHTML 2.0 Working Draft replaces the accesskey attribute with a new attribute called "access". The proposed new access attribute would allow the user to specify what keystrokes to assign to the access points, once browser makers get on the stick. Read more about this in "The Future of Accesskeys" article (http://www.wats.ca/articles/thefutureofaccesskeys/66). -- ElizabethWiethoff


From WhatIsWrongWithTheGeneralVisualBasicApproach

I agree that an app designer should have this power and this is why web-based GUIs are insufficient. You cannot reasonably expect to have that level of control over a browser. This is why writing a custom thin client is often the best (and, sadly, usually overlooked) solution to most of these problems. Once you factor out all the cross-browser issues (.NETs postback handling is nice in theory but generates exceptionally messy code and is difficult to override. It also creates a tendency to much tighter lockin than even the old "Only use the IE DOM" way did). Disclaimer: I write web apps for a living. The need to provide rich client functionality in a fundamentally limited platform is one of the most annoying parts of my job, especially when the gains from browser based functionality are generally minimal.

[Web based GUI's are only inefficient because of what limits them, HTML. HTML is the main programming language that everything wraps. HTML needs to be ditched for real web apps. See also ObjectBrowser, ComponentBrowser]

Companies seem to like the easy deployment of web apps and appear willing to sacrifice better GUI techniques and frameworks to get it. I often don't agree with this, but if the customer wants it, what else can you do? Also, sometimes they don't seem to understand the extra effort and complexity that results from forcing web apps to act like real GUIs. On the one hand they may complain about being married to Microsoft if they use VB, but don't mind sticking to IE-specific standards to get more client features.

(Following the move over to here) I agree, as said above it's what I get paid for. They sell themselves on the idea because of the ease of deployment, and because it's in all the trade journals. I've suggested client side apps a number of times and always get shot down. It's especially frustrating when I'm busy turning down requests for extremely rich data entry support that I can't provide because a browser doesn't expose the events I need, like high tech masked entry boxes. [Ease of deployment can work both ways though: Maybe sneak it in using Flash Forms or something. (I don't know if Flash supports masks, but it is richer than most HTML.)


Re: "using a text field for writing a post (like this one) when you should be using a text editor"

It would be nice if browsers allowed one to plug in their favorite TextEditor to replace the default one.

[They would with a ComponentBrowser or ObjectBrowser]

LynxBrowser allows this. :-) Launch Lynx, go to the Options page (o), and enter the path to your Editor in the General Preferences section.

Yes, some browsers are wonderful with features; however, these are all just hacks on top of HTML still. Why not design it better first, before tapping on to it and smack-hacking it? Not proper up front design and engineering. Even Emacs let's us do wild things like browse websites. These are all just hacks. You could ride your bicycle to Africa across the ocean if you lived in Florida, but isn't that just a hack? You need proper equipment that was designed right for the job.

If Emacs is the answer, I'm not sure I want to know the question!


Re: "People could be far better off using real applications that run on their computer, not inside their Web browser."

I don't think those are the only options. I believe in the idea of RemoteGuiProtocols such that we don't need fat clients, or at least app-specific clients. The problem with the current set of browsers is that they were fundamentally built for e-brochures, not business forms or highly interactive interfaces.

You're right. What I meant was either a different type of generic web browser which uses not html, but plug-ins and components. Or, a real application (thin client) for more customized work when you need more than just the browser, and you are allowed to install that client on the machine you are at. I've changed the paragraph at the top.
This page seems to come from folks with the assumption that the best technology will be the most successful technology. It's been obvious for a long time that HTML (plus JavaScript, Flash, plug-ins, etc.) was not the best technology for many of its current applications, but it's been equally obvious that it has been and will probably continue to be the most successful technology. Replacing HTML with a better remote GUI technology won't generate cash for anyone any time soon. HTML is good enough and popular enough that it has inertia on its side.
Note: Browser abuse typically occurs more when people design, or try to design applications in browsers. Since HTML is hypertext geared, applications have trouble existing as HTML alone. All server side languages still end up existing as HTML in the end, on the browser side. This is part of the problem. This page is not arguing that html browsers suck, but more about the abuse of html browsers when designing applications. Html browsers, I agree, are useful for reading HTML documents (help documents, instructions, things like that.). But for things like banks, software upgrades, service applications, shopping carts, video games, sending email,... browsers are lacking a basic engineering. That's why incomplete solutions like JavaScript and Robo Form, and non-standard unneeded browser hacks exist(variations between mozilla, opera, IE, konqueror)
No hope from 'RIAs' (RichInternetApplications), Flex, Silverlight, etc.? How about Windows 8's Metro system? Is it true, now all of the worst limitations of HTML can be applied to desktop applications?

I'd say their success is roughly in this order: Flash/Flex, Java, Silverlight. However, the industry wants an open standard.
See also: WhatIsWrongWithTheGeneralVisualBasicApproach, WebGuiWikiPoll, ComponentBrowser, AjaxWebApplications, ThinClientHasFailed, WebGuiWikiPoll, LimitsOfHtmlStack
CategoryWebDesign, CategoryRant, CategoryMultiPurpose

EditText of this page (last edited December 16, 2011) or FindPage with title or text search