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.)
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.
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?
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.
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!"
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 ...
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.
TBH, it's very optimistic to think that anything really will change in the HN code. People have suggested tons of improvements and nothing ever changes - perhaps it shows that even if we don't improve our products people still keep coming back anyway.
The product here is not the interface it's the social network - the people - and interactions that enables.
There is much to improve (page titles, semantic urls, recording of moderator edits, ...) but none of that is likely unless a sufficient quora of top contributors force the issue or decide to move (r/hackernews anyone!?). That in turn is unlikely because of the association with pg and ycombinator.
The product here is not the interface it's the social network - the people - and interactions that enables.
Exactly. Plenty of people cry foul every time Facebook update their UI or make another attempt to violate everyone's privacy, but as long as a critical mass of people continue to use it, Facebook will remain the default tool for the social networks of those people. If it works at that scale, it surely goes for small/niche discussion sites as well.
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.
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.
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?
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.
Try emailing "info@ycombinator.com" with this suggestion.
From the guidelines:
Please don't post on HN to ask or tell us something (e.g. to ask us questions about Y Combinator, or to ask or complain about moderation). If you want to say something to us, please send it to info@ycombinator.com.
I think the mods frown on this sort of HN meta-discussion; so, don't be surprised if they kill this post.
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)
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.
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.
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.
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.
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.
Don't remember if it applies to this particular glyph, but I've had some issues in the past with some configurations of IE and/or Windows, where the unicode symbols wouldn't render. Just something to be aware of, if you're blindly using these in web sites aimed at the general population.
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.
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.
What's with all the "CSS bad" comments? Who needs CSS to put a Unicode character in a web page? Based on some of the logic I am reading, we'd all be better off displaying every letter of text as GIFs. For a technical crowd, you people have some funny ideas.
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.
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:
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.
Hacker News' design has a lot of personality and I would never recommend redesigning it (for the same reason I enjoy Craigslist's "design") but making it resolution independent and maybe even responsive sounds like a great idea.
Personally I prefer a slightly larger serif font when reading comments on here which is why I wrote a quick dotjs [1] script that now also replaces the upvote arrow GIF:
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?
I also normally browse HN zoomed-in and see blurry upvote, but is this really a problem? Does it affect the way you read, vote on and respond to posts?
I didn't notice the problem until you mentioned it. For me it was obvious that it points up/down, but now that you mention it I see that it could point in other directions as well.
I guess the question is: Do users get confused about the arrows?
I am certain the users do not get confused about the arrows. However, if you can wrap your head around it, it might actually look like it is pointing at the message itself, but that would have no actual meaning to a person.
It might be mistaken for a collapse/expand option, but people have been conditioned that + and - or the down arrow and right arrows are for that.
If it had a stick indicating the bottom protruding from it, it would appear to be a direction rather than an action link.
Down 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