Keep in mind: there is more than css and tables in this equation. There is normally a backend involved, too.
If the programmer has made good decisions when creating the site structure, moving columns around should be fairly trivial.
Sorry, but with a very imperfect spec like CSS, keeping everything in the designers hands is impossible.
The folks behind the current CSS spec failed badly when it came to layouts. Even the newer specs aren't doing much better.
It's a shame, especially when we've had years of design to draw from, both in the traditional design world but also programmatic layout managers.
Its not the fault of the CSS spec that Microsoft decided not to implement it. Of course it doesnt change the reality - that cross-browser CSS currently is not powerful enough - but please blame IE, not CSS.
Regarding a display order independent of content order: Neither CSS 2.1 nor HTML-tables were designed to support this.
Tables only support content-reordering using some ugly hacks with merged cells. CSS have much more powerfull suport - using absolute positioning you can place anything anywhere you want, regardless of document order. However this comes at the cost of flexibility.
Some new CSS proposals suggest a layout model where visual placment of elements in a grid can be totally independant of document order. However, since IE have taken more than a decade to implement the relatively simple table display model from CSS, this will propably not become a reality for the foreseable future.
It is correct that some layouts are easier created using tables rather than CSS. However, there is also many types of layouts which cannot be created with tables, but require CSS.
A serious article (rather than a rant) would explain the limitations of both approaches, given the limitations of current browsers.
Separating layout and content for purity's sake doesn't make sense, because the ordering of the divs in the html affects the layout. If you want to separate content and presentation, use XML and XSL. That should cure any ambitions along those lines. HTML is a presentation language, not a content definition language.
I was on the tables side, but some of the new grid layout CSS things like Blueprint are almost as easy. However, Blueprint makes it easy by putting the presentation back into the HTML page- you don't have semantic markup, you have styles that define the height and width of your element. So, it gives us the simplest thing (mixed content and presentation) but in a way that looks like it complies with the "no tables for layout" dictum sent down from CSS heaven.
I don't understand why people keep trumpeting this like it's a big revelation. The layout of everything depends on the order whether you use CSS or not. Floats were not intended to change this, and complaining that they don't just because tables do is apples to oranges.
If you look at the specs, the example use case for floats is floating an image element inside a paragraph. For that and many other cases, floats work exactly as intended and expected. It's only when you use floats to emulate a table-based layout without using display:table that a problem like this comes up.
Because the dependency on entry order makes the div's class semantically meaningless. Yes, the order in tables makes a difference, but in a table, that makes sense. With CSS, however, if I add a div with a class name like "center_column", then I expect to be able to put it anywhere in its enclosing context, and it should render in the center of that context.
CSS as an abstraction leaks, and it leaks blood. It seems that CSS-supporting designers (on this thread and elsewhere) accept this far more readily than hackers. A table is a table is a table: you expect its order to matter, so no one blinks when this turns out to be the case. CSS looks superficially like it provides a higher level of abstraction, but it (1) does not, and (2) requires considerably more effort to get right.
<div class="article">
<div class="author">
John Q. Public
</div>
<div class="text">
Some text goes here.
</div>
<div class="date">
February 3rd, 2009
</div>
</div>
To me, this looks like an abstract thing. It says that an article consists of an author, text, and a date. The stylesheet should take care of rendering these elements in any layout the designer implemented inside that sheet. If the rendering breaks just because author goes to the end of the list, the abstraction leaks. It means that (author, text, date) is an article, but (text, date, author) is not.As I said before, floats do not change that (from the CSS2 spec): In the float model, a box is first laid out according to the normal flow, then taken out of the flow and shifted to the left or right as far as possible. Content may flow along the side of a float.
What you're asking is to be able to modify the document tree, which modifies the normal flow, and then have something which explicitly depends on the rendering of the normal flow to not change.
But I dont really see your point in favor of tables, since CSS is strictly more powerful in this case.
At least people aren't using JS to move everything around on the page any more. That really sucked.
But now that the pendumlum seem to have swung from never use tables for layout to always use tables for layout, I suppose it should be extended with an explanation of when not to use tables :-)
http://news.ycombinator.com/item?id=464342
http://www.newmediacampaigns.com/page/why-css-should-be-used...
Last month I created the template for an HTML email on behalf of my brother. Based on the advice of MailChimp (http://www.mailchimp.com/resources/how_to_code_html_emails.p...), I used tables for layout. It worked on my first try. I could NOT believe how easy it was.
Due to the dirty feeling I get from using tables, I didn't let myself consider using tables more broadly for layouts. But now ... I feel like an alchoholic saying, "maybe just one little drink."
I don't feel dirty from using tables now. I use floating divs whenever it makes sense, but if it takes too long to screw around with the divs, or if it feels like it will take too long, I switch to tables in a heartbeat.
Otoh, there's something to be said for the various grid css layouts out there, like Blueprint and the like. They might be contrived, but they work pretty well on a wide variety of browsers. Where reasonable, I still favour using something like Blueprint rather than tables. Not sure why, though...
Regardless, a solution that works in IE6,7,8 Fx2,3 Op/Saf/Chr would be sufficient these days I think.
I suggest people to read http://www.alistapart.com/articles/understandingprogressivee... and the other (most recent) ALA articles on the same subject from Aaron Gustafson.
Don't get me wrong, I'm not against CSS. I use css for styling. Not for layout.
CSS just can't do sane layout unless you're positioning and sizing things in terms of simple pixel values. If you want for example div C to be the same height as div A, then css is a failure. Either you use tables, or you use javascript and resize things on the fly which is pretty ugly+slow.
All it'd take is to be able to do some simple arithmetic in css, and reference other elements... eg
width: ((100% - leftCol.width)/5);
height: max(leftCol.height, rightCol.height);
I guess there's something to be said for IE css expressions... except allowing any js there is a bit overkill for most things and makes for a pretty slow UI.It's worth noting that floats would have been implemented the same way, with the same uses in mind, and would have exhibited the same kind of problem. The solution in that case would have been to use JavaScript and resize things on the fly. Not really so different, then.
This isn't new. Computer Science is called computer science because it can change. Algorithms can be shown to be less efficient than another algorithm. Ideas can be shown to be incomplete, meaning, they can't solve 100% of problems.
This is true in other areas as well. We still teach and use Newton's Laws to describe many concepts in kinematics, even though they don't do a perfect job.
My point is that the solution isn't to scrap CSS, but to add things like you suggest, which would be awesome. The problem however is that the browsers aren't going to support those new formulas, so what do you do for all the browsers out there that don't support your math, but you still want the site to be accessible?
Here comes in the problem with competition -- some vendors can't keep up, some customers can't keep up. IE is way way behind. Microsoft should just scrap the browser effort and focus on the operating system. FireFox is great, but it's buggy. Opera behaves strangely and the developer tools aren't as good.
The point is that each of these browsers doing things differently is part of the problem. They are vendors of the tool we use to display our pages. We are the ones inconvenienced by their lackadaisacal attitude toward standards compliance -- and they are slacking too.
The Standards bodies are slacking because there is no standard video format. There is no video tag. Oh wait, there is a video tag: http://www.w3schools.com/tags/html5_video.asp
But who supports it? Opera does. Not much else as of a year ago: http://blog.wired.com/monkeybites/2008/03/html-5-suppor-1.ht...
Oh wait, no one uses Opera.
You want to know the solution? Eliminate competition in the browser market. Oh your capitalist ears are burning aren't they? Why do we need IE, FireFox, Safari, Opera, Chrome, and on and on? We don't. They are slowing us down.
Standardize the browser. Make it open source. Make it work on all devices. Make it follow the standards. Make it follow the standards by a specific date. Release a new version and auto update everyone so we are always all using the latest standards compliant browser.
You argue it's against the american way. It's socialist. It's big government.
No it isn't. It's not America, it's The Internet. The companies should comply willingly. Take all the best browser people from Microsoft, Apple, Opera, Mozilla, and Google and make a new body funded by domain name registrations and credit card transactions on the web.
Yes a tax. A tax. It is a tiny one penny tax and it will more than pay for itself in the time saved to develop new information systems that will model the vision of the web.
I argue that the web is a public good. It is an international public good. It's a public good as much as roads, electricity, train tracks, bridges, and automobiles.
In the brick and mortar world that surrounds us, vehicles transport people, wires transport electrons. Those electrons today carry more information than a person, yet we continue to build infrastructure to transport physical bodies and neglect the information.
If we want to progress as a human civilication with powers beyond current imagination, the first thing we need to be able to do is collaborate effectively. To do that we need better, more accessible information systems, and to do that we need a stronger more capable infrastructure. The connection between that infrastructure and the human who will participate is the browser and that should not be controlled by a company with justifiably selfish motives.
We want corporations to compete and fight, but we want the world to collaborate. Corporations aren't always the best organizations to trust to enable collaboration. Sometimes collaboration isn't best insured by corporations.
So the question then is, are we going to let the corporations continue to slow us down? Are we going to form a one world browser? Are we going to pay for it with taxes? Are we going to pay for it with volunteer labor?
How is it going to get done? How are we going to continue to move forward supporting the laggards who don't want to upgrade from IE5 or IE6 or just do away with IE all together?
At some point you have to make a choice to embrace technology and move forward, or be left behind.