Wait, what? Who said you have to lock the sidebar to a fixed width? If you have an elastic layout, just make the sidebar elastic and it'll scale up right alongside the content.
Let me try again less carelessly. Ideally you want the browser to automatically draw the sidebar just wide enough to fit its widest contents. But with divs alone, you have to specify a defined, hard-coded (I said "fixed" before, wrongly implying units of pixels--sorry) position for the content column. Therefore the left sidebar width has to be hard-coded too, which makes it hard to plug arbitrary widgets into it, especially images. The values may be hard-coded using friendly units like ems, but they are still hard coded.
Widths can also be defined as a percentage of the parent element. That tends to blow up sidebars when the window is narrow, and make ridiculous sidebars on super-widescreen monitors.
The only real place to run into problems is in the padding and borders: people often forget that they get tacked onto the width of the element.
I want a LOLcoder picture of a CSS geek sitting at a computer using a pocket calculator with the caption "COMPUTING -- UR DOIN IT WRONG". Or maybe "SOMEWHERE A KNUTH IS CRYING".
CSS is only horrible at making block elements share horizontal space if you don't know how to make block elements share horizontal space. Fixed, elastic, and fluid two-column layouts are easy. Three-column layouts are harder, but it can be done in any of those configurations, and without sacrificing semantically correct code or scalability.
I just don't get the relevance of "semantic correctness". Everything from the template to the user output terminal is pure presentation, a collection of practical tools to create output documents. If the implementation is comprehensible and maintainable, which it will be with judicious use of the technique I recommended above, then it is Plenty Good. Not a single piece of software anywhere in the chain cares one iota about the meaning or interpretation of table contents: it's just another rendering instruction.
I mean, really. Postscript is an entire Turing-complete language. People can and have written application software in it. (Maybe they shouldn't have, but they did!) Yet we all blithely crank out whatever garbage Postscript it takes to render our documents without a microscopic thought for the internal semantics. When's the last time you upbraided the secretary for not generating semantic Postscript? LaTeX lets you define your own semantics on the fly, but nobody gets too grumpy when you use unorthodox markup to make an interesting layout. So why the sudden semantic HTML religion? As far as I can tell, it's just a bad case of Silver Bullet Syndrome.
There aren't many instances where tables give an advantage, and in the few instances it, the advantage isn't significant
CSS is terrible at sharing horizontal space. Consider a two column page: a sidebar on the left aligned to the left of the page, an elastic-width content column on the right, and a fixed-width margin separating them.
With a table, the code looks like this:
<table class="bare-layout-table"><tr>
<td><div class="sidebar"><% sidebar %></div></td>
<td><div class="content"><% content %></div></td>
</tr></table>
Is that really so bad? All of what you normally consider style is set by CSS. The table is just there to position the content horizontally at sidebar right edge + margin, regardless of how wide the sidebar is at the moment.
If you use raw divs for this, then you have to lock the sidebar to a fixed width, and manually give the content a horizontal position. Every time the sidebar is resized, you have to pull out a pocket calculator and recalculate, looking up the desired margin from whatever non-machine-readable place you stashed it. This is not good engineering, it is guru full employment. It is X Windows modelines brought to the web.
float: left is not a solution either. Oh, it will seem to work for a few toy tests. But think what happens if the content ever gets so much as a single pixel wider than you hoped: it gets reflowed vertically below the sidebar to give it that extra pixel. The poor user is left staring at a blank space where the content should be. In the modern context of resizing fonts and single-pixel fixups in Javascript, this effect is almost to be triggered eventually, probably by a junior employee who cannot even recognize what they have done. Quite a number of major websites blow up in this fashion. One feels an urge to pat the designers on the head and take away their crayons.
That's what the grandparent comment means by "ugly" and "brittle". Good engineering is about making the computer automatically do the hard work, not following the "semantic markup" demagogues off a cliff. Even if it is a damn stylish cliff and all the cool kids are doing it.
Contrast tables with radical layout changes that can be made with small CSS bits. CSS was a pain before IE6, and IE6 still has issues, but for the most part CSS is an absolute joy to use now.
CSS is pretty great for controlling typography**. Unfortunately, it provides no way to make block elements simply share horizontal space.
**But try indenting/outdenting your headings a certain number of ems when they use non-100% fonts. It's pocket calculator time. If you change the indent/outdent/percentages, you have to manually fix-up everything. Dammit, CSS! Learn some arithmetic!
Those are good points. I wonder what amount of template "power" would be optimal? Preventing changes outside the template's own variables would eliminate most mischief. Arithmetic is nice, and a major shortcoming of Django templates. Defining new classes is probably excessive.
Must stop designing
In OO you normally create an object and this means doing a malloc at the C level for every message.
Many object systems let you assign a custom allocator for high-turnover classes. It is also common practice to keep a pool (or even a pool for each core) of pre-constructed objects (reusing freed objects in MRU order), rather than constantly be tearing down objects and building them back up from scratch. It's more an issue of folks not having experience with high-throughput design, rather than a problem with OOP.
Django is a good example for the drawbacks of this approach since it went to the extreme and allows almost no logic in the templates - beyond the usual iteration and conditional constructs.
Which is just a default, not a policy. Django templates are cleanly isolated from the rest of the framework, so any sensible Python template renderer can simply be plugged in. Here's an example of Cheetah templates being plugged into Django with a dozen lines of glue code. Mako looks like it would be trivial to plug in too.
The result? It's a pain to develop with this part of django. Django constantly gets in the way here because you can't scribble even the smallest thing into a template to see if it works or "feels right", you have to fiddle with the controller or a custom filter all the time - and that becomes tiresome very soon.
What's wrong with jamming in some "lorem ipsums", fiddling until it renders prettily, then building the necessary view? You can dive in even before the models are built.
This separation of concerns obviously makes sense in a settled application that is deployed in, say, the publishing business, where you don't want the template guys to accidently screw with production code.
An even better property is that it forces the software engineer to separate the logic from the presentation, no laziness allowed. That makes it dead simple to reuse the logic for any number of presentation formats. For example, suppose you make a web page that shows a completed e-commerce purchase. With more templates and a few lines of glue code, the logic can be trivially reused to generate an e-mail copy of the order form, a
This is critical for maintainability. With a typical PHP-like system, there is an almost irresistible temptation to copy-and-paste code to make multiple presentation documents, a recipe for unfixed bugs and version drift. This potential problem is why Django is very big on the DRY principle, Don't Repeat Yourself. And still it is not mandated, just a handy default that steps aside if you know better.
While doing drugs and engaging in rampant promiscuity are things I don't really condone, inciting hatred, bigotry, ignorance, and possible violence is on a whole other level.
Ah, but that is Card's entire point. Gay "marriage" would apply those standards of behavior to child rearing. The predicted course of events is as follows:
1. Gay "marriage" is approved.
2. Billy Cornhole goes to the Mineshaft club, drops enough Ecstasy to make a rabid wolverine feel friendly, and spends all weekend screwing anything warm that moves. And a few things that are cold and/or non-moving.
3. Billy wakes up Sunday evening to find that he is married. To whom takes a while to remember.
4. Billy and spouse get into an epic cat fight about something silly a few weeks later and part ways. Billy finds that divorce is expensive, time consuming, annoying, legally risky, etc.
5. Billy successfully lobbies, by a combination of threats and charisma, to make divorce instant, cheap, and zero risk. And he would indeed be right that, given the adaptation of marriage to gay sybarites, divorce must also be adapted to be fair.
6. A generation of people are indoctrinated by the leftist propaganda machine that this is how divorce should be used in our brave new anything-goes society.
7. Those people grow up and do what they were taught: they act as if marriage, and therefore children, are disposable inconveniences.
It is not bigotry or hatred for Card to say that this is cultural suicide** and should be stopped. If he is wrong or misguided or improbable, then the gay leaders should explain how and discuss the matter logically, rather than vilify and terrorize their campaign opponents. Instead it appears as if many of the gay leaders cannot imagine that anyone would think screaming, puking babies are one of the greatest goods in the universe, so they incorrectly infer that their opponents' actions must be personal attacks, and therefore leap to personal accusations of bigotry and hatred.
**Remember that the Spartans did not meet their doom in battle or plague. They neglected fertility and child rearing, in a context of homosexual indulgence, and gradually just faded away.
It is also worth noting the history of the Mormons (Card is Mormon) for those who do not know. Due to their sexual unorthodoxy (polygamy), in the mid 1800s they were cast out of mainstream American society, driven away with naked violence, and exiled to parts ever more westward, ending in Utah. As a result, they tend to have a natural sympathy for underdogs and outcasts. However their history also gives them a powerful devotion to family and and its preservation at any cost, a devotion that is not simply a tradition but codified in writing. It is the latter motivation that the gay "marriage" advocates are bumping up against and (deliberately?) misinterpreting as bigotry to stoke the fires of their political movement.
We should also note that, in many jurisdictions, gays already have civil union laws that their lobbyists can modify to their hearts' content, and such laws are inevitable in virtually all jurisdictions. They can already get legal sanction for behaviors mundane or outlandish. The battle for recognition and support is over: they won. Gay "marriage" is not about supporting homosexual households and families, it is about forcibly remaking marriage for all people as an act of cultural aggression.
What needs to be mentioned if such a statement is to be of any use, is how long such melting is expected to take.
According to this CERN page, in the few microseconds that it takes a beam dump to complete. The circulating kinetic energy of the beam is an impressive 350 MJ, equivalent to running a 1000 watt heater for 97 hours.
Remember to say hello to your bank teller.