Why CSS should not be used for layout
flownet.com
flownet.com
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.
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.
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.
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.
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 ;)
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.
What would you suggest is better suited to layouts than CSS?
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.
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.
However I'll agree with your assessment about coders being too lazy to learn proper HTML. ducks
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.
Sounds a bit like an ad hominem attack to me
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>
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);
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.
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.
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.
Second, http://giveupandusetables.com/ for practicality.
If you're reading the page's source, you'll also find this eternal wisdom: "Fact: Chuck Norris hates layout tables!"
Why do I still laugh every time I see one of these? I always see it coming...
Second, http://www.nyt.com << reminder of why CSS grids are so beautiful
Then... a table on my site because I can't stand making two-column equal-height float hacks work anymore.
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.
So it doesn't work for the majority of browsers, yea, that's a technique I really want to count on.
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.
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.
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.
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.
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.
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.
Now if only 100% of people had JS turned on things would be peachy :)
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.
www.csszengarden.com
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.
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.
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.
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.
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.
When I view source csszengarden this is what I see: <div id="intro"> <div id="pageHeader"> <h1> <h2><acronym>
<div id="quickSummary">
<p class="p1"><acronym>
<p class="p2">
<div id="premable">
<h3>
<p class="p1">
<p class="p2">
<p class="p3">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.
I think it's great.
> 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.
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 meant this by reading http://www.csszengarden.com/zengarden-sample.html
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.
But you started that part of you message with
> 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.
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.
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.
I don't understand what you're disagreeing with.
> 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.
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.
Does anyone else feel that way?
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.
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.
So, is this at all a substantiative claim?
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.
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.
I've never seen a css example that behaves like a table.
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.
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.
> wow, demographics change on HN, pg wasn't kidding
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.
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.
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.
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."
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 article explanin the concrete cases where you should use tables: http://olav.dk/articles/tables.html
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 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?
Until CSS is improved, tables will never go away.
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.
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.
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.
That is my problem with it, as stated for the third time. His conclusion reaches far beyond what his carefully selected evidence supports.
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.
In a perfect world, CSS is awesome.
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.
With the CSS, Top Center Bottom are all centered, but with the tables, they're not.
Edit: am I wrong? Why am I being downvoted? I'm on Mac OS X 10.5 Safari 3.2.1
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.
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 :)
Also there are tons of CSS frameworks which do enforce layout semantics, possibly even better than tables ever could.
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).