Rendered once and cached? The cached GIF is rendered each time as well. As far as I know, it's not possible to cache a rendering. There are still calculations to do each time you want to convert the cached data into an image. The question then becomes, which calculations take longer. The calculations needed to convert the CSS into a bitmap for the screen, or the calculations needed to convert the GIF data into a bitmap for the screen. I'm betting the difference is negligible.
(If I have misunderstood some step of the rendering process, I would love to know how, or what. I don't know much about graphics processing, so I am unaware of any caches beyond what the browser maintains.)
Of course there are way to cache renderings, this is the reasons firefox used to use so much memory, it would cache the uncompressed images. Why would you think that was not possible?
Afaik, the browser will read GIF once and keep the bitmap in memory, then composite it into the right place when it needs it, which is a lot cheaper.
With SVG, the browser will render it once and keep a bitmap, then composite it.
With a CSS icon, there is no way for the browser to know that it's an icon at all. There is no clear delimitation between it and the rest of the page. The browser has no choice but to re-render it every single time.
Images or SVG are much better choices for icons than a bunch of CSS.
While 111 bytes is small, it is actually 111 bytes + size of the image HTML tag (82 bytes) = 193. When I checked (at 08:08 PST on Friday) there were 163 instances of the image tag in the code. That means that the way it is today 11 bytes the first time and 13,366 (82 * 163) bytes of extra HTML every time. If we changed it to the unicode character if would be 163 * 2 (2 bytes for the unicode character) which is 326. 326 is way less than the 13,366 bytes currently being served.
I'm pretty sure you get downvoting powers at 500 karma. (At least, that's about when I got them. I have heard rumors that it fluctuates, and like all the mechanics of Hacker News, the precise rules are proprietary secret sauce.)
I have downvote in this thread but not always. I find the removal of edit, reply and voting privelege at seemingly arbitrary conditions to be very annoying.
Downvoting is disabled for very new comments and for replies to comments you've upvoted, iirc. Editing is disabled after a "reasonable" time. I don't think replying is ever disabled.
Ha, and there we go, so I couldn't reply to you (no reply link) within the discussion but I can by following the "link" link and then replying. What's that all about?
My main point would have to be that you have to work all of this out. Shouldn't it just be written in the FAQs. You could make the UI more helpful, like keep the reply link but disable it (eg with strike through) or have it popup a note "new comment: reply disabled for 5 minutes" or whatever. Or on pages with no downvote have a header comment in a box saying "downvoting disabled; all stories have down-voting disabled after 24 hours".
Gah, I have to stop before I get on to not having collapsible threads and the lameness of greying out comments and not having vote count displayed and ...
New comments have a brief time without a reply link - although you can still get to it by going to the comment itself through the "link" URL. The purpose is to slow down the back-and-forth arguments between two people that become "Nu-huh!" "Yeah-huh!"
It's because the GIF arrow is anti-aliased. You always want to anti-alias after sizing, lest it look like that, but you can't do that in a bitmapped image.
I don't think anti-aliasing is the explanation. I had a look at the GIF zoomed up in Paint.NET and there's nothing unusual about it, just the gray triangle with some lighter-shade pixels around the edges. I think the browser has a flaw when enlarging images with transparency - eliminating the transparency around the arrow would probably fix everything.
Not really techcrunch's fault, that. It's because facebook comments are loaded via an iframe, browsers probably don't transfer the "outer" zoom to the "inner" one all cases.
I was under the impression that all browser already switched from "increase font size" to regular zoom (as Opera had for example). But yeah, Chrome seems to broken in this regard. It's not as horrible as Firefox and IE used to be, but still... I'd file it as a bug report to your browser vendor.
I felt that it would cross some imaginary line to go around actually flipping tables on HN, so I edited it out of my comment after I saw that it worked. But what the hell:
Alternatively it doesn't care at all. I mean, it may not even try to check the incoming encoding or do anything with it and you'd still get the right result if your browser behaves in a sane way (that is sends utf form contents to this site). It's just some bytes after all.
But I don't know the arc internals - does it do anything interesting with unicode?
Dunno, the public releases are usually behind HN anyway. I'm just going off some old (really old) pg quotes where he just said Arc only did ASCII, because he didn't care about text encodings that much. The question is why HN is somehow sending the right text encoding headers.
Excellent idea! Now if we could only convince w3C that the entire Unicode Symbol Set deserves names and not hex or octal then I'd be very happy indeed ♞ should be bnight and so on...
No, I don't think it's a problem. I believe HTML only had symbol names because of incompatible character sets, allowing Unicode characters in ASCII and other encodings. But modern text editors and sites can use Unicode symbols just fine, why avoid them?
You're so right, it hurts. Named entities are a hack from the past. Unicode does a better job at classifying the zillions of character across the world than any html-monkey ever will.
A hack, but a wonderful one. Thanks to it, even latin-1 and us-ascii sites can use Unicode characters, even from user submitted content. Sure, it isn't as efficient as UTF-8, but it does the job.
I think it would be incorrect to use css to create an interactive object, a page should be 100% usable without css.
And probably font rendering is a lot faster than css rendering, though I couldn't find a similar benchmark
"Interactive object" in question is just a link. It would work without CSS just fine. But it would not work without JavaScript (in current implementation).
As for rendering efficiency: it just does not matter. There is a lot of things that could be improved on HN that would have orders of magnitude larger impact on performance.
The image is only loaded once and does not block anything (in fact it's loaded in parallel with — and the same size as — the orange Y logo at the top-left, and the tracking gif).
Furthermore the images on YC have extremely low dynamicity and size, so there's little chance they'll be evicted from the browser's cache (short of a manual cache clear), so their 100 bytes will only be loaded once the first time ever you visit YC.
So no, it won't make pages render faster overall.
On the other hand, it will make pages look better on zoomed or high-DPI displays.
The image is only downloaded once, but each page you load re-requests it. If your account has enough karma to downvote posts, you're requesting two array gifs per page view.
There's no Expires header being set, so your browser is not caching these images. A full roundtrip to the HN server to get back the "content hasn't changed" status code (304) is required for each.
> There's no Expires header being set, so your browser is not caching these images.
That is not in the slightest correct.
It has both a Last-Modified and an Etag so it's definitely cached.
> A full roundtrip to the HN server to get back the "content hasn't changed" status code (304) is required for each.
Also incorrect. The roundtrip is done once per session. A session is not well defined, but it's basically till you close the browser or till you click reload. Merely clicking on other stories will not trigger another roundtrip.
(Also pressing enter on the url line will not trigger a roundtrip, but reload will. This is important sometimes.)
> It has both a Last-Modified and an Etag so it's definitely cached.
Even without that, it'd still be cached: pretty much all browsers will cache things by default.
Last-Modified and Etag only come into play when the internal cache expires (this expiration time can be configured with the HTTP/1.0 Expires header or the HTTP/1.1 Cache-Control: max-age attribute, but the timeout does not default to "don't cache anything").
If you are really worried about performance (and the operators of of this forum should be) then there are more important things that need to be fixed besides just adding caching headers to an images (which is still a good idea). https://developers.google.com/speed/pagespeed/insights#url=h...
On the other other hand, it takes 83 bytes of HTML to represent the image tag which requests that 100 bytes of image. It only takes a couple of bytes to represent the Unicode character.
Sure, that's a valid point. However considering the HN home page is sent as raw HTML right now, there'd be much better savings by enabling gzip, reducing the home page's over-the-wire size from ~22k to ~5k. Compared to ~2.5k (from 22k to 20k) of savings from removing all 30 instances of the image tag.
Makes sense because HN is not using jQuery or similar and it would be a lot more javascript to do it in a cross browser way (just source view hacker news - it's almost as small as it gets)
Using Unicode shapes and vector-based icons is a great step forward. They're not suitable for every use-case but for most purposes they work well. Lately I've been using Font Awesome[1] to a great extent.
Is there a tool that lets you simulate what a site would look like on a high-DPI/Retina display? Is it simply enough to zoom the page in to get a feel for it?
When you want an icon that isn't one color (font-base icons like Font Awesome or using Unicode), or when you require a graphic with a high amount of detail. There isn't really a good, cross-browser solution for that that I'm aware of. SVG works to some extent but I don't think it's very easy to work with. Another instance where image-based icons win over font-based icons is when the icon has a lot of small detail. Like a shopping cart (that isn't just a solid, but has the little lines) or an icon representing a list. The lines look imbalanced or one will be thicker than the other. I'm sure this is different across operating systems and browsers but the problem exists. Though you can fix that by never using those icons at a small size.
Edit:
One thing I hadn't thought of that was brought up by another commenter is that some people override the fonts used in a site's stylesheets and force only their font preference to be used (mostly for readability). This would mess with font-based icons. I can't think of a way to detect this but it's something to consider when choosing font-based icons. Maybe JavaScript betrays the actual font being used and you can detect and patch it at run-time for those users.
You could potentially detect it in Javascript (if there's no better way) by measuring the width of an off-screen element -- especially if you added a ridiculously-wide glyph to your icon font. Like "if this div isn't at least 3 times as wide as it is tall, my icons aren't rendering properly."
In addition to what coderdude said, not everybody has a browser that supports custom fonts, or has custom fonts enabled, so if your site depends on custom font glyphs for navigation you could be making it unusable.
Sticking to glyphs that are part of standard Unicode should be fine - those should render no matter what font the browser happens to use by default.
Sticking to glyphs that are part of standard Unicode should be fine - those should render no matter what font the browser happens to use by default.
As long as your font includes the entire Unicode character set, that is.
It would be a good idea to check that any glyph you were going to rely on for a site like HN was universally supported among common system fonts. Different platforms provide different fonts as standard, and even the likes of Arial and Verdana don't have 100% coverage.
Am I the only one here against this proposal? I sometimes browse HN from my phone (outdated Nokia with Opera Mini), and I get a rectangle instead of an arrow.
Am I the only one here against this proposal? I sometimes browse HN from my phone (outdated Nokia with Opera Mini), and I get a rectangle instead of an arrow.
Really? Those are completely irrelevant to me and I have no idea why anyone would care as long as the site functions. It's not ideal and I wouldn't encourage it but does it really matter?
Upvote = I like this.
Downvote = This is noise/off-topic/abusive.
Thats the way it should work, and is part of what makes HN different to say Reddit. In reality, its becoming increasingly common for people to downvote something simply because they disagree with it.
Then upvote/downvote are the wrong semantics for what you are proposing.
Change them to "like" and "spam". For a multi-lingual audience, that is easier to grok than to hash the up/down arrows.
I'm not proposing anything. "Upvote" and "downvote" are the names given to functions of the HN site. My descriptions of those words are my understanding of the consensus among HN users on what they mean and how they should be used. If my understanding of that consensus is wrong then I hope that others users will put me right.
Edit: Would whoever downvoted this care to explain why? I'm genuinely interested.
Ignore the downvotes. Unless you get more than one.
It would be nice if Upvote meant "This is good quality (whether I agree with it or not" and downvote meant "this is low quality, and should not be here, but is not spam, nor flagable". But since PG has said (something like) downvote can be simple disagreement you're going to meet people who use it for exactly that.
Also, reddit is trying to move away from "downvote to disagree" - they have a lot of hover text saying this.
I agree, but I also believe a little ambiguity and heterogeneous modes of use are actually beneficial, make the place alive.
I tend to up-vote people who make efforts and contribute important information or opinions, not necessarily those I agree with. (Will only down-vote trolls.)
People do it that way, but it's incorrect. You are not supposed to use downvotes to disagree. (Initially it was like that, but not anymore because it stifled the conversation and caused groupthink since people were too scared to post anything controversial.)
It is correct. What is incorrect is to thing that symmetrical interface elements can have asymmetrical actions.
How would you like if turning steering wheel to the left would give left turn, but turning it to the right would stop the car?
If you want asymmetrical meaning, please, use different elements.
When the site was initially made that was what the meaning was: Agree/Disagree.
However that norm changed when people realized that was a bad idea.
The UI didn't change with the norm change.
At one point the norm was you could downvote to disagree if the comment had a score greater than 1. But now that comment scores are no longer displayed, that norm changed too.
Now the downarrow basically means spam/stupid/useless, etc. Actually for spam you also need to click on flag.
By the time someone aquires 500 points, they will likely have spent enough time on the site to learn the distinction between the two. While using text labels would be fine, I do not think that would be better than using the symbols.
The reasons for clicking may not be symmetrical, but the actions when clicking are symmetrical. The points go down with the down arrow and the points go up with the up arrow. This is symmetry even if the reason (agree, disagree, quality, spam, etc.) for the increase and decline of the points is asymmetrical.
A lot of the comments below engage in back-and-forth (up-and-down?) about whether or not it is permitted to use downvotes to indicate disagreement. Pretty much every time long-time users of Hacker News participate in a discussion on this issue, someone remembers to bring up pg's comment in an early thread from 1608 days ago.
"I think it's ok to use the up and down arrows to express agreement. Obviously the uparrows aren't only for applauding politeness, so it seems reasonable that the downarrows aren't only for booing rudeness."
If you check the currently posted site guidelines,
asked, "How to stave off decline of HN?" He wrote, "The problem has several components: comments that are (a) mean and/or (b) dumb that (c) get massively upvoted."
So at that time, he thought that a significant subset of comments was getting too many upvotes (and, by implication, too few downvotes). That led to a software change such that users can no longer see the net comment karma totals of other user's comments. (You and I can still see the individual net karma totals for each of our own comments.)
To sum up, what I really like to do is upvote good comments. But there is no rule against downvoting a comment if it is mean (definitely not), nor is there a rule against downvoting a comment if it is dumb (the trick is perceiving whether or not a comment is dumb), and especially there is no rule against downvoting a comment if it is both mean and dumb. And if a comment is just a snarky remark that doesn't advance the discussion, or a lame attempt at a one-liner joke, or otherwise doesn't add value to the discussion, it doesn't harm the community to downvote such a comment without further reply.
(They're not really logical opposites and their use frequency is quite different.)
I'm happy to upvote more than downvote. I get the sense that some of the best stuff here on Hacker News still isn't upvoted enough.
Does anyone know the rule on when a user gains the ability to downvote? I've been here a while, but I rarely vote for anything. I still never see the downvote icon.
Yes but I don't like the idea of passing my username/password through a 3rd party. HN is big enough that it should have its own mobile friendly layout.
I've hit "flag" when I meant to hit the story. I've hit the story when I meant to hit the comments. We need a HN hosted CSS layout for mobile users. This site is pretty simple, how complicated could a mobile CSS file be?
That's one of the reasons I really like Opera mobile and Opera mini: if you fat-finger and there are two possible links you could've hit, it zooms in so that you can disambiguate the click.
189 comments
[ 5.7 ms ] story [ 227 ms ] threadDown arrow/triangle: ▼
It is not only matter of resolution but I personally like bigger fonts and have zoomed in HN so triangles look bad:
http://i.imgur.com/fpA7N.png
Out of curiosity, I was wondering why the triangle wasn't a CSS triangle.. wouldn't that be more efficient than a gif?
The CSS triangle would get rendered over and over again.
(If I have misunderstood some step of the rendering process, I would love to know how, or what. I don't know much about graphics processing, so I am unaware of any caches beyond what the browser maintains.)
With SVG, the browser will render it once and keep a bitmap, then composite it.
With a CSS icon, there is no way for the browser to know that it's an icon at all. There is no clear delimitation between it and the rest of the page. The browser has no choice but to re-render it every single time.
Images or SVG are much better choices for icons than a bunch of CSS.
++, although my eyes are giving up, and getting a high resolution / small screen size MBA didn't help.
Also, the margins are way too big for my taste. I feel like 1/2 of the screen is unused white space. Is there any way to tweak it?
It is amazing how many sites have css that does not work properly when zoomed.
I can't even read HN on my iPad because of the font issue.
Downvotes are disabled for any comment more than 24 hours old, but upvotes are still allowed after more than a day. Emphasize the positive.
My main point would have to be that you have to work all of this out. Shouldn't it just be written in the FAQs. You could make the UI more helpful, like keep the reply link but disable it (eg with strike through) or have it popup a note "new comment: reply disabled for 5 minutes" or whatever. Or on pages with no downvote have a header comment in a box saying "downvoting disabled; all stories have down-voting disabled after 24 hours".
Gah, I have to stop before I get on to not having collapsible threads and the lameness of greying out comments and not having vote count displayed and ...
You don't downvote submissions. You just don't upvote if you don't like it.
http://blogs.msdn.com/b/michkap/archive/2011/11/17/10238146....
http://chryss.eu/?p=331
http://www.jwz.org/blog/2012/02/unicode-character-pile-of-po...
http://i.imgur.com/sFrFT.png
Specifically, look at the Facebook comments on Techcrunch. I can zoom in all I want (command-+) but the comments-font stays tiny.
My eyes are bad.
So it does. This may or may not be a good thing.
┬──┬◡ﾉ(° -°ﾉ)
But I don't know the arc internals - does it do anything interesting with unicode?
http://css-tricks.com/snippets/css/css-triangle/
Furthermore the images on YC have extremely low dynamicity and size, so there's little chance they'll be evicted from the browser's cache (short of a manual cache clear), so their 100 bytes will only be loaded once the first time ever you visit YC.
So no, it won't make pages render faster overall.
On the other hand, it will make pages look better on zoomed or high-DPI displays.
There's no Expires header being set, so your browser is not caching these images. A full roundtrip to the HN server to get back the "content hasn't changed" status code (304) is required for each.
No, it most definitely does not does not.
> There's no Expires header being set, so your browser is not caching these images.
You're out of your mind, of course the browser caches it, the browser caches everything it can by default: http://i.imgur.com/hrmIs.png
> A full roundtrip to the HN server to get back the "content hasn't changed" status code (304) is required for each.
That is not even remotely close to what happens in the actual reality we're part of.
That is not in the slightest correct.
It has both a Last-Modified and an Etag so it's definitely cached.
> A full roundtrip to the HN server to get back the "content hasn't changed" status code (304) is required for each.
Also incorrect. The roundtrip is done once per session. A session is not well defined, but it's basically till you close the browser or till you click reload. Merely clicking on other stories will not trigger another roundtrip.
(Also pressing enter on the url line will not trigger a roundtrip, but reload will. This is important sometimes.)
Even without that, it'd still be cached: pretty much all browsers will cache things by default.
Last-Modified and Etag only come into play when the internal cache expires (this expiration time can be configured with the HTTP/1.0 Expires header or the HTTP/1.1 Cache-Control: max-age attribute, but the timeout does not default to "don't cache anything").
/a></u></font></td></tr></table></td></tr><tr><td><table border=0><tr><td><img
HN uses an image in javascript to simulate a HTTP GET request to signal that you have voted.
ex. var img = new Image(); img.src = 'http://ycombinator.com/signal-voted?id=12345;
Makes sense because HN is not using jQuery or similar and it would be a lot more javascript to do it in a cross browser way (just source view hacker news - it's almost as small as it gets)
Is there a tool that lets you simulate what a site would look like on a high-DPI/Retina display? Is it simply enough to zoom the page in to get a feel for it?
[1] http://fortawesome.github.com/Font-Awesome/
Edit:
One thing I hadn't thought of that was brought up by another commenter is that some people override the fonts used in a site's stylesheets and force only their font preference to be used (mostly for readability). This would mess with font-based icons. I can't think of a way to detect this but it's something to consider when choosing font-based icons. Maybe JavaScript betrays the actual font being used and you can detect and patch it at run-time for those users.
Sticking to glyphs that are part of standard Unicode should be fine - those should render no matter what font the browser happens to use by default.
As long as your font includes the entire Unicode character set, that is.
It would be a good idea to check that any glyph you were going to rely on for a site like HN was universally supported among common system fonts. Different platforms provide different fonts as standard, and even the likes of Arial and Verdana don't have 100% coverage.
Thats the way it should work, and is part of what makes HN different to say Reddit. In reality, its becoming increasingly common for people to downvote something simply because they disagree with it.
Edit: Would whoever downvoted this care to explain why? I'm genuinely interested.
It would be nice if Upvote meant "This is good quality (whether I agree with it or not" and downvote meant "this is low quality, and should not be here, but is not spam, nor flagable". But since PG has said (something like) downvote can be simple disagreement you're going to meet people who use it for exactly that.
Also, reddit is trying to move away from "downvote to disagree" - they have a lot of hover text saying this.
However that norm changed when people realized that was a bad idea.
The UI didn't change with the norm change.
At one point the norm was you could downvote to disagree if the comment had a score greater than 1. But now that comment scores are no longer displayed, that norm changed too.
Now the downarrow basically means spam/stupid/useless, etc. Actually for spam you also need to click on flag.
The reasons for clicking may not be symmetrical, but the actions when clicking are symmetrical. The points go down with the down arrow and the points go up with the up arrow. This is symmetry even if the reason (agree, disagree, quality, spam, etc.) for the increase and decline of the points is asymmetrical.
http://news.ycombinator.com/item?id=117171
"I think it's ok to use the up and down arrows to express agreement. Obviously the uparrows aren't only for applauding politeness, so it seems reasonable that the downarrows aren't only for booing rudeness."
If you check the currently posted site guidelines,
http://ycombinator.com/newsguidelines.html
the only guidelines you see about downvoting occur right at the end:
"Resist complaining about being downmodded. It never does any good, and it makes boring reading.
"Please don't bait other users by inviting them to downmod you."
A thread opened by pg 466 days ago
http://news.ycombinator.com/item?id=2403696
asked, "How to stave off decline of HN?" He wrote, "The problem has several components: comments that are (a) mean and/or (b) dumb that (c) get massively upvoted."
So at that time, he thought that a significant subset of comments was getting too many upvotes (and, by implication, too few downvotes). That led to a software change such that users can no longer see the net comment karma totals of other user's comments. (You and I can still see the individual net karma totals for each of our own comments.)
To sum up, what I really like to do is upvote good comments. But there is no rule against downvoting a comment if it is mean (definitely not), nor is there a rule against downvoting a comment if it is dumb (the trick is perceiving whether or not a comment is dumb), and especially there is no rule against downvoting a comment if it is both mean and dumb. And if a comment is just a snarky remark that doesn't advance the discussion, or a lame attempt at a one-liner joke, or otherwise doesn't add value to the discussion, it doesn't harm the community to downvote such a comment without further reply.
(They're not really logical opposites and their use frequency is quite different.)
I'm happy to upvote more than downvote. I get the sense that some of the best stuff here on Hacker News still isn't upvoted enough.
I've hit "flag" when I meant to hit the story. I've hit the story when I meant to hit the comments. We need a HN hosted CSS layout for mobile users. This site is pretty simple, how complicated could a mobile CSS file be?
[0] http://news.ycombinator.com/item?id=363