[hn_throwaway_99]

I like this, but my 20 years in web dev can't help but chuckle. Remember when tables were declared evil for layout, so we had the shit show of trying to use CSS floats for everything, so then we added flexbox, and then grid, and here is a nice set of elements that is basically, well, somewhat less useful than tables for layout.

Don't mean to bash the poster, I just think it's interesting in the "everything old is new again" vain.

[cpach]

Regarding tables, try view source on this very thread. Some of you might be surprised :)

[nickelcitymario]

Good God man, why did you have to point that out?!?

[cpach]

¯\_(ツ)_/¯

[ziroshima]

I work on an older project with some folks that never got the memo about tables being evil for layout. In my experience, they've actually been quite easy to work with. Granted, we develop for a fixed screen width. Why were tables declared evil?

[pault]

Aside from the semantic HTML movement, they're clunky and verbose, more difficult to break up into reusable components, and table rendering is more expensive than the equivalent layouts with non-table elements and CSS (at least that was my experience last time I tried profiling a table with hundreds of rows).

Edit: they also have a lot of intrinsic layout behavior that can be difficult to predict once you start getting into more complex layouts than header, sidebar, and footer.

[wishinghand]

They didn’t flex like flexbox. When smaller laptop screens and eventually mobile devices appeared on the scene, tables would often extend past the screen’s boundaries.

[sanbor]

They mix content and presentation. If you separate content from presentation, then you can have a presentation for desktop an another for mobile. Also, you can totally change the layout without the need to change your HTML, as showcased in http://www.csszengarden.com/

[sheeshkebab]

The whole concept of separated “content” form “presentation” in UI is a bunch of nonsense. Maybe it works somewhere in some very limited sense, but I’ve yet to see anything complex that separates these things.

[wongarsu]

In the specific case of html and css I agree that it rarely works. There are a few examples like subreddit css, but in general html does to much layout to meaningfully separate content from layout. Xml and XSLT is a much better separation, with Xml containing pure content and Xslt transforming that into XHTML with CSS for presentation. But that never got much adoption.

In other domains separating content from presentation works well. But in web development the incentives don't align with that idea.

[kjeetgill]

Agreed. The real answer, as you noted, is that presentation really is HTML+CSS. You can join it with content in JSON (or XML if you want) via client or server side templating.

It actually gets you pretty close to MVC or whatever MVVC is maybe? Is that still a thing?

[the_other]

It’s really not nonsense. Make a text file with line breaks to force a line length, and then make a non-trivial edit to the content. You’ll have to move all the line-breaks too. It’s awful.

If you’d instead left presentation to the display tool, you’d only need to change the content.

The HTML presentation/content argument is this scaled up.

[yellowapple]

> Make a text file with line breaks to force a line length, and then make a non-trivial edit to the content. You’ll have to move all the line-breaks too. It’s awful.

But Emacs does that for me if I press M-q.

[the_other]

Exactly!

Your editor is also your presentation tool here, and it knows where all the line breaks should be, so it can do the edits for you. It works those around the content. If you hadn't included the line-breaks in the first place, it wouldn't even have needed to do that (well, ok, it would to "soft-wrap").

If you passed/copied the file to someone who prefers a 78 character line to your 100 character line (or uses a machine from the early 80s for retro-cyberpunk chic), when they render the file, several things could happen: - their viewer/wditor might add temporary line-breaks to soft-wrap, in which case they'll see some short and some long lines - their viewer/editor might add hard-wrap line-breaks at 78 chars. This would remove all your 100 char ones, and could potentially break your content because it might not see the difference between a "wrap" and a "new paragraph".

In the second case, when you get the file back later on, the content wont suit your preference for 100 character lines.

When the presentation is kept out of the content, none of this happens.

My point was that even in something as simple as a text file, adding presentation commands (line breaks), adds work, or hinders accessibility.

Scale that up to HTML and the wider range of possible presentation options. Say you used the old-school inline colouring options. Maybe you find green text on red backgrounds really fun to read. You encode that into the content (the markup). Pass this file on to someone with red-green colourblindness (c7% of XY-chromosome carrying humans[0]) and they wont be able to read your file at all.

[0]: https://www.colour-blindness.com/general/prevalence/

[kickopotomus]

The separation of content from presentation is one of the primary purposes of MVC frameworks. The model (content) is separated from the view (presentation) by an abstraction layer (controller).

[_ZeD_]

I really need to tell you... html is already only presentation. The content is in the backend system

[pjc50]

Screen reader pedantry, I think; also they're "not semantic markup". The idea was that tables should only be used if the content was genuinely a table.

[madeofpalk]

"Screen reader pedantry" sure is a pretty abrasive way of describing creating websites for people.

[pjc50]

You're right, it's unnecessarily abrasive. But it is, as far as I can tell, a very minority use case, and these days most of the reader software has adapted. If you see some of the DOM horrors inflicted by Facebook, then suddenly tables look positively readable.

Perhaps what should have happened was the defining of a "table-layout" tag that behaves exactly the same as "table" except it's understood to be for visual presentation only. Flexbox almost achieves this, but for some reason isn't as popular.

[okcando]

There is such a thing in CSS. Display: table, table-cell, etc. It's supposed to make content render exactly as if it were cast in an Html table.

[lozenge]

All the table elements just have special values for the CSS "display" property. You can apply these to divs or any elements and get table layout.

[egeozcan]

Brain-washers and adblockers playing catch-up leaving a scorched-DOM behind.

Also, flexbox is very popular in my experience.

[shaki-dora]

One man's pedantry is another blind man's attention to detail. Or ability to participate in society.

[speps]

> Why were tables declared evil?

If you use them for layout, you're not respecting the semantic meaning of tags.

[shaki-dora]

One answer reveals itself by just switching two lines around:

> Why were tables declared evil? > Granted, we develop for a fixed screen width.

Personally, I was always more disturbed by the anti-semanticism of the layout use of tables. But I guess at some point the web developer community just really stopped caring about such issues. Or at least that's my takeaway of the common atrocity of style attributes on individual elements that css-in-js approaches frequently produce.

[jandrese]

I think the people really pushing for the Semantic Web kind of gave up. You hardly ever hear that term anymore.

I guess the value proposition of "You can add a whole bunch of complexity to your webpage that won't affect what people see so robots can scrape your page easier" didn't really resonate with developers. Also, the proposals I saw were much too granular and focused on people writing scientific papers on the web. It wasn't a good mesh for the "garbage" web, which is like 99% of everything.

[detaro]

"Semantic Web" and using the semantically correct tags for HTML aren't really the same thing.

[dmitriid]

There’s nothing non-semantic about inline styles. And most css-in-js convert thise inline styles to a separate stylesheet with classnames.

I’d say web developers care much mire about semantics now than they did ten years ago. At least now you can finally have meaningful conversations around accessibility and screen readers.

[ben509]

> But I guess at some point the web developer community just really stopped caring about such issues.

Any plan that depends on people caring won't survive contact with actual people.

[nine_k]

Sometimes simplicity is more important than expressiveness, when the scale is small. See markdown for an example.

So I for one like this super-compact and simple language, it's good for making simple interfaces quickly. It's unlikely to break in subtle ways on mobile, or so I hope.

Internally a solution like this may use CSS grids, flexbox, or any new hotness that makes thing easier to implement.

Of course this is going to get ugly, or outright break, if used at a large enough scale. But very often you manifestly do not have a large scale, and never going to.

[lloydatkinson]

And in that 20 years you haven't encountered custom elements/web components, etc, etc?