Old TechCrunch + really fast, clean, customizable layouts
tcfast.com
tcfast.com
http://feedvolley.com/ (code: https://github.com/niryariv/FeedVolley ) - could use a little UI love, but pretty stable. If anyone's interested in building this further I'd be happy to help you get started.
You forgot the illegally duplicated site designs (company livery, possibly trademark infringement, certainly someone would have a poke at passing off, ...).
But "backTo" parameter also accepts full URLs, so something like http://tcfast.com/?backTo=http://cnn.com/&t=g will happily redirect to CNN.
This might not be desirable for you, because in effect it will transform your site to a free redirect service ready for use by spammers.
You should check the value of "backTo" parameter and redirect only inside your own site.
Part of the justification for using narrow columns relates to the difficulty of finding the starting point of the next line when your eyes jump a large distance to the left. That advice applies quite well to books, and much less well to more structured content. For instance, on Hacker News, most comments don't have a wall of text with no paragraph breaks, and comments have strong delineation, so a narrow text width doesn't actually help.
That said, if you have the type of content for which a narrow text width does help (which TechCrunch sometimes does), please don't limit it to a specific pixel width; please use em instead, so that the width gets larger with the font size. That way, when users hit Ctrl-+ to override a site's smaller-than-the-browser's-default font size, the site will show about the same amount of text on each line, rather than producing narrower lines as the font grows.
That is stale 2008 advice. Every browser but ie6 uses zoom to resize pages. Text is resized on ctrl-+ regardless of px vs em. The days of sizing things with em's is long over, and these days it is counter-productive.
Also, many browsers that support zooming don't necessarily let that zooming override a size specified in px.
In any case, why would specifying the width of a column of text in em be "counter-productive"?
Em sizing is counterproductive because 1. That's not how most designers think, (We use Points, Pica, and Pixels.), 2. It's unnecessary for scaling with normally configured browsers, and 3. If someone changes their default type size, I am NOT going to support them: they have full knowledge of how to change the setting to fix a suboptimal page, and they have chosen to have suboptimal pages in the majority of their browsing (You think leading and optimal line width don't matter just as much as text size?) To anyone who actually forces their typeface choice: please do so on a site-by-site basis--or at least typeface-by-typeface for those you find illegible. Please do not try to override the informed choices of typographically-aware designers.
Sorry if that sounded like a rant. :) I'm a designer, and I'm passionate about my work being displayed and read the way I designed it to. Otherwise, I'd give every user a typeface selection screen when they visit my websites. The fact is, average users don't make informed choices.
*Within the past three years.
If you're a web designer, keep in mind that you're displaying content that's useful beyond the artistic merit of the typeface and other decorative elements. If you want to show off a design, make a PDF or an image. If you are making content useful to the widest audience you can reach, there are compromises that have to be made.
1. Tough? Learn to think better. What would we tell a programmer who doesn't want to use recursion because they "think in loops"? What would you tell a carpenter who didn't want use screws to put your new furniture together because he "thinks in glue"? Units of measure are a tool, and your facility (or lack thereof) with a tool doesn't affect how good it is.
2. I actually admit to some ignorance about browser scaling algorithms, so you may be entirely right here. In any case, I think it's the least important of the issues at play.
3. I submit that it's more important to make sure that your users can use your websites in a way that's comfortable to them, rather than that they should be able to bask in the glow of your unsullied brilliance. I don't mean that I should be able to randomly change fonts around because today I like Georgia and tomorrow I'm going to like Chicago. I'm wondering what happens when your site suddenly starts getting traffic from Israel, and all your new users are using Google Translate to turn it into Hebrew. Not only do your font choices go out the window, but all your ragged right just became ragged left, and some page elements may have have spontaneously rearranged themselves. (See http://translate.google.com/translate?js=n&prev=_t&h..., for example.) Or what if some of your users are colorblind or elderly or dyslexic, or just have trouble reading your type selection for any of a myriad of reasons? Is it more important that your design should remain just how you like it, or that they should be allowed to read it? Before you answer, read this: http://tigerbeatdown.com/2011/07/14/harry-potter-and-the-oh-... It's not about web accessibility, but the major themes are still there.
One of the incredible things about the web is that not only do we have the power to make the content we're producing available to an extraordinarily diverse population, we have the power to make it so that they can all read it in a format that works for them, as individuals. When you have to design a poster that's going to get sent to a printer and plastered over bus stops, everyone waiting all over town is going to see the same poster. When you design a web page, everyone who sees it gets a separate stream of bytes and a separate display to see it on. Why not let each user find the best web page for them, instead of forcing them all to see the best web page for you?
Still, in 2003, ems might have been best practice. In the modern web, ems and pixels are equivalent when it comes to scaling. One shouldn't avoid a good tool because it's hard to learn. (Example: I use Vim for all my coding.) However, one shouldn't use a tool just because it's hard to learn. Ems, in my opinion, introduce bugs, make planning more complicated, and have no meaningful benefits.
Using ems is like avoiding functions and instead duplicating code everywhere it's needed. Ems behave differently depending on their scope, and they're a pain to keep track of.
There's a similar issue with percent-based sizing. Let's look at some css:
*{font-size: 75%} h1{font-size: 125%;}
What size is h1? I honestly have no clue without a calculator. It almost definitely contains fractional pixel value. There's no way I'm getting appropriate vertical rhythm with percents. It's the same for ems.
I might be entirely wrong. Maybe I'd fall in love with ems if I started working with them regularly. It's a personal choice, from my understanding of modern browser scaling. Pixels are a completely valid method.
Second, I can easily tell you exactly what size h1 is: 25% bigger than the rest of the text on the page. If you're just going to start by assuming the browser has a given point size by default, and fill in percentages that result in exactly the point sizes you think the user ought to see, you're not really thinking in relative sizes, and you might as well use absolute sizes.
What method do you want to use to determine the font-size of h1? Presumably you have some idea in mind for how it should contrast with regular text. Try to answer that question without actually knowing the exact point size of the rest of the page text. If you can, then use that relative size in your CSS. If you can't, then perhaps browsers need more capable CSS so you can express what you want. :)
I'm sticking with the quite capable pixel unit for the foreseeable future. :)