window.location = window.location; //refresh lol!

But you’ll get screwed if there is a fragment, like, say, http://example.com/index.html#section1. The page won’t refresh. Or rather, it will, but browsers won’t send a request to the server if the url contains a fragment. It will just try to navigate to that fragment within the document.

Solution: be awesome.

(function(){
  var refreshCookie = "mysite.refreshFragment";

  var refresh = function() {
    var url = window.location.href;
    var fragmentPosition = url.lastIndexOf("#");
    if (fragmentPosition >= 0) {
      if (fragmentPosition !== url.length - 1) {
        $.cookie(refreshCookie, url.substring(fragmentPosition + 1)); //store the fragment in a cookie
      }
      url = url.substring(0, fragmentPosition);
    }
    window.location.href = url;
  };

  var applyFragmentFromCookie = function() {
    var fragment = $.cookie(refreshCookie);
    if (fragment !== null) {
      window.location.href += "#" + fragment;
      $.cookie(refreshCookie, null); //delete cookie
    }
  };

  //reapply the fragment (if necessary) when the page is loaded
  $(document).ready(applyFragmentFromCookie);

  //expose to the public (you would of course properly namespace this, right?)
  window.refresh = refresh;
}());

//then, when you wanted to refresh the page...
refresh();

I use the jQuery cookie plugin, because all the kids nowadays are using jQuery. Substitute your own cookie handling framework, or roll your own (I’ve done it, it’s not enjoyable).

See it in action.

Anyway, I’ve compiled a short list of seven things that I’m constantly googling for. Note that this isn’t a list of “Tommy’s 101 CSS tricks for beginers (sic)!”. This is a list of things I can’t be bothered to remember. I already know all of the basic stuff, and I’m assuming you do too.

1. Reset

Reset CSS by Eric Meyer

/* v1.0 | 20080212 */

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
	margin: 0;
	padding: 0;
	border: 0;
	outline: 0;
	font-size: 100%;
	vertical-align: baseline;
	background: transparent;
}
body {
	line-height: 1;
}
ol, ul {
	list-style: none;
}
blockquote, q {
	quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
	content: '';
	content: none;
}

/* remember to define focus styles! */
:focus {
	outline: 0;
}

/* remember to highlight inserts somehow! */
ins {
	text-decoration: none;
}
del {
	text-decoration: line-through;
}

/* tables still need 'cellspacing="0"' in the markup */
table {
	border-collapse: collapse;
	border-spacing: 0;
}

The reset CSS creates an even playing field across all browsers, by removing the default styles that each applies. If you want to create a cross-browser compatible web app, then use this, and don’t question it.

2. Clearfix

Clearfix

/* new clearfix */
.clearfix:after {
	visibility: hidden;
	display: block;
	font-size: 0;
	content: " ";
	clear: both;
	height: 0;
	}
* html .clearfix             { zoom: 1; } /* IE6 */
*:first-child+html .clearfix { zoom: 1; } /* IE7 */

This hack has gone through a few iterations, so I don’t know who the original author is. I use the one described at the link above. Use this if all child elements are floated, and you want the parent element to retain its “assumed” height. Useful for horizontal menus made up of floated lis. Give your <ul> a clearfix.

3. MIR Image Replacement

Malarkey Image Replacement Examples

.mir { letter-spacing : -1000em; }
/* Just for Opera, but hide from MacIE */
/*\*/html>body .mir { letter-spacing : normal; text-indent : -999em; overflow : hidden;}
/* End of hack */

This is a useful hack for when you want your fancy menus/giant h1 tag to gracefully degrade when styles are removed. Slap a class="mir" on it, give it some text, and you’re good to go. See the examples for examples (derp).

4. 100% height

CSS 100% Height

html { height:100%; }
body { min-height:100%; }
#content { min-height:100%; }

While you can of course solve this (and the world’s) problem with tables, you shouldn’t. Because tables suck, much like urmom. But seriously, this is an incredibly difficult problem with an extremely simple solution.

5. Center an unordered list

Centering a floated menu

.container {
  width:100%;
  overflow:hidden;
}
ul#menu2 {
  margin:0 auto;
  list-style-type:none;
  float:left;
  position:relative;
  left:50%;
}
#menu2 li {
  float:left;
  position:relative;
  right:50%;
}

You won’t figure this one out on your own. Stop trying.

Tommy’s Steps to Success

1. Ctrl+C
2. Ctrl+V
3. ???
4. Profit

6. Opacity in IE

CSS Opacity in IE

.something-with-opacity {
  opacity: 0.5; /* everybody under the sun except IE */
  filter: alpha(opacity = 50); /* IE */
}

You might also need that zoom: 1 crap for elements that don’t have layout.

7. Vertically center a block element

Vertically Centering in CSS or How (Not) to Vertically Center Content

If you already know the width and height of the container, then you should be able to figure out how to vertically center something by using math (hint: division) and absolute positioning. If it’s more fluid, then you’re probably screwed.

For inline elements, use line-height. For block elements, use JavaScript. If that’s not an option, then you can attempt at implementing something like the above links, but I wouldn’t hold your breath. It’s mostly impossible.

If absolute positioning is not an option, you can try the display: table-cell; vertical-align: middle route, but it’s a crapshoot, and it doesn’t seem to work in all browsers. Using position: absolute; top: 50%; is viable as long as you know the height of the element and don’t care about absolutely positioning something.

Of course, you could valign yourself to success if you’re using tables, but you wouldn’t be stupid enough to do something like that, would you?

For my Linkurious project, I needed to get the computed style of an element in a cross browser way. I came up with an implementation that works in every version of every browser (within reason, the C64 is not supported), and is easy to use.

I’ll leave the details of how it works as an exercise to the reader. I will say that this is a good example of how to use a closure to improve the efficiency of a function. Notice that the cross-browser garbage is only executed once, not on each call.

//must be executed on or after the domready event, since it (may) require document.body to be non-null
var getComputedStyle = function() {
  var func = null;
  if (document.defaultView && document.defaultView.getComputedStyle) {
    func = document.defaultView.getComputedStyle;
  } else if (typeof(document.body.currentStyle) !== "undefined") {
    func = function(element, anything) {
      return element["currentStyle"];
    };
  }

  return function(element, style) {
    return func(element, null)[style];
  }
}();

//and use like so:
getComputedStyle(document.getElementById("foo"), "display"); //might return "inline-block"

Anyway, I found myself dissatisfied with the state of jQuery’s DOM manipulation (hint: there isn’t any). You can traverse, and do stuff with events, but there’s no API to create elements and then append them to the DOM. So I looked at the jQuery plugins, and found this, which I tried and quickly learned to hate. Using JSON to create DOM elements is just as painful as creating them using the native DOM API.

So, like any good programmer, I rolled my own. And I called it FluentDom (or $dom for short). Tested in Firefox, IE and Opera. Licensed under the WTFPL license.

FluentDom.js

/**
 * Fluent DOM Manipulation
 *
 * @author  Tommy Montgomery <http://tommymontgomery.com/>
 * @license http://sam.zoy.org/wtfpl/
 */

(function(){

	var FluentDom = function(node) {
		return new FluentDomInternal(node);
	}

	FluentDom.create = function(tagName) {
		var f = new FluentDomInternal();
		f.create(tagName);
		return f;
	}

	var FluentDomInternal = function(node) {
		var root = node || null;

		this.fluentDom = "1.0";

		this.append = function(obj) {
			if (!root || !root.appendChild) {
				throw new Error("Cannot append to a non-element");
			}

			var type = typeof(obj);
			if (type === "object") {
				if (obj.fluentDom) {
					root.appendChild(obj.toDom());
				} else if (obj.nodeType) {
					root.appendChild(obj);
				} else {
					throw new Error("Invalid argument: not a DOM element or a FluentDom object");
				}
			} else if (type === "string" || type === "number") {
				root.appendChild(document.createTextNode(obj));
			} else {
				throw new Error("Invalid argument: not an object (you gave me a " + typeof(obj) + ")");
			}

			return this;
		}

		this.attr = function(name, value) {
			if (!root || !root.setAttribute) {
				throw new Error("Cannot set an attribute on a non-element");
			}

			root.setAttribute(name, value);
			return this;
		}

		this.text = function(text) {
			return this.append(text);
		}

		this.create = function(tagName) {
			root = document.createElement(tagName);
			return this;
		}

		this.id = function(value) {
			return this.attr("id", value);
		}

		this.title = function(value) {
			return this.attr("title", value);
		}

		this.cls = function(value) {
			return this.attr("class", value);
		}

		this.clear = function() {
			root = null;
			return this;
		}

		this.toDom = function() {
			return root;
		}

		this.href = function(link) {
			return this.attr("href", link);
		}

	};

	window.FluentDom = window.$dom = FluentDom;

}());

Usage

Some sample usage, also showing how to integrate with jQuery:

//let's make a list!
$dom(document.body).append(
	$dom.create("ul").id("menu").append(
		$dom.create("li").cls("menu-item").id("menu-item-1").append(
			$dom.create("a").text("List Item #1").href("#")
		)
	).append(
		$dom.create("li").cls("menu-item").id("menu-item-2").title("click to toggle").append(
			$($dom.create("a").text("List Item #2").href("#").toDom()).bind("click", function() {
				$(this).next("ul").toggle();
				return false;
			}).get(0)
		).append(
			$dom.create("ul").append(
				$dom.create("li").cls("sub-menu-item").id("menu-item-4").append(
					$dom.create("a").text("Sublist Item #1").href("#")
				)
			).append(
				$dom.create("li").cls("sub-menu-item").id("menu-item-5").append(
					$dom.create("a").text("Sublist Item #2").href("#")
				)
			).append(
				$dom.create("li").cls("sub-menu-item").id("menu-item-6").append(
					$dom.create("a").text("Sublist Item #3").href("#")
				)
			)
		)
	).append(
		$dom.create("li").cls("menu-item").id("menu-item-3").append(
			$dom.create("a").text("List Item #3").href("#")
		)
	)
);

Which creates and appends this DOM tree to document.body:

<ul id="menu">
  <li class="menu-item" id="menu-item-1"><a href="#">List Item #1</a></li>
  <li class="menu-item" id="menu-item-2" title="click to toggle"><a href="#">List Item #2</a>
    <ul>
      <li class="sub-menu-item" id="menu-item-4"><a href="#">Sublist Item #1</a></li>
      <li class="sub-menu-item" id="menu-item-5"><a href="#">Sublist Item #2</a></li>
      <li class="sub-menu-item" id="menu-item-6"><a href="#">Sublist Item #3</a></li>
    </ul>
  </li>
  <li class="menu-item" id="menu-item-3"><a href="#">List Item #3</a></li>
</ul>

Admittedly, it kind of looks like a lot of code, but it’s much easier to read than if you had used the native API. Compare that with what the same implementation would look like if you went native:

Native API Implementation

var ul = document.createElement("ul");
ul.id = "menu";
var li = document.createElement("li");
li.className = "menu-item";
li.id = "menu-item-1";
var a = document.createElement("a");
a.href = "#";
a.appendChild(document.createTextNode("List Item #1"));
li.appendChild(a);
ul.appendChild(li);

li = document.createElement("li");
li.className = "menu-item";
li.id = "menu-item-2";
li.title = "click to toggle";
a = document.createElement("a");
a.href = "#";
a.appendChild(document.createTextNode("List Item #2"));
$(a).bind("click", function() {
	$(this).next("ul").toggle();
	return false;
});
li.appendChild(a);

var subList = document.createElement("ul");

var subItem = document.createElement("li");
subItem.className = "menu-item";
subItem.id = "menu-item-4";
var subLink = document.createElement("a");
subLink.href = "#";
subLink.appendChild(document.createTextNode("Sublist Item #1"));
subItem.appendChild(subLink);
subList.appendChild(subItem);

subItem = document.createElement("li");
subItem.className = "menu-item";
subItem.id = "menu-item-5";
subLink = document.createElement("a");
subLink.href="#";
subLink.appendChild(document.createTextNode("Sublist Item #2"));
subItem.appendChild(subLink);
subList.appendChild(subItem);

subItem = document.createElement("li");
subItem.className = "menu-item";
subItem.id = "menu-item-6";
subLink = document.createElement("a");
subLink.href="#";
subLink.appendChild(document.createTextNode("Sublist Item #3"));
subItem.appendChild(subLink);
subList.appendChild(subItem);

li.appendChild(subList);

ul.appendChild(li);

li = document.createElement("li");
li.className = "menu-item";
li.id = "menu-item-3";
a = document.createElement("a");
a.href = "#";
a.appendChild(document.createTextNode("List Item #3"));
li.appendChild(a);
ul.appendChild(li);

document.body.appendChild(ul);

30 lines vs. 70 lines. Fluent == rad. Tell your friends.

<script type="text/javascript" src="http://linkurious.com/js"></script>

where the src attribute was pointing to an external server; namely, my server. If enough people start using these utilities (extremely unlikely, although they are pretty awesome) it could be a strain on my server.

So I decided to offer a plain text version and a gzipped version. But I didn’t want to store two versions of the scripts in separate places on my server just to satisfy that need. The reasons had nothing to do with disk space or anything tangible; I just didn’t “feel right” doing something so hackish. Damn this ego of mine!

Anyway, once I figured out how to use mod_deflate:

#DER!
SetOutputFilter DEFLATE

I realized that that would make everything gzipped! OH NOES!! But then I noticed you could filter the… er… filter by mimetype, like so:

#only text/html will be gzipped
AddOutputFilterByType DEFLATE text/html

But that still didn’t help me. I needed conditional gzipping, like if the query string said ?gz it would know to serve the document gzipped; otherwise, it would just serve it with no compression. But how to accomplish this? Apache’s docs were no help. Luckily I’m fairly proficient at mod_rewrite, and I’m decently intelligent. Let’s see if I can figure it out (SPOILER: I figured it out; this 1st person past-tense non-omniscient narrative is just a literary technique).

Here were my requirements:

1. A request to http://acronymulator.com/1 would serve the JavaScript document with no compression
2. A request to http://acronymulator.com/1/gz would serve the JavaScript document with gzip compression
3. Only one physical copy of the document exists on the server

Let’s get to work!

First, let’s do the rewrite rules:

RewriteEngine On
RewriteRule ^/([1-9]\d*)(?:/gz)? /acronymulates/$1.js

The first line turns on the rewrite engine. The second line matches anything from the root that is made up of numbers, at least one number long where the first number is not a zero, with an optional /gz on the end. The rule finishes by internally redirecting those to the acronymulates directory, and serves up the JavaScript file whose name is the number with .js at the end. Simple enough, right? Sure.

Hopefully, you’ve deduced that /gz indicates that we want gzip compression; if it’s omitted, we don’t want gzip compression. Notice that it’s redirecting to the real JavaScript file whether the /gz is tacked on the end or not.

Now we need to do the deflate stuff. How we do it? Well, the most obvious solution is something like this:

<Directory /path/to/acronymulates>
    SetOutputFilter DEFLATE
</Directory>

This makes sense because the only thing in the acronymulates directory is the JavaScript files that we want to compress. See?

The files inside the acronymulates directory

However, this will force gzip compression no matter what, and we want it be conditional: only when the /gz is part of the URL. What do we do?

Location to the rescue!

The Location directive accomplishes this for us. more specifically, the LocationMatch directive accomplishes this for us. The difference between Directory and Location is that Directory matches a physical directory on the filesystem, whereas Location just matches a virtual directory (i.e. the path of the URL: /1/gz, in our case). Now it’s fairly obvious what the solution should be:

<LocationMatch /[1-9]\d*/gz>
    SetOutputFilter DEFLATE
</LocationMatch>

And there’s your dynamic gzipping using Apache. Note that these are real life examples (IRL ZOMG). Let’s prove it with Firebug’s help.

Without compression (http://acronymulator.com/1:

Dynamic gzipping: without compression

Without compression (http://acronymulator.com/1/gz:

Dynamic gzipping: with compression

And here’s proof that both URLs serve the same content:

Proof that both URLs serve the same content

In Review: A History of Suck

In the early 90s, it was all about Netscape Navigator and its little ship helm logo. Anybody who was in junior high in the 90s should have seen it. Then, while Netscape basked in its glory, doing nothing to improve itself, along came IE and the little blue E that we’ve all come to know and love despise with the wrath of a thousand suns. Netscape pretty much disappeared, largely due to the fact that the early IEs were much, much better, and also because everyone started using Windows, which of course shipped with IE (since it was made by Microsoft).

The pinnacle of browser beauty culminated in the advent of Internet Explorer 6 in the late 90s, and pretty much spelled the doom for Netscape, which hadn’t been significantly improved for 6 years. You could look at futhermucking PNGs with IE! How could Netscape possibly compete with that!?

Anyway, IE and Microsoft enjoyed its reign as king of browsers, until Netscape realized they had no hope of ever competing because they were ugly and lazy and stupid. So they sold their souls to the Mozilla corporation, which took out all of the good stuff in Netscape (the Gecko engine), and left the suck to rot in versions 8 and 9. They created Firefox, which hipsters and linux geeks the world over have heralded as the second coming of Christ. Firefox basically was just a way for nerds to assert their superiority over other nerds by name-dropping it. Because everyone knows that if you haven’t heard of Firefox, you can haz a n00b. Kind of like what I did with RockMelt several paragraphs ago. Try to keep up.

Meanwhile, a bunch of Norwegians, in true viking style, started their own browser called “Opera”. I can only assume they named it something so lame because of the language barrier. Opera began being used by an even smaller clique of nerd know-it-alls than Firefox. They are even more annoying than their Firefox counterparts, albeit less vocal. Opera proclaimed a love for standards-compliant (an admirable goal), lightweight, portable browsers, and they pretty much succeeded. Unfortunately, nobody gives a crap, because it looks hideous.

Back at Microsoft, the genius engineers behind IE6 were enjoying their throngs of groupie women, failing to realize that in the last 10 years things have actually happened! Say what!? IE6 is a horrible, horrible abomination? I thought we could just build an application and then let it stagnate for a decade and it would still be awesome! How did we miss this!?

Microsoft scrambled to alleviate the most vocal of the complaints against IE6 (“no tabbed browsing!? what is this, the 12th century? Firefox is safer LOLZ”). IE7 came out, to no buzz whatsoever. Since all the people who knew how to use the web were already using Firefox (all 20 of them), and most people turn off automatic Windows updates as soon as they plugin their computers, IE7 was pretty much not adopted by anyone. All it really did was give web developers one more browser to test. Granted, in terms of standards compliance, it was far better than IE6 (transparent PNGs gasp!), but it was still worse than Firefox 1.5. And Opera. So nobody was converted, but frankly, that wasn’t really the goal of IE7 anyway, because IE still had 95% of the market share anyway. They were still sitting pretty, until…

Mozilla Add-Ons, or How Firefox Lessened the Suck

This was Mozilla’s most brilliant breakthrough, and frankly, it’s the only thing that’s currently keeping people from switching to a browser that doesn’t require 300MB of memory to sit idly. Mozilla created this thing called XUL, but didn’t put it to good use until they created the addons site, and people actually started using it. Suddenly, the browser wasn’t just an application, it was a way of life. The Firefox bigots finally had a solid reason why their browser was better: it was customizable. In a way in which pretty much no other desktop application was. It really was and is still a remarkable amount of genius. Firebug is the only only that reason I still use Firefox. It’s bloated, slow, resource-intensive, ugly, and its users are among the most annoying on the internet, but it’s the only way I can actually debug anything on the web.

Meanwhile, in Microsoft Land, IE7 was stagnating (surprise). Business managers are mostly Nazis (Godwin’s law) and don’t want anyone browsing anything besides their intranet and/or SharePoint, so they had no reason to allow their underlings to upgrade their browser to IE7. That hideous rite still rages on today. In Norway, Opera was developing rapidly to the tune of CSS3 and standards compliance, but nobody cares about that besides web developers, and they weren’t about to leave Firebug behind. Not to mention the fact that they were still verifying that their websites are IE4+ compatible, so any technology more recent than an animated gif was not used anyway. In version 9.5/6, Opera released Dragonfly, their own version of Firebug, which was a giant step forward, but still much worse than Firebug. Nobody was converted. The market share had shifted slightly in favor of Firefox, but IE still held a commanding 4:1 lead.

Google Starts Sucking, Too

Then, suddenly, a new player emerges! Google enters the fray with Chrome, a brand new browser!… Except that there wasn’t anything new or innovative about it. The one nice feature that Chrome had was that each tab was its own process, which meant that while Flash was busy crashing in one tab, the other tabs would independently and cheerfully continue to load…. Until they eventually crashed as well. Chrome captured approximately 2% of the market, which is actually pretty impressive for a browser that has nothing to offer, besides the coolness of its brand. That figure is even more impressive when you factor in how it was only available on Windows for over 6 months.

And here we are, in 2009, with about three browsers to choose from, all with huge, gaping flaws. You’ll notice that I left Safari out of this little anecdote. That’s because it was an egocentric history of browsers, and I’ve never used Safari except for testing, and marveling at how incredibly difficult it is to turn on the JavaScript error console (defaults write com.apple.Safari IncludeDebugMenu 1: are you %@#!ing kidding me!?).

A Full Circle

So, why did I go through all the trouble of outlining this? My negativity towards browsers is universal, as I’ve sampled all of the major ones and a few of the minor ones, and they all have one thing in common: sucking. The world of technology is evolving. Even though the open source community is strong, all of those people have day jobs because they can’t make a living by writing awesome software. They write awesome software on the side while they support their families by implementing SOA through REST visa vis SaaS. The software industry is a wave of fads and trends that executives latch onto to try and be the next Google, despite the fact that companies like Google never employed such empty things like SOA. Well, maybe they did indirectly, but that was never their strategy. Every developer who has a job now is a slave to these trends, even when they’d rather not be. Money and greed rule the day; in any industry, really. It’s the one downside of capitalism: it always seems to morph into pure greed.

So, allow me to come full circle on how the the browser wars are similar to the trials and tribulations of the software industry. The new waves of browsers are very similar to how non-techie executives would mandate that a software application would develop.

Firesuck

New features in Firefox 3.5 include one-click bookmarking, an improved address bar (awesome bar), something about tabs, better memory management and session restore. Useful features, sure, but where’s support for CSS3, or improved stability of Flash, or a faster rendering engine, or more standards-compliant HTML rendering? Besides improving the memory management, they were clearly more focused on improving the user experience than improving the actual software.

Not that improving the user experience is bad, but when a YouTube video causes Firefox to lock up for 30 seconds, that seems like something that should be fixed before, say, a more convenient way to bookmark pages. I mean, who even uses bookmarks anyway? I have like four bookmarks (all to login pages for paying my bills online). There’s only about 10 sites that I visit on a regular basis, and I don’t have trouble remembering the fully qualified domain names of 10 sites.

Unite the Suck

Opera 10 introduced Unite, which basically turns Opera into a web server. Kind of cool, I guess, but how trying to take some competition away from Firefox by making Dragonfly not the slowest piece of tripe ever? Or use a font that doesn’t look like it was created by a three year old with a box of crayons? Or make the default skin less hideous? Or support JavaScript features past version 1.5? And if someone is actually smart enough to know what a web server is, they’re probably already running their own web server, and are not going to relinquish control to a web browser.

I’m Feeling Sucky

Google recently announced that their new operating system will be available in 2010 sometime, which is basically a wrapper around their browser. A novel idea, but why I would leave my current operating system for one that’s based around a browser that I don’t use? Maybe their idea will work, but I don’t think people are quite ready to turn their computers into a giant, fancy web browser. More importantly, I don’t think the web is ready for it. Connections are too slow, servers are too easily assaulted, and web applications are too unusable (compared with desktop apps) that being as productive on the web as you are on the desktop is still 10 years away.

This guy says it pretty well, with some MSPaint-inspired graphics to help you learn. Because learning is fun!

The Conclusion

The next generation of browsers need to focus on delivering content in the easiest, fastest and least painful way possible. I would happily give up 90% of the features in Firefox if the application never crashed. Firefox crashes so often that it has its own built-in crash reporter. I might use Chrome exclusively if flash didn’t crash the browser 10% of the time. I might use Opera if Dragonfly was slightly usable. I might use Safari if… well, I’ll never use Safari. I might use IE if Microsoft didn’t insist on deviating from every known web standard.

RockMelt, like Chrome, seems to be focusing on bridging the gap between desktop and web. Why don’t they just focus on fixing the problems with all the other browsers? What if they made an easily debuggable, solid, secure, fast, easy-to-use, lightweight browser? Instead, we’re probably going to get another Opera Unite, with the absolute latest in bookmarking technology. We’ll be able to bookmark freaking everything! Our lives will never be the same!

Plz.

I appeal to the browser makers: stop giving me new features, and fix the stuff that is already broken. Right now, nobody is winning. Let the users win the browser wars.