The article's argument would carry more weight if the author gave an example using tables where he changes the order without affecting the layout.
The whole point of the argument is to show that if you change the order with the CSS version, things move around. Then he goes on to show a static table. What the article really proves is that tables are not better than CSS. And CSS can do millions of things that tables can't (I'm not trying to start a troll on that topic). So I'll stick with CSS, thanks.
There is one valid point in the argument: improving CSS so that you can position elements in relation to each other by name would help. So I could say that the DIV element called "left" should be on the left of the "center" element. Right now, relative order is based on the order in the HTML source.
"What the article really proves is that tables are not better than CSS."
Well, no. What the article shows is that, for layout, CSS has one of the same chief defects that people complained about for tables (content and presentation codependence), and that CSS doesn't even have the saving grace of allowing the content to be in the same order people read in (in Western languages, yes, yes), as tables do.
I always hated that in RTL pages all the tables get reversed, but the floats don't. It's a bad design decision IMO. I ended up creating two sets of CSS for my pages, where I reversed right/left each time I used it (float, border, margin, etc.)
I want to propose start and end (or something else? suggestions?) as RTL aware version of left/right, so margin-start: 10px; for example.
This is only true if you use CSS floats in a particular way which was not foreseen when the specs were written, which is only necessary if you want a certain kind of layout and don't want to use positioning or scripting. That strikes me as a step forward from always having that codependence.
If this is true, then the CSS spec is bad. You should not have to require scripting to position elements. Period. If you do, then it shouldn't be called CSS, it should be called CSS/JS or some other merged acronym.
I've spent many hours tweaking a design with CSS and javascript to replicate what would have been a simple table layout. There are just somethings that CSS isn't good at, for example, it's bad a fluid column layouts. Particularly where you want to have a vertical alignment of a block line up with the bottom of the longest column. (I probably didn't explain that well...) I'm not aware of any CSS that can handle this well w/o javascript.
Who said you have to require scripting to position elements? I most certainly didn't mean to suggest that. That said, CSS is not a programming language, so by nature there are things possible in combination with JavaScript that would not otherwise be possible. I think it's worth considering when attempting to go against the grain of the language, just as it's worth considering changing direction to do something the language is better equipped to deal with.
The strength of CSS layouts is flexibility. Yes, you need to fiddle a bit with it to make it all work, but the majority of the stuff is done in an external CSS file. Redesigning parts of a CSS site is much easier than with a table -- indeed it is almost impossible with a table in some cases because it is so static. With CSS you can change positioning and float it in another direction for example. A lot of repositioning can be done with absolute positioning, though floats are more ideal for the "core" structure.
I think the example provided in the article is good though. CSS layouts should be so trivial to do, and it's a shame they're not. Going back to tables doesn't come without a cost however.
Most sites also used a backend with their own templating functionality. Often, it's surprisingly simple for a programmer to change out the look of the site by tweaking a simple template.
I have the sneaking suspicion that there are a lot of coders contributing to this recent rash of CSS vs. table discussions who flat-out don't know how to write CSS very well, and can't be bothered to learn.
That was my obligatory quasi-offensive hook to get you reading. Now, before you actually get angry... there's nothing wrong with that! You're a coder! Do what you do best - write awesome useful stuff! ...and don't be afraid to acknowledge that there's a language out there that looks like code, but that you don't have a handle on.
As someone who has spent the last several years doing nothing but writing HTML and CSS in a professional capacity, I am here to tell you that if all you beautiful, intelligent hackers out there (I'm only being facetious about the beautiful part, 'cause I've seen some of you ;) really understood front-end layout the way you understand all your programmy stuff (which I do NOT), we wouldn't be having this discussion.
If you're just working on a personal project, or trying to hammer out the beta version of your web app... sure, use tables, so you're not wasting time trying to do something that's not your core competency. However, if you're taking it beyond that, or trying to get into front-end stuff in a professional capacity, you need know CSS like the back of your hand. Someone who's competent at layout should be able to write something from scratch that does whatever they want it to without having to debug it for hours.
If you're at the point where your biggest problems would be solved by using table layout instead of CSS, you're probably not at a point on the CSS learning curve where it's appropriate to make assertions about which layout technique is superior.
All that said, if you're a coder, why do you want to get into layout anyway? Your skills are WAY more valuable... designers like me are just here to make your work look good ;)
Well, is there anything you have to say on the substance of this debate? The good thing about Ron Garret's article is that he said specifically why he thinks that CSS is unsuitable for doing layouts. You're free to come up with a counter argument.
Instead what you do is talk in general terms about the competence of people whose CSS competence you know nothing about. That's just not very convincing.
And by the way, you're "argument" reminds me of what C++ advocates keep going on about. Templates are turing complete, etc, you just need know how to use them. But even if competent CSS experts can make most things work, that doesn't mean they wouldn't be much more productive using something better suited to layout.
I agree with Ron Garret that tables are a better fit in most cases, even though they do have their own drawbacks that I'm not denying.
I don't buy the argument that tables somehow imply semantics that contradict their use in layouting. Tables have no semantics without a formal system that lends them semantics (like the relational model).
I'm not aware that the W3C or anyone else defined the formal meaning of tables, and since HTML is a UI technology I don't see why "table" should not be interpreted as a form of laying out content in rows and columns.
"Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables."
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]
http://www.ietf.org/rfc/rfc2119.txt
From that RFC:
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
I'm not a coder (pro designer for 9 years) and usually back most arguments made for Tables. Sure CSS is slightly more evolved but sometimes using older tech makes much more sense for other reasons (besides content vs layout). Also support for Table layouts is still strong and there's no compelling reason to upgrade for most webmasters.
However I'll agree with your assessment about coders being too lazy to learn proper HTML. ducks
I dont want to speak for everyone at least but I dont particularly agree with thin divide between programmers and designers, the lack of gap is one of the reasons that the web is so popular.
While I havent seen that many programmers who can produce aesthetically brilliant design, I have seen far less designers that know nearly as much about the technical limitations of css layouts as the typical web programmer.
There are solid situations where css (as much as I love it) just isnt capable and isnt the best solution, it isnt just down to lack of knowledge.
After many years of flailing from side-to-side of the css/table argument, I've found myself doing what the author talks about -- simple table for layout, css for everything else.
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.
> The folks behind the current CSS spec failed badly
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.
You seem to suggest that CSS is good enough to do what we would want, but necessary parts of it are unsupported on IE. However, the article describes a problem (content order matters in the presentation) that is due to the rules of the CSS spec and has nothing to do with IE incompatibility.
The CSS spec supports the same display model as HTML tables (using display:table|table-row|table-cell). So if tables work for you, CSS (when fully implemented) should work too.
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.
Tables for layout, CSS for styling and PHP for includes is a winning formula for me, and has been for years now. I can design almost the entire page/site offline and do minimal browser testing because of it.
Above average, sure, but still misinformed and one-sided.
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.
Obviously, neither option is ideal, or this discussion wouldn't keep happening. However, I think it's much easier to prove a purist wrong than to prove a pragmatist wrong. The pragmatists just change their position.
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.
> because the ordering of the divs in the html affects the layout
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.
I don't understand why people keep trumpeting this like it's a big revelation.
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.
You don't know what you're talking about. "center_column" illustrates that. You're still pretending that floats are tables, which they are not and never were intended to be. That's my point, and it went way over your head.
Let me try a different class name and a more thorough example.
<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.
It isn't an abstract thing, it's HTML, and it behaves like HTML. That CSS styles HTML is not an implementation detail -- it is dependent on the underlying document tree, not an abstraction of it.
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.
The reason people make a big deal out of it, is that people are claiming that you can use CSS to separate semantic content from the presentation, when that is not 100% possible with current design of HTML/CSS. It's not really an argument about what floats were designed to do, it's a reaction to the purist argument that layout shouldn't be in the HTML. Perhaps that's a bit of straw man, since, as you say, it's obviously false. However, there is a bit of confusion out there resulting from people arguing HTML can be kinda like XML, and CSS can handle all of the layout. It's not a good position to argue, because HTML is a primarily a presentation language, in addition to offering a few opportunities to sneak in some semantic metadata.
At least people aren't using JS to move everything around on the page any more. That really sucked.
HTML is not a presentation language. It has historically contained a bunch of presentational elements (<CENTER>, <FONT> and so on), but they are deprecated now, and not necessary when we have CSS.
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 :-)
Yeah, it made me think about a funny thing that happened to me a month ago:
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...
May I suggest reading "Everything you know about CSS is wrong" by Rachel Andrew and Kevin Yank? It teaches to produce table-like grid layouts using CSS.
As the book states one cannot provide such a solution for all of them. I get your (and other people in the favour of the table argument) POV, but I simply do not agree.
"I get your (and other people in the favour of the table argument) POV, but I simply do not agree."
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
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.
So what you are suggesting here is not: "Do away with CSS" but rather, "Add some stuff to CSS"
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.
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.
You wouldn't rewrite cstdlib why would you rewrite your CSS framework for every project?
More over I think a lot of people neglect the real issue which is the high touch point of the Web, it's the multiple clients. You try to write cross-OS GUIs in Java and Swing and find out how easy that is (it isn't, obviously).
The reason people advocate CSS is that it presents some real tangible benefits. CSS was specifically designed to present the semantics of layout rather than HTML tables. The author doesn't even talk about CSS tables (http://thinkvitamin.com/design/css/tables-the-next-evolution...).
Again I wish people would talk about technologies they were familiar with and had even made spent time with. You don't see me critiquing the algorithmic design of search engines because I didn't choose to follow CS down that route of expertise.
Grids need more coverage, as they are by far the best way to bypass css misery and create a flexible, controllable layout for your website. They require a whole lot less markup than tables, are more intuitive, are much more controllable, and in general should never be not used. With Grids, you start thinking about ratios rather than pixels, which is a real help in making your site aesthetically pleasing and flexible.
Yeah, pretty much. I'm not sure why this debate is even still coming up; It's been "solved" by a half-dozen grid frameworks.
The other issue is that people trying to get these pixel-perfect layouts need to rethink their strategy. Its a hypermedia document, stop trying to make it look like a printed page or a magazine ad.
+1 for the second one. That made me laugh (and made me think that if I had something like this for all areas of my life I'd be single, have a 7th grade education and hoping the manager at Burger King returns my call...)
CSS layouts are a fascinating and sometime beautiful execution of technology, but it's not (at least this version) the next step in evolution of layout.
His html example for the 3 column layout is subpar anyway. The wonderful advantage of CSS is that I can create a multi-column layout where the html might put the content div first and the nav last, if I have a reason to do so. My underlying html structure doesn't need to be in any particular order in order to achieve the layout that I want.
He completely misses the fact that CSS2.1 has had display: options to do table-like alignment for years. These are well supported in modern browsers, except for IE6 and 7.
I completely recognize this is an argument of "what should be" versus "what is". As it stands though, I have been doing this for years and have never, never EVER needed to use tables for layout purposes. I get that some people are more interested in writing applications and just don't have to time to learn all of the idiosyncrasies that go into dealing with cross-browser display problems. However most of these are easily overcome, most without even needing CSS hacks.
It depends on how you are counting "majority." According to w3schools, IE6 & IE7 combined make up 46% of browsers right now and Firefox makes up 44%.
If IE had taken Opera & Firefox's lead a long time ago we would not still have this problem. CSS is not the problem, support for CSS is the problem.
Hopfully the IE8 will swallow the IE6 & IE7 market because we really need to take advantage of these great "display: table" properties that have been around for the last 11 years.
w3schools overestimates the firefox share because there are far more web designer/developers going to their site. The actual breakdown is more like 66% IE6/IE7 and 33% FF/Opera/Safari. Opera and Safari are a couple percentage points each.
"My underlying html structure doesn't need to be in any particular order in order to achieve the layout that I want."
Sorry but in my experience you do need to tweak your document order to achieve the layout you want.
As an example, I made a (unreleased) site where I have "navboxes" floating on the left and right, and content in the middle. I had to put the floated divs before the content so that the top of the navboxes were aligned with the top of the content instead of having the content and then the navboxes below.
That worked fine but I wanted to have the content first in the document because if someone accesses the page with, say, lynx (yeah, I know) I deem the content more worthy of being at the top than the navigation (that took a lot of space).
Finally I decided to use absolute positioning for the floats I think (there were bad interactions when I put floats in my content), it's fortunate that I had this choice so I could get the document order I wanted.
"He completely misses the fact that CSS2.1 has had display: options to do table-like alignment for years. These are well supported in modern browsers, except for IE6 and 7"
haha are you serious? What percentage of people are using ie6 & 7?
I think that layout shouldn't be that complex - lets be honest here we aren't building applications or anything difficult like that - we're layout out text and pretty pictures and CSS often makes this more difficult than it has to be.
That being said I still use CSS as often as I can for layout.
I suspect he was serious, and he has a good point. If IE had supported "display: table" et al, coding CSS would be a hugely different and less confusing/frustrating experience for both the novice and the expert.
I'm really not sure what point your comment is actually meant to convey.
The relevant point which apparently needs clarification is that CSS has had "display: table" for bloody ages and "Blaming CSS for the inadequacies of MS browsers is flawed logic."
If you don't want to use CSS because of the "inadequacies of MS browsers" or because your knowledge of CSS just isn't up to it in relation to particular layout you are trying to achieve, no one is holding a gun to your head. But don't blame CSS for this.
I'm happy to come from the POV of pragmatism. I don't see myself as a CSS fanatic. But honestly, I have been using CSS so long that I actually find it harder to work with tables for layout (as I have recently found when I had to work on a legacy site that uses tables for layout). The markup is so much more verbose than what I am used to now (nested tables are evil, full stop). CSS layouts are clear and uncluttered to me in comparison.
My own experience tells me that if you put the time in, CSS will make more sense than tables for layout and will become easier, regardless of the crappy support from some browser vendors. Whether one wishes to put the time in or not, is up to them.
I don't see how this is relevant at all. I'm not blaming CSS for anything. Who cares whose "fault" it is?
My point is that it doesn't matter what CSS could do with the right browser. Out here in the real world, 38% of my site's traffic is IE6. If my design doesn't work perfectly in IE6, then it doesn't work period.
I don't see how this is relevant at all. I'm not blaming CSS for anything. Who cares whose "fault" it is?
OK fair enough, maybe I interpreted the tone of your earlier comment in a way that you didn't intend. But I think it actually does matter whose fault it is to a certain extent though, only becuase people seem to be so quick to jump on the W3C while they give other organisations who sat on a crippled browser for years before Firefox freaked them out enough to get moving again, a comparitively free pass. I agree that moving forward, it really doesn't matter, but for the sake of historical accuracy, yeah it does.
Your argument appears to be that you are unwilling to make use (or at least very much use) of CSS due to the lack of support from IE and that you cannot sufficiently support IE6 with CSS.
I have been making sites with pure CSS that support IE6 for years. For sure it would be easier if IE supported display: table, but it's absolutely possible right now.
Your initial quip implies that it is not possible right now and this is incorrect. If you wish not to implement a pure CSS layout due to not having the time, knowledge or inclination, that's your choice to make with your projects. But understand that this is all that holds you back.
Incidentally, 38% is a pretty low IE6 stat, I envy you... If any of the sites I support hit that mark, I would seriously start thinking about dropping support for IE6 on that site all together, or at least looking at graceful degredation/progressive enhancement possibilities.
You're not building applications? I hope you are referring to your specific case - Those of us who are dealing with a significant JS layer need to use every feature CSS and HTML5 have to offer us.
That's a whole different kettle of fish altogether! If you're building an application that requires JS then you have the power to completely modify the DOM, reorder elements, position absolutely and adjust position based on screen size etc - in this scenario you are no longer tied to CSS limitations or browser inconsistencies :)
Now if only 100% of people had JS turned on things would be peachy :)
The arguments presented seem like a half truth to me.
1 HTML multiple CSS
not 1 CSS multiple HTML
The whole concept should be that HTML should be written to have 100% accessibility across all readers (browsers and mobile devices), meaning someone with the most ancient browser can read the page and understand the content of everything without any form of presentation.
What the author has done essentially is the following:
Try reversing some words in a sentence and then later complain that English is flawed because the sentence no longer makes sense reading it left to right.
The HTML won't make any sense if you start reversing it... I mean what is the point of putting <h2> tags below your <p> when it's obvious that the <h2> tag is acting as the heading for the <p> below. I wouldn't be able to read that, so why is CSS @ fault?
The logical flow of the content should be based upon the reading the raw HTML in a procedural order.
This will keep it simple for coders to update the content, and css artists can pump many different layouts and show many different layouts to clients in a matter of seconds.
Good CSS also requires good HTML.
Why the author of the article is using a div container to wrap them all when a body tag exists is beyond me.
I think as much as we point our fingers at css as a flawed language, we need to point our fingers at how write our HTML as well.
> I mean what is the point of putting <h2> tags below your <p> when it's obvious that the <h2> tag is acting as the heading for the <p> below. I wouldn't be able to read that, so why is CSS @ fault?
Nobody is talking about putting headers after the content they're introducing. The author is talking about a situation where it makes sense to order the markup one way, but CSS demands it to be done a different, not easily readable way. Which does happen sometimes.
> Why the author of the article is using a div container to wrap them all when a body tag exists is beyond me.
This looks like a ridiculous statement to me. But please, explain further what you want him to do.
I find it comical that you go on about "good HTML" and then point to CSS Zen Garden, where the HTML is inextricably bound up with the presentation (ie, adding wrapper elements to allow for flexibility in styling). CSS Zen Garden is an example of HTML as it should not have to be.
CSS doesn't demand it to be done differently though. If the HTML is written with a different flow the CSS will need to be written to accompany that.
I won't say it's perfect, but if you wrote
div col 1
div col 2
and then you wanted col 2 to be on the left of col 1, you'd write the css differently then you would the forward method.
>This looks like a ridiculous statement to me. But please, explain further what you want him to do.
Well look at it this way
<html><body><div container><stuff><div container></body></html>
What is it that div container is doing so well that body isn't already doing as a binding tag?
> I find it comical that you go on about "good HTML" and then point to CSS Zen Garden.
I will have to disagree. CSS Zen Garden reads perfectly and logically without css. It's something that 90% of sites are missing out there. And although the HTML is inextricably bound up with the presentation as you write, it is 100% readable by Netscape 1.0.
He uses HTML to describe the data that is being wrapped in the tags, and the information that is grouped by divs are grouped by the fact that the content is related, not by the fact that the data should be visually sitting beside each other.
While there is excessive usage of <span> tags written throughout, it was a design decision to enable css artists to replace text with images, or allow them to get around browser quirks that are challenges that CSS still face today.
> and then you wanted col 2 to be on the left of col 1, you'd write the css differently then you would the forward method.
At the cost of a lot of flexibility. Most people, when faced with a change in design like this, simply reorder their HTML. So perhaps "demand" was hyperbole, but CSS does still push developers to rewrite their HTML when design changes happen.
> Well look at it this way <html><body><div container><stuff><div container></body></html>
The container is providing a hook for layout information that the body tag cannot. For instance, if I wanted the body background color to be blue and the container's background to be white. Also, if you want your content to be restricted in width, it's a lot easier to wrap it with a div than deal with the lack of the > operator in IE 6.
> CSS Zen Garden reads perfectly and logically without css.
I didn't say that it's hard to read. I said that by the standards community's definition it is not good HTML, because it mixes content and presentation.
Just to be clear, I think that "bad HTML" is pretty much the only practical way to go right now. So, I don't have a problem with the way CSS Zen Garden uses wrappers, nor do I have a problem with the wrappers in this blog post. But you are criticizing one and making excuses for the other.
>At the cost of a lot of flexibility. Most people, when faced with a change in design like this, simply reorder their HTML. So perhaps "demand" was hyperbole, but CSS does still push developers to rewrite their HTML when design changes happen.
I don't doubt that cost/time is a factor. As programmers, we would all love to do without the additional overhead of coding practices, and for an unlimited number of reasons.
I realize that css isn't the best language in the world. But if it was intuitive to write css forwards and backwards regardless of document flow -- this wouldn't be a discussion topic. The question is the amount of time invested to learn it.
>The container is providing a hook for layout information that the body tag cannot. For instance, if I wanted the body background color to be blue and the container's background to be white. Also, if you want your content to be restricted in width, it's a lot easier to wrap it with a div than deal with the lack of the > operator in IE 6.
This is true. I was looking purely from layout perspective, but yea, body bleeds background-color and image everywhere regardless of limiting the width.
>Just to be clear, I think that "bad HTML" is pretty much the only practical way to go right now. So, I don't have a problem with the way CSS Zen Garden uses wrappers, nor do I have a problem with the wrappers in this blog post. But you are criticizing one and making excuses for the other.
Practical -- yes I don't disagree. With the way browsers interpret things differently, it's just about the only way you can get compatibility across the board.
Though you are right that I criticizing one and making excuses for the other: at least one follows a clear stated goal -- html describes the content, css draws the presentation. Provided items are added to make do with incompatibility issues, but at least at the core we can see that HTML is purely being used to describe the content. Allowing _enough_ separation required for programmers to be nearly clueless of a designer's job.
The other has no such goal; creating a massive grey area between the programmers and the designers.
> I realize that css isn't the best language in the world. But if it was intuitive to write css forwards and backwards regardless of document flow -- this wouldn't be a discussion topic. The question is the amount of time invested to learn it.
Quite right. The argument, as I see it, is that it's much more practical to use the best cross-platform tool for the job, which in many cases is tables and not CSS. He's arguing that it's not worth the time.
> at least one follows a clear stated goal -- html describes the content, css draws the presentation.
This isn't even close to CSS Zen Garden's stated goal. Its goal is to show what is possible to do using CSS. It's goal is to be "A demonstration of what can be accomplished visually through CSS-based design." There's nothing about content/presentation separation anywhere on the site.
> but at least at the core we can see that HTML is purely being used to describe the content
That's certainly not what I see at all, especially at CSS Zen Garden, if that's what you're still referring to here.
> Allowing _enough_ separation required for programmers to be nearly clueless of a designer's job.
If you mean programmer == HTML, and designer == CSS, then this is simply wrong.
<div id="supportingText">
etc etc. And it goes on.
All I see are information grouped by content. The ids, and class tags describe the information. The paragraphs are ordered p1,p2,p3, because for them to make sense they have to be in that order.
Page header, quick summary and preamble are all items that belong to an introduction.
In the source of csszengarden, do you also see this
> There are more classes and extraneous tags than needed, and in a real world situation, it's more likely that it would be much leaner.
and this
> <!--extra div for flexibility - this list will probably be the trickiest spot you'll deal with -->
<div id="linkList2">
and this
> <!-- These extra divs/spans may be used as catch-alls to add extra imagery. -->
<!-- Add a background image to each and use width and height to control sizing, place with absolute positioning -->
<div id="extraDiv1"><span></span></div><div id="extraDiv2"><span></span></div><div id="extraDiv3"><span></span></div>
<div id="extraDiv4"><span></span></div><div id="extraDiv5"><span></span></div><div id="extraDiv6"><span></span></div>
The HTML guy could not be "nearly clueless" about the designer's needs if CSS Zen Garden's flexibility is what you're looking for.
But your whole argument is on the basis points of 2 commented divs?
<!-- These extra divs/spans may be used as catch-alls to add extra imagery. -->
Add extra imagery -- it's posted at the bottom and away from the content. It's not like it's messing with what the programmer needs to develop. You could have easily have removed those tags and only the designs that decided to take use of them would get hurt -- but it is optional, not a requirement.
<!--extra div for flexibility - this list will probably be the trickiest spot you'll deal with -->
I thought we discussed that browsers incompatibilities are the reason for this.
The core of the content is listed at the top of the HTML page which is organized properly.
TBH: I would hardly call this level of adding extra markup anywhere close to other HTML where the presentation is completely ingrained.
> it's posted at the bottom and away from the content
But it's HTML, and should therefore should BE content. But it's not; it's presentation.
> I thought we discussed that browsers incompatibilities are the reason for this.
You seem to be missing my point. If CSS, as implemented NOW, worked as advertised and offered a way to separate content from presentation while retaining flexibility, then we'd have no argument. I'd happily be using it for what is intended. You just can't do that now, and I'm tired of people telling me that I can.
> I would hardly call this level of adding extra markup anywhere close to other HTML where the presentation is completely ingrained.
Of course it's not completely ingrained. But I want it to be able to be completely separated before I'm going to join your camp.
>I didn't say that it's hard to read. I said that by the standards community's definition it is not good HTML, because it mixes content and presentation.
not reading the html markup, but what the markup gets converted to when there is no css involved. Even the earliest of mobile devices can read this web page because the information still makes sense just reading it from top to bottom.
If CSS Zen Garden was truly mixing presentation with content, you wouldn't be able to read that link above as easily as you can.
> The HTML won't make any sense if you start reversing it
?
> If CSS Zen Garden was truly mixing presentation with content, you wouldn't be able to read that link above as easily as you can.
I'm sorry, but using wrapper divs for purely presentational purposes is mixing presentation and content. The whole concept has to do with how the code is written.
>But you started that part of you message with
> The HTML won't make any sense if you start reversing it
>?
I thought what I written was clear, but I guess it's coming off as vague. When you view an html page without presentation the logical flow of all the information should be based on the content. Therefore the tags and what is written you would never reverse the order, because the content will no longer make sense right?
So when you're doing something like
div #header
div #col left
div #col middle
div #col right
div #footer
You've grouped content in the form of header, left, middle right, footer. You can't reverse it, it's stuck because of the way it's been written. Every site redesign will require an HTML redesign each and every time.
If you grouped your content in the form of (like csszengarden has done)
Introduction
About the site
Site Navigation
Sub Menu
Content
Corporate Info
Then ONLY the CSS needs to change. Which is why there are 300+ different and dramatic css layouts on csszengarden, and yet only 1 html. If presentation was truly mixed in there, something would have locked them all into looking a certain way - but as you can see, all the designs are different.
CSS does not demand that the markup be ordered that way. That is entirely a product of the author's choice of layout and his chosen method of generating it, which happens to bring his expectation (that floats work like tables) into conflict with the way that floats are specified to work (that floats work like floats).
You should read my reply to the other guy for a fuller treatment, but here's what I said about this to him, 'perhaps "demand" was hyperbole, but CSS does still push developers to rewrite their HTML when design changes happen.' The cost in flexibility to do it any other way is simply too high. This is sufficiently close to demanding to justify the hyperbole, in my mind.
edit: Furthermore, you speak as if the author is criticizing floats, but he is not. He is criticizing the attitude that tables are to be avoided for layout at all costs, when there simply is not a simple, implemented, cross browser way to replace them. Floats are simple the closest thing we can practically use, so he uses them for comparison.
The author draws a conclusion about CSS in general from an argument that hinges entirely on the use of floats to emulate table-based layout. Ergo, he's criticizing floats for not being tables.
He is criticizing the available subset of CSS of not being tables. As I said, floats are the closest approximation currently on offer. How many times must I repeat it?
Repeat what? Previously you claimed that the author was criticizing an "attitude" and not the way that floats work. Now you're saying he's criticizing the "available subset" which you define as floats.
Repeat the thing I said right before "How many times must I repeat it?" It's not hard to follow. Here's where I said it before:
> Floats are simple the closest thing we can practically use
Furthermore, I did not define the "available subset" as floats. I'm saying that floats are the best available tool in that available subset for implementing table-like behavior. And yeah, they suck for that purpose, but _there is no better alternative_.
If you still don't understand that, then I'm afraid there's no use in continuing this discussion.
Do we really want this kind of bickering around here? There's a time and a place for every technology. Everything has pros and cons. There's no perfect solution. There are lots of good solutions. Sometimes CSS is one and sometimes Tables are one.
Usually tables are used for tabular data. It is helpful for understanding what is on the page. It helps the robots.
CSS knows nothing about the data. It doesn't care what's in whatever it is making pretty and the robots are fine with that.
There's so much work to do. Why do we argue over these silly things. If you can do it with tables, do it with tables. If you can do it with CSS, I'll pay you 5 or maybe 10 dollars more per hour.
Look, for every weakness you can find in the CSS route, I can find a weakness in the tables route. Try doing a fluid design with tables. Show me a search results page that will automatically fill in tiles to fit the users' resolutions. That's hard to do with tables, you have to use JavaScript and it's nuts.
With CSS, just make them float left.
That's why CSS is cool, little things like that. Yes, Tables are easier, they are. No one denies it. Easier does not make it better. Just because CSS has some flaws doesn't mean you shouldn't use it.
CSS is good, it's separation of data and presentation. It's division of labor. It's not bad. It's good.
If you have an application for example and you want to let your users put information anywhere using only one text file and without programming, let them do it with CSS. That makes sense. Tables are hard to make dynamic...
Maybe that's the divide: static vs. dynamic
Static layout with tables, fine. Dynamic layout with tables, not fine.
Look, anyway, why all the animosity toward the CSS'ers? CSS is totally fine. No need to be hatin. It's not a popularity contest, it's a technology that can be used to do things.
It doesn't matter if the logic behind using xhtml+css is flawed: the xhtml+css evangelists have so saturated the development world with their propaganda that I'm worried if I make an educated decision to use html 4.01 or occasional layout tables it will hurt me when potential employers, clients, or even the general webdev community review my code and think I don't know what I'm doing.
I always opt for HTML 4.01 Strict, just because the way XHTML is deployed on most sites is not actually XHTML, due to the mimetype that's being set. It really exists as badly malformed HTML.
Furthermore, I wouldn't say it's propaganda. In a sense it's somewhat like the difference between functional programming and non-functional programming, i.e there's a difference there in the interest of maintainability.
It isn't just propaganda anymore. Pure CSS is what you're going to see in almost every code base you might work on. The last several gigs I've had wouldn't even allow tables for tabular data, which I think is ridiculous.
If I were reviewing your code, I'd give you points for using tables to deal with tabular data. I might not even hold it against you if you used it in a layout, depending on context. Unfortunately the person reviewing your markup will probably expect pure CSS, even if it is data displayed in a table format. Adjust your expectations accordingly.
A related argument against table-based layouts, which I don't see any discussion about yet, is that "it's important to maintain a high ratio of content to markup for SEO purposes."
In my view, a complicated div-based layout is just about as markup-heavy as a table layout, given separate CSS files in both cases. So I would think the point is moot. And my suspicion is it's just SEO firms blowing smoke in an effort to figure out things to sell.
One of my Great Plans For The Future is to write a language that abstracts away HTML, CSS, and (some) JavaScipt. You describe your layout in a format that makes sense, and the compiler will decide whether to use tables, CSS hacks, or whatever.
Ideally, this wouldn't be necessary, but I've never written CSS without the knowledge of the HTML it's going to be applied to, nor have I written HTML without considering how to style it.
I am not being dumb, either. HTML needs all sorts of hooks for styles (classes), since HTML doesn't have any meaningful elements. (Oh boy, I get <p>, <strong>, and lists.) When I have done three-column layouts, my HTML has always needed tweaking -- the content has to be in a certain order (usually left/right/center, which is stupid), and it has needed hacks like <br class="clearfix">.
So clearly we don't live in an ideal world; we are stuck with HTML and CSS the way they are. It is time to abstract away the stupidity like programmers abstract away the computer with high-level languages.
I'll stick with CSS. I've never once had to place CSS items out of order that is a ridiculous statement. There is a place for tables from time to time but once you actually "understand" CSS, life becomes much easier. I think the problem with most people is, they are told to use CSS, but without guidance they might not understand the core and basics.
His argument that you could take expert code and accidentally break it without much effort at all is a pretty sound one. I've designed a lot of stuff in CSS and I'm debating whether it's worth just putting it all in a table and getting it over with.
I'm not sure what to think of your comment, to be honest.
It's not an issue of how CSS was created that would cause the scenario (need to be an expert for CSS) that you indicated, rather it's how CSS ended up being implemented by the various browser vendors.
Please paste an update to the example, that just 'behaves' like the table then?
eg the background goes to the bottom, bad things don't happen depending on size of the content etc.
I've never seen a css example that behaves like a table.
Just out of curiosity... why do you want something that is not a table but behaves exactly like a table? Isn't that what tables are for?
I think starting from the premise that CSS (as it is currently implemented by major vendors) is a super set of tables, and as such, must do everything tables do is misguided. From my experience, the absolute need to use tables doesn't appear in every layout (for me, at least, it's rather rare), and pragmatic CSS developers tend to use tables only as a fallback when CSS / IE / whatever doesn't quite work.
I've seen css examples that can't be done with tables, so I don't know exactly where we are trying to get with this line of reasoning.
I would be more inclined to be sympathetic to the cause of the author, and the ridiculous amount of people who upvoted this (wow, demographics change on HN, pg wasn't kidding) were he/she to show more than a three hour understanding of CSS.
Obviously, when you can produce something like this: http://www.csszengarden.com/, showing how a single html page can be manipulated in an infinite number of ways, it isn't CSS that's lacking, but your knowledge of it.
I'm sorry if this isn't the popular opinion on this board, but as someone that coded tables and then made the transition, I can assure you that css is a much more powerful medium for web page layout, despite its quirks.
The markup on CSS Zen Garden makes use of things like layers of wrapper divs to achieve what it does in terms of design. And this means the HTML is being used for more than just content, which is a direct controversion of CSS's goals. The site is actually a good example of what is wrong with the subset of CSS that is currently practical to use.
Are there any examples in the css Zen Garden which have the really boring layout described in the article? Three columns which have the same height regardless of the height of the content in each column?
If so, I'd love to see how they did it. The best way I know is to fake it using well designed background images. Quite painful to do.
One of the most compelling arguments for css is to use it rearrange the content of your webpage so the most relevant content appears earlier in the data. Apparently this can have a significant effect on your search engine optimization.
One thing that CSS does especially badly that tables do well is correlated sizing. It's easy with tables to make all the elements in a layout row all have the same height. Doing the same in CSS is possible but requires so many hacks that the net result makes you feel dirty.
I've watched this war for years now, and just wish both sides would give some ground. As long as you do your layout with the fewest amount of tables needed (trending toward zero), the you shouldn't need to guilt yourself out about it.
Conceptually, styles and positioning are two different animals. We need a tripartite model of 1) content, 2) styles, and 3) layout/positioning. Unfortunately neither tables nor CSS handle positioning well in all cases, hence the perpetual argument.
Maybe I'm just ignorant, but I've found it necessary to use CSS, tables, & JavaScript (yes, all three) to produce acceptable dynamic layouts for web-based apps. This is unfortunate.
The paradox is that CSS was not meant for precise layout. It was meant to only vaguely suggest a layout. That's why it deliberately excludes the ability to force elements next to each other the way tables can and spread them out evenly. It's not for generating pixel-perfect PDFs. It's for saying, "Hey, put some content here, make it kinda look like this, and if it doesn't fit, let it flow to the next line. No big deal."
Yet the people who are so gung-ho about how it's superior to tables are...get ready: the people who think CSS is for controlling every pixel of a layout. Those people should really be using tables not because they're easier for what they want to do, but instead on principle!
Instead we end up with some horrible, disgusting hybrid. Pixel counters for whom tables work perfectly instead abusing CSS to force a precise layout all the while gloating about how they're doing something noble and difficult and looking down their nose at those who do it the "easy way."
I thing you got that backwards. CSS supports pixel-precise sizing and positioning. However, CSS also supports sizing and positioning based on the properties of the viewport, which adapt better to different screen sizes. Both approaches have advantages and drawbacks.
HTML-tables OTOH does not support pixel-precize positioning, although you can get some of the way if you combine it with transparent gifs, as people used to do before CSS support became widespread.
This whole CSS vs. HTML-Tables discussion is ridiculous. It is not either/or. There are some specific cases where Tables are superior over CSS, but many things can be done with CSS which is impossible to achieve with tables.
The submission shows some examples where tables are needed. However, one could easily show other layouts where HTML-tables would be useless and CSS is necessary. Any serious web developer need to know the limitations of both tools.
BTW. the submission also contains some major misunderstandings:
> when it comes to layout, the design of CSS is fundamentally flawed. Use tables instead
This is blaming the shortcomings of Internet Explorer on the design of CSS. The CSS spec supports exactly the same layout model as HTML-tables, it's just that IE doesnt support this CSS feature.
I'll tip my hat to the author for writing the first well-formed, non-ranting, description of why one should use Tables over CSS (that I've come across), though I'm sure with the amount of these people that are coming out of the woodwork I'm sure I'll end up seeing more...
I still feel the need to disagree with him though. This kind of mentality is counter-productive to the web moving forward - CSS can be a bit more difficult at points, yes, but 90% of the issues that are generally encountered with it stem from IE's horrific rendering engine. We've finally gotten to a point where IE's market share is declining, and with that CSS based development will only get easier.
On one last note, CSS is being adopted in more places than just the web - for instance, there's various projects attempting to integrate CSS into the GTK setup. If CSS was really that bad and unusable, do you think it'd be getting any further adoption at all?
I guess the way I'm looking at it is that this argument has already happened. CSS doesn't necessarily need to be improved, rather the browser situation does, which is certainly not helping CSS to look better in comparison to Tables.
CSS3 (and CSS 2.1, which is still not fully supported in some cases) have various properties for forcing display models, but the caveat always ends up to be IE6/7.
Though to be fair, I guess you're right, this argument is rather essential to the web moving forward, I just have to wonder if this is really the argument worth having.
I find his choice of "typical" CSS layout to be misleading, when neither his site (which uses CSS, naturally), his blog (CSS), any of the pages he links to (CSS), or this site (tables) use such a layout.
Yes, he chose it to illustrate his point, but that point doesn't connect to the trollish overstatement of the title. It is evident that person can use CSS for other layouts (even using floats) without ever encountering the problems he describes. The real conclusion here is that CSS is hard or even impossible for some desired layouts--something just as true with tables. I doubt that that's news to anybody.
The auto-expanding equal height three column layout is such a standard layout on the web, and ways to do it are so often requested that it is referred to as the "holy grail" by the CSS community. So I find your critique and accusation of trolling to be rather misplaced.
I did not say it was uncommon, I said his choice was misleading. It's a trick: it allows him to demonstrate a problem with one kind of layout using floats (which by definition do not behave like tables) but then claim it is generally applicable to all layouts and CSS in general. It is not.
I stand by my statement that his title is a "trollish overstatement". It was chosen for the sake of continuing argument, not reflecting the content, educating, or informing.
You said it was misleading that he implied it was "typical", which is a synonym for "common". You can take issue with his conclusions, but illustrating your thesis with a common case can in no way be construed as a trick.
You're missing the point. Yes, it's a common case in that it occurs frequently, but it is not a typical case in that it is characteristic of the whole set.
That is my problem with it, as stated for the third time. His conclusion reaches far beyond what his carefully selected evidence supports.
And for the second time, "common" and "typical" are synonyms. Furthermore, there is no one case that is "characteristic of the whole set". Apparently, in order to satisfy you, a blog post (!) must cover every type of layout. Awfully demanding, aren't you?
> And for the second time, "common" and "typical" are synonyms.
That two words can be synonyms does not mean they have only one shared meaning. In context, a thing can sometimes be one but not the other, e.g. A dictionary is a common type of book, but it is not typical of books to consist of lists of definitions set in very small type on very thin pages.
I don't understand why you're insisting on interpreting the word as "common" as I have already stated that that was not my meaning and in the context of the article (in which the author uses a single example to reflect badly on the whole) it's likely not that of the author's.
> Furthermore, there is no one case that is "characteristic of the whole set".
My point. I disagree with the author's attempt to depict this case as characteristic of the whole set of CSS layouts.
> Apparently, in order to satisfy you, a blog post (!) must cover every type of layout.
Hardly. I only wish for the author to restrict his conclusion to one that is supported by his example.
tables are good, except when it comes to a point when you have to start nesting tables within each other to format your your layout.
explanation is below:
---------------------------
people who love tables would switch over to CSS if it did what everyone(and standards) makes it out to be and actually worked and/or rendered the same in ALL browsers (css hacks don't count as css)
but no matter what you say about CSS....(and i'm all for CSS) ...CSS can't solve all design issues...and if it can...it takes way to long to figure out... and if only a 10 year veteran/css master can implement flawless layouts then CSS isn't a practical language.
in theory is CSS is awesome!
i use tables for tables (tabular data)
and i use CSS to layouts and comesic design.
think about it...if CSS rendered the same way in every browser abiding by CSS standards ...even developers who are pro tables...would switch over.
the reason why there is such conflict between tables and CSS is because many of people have tried CSS countless number of times and hours trying to make their template/layout work...however they've came across so many road blocks ...they give up.
i'm not saying tables are the ultimate design language...and i think people agree....they just use it because it works. in ALL browers!
but me say ONE LAST THING!
its not CSS the language that is problem....is the number of browsers that choose not to render CSS properly.
I still don't get this debate. Before, it definitely used to be easier to just use tables, but now there are so many examples and frameworks out there that I never spend more than 20 minutes or so with CSS, even on very complex layouts. What am I missing?
This is going to sound totally flippant, but I think it's always worth considering sources... let's take a look at the author's site, and reflect on how we feel about taking front-end design advice from this person.
I agree, so I read a bit further after looking at the page (which is, conceded, not exactly a high point in design), here is an interesting bit of information about the author:
Even if they weren't, it's trivially easy to center it with CSS, or attributes. In the td tag, align="center", or in CSS text-align: center;
Another pet peeve of mine with any CSS layout is that vertical alignment is a huge pain. With tables, you can use valign="top" in the td, or via CSS, vertical-align: top.
I think it's pretty obvious that often tables are better and more intuitive to use for layout than CSS. The problem is that we've been told for so long that tables for layout are bad that it makes one feel kind of dirty using them.
Web page layout should be simple it shouldn't require months/years of experience to work around CSS limitations and browser quirks to get some text and pretty pictures to display right.
Sometimes I spend (waste) hours working on a CSS layout because it makes me feel clever, but lately I've been shrugging my shoulders, going the easier route, sending an invoice and moving on :)
What rubbish are you reading? Tables vs css make zero difference. never has, likely never will, for all the obvious reasons (why bother? What difference does it make to users etc).
The whole point of the argument is to show that if you change the order with the CSS version, things move around. Then he goes on to show a static table. What the article really proves is that tables are not better than CSS. And CSS can do millions of things that tables can't (I'm not trying to start a troll on that topic). So I'll stick with CSS, thanks.
There is one valid point in the argument: improving CSS so that you can position elements in relation to each other by name would help. So I could say that the DIV element called "left" should be on the left of the "center" element. Right now, relative order is based on the order in the HTML source.