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).
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.
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
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.
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.
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!
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.
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.
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.
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).
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?)
52 comments
[ 3.2 ms ] story [ 81.7 ms ] threaddef 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).
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.
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
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.
Why not?
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.
I like to let the parent layout its children in a situation like that but that's also not without its issues.
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.
Please wake me when this nonsense is over.
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?
“Modern web app development sucks” is a really tired trope.
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?
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.
But this is for us using the net before 2000.
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.
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
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:
They told 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.https://spacergif.org/privacy/
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)
That's also a not very great idea though. It's almost like all these ways of doing it have tradeoffs or something.
It's just about creating a spacer component, which loads of component frameworks already have.
Please don't.
Well done!
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.