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.
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
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.
Readit News
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.
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.
Deleted Comment
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 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
Deleted Comment
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.
It's just about creating a spacer component, which loads of component frameworks already have.