Hacker News Reader

Comment by ajross | Hacker News Reader

As a systems guy who only occasionally pokes his head into this web stuff: have we now completed the circle? For well over a decade I've seen generations of web hackers rail on about the evils of tables for layout. And now I look at this thing, and... it's a table. For layout.

Oh sure, it's a table defined externally to the components. So your screen-reader enumeration of the document structure is unpolluted by the physical layout which is stored in a separate data structure in a separate language. And that's... good, I guess?

Meanwhile I see that native app development continues, as it has for like 30 years now, to shamelessly put UI components directly into hierarchies based on physical layout. And they still haven't tripped over the paradigm.

I know it sounds glib, but it's a serious question: tell me again what was wrong with <table>?

View on HN

CSS Grid isn't about replicating the table experience, it's closer to native support for css grids like bootstrap etc.

The major advantage is its flexibility and ease in creating responsive layouts that look good at every screen size. One example is the minmax property: I want all these products in a grid, large enough to fit all their names. If you have the space, make the bestsellers larger and include the description. Oh, and they should really line up vertically and horizontally.

There's nothing that was completely impossible before, but there are a million hacks that we can finally discard, like all the shenanigans I've had to play with negative margins over the years.

That separation between markup and presentation language (CSS here) is exactly the point. Kicking all this stuff out into CSS means your markup can mean what you're trying to say.

Using <table> elements should mean you're defining a table with tabular data in it. These new bells and whistles don't change that. You'll still use <table> for tabular data.

And I'm not sure what you mean about native app development. We bitch and moan about the inadequacies of CSS (more its implementation) but layout engines in real programming languages are a total ballache to get along with, especially if you're from a CSS background. You can't just commandeer a table and twist it for your own evil deeds, you have to use one of a finite layouts. Gtk3 is the closest I've found to something I didn't want to stab on sight.

Why must a table be used in such a way, only for tabular data? Sorry if I seem obtuse, but I don't really see the purpose behind semantic elements. Tables were fine for layout with much fewer things that you needed to get right. Wikipedia still uses tables for the layout on the Main Page, for example.

I don't think there is any 'meaning' in the tags that we use, and any meaning implied there is invented as a way to try and match concepts on the screen to things we recognise in real life. I can mean the same thing to a user using tables, because they don't know that it's a table. Can I put a comment like "This table is for layout"? That would also convey meaning, and be a lot easier than messing around with CSS layout.

After a while of trying to get CSS to work with table-like layout, I think I'm going to move back to just using tables in future. At least, until something better than CSS+HTML comes along.

As a developer who somehow survived the times of frame, imagemap, and table-based layouts, I can promise you, they all had their own issues. Well before semantics, developers and designers needed CSS just to make things possible.

But you're focussing on people and healthy ones at that. Semantics matter a lot less there because you can style anything to look like anything else. But somebody with a screen reader literally needs semantics for accessibility. You set your page up as a table and their screen reader is going to iterate through it like a table.

And things like microformats are soft-semantics that allow your devices to explicitly know that "this thing here is an address", "that's a phone number you can click", and there's a whole bunch of formats for declaring embed data rather than making a service infer it from your actual content.

But if you just can't be bothered, do yourself and your users a favour. Use a framework (eg Bootstrap). It won't be perfect but it'll stop you using tables for layout and that's already a lot better. I can't believe it won't also look better.

HTML is not just about putting text on a screen. It is markup; the tags and attributes imply meaning about the contents they contain.

This makes it not only usable by a web browser, but parsable by software. That includes, but is certainly not limited to, screen readers, assistive technologies, and search engines.

Consider an example where I use JavaScript to make <i> tags behave like links. I can make it “work”, but by doing so, I am disregarding—and breaking—a primary function of the language.

Well, considering that the table layout has been available in CSS (without the 'baggage' of poor semantics) for a while (display: table-cell), CSS Grid and Flexbox must offer new layout options, which it does.

Apart from the semantic issues that result when littering your HTML with <table> tags that inaccurately represent the content they contain, Grid also provides features that tables cannot do:

  * overlapping cells (http://gridbyexample.com/examples/example15/)
  * empty cells, without a bunch of empty <td> tags (http://gridbyexample.com/examples/example12/)
  * size columns (or rows!) in proportion to one another
  * complex alignment of contents within a cell (http://gridbyexample.com/examples/example24/ and http://gridbyexample.com/examples/example25/)
  * specify exact min and max sizes for columns & rows
  * provide a full definition of responsive behavior, often without any media queries

It also provides everything a table does with far less code and easier to read markup.

You're assuming HTML, CSS, etc are created/optimized for conveying information. They are in fact optimized to sell books, conference tickets and generation of page views. Iterating on versions, technologies, etc is a wonderful way to make money without ever exposing yourself to the cruel reality of solving problems. You have to hand it to them - a brilliant, if obvious strat.

I can imagine the conversation in some disused conference room going something like:

Organizer: Guys, I think the jig is up, we literally have ran out of new ways to layout a page. I think the string is run on this con.

New guy: Why not just repeat things like they do in fashion? Y'know like bell-bottoms.

Organizer: C'mon these lemming-like developers are not that idiotic.

Old guy: We can always go more dumb. tables v2 it is.

I've often wondered if one reproduced a sample of web pages in OpenGL/C, and compared the compressed source to the equivalent HTML/CSS/JS source, which would be larger?

>So your screen-reader enumeration of the document structure is unpolluted by the physical layout which is stored in a separate data structure in a separate language. And that's... good, I guess?

Yes, that's very good.

You don't have source order independence with <table> either.

Why do we want source order independence?

I'm seeing a worrying trend in front-end dev towards things that are "nicer" to "read" but more difficult to actually reason about. I don't understand what benefit we're gaining for removing the relationship between the order of the source code and the order things are rendered. All I see is a negative (it's more difficult to find the place to make an edit later on).

As the other guy said: "Meanwhile I see that native app development continues, as it has for like 30 years now, to shamelessly put UI components directly into hierarchies based on physical layout. And they still haven't tripped over the paradigm."

Eh, they just reproduce paradigms from 30 years ago on the native app side, as the JS crowd does.

>Why do we want source order independence?

For when things change, for when we want to reorder content without scripting. Why would having it as an option not be preferred?

Tables are for tabular data. The layout functionality is perfectly fine for layout, but the fact that you're semantically describing the page contents as tabular data goes against the original intent and meaning for the <table> element.

So... and I swear I'm not being as glib as I sound: The only reason Grid is OK and Table isn't is adherence to the design intent of a 25 year old SGML hack?

Basically you're just restating the orthodoxy. I know the orthodoxy. I'm asking if maybe this is time to revisit it, and wondering if maybe the last 16 years of flamage were a mistake.

You're speaking as if table layouts are equivalent to CSS grid layouts. They're not, otherwise `display: table-cell` would have been enough.

This is a very fair point. For instance, you can't do the sticky footer Flexbox example with a table layout: https://philipwalton.github.io/solved-by-flexbox/demos/stick... (or, at least, I can't immediately think how you'd do it, but hey, it's late, and it's been more than a decade since I've used tables to lay things out...)

Reply on news.ycombinator.com