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 ( ), or an em-space ( ). Or just add a right margin to the icon — there's no need for an extra wrapper element.
"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.
> 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.
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?
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.
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.
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.
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 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).
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.
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
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.
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:
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.
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!
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).
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.
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 ( ), or an em-space ( ). Or just add a right margin to the icon — there's no need for an extra wrapper element.