The general view of the W3C as a standards body is broken.

The W3C gets companies and individuals together to hash out ideas for the Web. After some time and trial and error they assemble a recommendation. Hopefully people (i.e. the members of the W3C) put this into practice to see how well it flies in real-life. At some point, if the recommendation proves its worth, a standards body such as ISO or ANSI may want to formalize it. Or so it was.

Once upon a time yo could find on the W3C site a statement to the effect that they were not a standards body. However, some people who wanted to see the ideas from the W3C gain more traction (i.e. XHTML) started referring to W3C docs as standards, and the W3C as a standards body. Jeffrey Zeldman, in Designing with Web Standards [sic], says the use of the word "standards" when referring to these specs was, in fact, "a guerilla marketing maneuver."

This is not mere semantics. There is great value in making a distinction between well-considered ideas that still need to be battle-proven, and proper formal specs that have been sufficiently vetted.

Eventually the W3C began to believe the hype and now presents itself as a standards body, to the detriment of the greater Web community because, as you point out, they are "standardizing" things that people aren't actually doing.

http://www.scss.tcd.ie/misc/15445/15445.HTML

The CSS layout model were indeed based on exactly the layout properties of "presentational HTML" which people were using for style and layout at that time. It was just made more fine grained, and separated from the markup.

For example, the much hated "float/clear" layout model were based on the align="left|right" and clear="left|right" attributes which Netscape (I believe) introduce on img- and table-elements, and which people did use a lot. The layout model of tables were also widely used, and that was codified with the display:table-* properties, which again provides exactly the same layout model in CSS as tables provided via markup.

The problem was basically that IE development were frozen for many years. IE implemented the float-related CSS before the freeze, but not the table-model. I believe IE 8 were the first version of IE to support the table model, more than a decade after CSS2 became a recommendation.

This resulted in period of many years where the float model were supported via CSS in most browsers, but the table-model were not. This in turn resulted in an amazing amount of confusion, and people believing that floats are somehow the CSS's substitute for tables.

As in "Oh, we forgot to model certain properties of tables that numerous websites actually use. Here's a workaround that imitates a table cell until we get around to figuring it out. PS: tables are still bad."

Tables are not bad.

CSS purists state that using table markup purely for layout purposes (e.g. for positioning a page footer) is bad, because it violates the separation between content and presentation. In that case display:table-* will give you the same layout (neither worse nor better!) but without requiring any specific markup in the html.

But this poses a dilemma for web developers, because display:table-* is not supported by all browsers, so some specifc kinds of layout can only be achieved with table markup.

Developers had to choose between (1) compromising the layout (2) compromising the semantic/style separation or (3) use complex workaround like the CSS frameworks, which tried to emulate the table-layout model without requiring display:table support in the browser. Neither is optimal.

The rest of it though I agree with you.

Like this? http://www.w3.org/TR/CSS2/tables.html

Despite being first defined in CSS2 (1998) CSS tables were not supported in IE for 10 years (IE8, 2009), and while some of the blame for this is surely Microsoft's, with a standard as big and complex as CSS it's hard to expect implementations to get it right for a long time.

To avoid this disaster CSS3 is "modular" and currently has over 40 modules defined! This is madness. The more complicated things get, the more difficult it is to bring the web to new devices or to innovate in the browser space.

OTOH, it was the early adopters that were driving it, and I dont really have a problem with that. That is what early adopters do.

In other words, W3C missed the boat on this. I don't think it's to their great credit that they joined a three-year-old effort after it was already clear that the whole industry was headed towards HTML5 and not XHTML.

After it was clear how useful HTML5 was, the W3C was dragged into participation, but unlike W3C standards, HTML5 continued on with it's open development model where discussion takes place in the open.

The W3C has not contributed the idea, the execution, the prolitical process, or the people to HTML5, and HTML5 is a W3C standard by label only. If you look at the other standards the W3C creates, you'll see a pattern where standards are developed in isolation behind closed doors and without implementations, in direct contrast to any useable and useful standard such as HTML5. RDF, OWL, SVG, all abominations that seem to exist to hold back others from making reasonable and useful replacements.

    <table width=100%><tr>
      <td width="200px">Fixed left column.
      <td>Liquid center column
      <td width="200px">Fixed right column.
    </table>

    <section id="box">
        <div class="left">...</div>
        <div class="center">...</div>
        <div class="right">...</div>
    </section>

    #box { display: '  a   b  c'
                     200px * 200px;
           width: 100%; }
    #box .left { position: a; }
    #box .center { position: b; }
    #box .right { position: c; }

    #box { display: box; box-orient: horizontal; width: 100%; }
    #box .left, #box .right { width: 200px; }
    #box .center { box-flex: 1; }

    #box { columns: 3; grid-columns: 200px * 200px; }
    #box.left, #box.right { width: 200px; }

If webpages were always only made of box-like structures, CSS would have never made it. But you will admit that it offers a web designer much more flexibility.

That flexibility comes at a cost though, because some examples (like yours) that were very easy to realize with the very limited layout options pure HTML offered have now become more difficult. But that's because it provides a more general approach that takes care of many problems, not just three-column layout, and must thus be flexible. And flexible is what old timer HTML was not.

I'm not saying that CSS is the best or even a very good solution to the problem. I'm sure there are a lot of different approaches how to address the general problem of dividing content and layout. But it's there now, and it's bearable, I think.

Besides... all of what I wrote has nothing to do with the w3c :-)

    <style type="text/css">
    .table { display: table; width: 100%; }
    .tr    { display: table-row; }
    .left-column { display: table-cell; width: 200px; }
    .middle-column { display: table-cell; }
    .right-column { display: table-cell; width: 200px; }
    </style>
    <div class="table"><div class="tr">
      <div class="left-column">Fixed left column.</div>
      <div class="middle column">Liquid center column.</div>
      <div class="right-column">Fixed right column.</div>
    </div></div>

Btw., if you don't want a seperate stylesheet, you can embed the css style information directly in the html:

    <div style="display: table; width: 100%"><div style="display: table-row;">
      <div style="display: table-cell; width: 200px;">Fixed left column.</div>
      <div style="display: table-cell;">Liquid center column.</div>
      <div class="display: table-cell; width: 200px;">Fixed right column.</div>
    </div></div>

Additionally, you don't have to confuse screen readers with a table which don't really contain tabular data. So it also more accessible.

That may not appear to be a big deal, but try loading that page on a mobile device and it will become a bigger deal.

    <div id="site">
        <div id="left">Fixed left column.</div>
        <div id="middle">Liquid center column</div>
        <div id="right">Fixed right column.</div>
    </div>

I don't see how that's really an improvement in this particular case. In fact, I would say that using 'width="200px"' inline may actually be more readily understandable and maintainable than having the style defined somewhere else and then used only once. (I'm assuming that the 'width="200px"' is not duplicated multiple times in the PHP/Python/Arc/etc code that generates the HTML page. If the same style needs to be identified multiple times in the source code, then of course it may be a better idea to define it once and thereafter refer to it by name.) Are there any practical benefits that I may be missing?

Besides that, it's nice to know where all your styles live instead of having to grep your whole project. And inline styles take precedence over everything else, so mixing them with stylesheets can create havoc.

Furthermore, separating style info into a style sheet allows you to adapt the style for different devices.

  #left{
    float:left;
    width:200px;
    margin-right: -200px;
  }
  #right{
    float:right;
    width:200px;
    margin-left: -200px;
  }
  #middle{
    float: left;
    margin-left: 200px;
    margin-right: 200px;
  }

edit: it's not an ideal solution, as it has those negative values which have to match the related positive ones. Which is solved with something like Sass or Less, because CSS lacks any "programming" abilities, which I see as its main failure. Even variables and simple math would be acceptable, but instead, nothing.

  <div class="column">1</div>
  <div class="column">2</div>
  <div class="column">3</div>

  div.column {
    margin: 10px;
    width: 200px;
    float: left;
    }

IIRC, you could stick the TD's width value in a CSS class and it would work exactly the same.