Apparently you can remake your HTML code and use a combination of CSS definitions and li tags. What is the great advantage of this, besides having to rewrite all your code and it not working on older browsers?
Several reasons:
Because of new rules on disabled accessability, websites need to be viewed by non-standard browsers like screen readers. These don’t handle tables well. Using CSS and HTML means the page content displays as a text stream when the CSS is removed which braille and voice readers can interpret more legibly.
From the developer’s point of view, by seperating the content from the display code you can change your website’s look and feel more easily across the entire site. You can also serve different CSS for different browsers, optimising the site for each browser without having to create alternate pages with the same content or use a CMS or Server-side technology.
The W3C’s take on it: http://www.w3.org/Style/CSS/Buttons/
BTW, I’m not sure why you would use Li tags - Usually Div and Span tags are a better way to apply CSS.
Tables are still fine for displaying tabular data, of course. Just don’t use them for layout.
Here is what my Web site looks like, using HTML and CSS.
And here is what it looks like if I disable the CSS.
The only difference between the two is the CSS - the second page has none. The HTML is identical.
Like tirial said, a screen reader can handle that a lot better than if the content was all stuck into table cells. And what friedo said: tables were never intended as a page layout tool.
Ooops …
No offence, but better disabled accessability seems to be a pretty marginal advantage for the fairly big work and mental reorientation that goes into new layout – especially if it’s a site heavy on graphic material that makes little sense for screen readers. Don’t see why the onerous should be on the existing web developers anyway. Surely screen readers can be programmed better to better handle tables.
Separating content and display makes more sense. But if you use tables, you’re probably already using stylesheets to control the tables. How’s that different from using stylesheets to control Div and Span tags?
Try switching a sidebar from the left to the right when you’re using tables for layout without making significant changes to the HTML.
I read an article a while back where the author tested a half-dozen different layouts with the same text to see which ranked highest in Google. The pure CSS-based layout came in the highest. The author believed it was because it had the greatest ratio of text to markup.
Of course, Google is a text only sceen reader, the equivalent of a disabled person reading your website.
But it’s a very important reader!
If you want your website to be found via Google, you need to design it so that it works well on text-only browsers. This is especially critical on commercial websites, which usually get most of their customers via google.
A commercial website designed as Rune suggested, “heavy on graphic material” and
treating Google & other screen readers as “marginal” will soon go bankrupt.
It’s up to you! It all depends on what kind of website you’re working on and who you’re trying to please. If it’s a personal homepage that only your friends see, nobody is going to give a damn whether you use WebNazi-Compliant Ultra-XTXHTML 7.2 or some half-assed mishmash from the early 90s. On the other hand, if you’re working on a corporate or ecommerce site, compatibility (with browsers or standards) and ease of maintenance may be higher priorities on your list. And Accessibility may be a legal requirement.
CSS can be a pain to set up the first time around, but it makes subsequent edits much easier and it also makes it easier to transform the same page content to different forms of media (PC, print, PDAs, cell phones, whatever).
I think the biggest advantages is the ability to style multiple pages at once – change one style sheet and 1, 10, or 10,000 HTML pages will instantly look different. You can’t do that with regular, non-CSS HTML unless you have some sort of server-side templating solution set up.
Tables and stylesheets aren’t mutually exclusive. If you want to arrange something in a tabular format, you can continue to use tables and style them appropriately. But not all data needs to be in a tabular format, and in these cases, DIV and SPAN act as generic markup tags: Their real purpose is to let you assign CSS IDs and classes – which perform the real magic – to arbritrary sections of text without affecting the way they look until you’re ready.
For example, you can mark up different sections of text using <span class=“veryimportant”>. At first, you may want this “veryimportant” text to be bold. But a few weeks later, you decide that bolding doesn’t capture enough attention… and with one edit in your stylesheet, all the “veryimportant” in your 10,000 pages can instantly become bold, red, and a larger font size. Then you realize that some of your visitors are printing your pages out and they’re complaining that the big red text looks ugly on paper. You edit the stylesheet again and add a special rule for printing: All “veryimportant” text will print as regular-color, non-bold, italicized text; the web version, on the other hand, will continue to look exactly the same.
Oops, you obviously knew this already. I meant that tables and DIV/SPAN tags aren’t mutually exclusive.
Well search engine optimization is an arcane art. If you have three self-declared seo-experts in one room, you have four opinions on what works. I have heard that CSS organised pages were better for Google because of the way they structured the data. On the other hand, SDMB, Amazon, MySpace, all linked to from phase42’s site, seem to be doing fairly well with a table layout. Barebone which he also link to and which use a CSS approach, doesn’t even show up on Google’s first few pages when you search for “editor”. On the other hand, of those that do show up, the first five I looked at were designed with a tables. Of course that could all be because of the hundred other things that also go into a google ranking.
Phase42’s page does indeed look very good, and manage to keep a fairly consistent look across a number of different browsers. However it’s also a simple site, and even so it requires a number CSS hacks and work-arounds for it to work. I suppose if you try to create a more complex site, it’ll require an even larger number of “hacks”. Apparently a number of those CSS hacks are going to fail with the upcoming IE7 browser. And the code looks a lot more complex, making for higher probability of errors. Easy code is also easier to manage.
But it seems that compatibility is the second (after the added complexity) worst problem with CSS structured sites. It already requires a number of hacks and work-arounds to work. Something that doesn’t seem to get any better in the future. MS says it won’t adhere to the CSS standard in their upcoming browser, which it considers flawed. And probably a number of the old CSS hacks won’t work in IE7. So it seems it requires more maintenance than using a table approach.
No. But you can just as easy do it with CSS on TABLEs as you can with CSS on DIV and LI/UL tags.
This is pretty much how I’ve been coding HTML. Just using TABLE with CSS classes instead of DIV/SPAN and LI/UL tags. I agree that using DIV and SPAN tags probably makes more intuitively sense than TABLES. On the other hand, I don’t see why using list tags like LI and UL, as Apple and BareBones do, should be more natural than tables. The design is no more a list than a table.
Somebody wants me to redo his site featuring artistic pictures of scantly clad but very pretty girls into an exclusive CSS format. There’s probably not going to be much money in it, so I’m looking for a good reason to take on this work and to go through all the learning of the finer details of CSS (as opposed to the fairly simple CSS I’ve been dabbling in, that is required to just set font and colours and such). I don’t think accessible for sight impaired is of very high priority for a site which peddles images of nude girls. Of course, being honest I don’t need a very good reason to do this and I’m going to do it regardless. But I was thinking that perhaps I should go the extra mile and apply the techniques to the other sites I’m using.
Not a reason for eliminating tables: You just have to design them so that they’re read sequentially. Most text browsers read top to bottom, left to right, so if your table makes sense that way, it can be read by disabled users perfectly well.
Similarly, using a table to contain a graphic can be set up so that it has no issues with text browsers/screen readers.
My complainit with CSS-styled sites is that they don’t resize well. I don’t use standard fonts, I don’t use standard window sizes and I often see stuff mispositioned all over the place.
Also, I block most of their ads, meaning the graphics are much smaller than their absolute positioning expects.
Result: a mumble-jumble of stuff on top of stuff. Link bars on top of content, icons on top of link bars.
Had they used tables for layout I’d see an organized outcome with no overlapping. Sure, it wouldn’t look like the designer intended, but the critical baseline concept of HTML is (was?) that the browser/user ultimately controls how it looks, NOT the web designer.
Now if css has robust relative positioning, then things would work OK. But it doesn’t, and won’t any time soon.
Oh yes, sorry. I didn’t mean to suggest that CSS is more compatible. Hacks are definitely required in some cases, and unfortunately, I think the problem gets compounded when you use tables in conjunction with CSS. The browsers are pretty liberal about CSS interpretation to begin with and they screw up even more once you start styling tables. So yes, compatibility is going to suffer.
In terms of maintenance, however, the main pluses of CSS are separating content from layout (as much as possible) and being able to style more than one page at a time. Whether you use tables or DIV tags isn’t terribly important… why not just use whichever one is more appropriate for a given situation? If the content fits in a table, use a table; if it’s a list, use a list; otherwise, use one of the generic spans or divs.
One problem with using tables for layout is that the cells are hard to rearrange and update if you ever want to change your layout. You’d have to untangle a whole nest of TRs and TDs or hope that your WYSIWYG editor can do the job well. Then you have to propagate that change to all your pages somehow… a find & replace might work if all of them use the same code block, but otherwise it could be a real nightmare. On the other hand, if you just have a couple of floating div layers, you could edit a few numbers in your stylesheet and all your pages will immediately use the new layout.
I dunno why they did that.
It’s totally up to you. Good luck if you choose to try it.
Another solution you might want to consider is some sort of server-side templating… you could use a content management system, a database of some sort in conjunction with PHP/Perl, or even something as simple as server-side includes. That way you can maintain a table-based layout and still have some degree of maintainability.
Most of us who design with tables set them up so that they are easy to edit and rearrange; sidebar on the left needs to go on the right? Just snip the sidebar cell out of there and put it on the other side of the main cell. That’s why nested tables are used, even though you could theoretically do a very complex site in only one table, with lots of colspans and rowspans. And with PHP and asp includes, you can change a single file (sidebar.php) and have changes throughout the whole site.
My reason for using tables is pretty much just a distrust of CSS’s future compatability, dislike of absolute positioning, and a certain amount of unfamiliarity with CSS. I do use a lot of CSS now and try to keep the “look” in the CSS, but for basic structure I still prefer tables. The trend does seem to be for all-CSS pages, though.
So once again, the 800-pound gorilla is blowing off standards, knowing that most designers are going to scramble to make their sites work in IE, and maybe work in other browsers.
It will be funny if this bites MS in the butt when people visit their favorite sites with IE7 and nothing works right, and they all switch to Firefox.
One thing I haven’t seen mentioned yet, which may at least partially apply, is the problem with nested tables. On some pages you can find you suddenly have tables inside of tables inside of tables inside of tables… and it can take longer to process and display those pages in the browser than it would if they were done CSS. At least this is my understanding…
To me, it’s part of a larger move to get presentation details out of the HTML. Tables make a lot of sense for displaying grids of information. However, when you use them for layout, they tend to overwhelm the rest of your source code and make it look more like a programming language than marked-up content. (Also, in many cases, they are much less flexible than the equivalent CSS.)
Much better to use as few tags as possible and put the design details in your CSS. Then…
[ul]
[li]when you’re looking to update the site design, you work with the CSS[/li][li]when you’re looking to update the content, you work with the HTML[/li][li]you never have to wade through one to get to the other[/li][/ul]
In the world of dynamic web applications, this is even more important, because it’s common for different groups of people to be responsible for generating the HTML on the fly vs. styling it with CSS.