Let's Bring Spacer GIFs Back | Hacker News Reader

Let's Bring Spacer GIFs Back

joshwcomeau.com

41 pointsfeross49 comments

Let's not.

This is a huge amount of unnecessary code just to add some whitespace.

Instead you could just directly add a whitespace character between the icon and the text, e.g. a non-breaking space ( ), and en-space (&ensp;), or an em-space (&emsp;). Or just add a right margin to the icon — there's no need for an extra wrapper element.

Yes, my first thought was  

Let's not use space characters in the markup.

Instead, use "white-space: nowrap" [1] in CSS.

Well, or just read up on the display box model in the first place.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/white-space

"white-space: nowrap" just stops line wrapping — it won't add a space that doesn't already exist in the source code.

The cleanest way to add whitespace in this situation is to add a right margin to the icon. The quickest way is to add an HTML character entity. The lightest way is to add a single unicode space character before the text.

Y'all realize that this is precisely why some people just want to bring spacer GIFs back, right :-D?

> Let's not use space characters in the markup.

Why not?

> This is a huge amount of unnecessary code just to add some whitespace.

Only if you use the whole React nonsense. You could just make a CSS class and use that on <span> elements to use as spacer elements. That's hardly 'a huge amount' of code.

This is everything on how the modern web is a complete disaster. We need react and a 30+ line “component” to represent what used to be a single html tag.

Please wake me when this nonsense is over.

I thought this was a parody post.

The article doesn't make any argument that you need react. It just happens to be what the author uses. (yes he assumes that you do as well but come on, you can translate it to whatever you're doing)

Also, the flexibility described will not fit in a single tag - what tag exactly did you mean?

I personally prefer gap-style solutions like a Stack component or something like Tailwind's `space` classes (both using an owl-selector to set margins on children).

Either way, margin is tricky in a components-based world because it often breaks the encapsulation. I see this as just an exploration of an option to solve that, do we really need to be this dismissive of exploration?

And yet somehow developers are more productive and build better web apps than ever.

“Modern web app development sucks” is a really tired trope.

> build better web apps than ever

Is this really true? Most apps and websites are broken in one way or another, terribly slow on older devices or connections and sometimes break for unknown reasons.

They look better, yes, but are they really that much better in a complexity to function ratio?

> And yet somehow developers are more productive and build better web apps than ever.

Only if you ask the developers themselves. They sure feel that way. Ask their bosses, or hell, ask users what they feel about the modern web, and the answer may start to differ.

Old users might note that sites start to work after refreshes and that the history is broken from time to time and that adblockers might nowadays break sites.

But this is for us using the net before 2000.

Mobile first web development leaves many sites unusable on the desktop, this includes banking sites where you can't see the whole row of numbers when entering accounts, how is that not broken. Clueless developers using myriads of JS frameworks doesn't make "better web apps than ever" ever.

Spacer components are great.

They’re very obvious when reading code why they’re there. You don’t have to think about whether margin or padding makes more sense, and which element it should belong on. No one is reading your perfectly crafted semantic HTML anyway. Screen readers don’t care about an empty span.

And apparently they really bother the “get off my lawn” types on Hacker News.

My preferred API is allowing one of 3 props: “size”, “width”, or “height” (because including both “size” and “axis” is pretty verbose)

I care because it's cognitive overhead, i MUST know what the "spacer" does and how it does, instead of having a simple margin or padding which works so well when you set box-sizing: border-box.

If the semantics of margin really are a problem as the article suggests why not use a css grid with a gap? Surely creating a JS component just to add a small gap is a more egregious semantic violation? I would argue that the icon is a visual only element and so the element should render correctly with no icon and the icon should add the necessary space to separate itself from the text.

He commented on this in the "What about `gap`?" info box.

I want to add that gap does not work well when you want different gaps between different items; then you have to whip out margins again.

... or pass a class to the component variant and set an according gap?

Adding a dedicated node with it's own properties to adjust width of whitespace is nowhere a better solution than just adding a css class

Fun fact: HN uses spacer gifs to indent comment replies.

I recommend that everyone go check out Sian Bahram’s 2016 talk on computing while blind. At around 6:30 he specifically addresses how inaccessible HN is to a visually impaired user: https://www.youtube.com/watch?v=G1r55efei5c

I find it interesting that not a single problem mentioned in the talk has been addressed on the site in the intervening 5 years.

And Paul Graham's page uses them extensively. Only places on the modern web where I see them used.

I wouldn't call PGs page an example of the modern web. And I doubt he would either. :)

I guess you can define modern web several ways - two ways I might use

def 1: Built using modern styles and with a modern design aesthetic.

def 2: commonly accessed as a useful destination in modern times.

Using definition 2 there are still some blogs out there that are still part of the modern web, although probably not as important as they were in their heyday. I mean definition 2 would apply to HN as well, whereas not sure if definition 1 would (it scales like a modern website should though, so maybe).

HN runs on a single core!

that's not modern!

Yup, you can spot them easily if you select a bunch of text.

Proper developers indent their code with gifs rather than tabs or spaces.

It feels like the author has read a lot of very sound arguments against using margins in component systems (they leak, they collapse, etc) and has taken those arguments to mean "never use margins". I don't see a good reason to avoid margins in the specific "icon and label" example.

It's a bit contrived but say both the icon and the text element are components. Now you need to find a solution.

I like to let the parent layout its children in a situation like that but that's also not without its issues.

It's a bit contrived but say both the icon and the text element are components. Now you need to find a solution.

There are solid arguments not to use margins with components, but that's not what the article is about. In the example in the article using margin is fine.

Specially as margin collapse is a thing that only affects vertical margins on blocks. The "icon has margin right if something comes after it" is perfectly solveable with even CSS 2.1

The title is clickbait, since the article is actually NOT about bringing back spacer GIFs.

It's just about creating a spacer component, which loads of component frameworks already have.

which essentially is just the same, spacer gifs aren't inherently bad because they're a gif, but because they're an empty DOM node used to handle presentational attributes

I was just pointing out that the article wasn't about bringing back gif spacers. It's actually about using normal css spacers, which is pretty much the standard nowadays across a lot of component libraries. This makes the article a lot less interesting.

Why on earth would you even waste the HTTP request?

There isn't an HTTP request. The 'spacer' is just a <span>.

Josh ends up not actually advocating for spacer GIFs (the title is clickbait), but still mentions spacergif.org, and that took me down a rabbit hole.

spacergif.org statistics suggest it’s spending roughly 1.5–3KB of bandwidth on each request (I haven’t bothered to go too precise, and it’d be hard to do so anyway because the traffic includes requests to things other than the GIF also). Remember that a spacer GIF is 43 bytes. (This, incidentally, is a reason to prefer GIF to PNG even now that PNG is widely supported—a spacer PNG is 65 bytes, if I recall correctly.)

Just imagine if, instead of telling you to put this in:

  <img src="https://img.spacergif.org/v1/spacer.gif" width="1" height="1">

They told you to put this in:

  <img src="data:image/gif;base64,R0lGODlhAQABAIAAAP///////yH5BAEAAAEALAAAAAABAAEAAAICTAEAOw==" width="1" height="1">

Lighter, more robust, just as developer-friendly, cheaper for them to operate (but perhaps harder to get donations or other moneys out of), and actually privacy-friendly. On that last point, spacergif.org’s privacy policy is a horror show that says “we’ll take whatever we can get our grubby little hands on, and do absolutely whatever we like with it, except that we’ll pay lip service to the law”. Certainly it’s extremely GDPR-noncompliant.

Not to mention that you wouldn't be making HTTP requests on every page of your site to a third party with this privacy policy:

https://spacergif.org/privacy/

I did mention that.

I find spacer.gif or even this "inlined gif" solution much more elegant and straitforward - better than bothering with div/span element and correct styling. And Josh could easily implement that react component with gif!

The spacer image is basically the same as this shorter and better thing:

  <span style="display:inline-block;width:1px;height:1px"></span>

This is a horrible idea, and the article reads like the author has completely lost the notion that there is even a thing like CSS.

Please just add margin-right to the icon that is already an actual targetable node in your DOM or skip the headache altogether by making your button display:grid & setting appropriate gutter width or something.

But the proposed idea is nothing but a showcase of everything that's wrong with "styled components only" and where it might lead you.

(unable to edit, addendum: the fallacy even begins with the idea that you'd need a <span> now to set margin and therefore you HAVE to introduce another node anyway - how about just giving your icon marginRight and be done?)

A little off topic, but I really enjoyed the little guy over on the side that led to the newsletter prompt. Didn't appear til I had read most of the article (so it doesn't bother people who just leave), it didn't immediately throw up a full page thing (because it just asks if you want to see something else they've been working on).

Well done!

Let's not. Please. We have margin, we even have flex and grid gap (which is my personal favorite new addition to CSS).

Please don't.

aside from all the other issues not to do it if you really wanted to do this you could just have a while loop that output   the number of times as your input number - so Spacer len={15} becomes 15 times  

That's also a not very great idea though. It's almost like all these ways of doing it have tradeoffs or something.

Reply on news.ycombinator.com