[goto11]

> It's just annoying to have to keep telling the computer over and over and over again "this is for layout" or "this is for structure" particularly in a case where the number of repetitions can be very, very large.

I have a hard time understanding this scenario. What kind of content are you working with?

[lisper]

What difference does that make?

[goto11]

I'm trying to understand the scenario you describe in the context of HTML.

[lisper]

If I am inside the context of a <table-for-structure> tag and I want to create a new row then the only kind of row I can create is a <table-row-for-structure>. It makes no sense to put a <table-row-for-display> inside a <table-for-structure> so requiring the programmer to specify <table-row-for-structure> rather than just <table-row> or <tr> is making her do a lot of extra typing for no value add. A <tr> inside a <table-for-structure> is necessarily a <table-row-for-structure> and a <tr> inside a <table-for-display> is necessarily a <table-row-for-display> just as a + operator operating on two integer values is an integer addition and a + operator operating on two floats is a floating point addition. There is no need to force the programmer to do extra typing to specify what is meant by + in a particular context. Likewise there is no need to force the programmer to do extra typing (or thinking) to specify what <tr> means inside a particular context.

[goto11]

But...you do only need to type <tr>. The problem you describe only becomes an issue if you use <table>s for layout in the first place, so just don't do that. If you want to display something (which isn't semantically a table) in a grid-like layout, you use display:table or display:grid in CSS, you don't change the markup. And vice-versa if you have <table> which you don't want to display in rows and columns, you can override the default presentation in CSS without changing the markup.

The hypothetical <table-for-layout> element is just not needed in any scenario. It would have been useful back in the day before IE supported display:table, but that is at least a decade ago.

[lisper]

> The problem you describe only becomes an issue if you use <table>s for layout in the first place, so just don't do that.

I could just as easily say that the "problem of overloaded operators" only becomes a problem if you try to use + to add anything other than two ints. So don't do that.

But OK, assuming I accept the premise, what should I do instead? The CSS community has been dithering about the answer for years. Only very recently has there been anything even remotely approaching an acceptable solution i.e. a solution that actually reproduces table layouts without having to pile on a ton of hacks. In the intervening years, a lot of legacy code was produced that used <table> for layout because it was the only thing that actually worked.

There also the fact that <display-table><tr><td> or something like that just looks a lot cleaner and is easier to read than <div class=table-for-display><div class=table-row-for-display><div class=table-cell-for-display>. When you make complex table layout you end up with a lot of TR and TD tags, so it makes sense to keep those short to avoid cluttering things up.

[goto11]

If you genuinely want a layout exactly like a html table you use display:table. You probably don't, but it is there if you want.

You don't really need repeated class=table-row-for-display etc, this can be achieved by CSS contextual selectors.

But in reality html tables was not designed as an all-round layout tool in the first place and the layout algorithm was never specified in detail. Flexbox and flexgrid are typically more appropriate and powerful as layout tools.