I am not going to reply to all your gripes.
It is not a new model. There was no width attribute until html3.2, and then only on select elements such as hr, but not div or p. CSS1 described the content box model from the get-go. If you learned the wrong way, what's your beef?
..[sic] to structuralists I assume.
HTML is a markup language for describing the structure of a document, so I hope so.
Oh please, that smacks of elitism (though that was also a great C64 game). The web was a "dynamic, interactive medium" long the before the W3C came along.
That, elitism, is a specious argument. Until Netscape brought us a scripting language, the web was not what you'd call dynamic. It did offer forms. The W3 formalized IETF's rfc 1866 in 1995 as html2. HTML had only existed since 1990.
Even as a coder it doesn't make much sense: When I ask the DOM "what is the width of element xyz?" I want the width of the element. I'm not asking about the width of the element's text node - which should stay where I want it to stay, inside the bounds of my dynamic and interactive box. If the text overflows the box's border, does width return the real actual width of the text outside the box as rendered? Strangely, no. So, suddenly, there's no access to this so-called "content box" anyway. Content has a bit of a life of its own now.
I have no idea what you're going on about. Overflow is not a box model issue. I assume that you're melding IE's faulty border box model with IE's really, really stupid version of a new block formatting context known as hasLayout. hasLayout was the epitome of WAD bugs in action. Most of IE6 and below's rendering bugs, including its really screwed up mistreatment of overflow:visible are due to hasLayout. IE7 was patched to fix most of the hasLayout rendering bugs, and IE8 has killed the concept, and adopted a proper block formatting context.
WAD stands for "works as designed" so "WAD bug" is an oxymoron, isn't it? Maybe depends what you're calling a bug.. you mean the conflicts between browser implementations?
No, I mean that the border model will/can break itself due to its design.
You could say that of the border-box model too. Except content didn't flow out of them! The box grew with the content. Did W3C provide an alternative like "overflow: growbox" or something in case we want different behaviour? Nup. Nice idea perhaps, sloppy implementation definitely.
The content didn't grow out of them because of that massive WAD bug, hasLayout; a different and orthogonal issue from the box model.
Perhaps if you explained why content overflow is a good idea and how to manage it, I'll understand your css position (pardon the pun) better.
Because it is better for the content to overflow than have the box expand, breaking the layout.
They just don't think about practicalities. Why else do we still not have vertical centering of content or a host of other dead-simple but invaluable layout features?
We do have it. Learn css.
Their focus seems remarkably misplaced. I mean, if you want to replace tables with CSS, then give us equivalent functionality at least.
Again, learn css and well structured, semantic html. CSS does not replace tables. Tables are structural elements, and css is a presentational declarative language.
We need a body to regulate and standardise the language, of course. But it needs to be more practical and real-world, less academic and political.
Even in terms of "structure" the thing is a mess IMO. We've gone from nested tables to nested divs - not a huge improvement there.
Anyone who has done that, doesn't understand what css and semantic html are all about.
They keep missing opportunities to really advance the medium. Why else are we seeing Silverlight and Flash competing now in the application space? Because HTML & CSS for apps is still a mess for coders and designers in any complex application.
HTML, css, and js are for documents. Flash, Silverlight, audio and video players, pdf viewers, etc. are plugins that extend the document. I see no conflict.
Look into any popular JS library - YUI, jQuery, Mootools, whatever (bless their socks) - you'll see many sizing and positioning complexities introduced by the content-box model which would be so much simpler in the border-box model. And it would still be dynamic and interactive.
Look into any of those libraries, and you'll see potloads of cruft, all due to their attempts to be all things to all people. Write your own lean, mean, fighting machine library.