Live data from Hacker News

Old TechCrunch + really fast, clean, customizable layouts

tcfast.com

61–70 of 72 posts

Re: Old TechCrunch + really fast, clean, customizable layouts

#61

Earlier quoted context omitted.

Google Reader is used for the private consumption of public RSS feeds but this republishes content.

Right, the private consumption by tens of thousands of Google Reader users. Is it private because they have to login? Like what is the difference? One is a web page with all of Techcrunch's content, and the other is a web page with all of Techcrunc's content. You think I'd go to tcfast.com only when I'm at a bar? Is it because I can read the contents from more than one site?

Well for one thing, TechCrunch puts out an RSS feed for the purpose of using an RSS reader to see their new content. Yes, both Google Reader and this site are "web pages" (in the sense that it's HTML over port 80) but the differences I think are obvious. For one, Reader is behind a login screen and you only see what you've subsribed to. There aren't any public pages generated from the content and the individual content viewed in Reader can't be linked to or indexed. TCFast.com is basically the exact opposite. They take one site's content and republish it publicly in a way that TC would likely have never approved of. The site has linkable content and the pages are indexable. You can eliminate the indexability but that doesn't take away from the core issue that they are republishing TC content and attempting to divert TC traffic with that content.

Re: Old TechCrunch + really fast, clean, customizable layouts

#62
post #59

The links on the top bar of an individual article page are in the form of http://tcfast.com/?backTo=/2011/07/14/larry-page-earnings-ca... 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…

thanks. fixed now.

Re: Old TechCrunch + really fast, clean, customizable layouts

#63
post #50

Earlier quoted context omitted.

I have enormous respect for designers, and I know full well that I, a programmer, can't do what you do and that anything I might produce that puts pixels on a screen benefits immensely from a qualified designer's input. That said, those are poor arguments. 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 w…

I agree with most of your post. I'm not saying designers should actively hinder accessibility or make users uncomfortable. We should do the opposite. 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 becau…

First, please don't ever do something like "* { font-size: 75%; }" ; that literally means "take whatever readable font size the user's browser wants to use and shrink it by 25%". In other words, it means I'll almost certainly hit Ctrl-+ until the font grows back to 100% and the rest of your page will scale accordingly.

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. :)

Re: Old TechCrunch + really fast, clean, customizable layouts

#66
post #17

Very cool. Reminds me of an app I once co-built (with the now famous Mr. Bragger ;) that lets you skin an RSS feed with a customizable HTML/CSS template (compatible with Tumblr's template markup) 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.

Interesting. It can't seem to find a feed on https://grepular.com/ though. Is that because it's https?

Re: Old TechCrunch + really fast, clean, customizable layouts

#67
post #32

In past few months or so I've found TC to be unusably slow. I don't know if it's all the ads/tracking/js being loaded but it takes 20 seconds or more for me to be able to actually interact with the page and so I've just stopped reading it. This is a very welcome new way to read it.

I just loaded the page, the last thing to load: post titles. Simply amazing that they don't see this as an issue.

Re: Old TechCrunch + really fast, clean, customizable layouts

#68

Earlier quoted context omitted.

I agree with most of your post. I'm not saying designers should actively hinder accessibility or make users uncomfortable. We should do the opposite. 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 becau…

First, please don't ever do something like "* { font-size: 75%; }" ; that literally means "take whatever readable font size the user's browser wants to use and shrink it by 25%". In other words, it means I'll almost certainly hit Ctrl-+ until the font grows back to 100% and the rest of your page will scale accordingly. Second, I can easily tell you exactly what size h1 is: 25% bigger than the rest of the text on the…

I agree. I gave that code as an example of a bad idea. For me, "If you can, then use that relative size in your CSS", has never been an option. Ems also have the same sizing problems regarding not knowing the browser's base text size.

I'm sticking with the quite capable pixel unit for the foreseeable future. :)

Post reply on HN