[tristanperry]

I do agree generally, but it's funny that the suggested solution (spacers) are basically back to the old 1px transparent gif trick from the 90s/early 00s.

Nothing wrong with the suggestion, but it's just ironic that we seem to be coming full circle again.

Next we'll probably have posts extolling <Table> components for layouts ;)

[ratww]

> I do agree generally, but it's funny that the suggested solution (spacers) are basically back to the old 1px transparent gif trick from the 90s/early 00s.

They aren't the same thing. Check the link in the article [1]. It is using regular CSS, and some of those components use more modern things like Grids.

They also aren't applied between components like old element-spacers. Component Spacers have much more in common with regular margin/padding than with 90s spacers.

[1] https://seek-oss.github.io/braid-design-system/components/St...

[armandososa]

> it's funny that the suggested solution (spacers) are basically back to the old 1px transparent gif trick

Not really. The Stack component he uses as an example is actually just a thin abstraction over some reusable css. In plain html, it could look like

    <section class="stack stack--space-3">
        <article class="item">...</article>
        <article class="item">...</article>
        <article class="item">...</article>
    </section>

There are no "spacer gifs" anywhere, it's only that you're lifting the margin responsibility to the parent. I may be wrong, but I think the whole stack concept is borrowed from SwiftUI.

That said, I've recently started using actual spacer divs that are more similar to the spacer gifs of yore, you mentioned. So I could do things like:

    <section>
        <div class="vertical-spacer-2"/>
        <article class="item">...</article>
        <div class="vertical-spacer-1"/>
        <article class="item">...</article>
        <div class="vertical-spacer-1"/>
        <article class="item">...</article>
        <div class="vertical-spacer-2"/>
    </section>

Having been alive during the whole semantic web era, that feels very wrong to me. But it works like a charm to keep your code consistent with a design system which seems like a more noble endeavor than to write html that makes more sense to machines (which was, if I remember correctly, the objective of the semantic web).

[arcticbull]

Stacks started in UIKit (UIStackView) and before that were cribbed from Android, IIRC.

[nevercomments]

"Stacks" are an ancient concept, you'd struggle to find a UI framework (other than HTML) that's missing an analogous layout tool. Java's Swing had BoxLayout, JavaFX had VBox, Qt has QVBoxLayout, etc.

[timeon]

Tendency towards semantic web is unfortunately dead. Now you have simple blogs rendered by shadow DOM components. Even with templates separation of template and code was ideal - now you have 'reusable components' with templates all over the place. Functional programming has its place, but I'm not sure if everywhere. (You can separate code from templates even with FP and React - but often it is not the case).

[tambourine_man]

>Tendency towards semantic web is unfortunately dead.

Not dead, but under severe attack. We can and will fightback

[spicybright]

Can you elaborate a bit why? I've don't think I've seen a time where most sites were generally semantic

[jimmygrapes]

Accessibility is the main reason, I believe

[tambourine_man]

Search engines, screen readers, ancient browsers, future browsers, etc.

The important concept is that HTML tags should convey the meaning of its content, rather than merely being a target for CSS to define its appearance.

[7sidedmarble]

I don't think you know what Shadow DOM means. Shadow DOM is not just another virtual DOM. It is a very specific thing built into browsers used only for HTML Custom Elements.

It is not very popular. React, Vue, etc., do not use the Custom Element spec.

[jerrycruncher]

Concurrent with spacer.gif, there was also a `<spacer type="block">`[1] tag that was in use at the time.

Working at a boutique design shop back then, I remember trying endless combinations of the spacer tag along with spacer gifs to try to ship layouts that were at least semi (and hopefully mostly) consistent cross-browser.

Having lived through those web dev dark ages, I'm pretty baffled by the resurgence of 'markup as styling'.

[1] https://www.tutorialspoint.com/html/html_spacer_tag.htm

[thrower123]

Time is a flat circle, and we're just going to be rehashing the same ideas endlessly every five years until the heat death of the universe.

[tambourine_man]

It's more like a spiral if you adjust the perspective.

We'll revisit old ideas from time to time after going the opposite extreme, but never in the same way.

[ratww]

Spacer components and spacer elements are not the same idea, though, far from it.

[dmix]

> but it's funny that the suggested solution (spacers) are basically back to the old 1px transparent gif trick from the 90s/early 00s.

I have to agree with others. It is not the same as 1px spacer hacks at all.

[j0ej0ej0e]

My company recently had a FE candidate supply a test using tables.

[MarcellusDrum]

Serious question: What is inherently wrong with using Tables for organizing simple layouts? Is it frowned upon just because it is a "hacky" way of doing stuff?

[schwartzworld]

I think it would be hard to make it responsive. Also, table is a semantic element. You should use it unless you're displaying tabular data.

[ectopod]

I wonder how many millions of man hours could have been saved over the last twenty years if we could have added semantic="false" to our tables rather than redesigning everything.

[martin-adams]

You can make them responsive easy enough if you override all the table styling. I've done that before.

For me it's the semantic meaning, a table is tabular data.

However, I must say that using CSS grid is just like the old table-based design days.

https://twitter.com/Martin_Adams/status/1477214581449793538?...

[the_other]

Tables "mean" tabular data... grids of values with headings. The intent was that software could consume tabular data for processing without having to worry that it might be a "table for layout".

"table-like" layouts made using <div>s and CSS, including `display: table` are fine.

[drdec]

The original reason webmasters (remember them?) were discouraged from using tables for layout is that you quickly ended up with many layers of nested tables. The browsers at the time were not performant enough to handle it and the user experience suffered.

[dmix]

There’s still a place for tables in some use cases. But that use case is thin.

[Mezzie]

cries in email