Hacker News Reader

Comment by jawr | Hacker News Reader

I also zoom in to 125%, not sure if it's just me, but for a textual site the default font size seems too small. Maybe my eyes are just giving up.

Out of curiosity, I was wondering why the triangle wasn't a CSS triangle.. wouldn't that be more efficient than a gif?

View on HN

> for a textual site the default font size seems too small. Maybe my eyes are just giving up.

++, although my eyes are giving up, and getting a high resolution / small screen size MBA didn't help.

There are a few Chrome plugins to improve the readability of HN. I personally use Georgify: https://chrome.google.com/webstore/detail/ofjfdfaleomlfanfeh...

+1000 for Georgify chrome plugin!

I just tried it out. This font is... massive! It's pretty to look at, but tough to quickly parse, IMHO. I think I prefer HN's micro font.

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?

I use AutoZoom for Chrome. Although the fonts here are too small for me, so too at some other sites.

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.

Not necessarily. The gif is requested once and cached, and then rendered once and cached.

The CSS triangle would get rendered over and over again.

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.

The rasterization of the Unicode character will be cached in the glyph cache just like the rest of the glyphs, so the GIF is not really any cheaper.

Ok, SVG, character and GIF are better than a bunch of CSS :)

You misunderstood a lot of things. Most importantly that replacing a graphic with a unicode char has something to do with CSS :-)

My original comment is a reply to the suggestion to use a CSS icon.

Well, using the :before or :after pseudo-selector and content property is a possibility.

All that for a difference that would be negligible anyway. I'd say that's a premature optimization if I've ever seen one.

The GIF is 111 bytes. A CSS triangle might be smaller, but it's probably not much of a win.

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.

Reply on news.ycombinator.com