Everything shifts to the left - or How I Learned To Love CSS

[Vera]

I'm not trying to start the table vs div discussion. But I just don't see why we (including myself) try to limit our selfs to the things that css cannot do but html could have. And the only reason we do this is because of "semantics". The table tag is called table and was originally designed for table data; hence we can not use it for none tabular contents. But a one-row-three-column table does not have the readability disadvantage often mentioned (it reads the same as three divs wrapped in a div container, except then wrapped in table, tbody and tr), it gives you greater background control (plus contents never get outside of the content area), its css is easier and column width can sometimes be self regulating, its cells never break to the next line and if Id think about it I'll probably find out more. In fact, you call the content area's left, main and right column which to me sounds like a table that has rows and columns. So if for main content use (1 to x columns in a single row only). I do agree the website should not be one big table or whatever people (and myself) made almost 10 years ago. It has been that long since my last full table-for-layout website and I like it that way, but it has been only 4 months since the last time I used a table for the main content area's columns for a 7 browser consistent layout that would have been very unstable as div+css

Regarding fluid design: I do not like that a website text does not show up the same on everybody's browser. I like that a client can add text, like the way it looks on his screen, perhaps shift some word over to the next line so everything looks even nicer (both the content and the visual of the text). And then everybody else will see it the same way. (Except for IE6 and Safari on a Mac, because they just don't get the fonts the way other browsers do...)

OR is it just me who sees the use of tables and fluid widths this way

[Medianomaly]

Vera,

My opinion -> I think I completely agree with you on both things.

I'm far from a CSS purist, and I do miss tables sometimes. I think we are at a point now where there's a whole new generation of developers that came after the era of the table, and they blindly follow this "tables are evil" thing without really understanding what you just said. Plus it's almost become this "certification" for what we do, meaning in many people's minds (including even some clients now), you don't know what you're doing unless you don't use tables.

All the arguments for CSS-only layouts sound great if we lived in an "ideal" world, but if you look at most of them in a practical, real-world context, most don't hold much water -- they just sound nice.

Second point -> I don't remember the last time I did a fluid layout myself either -- I prefer fixed too. But I've seen differing opinions, and for certain types of sites it's been used very effectively.

[tomchadwin]

In the spirit of interesting debate...

I couldn't disagree more. I agree that there are few advantages to CSS-based layouts which rely on many non-semantic elements (<div class="clearing"></div> is a particular irritation). However, it is possible to eliminate this. It's not easy, I agree, but it is possible.

I don't think the key argument is the semantic meaning of table, as opposed to the neutral div. I think it is the markup bloat associated with tables. Having all these extra table and tr tags, not to mention thead and tbody (which, even if you don't use them explicitly, the rendering engine of browsers inserts) makes code extremely difficult to read, and inefficiently bloated.

The other key argument is multiple stylesheets. If you use tables, especially with cell spans, you will find it very difficult to hide navigation in print versions. The best way to allow alternative browsing technology to get at your site's content is to use CSS. End users with vision problems can then specify their own CSS (high-contrast, large type, etc).

There is also the search engine issue. One criterion used by search engines which determines how a page is ranked against a search phrase is the ratio of the phrase to the page content. The less markup you have, the greater this percentage.

As for fixed versus fluid layouts, I've always been a fan of elastic layouts, where the em is the prevailing unit. This allows you to fix the width, but text line length remains constant as text is resized by browser controls, and the layout doesn't break. This is less of an issue these days, though, since IE (v7, I think) made its default zoom behaviour a full zoom, not a text size shift.

So, it's not massively easy, no, though I can assure you that is does get easier. But it's worth the effort.

My tuppence...

Cheers

Tom

[Medianomaly]

Touche Tom, I will play ball...

I don't think the key argument is the semantic meaning of table, as opposed to the neutral div. I think it is the markup bloat associated with tables. Having all these extra table and tr tags, not to mention thead and tbody (which, even if you don't use them explicitly, the rendering engine of browsers inserts) makes code extremely difficult to read, and inefficiently bloated.

The difference between this:

Code: Select all

<table class="someWrapper">
<tr>
<td class="someColumn"></td>
<td class="someOtherColumn"></td>
</tr>
</table>


...And this:

Code: Select all

<div class="someWrapper">
<div class="someColumn"></div>
<div class="someOtherColumn"></div>
</div>


Is minimal. And I've heard the "yeah but multiply that by 1000 pages" argument many times, but in a real-world setting I'm not really convinced about those 6 extra characters. (HTML files are compressed anyway, so the bandwidth savings are not 1-1). And in return for those two extra tiny <tr> tags, in many instances you would buy yourself at least a little bit of convenience and simplicity when you develop.

The other key argument is multiple stylesheets. If you use tables, especially with cell spans, you will find it very difficult to hide navigation in print versions. The best way to allow alternative browsing technology to get at your site's content is to use CSS. End users with vision problems can then specify their own CSS (high-contrast, large type, etc).

I think you are assuming we are talking about the "one-hulking-table-shell-that-surrounds-everything" approach. When I coded with tables, I didn't really do that. I stacked simpler, individual tables, one after the other when I needed columns, and still used div's when I did not. So something like a horizontal navigation menu would have had its own table, and that table could easily be hidden with a print stylesheet like any other element.

I'm glad you brought up menus -- the great thing about a table for a horizontal menu was you could automatically space out the items equally without extra CSS declarations (like hard coding padding in pixels, or specifying widths as percentages -- both of which require CSS changes when new items are added).

There is also the search engine issue. One criterion used by search engines which determines how a page is ranked against a search phrase is the ratio of the phrase to the page content. The less markup you have, the greater this percentage.

I will defer to argument #1 on this (the amount of code weight that is actually added).

As for fixed versus fluid layouts, I've always been a fan of elastic layouts, where the em is the prevailing unit. This allows you to fix the width, but text line length remains constant as text is resized by browser controls, and the layout doesn't break. This is less of an issue these days, though, since IE (v7, I think) made its default zoom behaviour a full zoom, not a text size shift.

I quoted this not to comment on the fixed/fluid issue (which I think is a largely personal preference -- with some specific exceptions). But you have to admit -- how much easier is it to make a layout with a mix of fixed and fluid columns if you still used tables? You don't want to admit, but deep down you know it's true.

Yeah, so suck on that, Tom!!!

[Vera]

First off; this is off topic. Shouldn't we start a discussion elsewhere? I'm sure a part of this forum will suit us.

Tom, did you ever notice that many people (and even TL by default) place the right column content in front of the main column in their HTML? How does that work for screen readers? If you are really concerned about those screen reader people you'd agree that CSS might force you to do illogical things to get what you want. Placing the content in the wrong order is even worse then adding an extra element if you ask me.

CSS was initially never intended to be doing all of the things we do today; so by definition not the best method for everything. It has problems with the vertical.

The way I used tables and frames in my first few websites are absolutely good examples of how things should not be done. But hey, I didn't know any better, nor did anybody else in those days A guy from school who used javascript to do some browser detection and frame content reloading was my website god and guru; he seemed to know the inner workings of the beast, how else did he know how to do those things... I did keep a copy of his website, to learn from. I just looked at it, and now I can only learn from it how not to build websites.

I'm currently building a website that is supposed to show off what I can do in terms of a professional looking site and I floated everything and it looks spot on in every browser (table-less), The content reads in the html left-to-right, top-to-bottom. It is more or less a good example of how things should be. But because the client wanted a newspaper style column layout for part of the site I added tiny templates that do nothing but inserting one row and x column tables. Initially I made the templates with div, floated them and gave them a border in basic.css so they would show in a more intuitive way in tinyMCE. Client came to look at the progress and asked what 4 columns looked like on that page... I could insert a new column using some smart copy and paste actions and show him, but the client would probably not want to learn how to do that and forget because that action is not very frequent. If you have some content in the columns you will not feel very happy to having to copy this and paste back in one by one. Changing this to tables means he can use tinyMCE to just add or remove columns easily. A thing that CSS alone will not be able to do.

The faux columns technique (like the before mentioned perfect fluid layout uses) is the best argument to prove you'd sometimes be better off using tables. The technique is simulating a column, to fix a problem with css.

Finally I'd like to just mention I do not have any trouble using any css technique. It took some time to learn and gain experience. But I do not use tables because I know of no other way to solve the problem. Sometimes tables are the logical choice: robust, greater vertical control of columns and they still need to be fully styled using CSS. I might actually save a few byte in the CSS

[ramjet]

Its great reading all this stuff... I can't really contribute as I know very little, but I like reading the different points of view and techniques used.
I used to do quite a lot of "art" when I was younger, and I took a real shine to Flash when it was relatively new and mainly a graphics tool. The thing I loved about it was/is that things stay where you put them. I know it took a lot of flack (yes, I used to make Flash Only websites - one big flash file embedded full size in the browser.... it scaled up, it scaled down, you could download the whole website!!!) but what a lovely thing it was to use.

Anyway I think this is my resistance to learning CSS... I really get annoyed trying to track down little bits and pieces, and then find that in changing them something else is now half-invisible six feet from where it was. I didn't like paper and-glue stuff as a kid, or cutouts or jigsaws ... this probly explains it.
The price of being a novice really. So all discussion good, wherever it takes place.

Oh and I've taken the 960 pix and fixed layout advice initially anyway. I think a technically correct base is always a good starting point to go obscure from.

Any opinions on floating appreciated ... I don't understand it.
May as well stay here Vera if anyones keen to keep going (its like shifting pubs when you've just settled in!!)
I've edited the topic.

[tomchadwin]

OK, you've convinced me... Only joking, and I'll do my best to respond, but I can guarantee that I won't have arguments against many of your excellent points.

The difference between this:

[snip]

...And this:

[snip]

Is minimal. And I've heard the "yeah but multiply that by 1000 pages" argument many times, but in a real-world setting I'm not really convinced about those 6 extra characters.

I'm not talking about character count, or download size. I am presuming that all fully-featured search engines parse the HTML to rank a page. The relative density of different DOM elements is what counts.

I think you are assuming we are talking about the "one-hulking-table-shell-that-surrounds-everything" approach. When I coded with tables, I didn't really do that. I stacked simpler, individual tables, one after the other when I needed columns, and still used div's when I did not.

I just don't underdstand the objection: columns can be achieved using non-tabular HTML and CSS, so why revert to tables for this specific layout requirement?

the great thing about a table for a horizontal menu was you could automatically space out the items equally without extra CSS declarations (like hard coding padding in pixels, or specifying widths as percentages -- both of which require CSS changes when new items are added).

I would strongly argue that you have to check manually every time you add an item to a horizontal menu because it might have layout issues. Yes, the layout issues in the CSS UL approach are different to those in the table approach. There's a limited amount of horizontal space. I'd always want to check.

But you have to admit -- how much easier is it to make a layout with a mix of fixed and fluid columns if you still used tables? You don't want to admit, but deep down you know it's true.

I really don't. I think of layouts like scholar's margins, which I adopted to use for images, and that would be impossible to achieve sensibly with tables. What is seen as an irritation with CSS - floats coming out of the flow, and hence not being contained by their parent - becomes a useful feature unavailable in tabular HTML. I've not come across a design which it has not been possible to implement with non-tabular HTML and CSS, and I have come across plenty of layouts not possible with non-CSS tabular HTML.

did you ever notice that many people (and even TL by default) place the right column content in front of the main column in their HTML

Sure. Just because many people don't code correctly using a technique does not invalidate the technique, surely? If it did, then tag-soup tabular HTML layouts would be a clinching argument against that approach.

Initially I made the templates with div, floated them and gave them a border in basic.css so they would show in a more intuitive way in tinyMCE. Client came to look at the progress and asked what 4 columns looked like on that page... I could insert a new column using some smart copy and paste actions and show him, but the client would probably not want to learn how to do that and forget because that action is not very frequent.[...] Changing this to tables means he can use tinyMCE to just add or remove columns easily. A thing that CSS alone will not be able to do.

Is this a criticism of CSS-based columns because of how they need to be inplemented in tinyMCE? Again, to me that means that there is a problem with tinyMCE, not a problem with CSS. Forgive me if I am misinterpreting your point - always tricky to visualize these things from a textual description.

The faux columns technique (like the before mentioned perfect fluid layout uses) is the best argument to prove you'd sometimes be better off using tables. The technique is simulating a column, to fix a problem with css.

So is using a table in HTML! It is simulating a column using a table, to work around a limitation of HTML. A limitation which has good reasons for being there. Caveat: I'm not an adherent of the faux columns approach either, so I'm not an apologist for it, as it fixes some column widths in pixels, the last time I looked at it, so it wasn't compatible with elastic layouts.

Perhaps I'm being too idealistic, but to me, the concept that HTML (which, let's remember, is not a new idea, as anyone who has waded through SGML will know) provides only sematic information is such a powerful one. Keep your content in this semantic form, never repurpose it at that source level, but use CSS to present it across multiple channels. OK, so perhaps CSS implementation in user agents is not advanced enough to make this process as painless as it should be (how long has the :hover pseudoclass been an IE issue?), but it has got a lot better in the past few years.

Back atcha!

T

[Vera]

It is not that I disagree with you, you are mostly right. I originally meant to say that using tables for layout purposes sometimes just makes sense, even more sense then divs and css. I do agree though with your last point; html should contain semantic information only. From that point of view tables are definitely wrong. They are however not simulating columns, they consist of columns (and rows) by definition. So even though they are strictly speaking used wrongly in HTML, they do have some logical meaning. Columns can not always be achieved using css as they can be with tables in very specific cases, that is why they thought of faux columns which is a rigid workaround. These are also the only times I use a table.

Is this a criticism of CSS-based columns because of how they need to be inplemented in tinyMCE? Again, to me that means that there is a problem with tinyMCE, not a problem with CSS. Forgive me if I am misinterpreting your point - always tricky to visualize these things from a textual description.

This was just to demonstrate I sometimes make choices that are not the purest approach, but that tables for the client gives some advantages. tinyMCE can never provide a proper solution. I tried to provide one, but as soon as it needs changing then that gives some problems which might be extremely hard to ever sell to a client. I still need to make some money Clients that find maintaining the website too hard will be less enthusiastic, I can never explain to them why they cannot use tables...

Sure. Just because many people don't code correctly using a technique does not invalidate the technique, surely? If it did, then tag-soup tabular HTML layouts would be a clinching argument against that approach

You are right. But again, we are NOT talking about tag-soup tablular HTML layouts. Only 1 table, 1 row.

I'm not talking about character count, or download size. I am presuming that all fully-featured search engines parse the HTML to rank a page. The relative density of different DOM elements is what counts.

Doesn't that come down to the same thing? How many elements there are... Anyway, can you show anything that sort of proves to me google does this? For as far as I know they nowadays index what people can see, not sure if they can say how good the actual content is based on the person who build the website...

I really don't. I think of layouts like scholar's margins, which I adopted to use for images, and that would be impossible to achieve sensibly with tables.

What does scholar's margins mean exactly?

What is seen as an irritation with CSS - floats coming out of the flow, and hence not being contained by their parent - becomes a useful feature unavailable in tabular HTML. I've not come across a design which it has not been possible to implement with non-tabular HTML and CSS, and I have come across plenty of layouts not possible with non-CSS tabular HTML.

Again, I build up websites as layers on top of eachother, no tables, no several image slices making up part of the layout. Using tables for the entire layout is completely unusable. (I actually did that today for a newsletter template because the different email clients do not process css properly. And it is hardly readable, let alone changing any part)

All being said I think we do not disagree at all except for what a table consists of, and its advantage in 1 single specific type of application.

[Medianomaly]

Just to follow up what Vera said (and then I think I'm tapped on the subject)...

It goes back to what I said originally. Most of your points are valid and make perfect sense. And look, it's been a few years since I've used a table for layout. And I try to follow best practices -- keep things semantic, properly structure it, validate it strict, blah blah blah. And when pressed I can spout all the pro-CSS arguments along with everyone else. So really we're (all) in the same boat here. It's just a matter of to what degree we get high off our own supply, so-to-speak.

I'm just saying there's a big difference between all of the idealism we've all learned about why CSS rules and tables suck, and what actually matters in a practical, real-world setting. There's what matters to purists and bloggers and CSS galleries and fellow designers, and then there's what actually makes your clients happy and makes them more money.

And although the landscape may change in another 5-10 years, for today's Web (and the Web we've had since '05 or so when this craze all started), when we consider the latter (which when you get down to it is our sole job), a lot of this stuff is WAAAAYYYY overblown. Not all of it -- but definitely a majority of it.

[Medianomaly]

OK -- one more, because I don't want to disregard your points -- all technically true and valid (and thanks Vera for your counterpoints as well).

I'm not talking about character count, or download size. I am presuming that all fully-featured search engines parse the HTML to rank a page. The relative density of different DOM elements is what counts.

If the difference between the two blocks of code make any difference in SEO rankings, I stand corrected. But in practice I have not found that to be the case.

I just don't underdstand the objection: columns can be achieved using non-tabular HTML and CSS, so why revert to tables for this specific layout requirement?

Because before I learned the ins and outs of browser bugs (IE), and learned how to avoid them when I code off the bat, it was tons simpler to use tabular columns -- I got things done that looked right in all browsers in a fraction of the time.

I would strongly argue that you have to check manually every time you add an item to a horizontal menu because it might have layout issues. Yes, the layout issues in the CSS UL approach are different to those in the table approach. There's a limited amount of horizontal space. I'd always want to check.

Check -- yes, you are absolutely correct. Know as a given you'd have to dig into your CSS each and every time a change was made -- no.

I really don't. I think of layouts like scholar's margins, which I adopted to use for images, and that would be impossible to achieve sensibly with tables. What is seen as an irritation with CSS - floats coming out of the flow, and hence not being contained by their parent - becomes a useful feature unavailable in tabular HTML. I've not come across a design which it has not been possible to implement with non-tabular HTML and CSS, and I have come across plenty of layouts not possible with non-CSS tabular HTML.

If you tell a non-expert to make a site with a 200px fixed left column, a 200px fixed right column, and a fluid center column with CSS, it would give them absolute fits. It's trivial with tables. And again, in my opinion the benefits of all that back-breaking work doing the former are minimal if at all in a real-world setting.

Your point that there are things you can do in CSS that you can't with tables is absolutely true, but I'm not sure it's relevant to this specific point I was making (plus it goes both ways).