Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

eclipse

macrumors 6502a
Original poster
Nov 18, 2005
989
14
Sydney
From the wiki

As of 2006, CSS layout capabilities improved considerably. However, many popular browsers have limited or buggy support for these newer features of CSS, which has slowed the adoption of tableless web design. Many websites still use CSS for text formatting only, while using tables for layout.

Is this still the case?
 
Browsers are getting better, even IE7 made improvements. Unfortunately there's a whole lot of people still using IE6, which means you still have to design for the older browsers. Though I don't even support IE < 8 at my site anymore. I'm a rebel :cool: We'll see if IE8 is all they promise, but I won't be holding my breath.

Seriously though, there's plenty of people doing CSS layouts that look fine in IE5/6/7. It's really about what the designers knows. A lot of us know the tricks and frown upon table layouts.
 
Browsers are getting better, even IE7 made improvements. Unfortunately there's a whole lot of people still using IE6, which means you still have to design for the older browsers. Though I don't even support IE < 8 at my site anymore. I'm a rebel :cool: We'll see if IE8 is all they promise, but I won't be holding my breath.

Seriously though, there's plenty of people doing CSS layouts that look fine in IE5/6/7. It's really about what the designers knows. A lot of us know the tricks and frown upon table layouts.

a LOT of 'us' frown on tables. Do yourself or your prospective client a favor and learn "standards-based" design with Direct Object Model (DOM) and CSS. Though there are still cross-browser problems to consider (thanks largely to microsoft), it opens up a world of possibilities, is cleaner, easier to maintain, and is very powerful/scalable.

If only I could have back the time i spent learning/using tables for layout - I'd be one really happy man.
 
I nearly gave up on css for layout, but I forged through, and now know enough 'tricks' to get a decent layout working reasonably consistently in most browsers. But yeah, when you read the specs on how you should be able to do things you're going to be maddeningly frustrated when they don't work (such as the hours I spent trying to get min-height to work only to find that IE doesn't really respect it). Tables are terrible for code design, but when your css isn't doing what it's supposed to, tables seem very reasonable. In the end, though, css is worth it. I still come across oddities often enough, but I've been able to resolve them quicker knowing the quirks of various browsers.

Also, DOM explorers are your best friend. You can see style and layout information for all the elements in the page as the browser renders it. Fortunately, browsers are getting better at supplying them so you don't have to look for your own. Safari has one available when you enable debug mode, you can get an extension for Firefox, and the IE8 beta has a pretty nifty DOM explorer.
 
I'm still forced to develop web apps for IE6 and, to be honest, sometimes it's so much easier to use tables to render side-by-side elements or get vertical alignments working than messing with CSS. I'm not happy about it but there it is.
 
We'll see if IE8 is all they promise, but I won't be holding my breath.

Still no XHTML support. No support for the opacity filter hack anymore (in IE 8 mode), yet Microsoft hasn't implemented CSS3 opacity either :rolleyes:

I'm glad that you're not holding your breath!
 
Personally, I still see some use for tables, eg, creating forms. I am not using it for layout but I don't see why some people are so against using tables at all, as if it is a bane of internet. :confused:
 
The wiki says it all, all praise the wiki!... and states the below, and more.

http://en.wikipedia.org/wiki/Tableless_web_design

Bandwidth savings

Clever implementation of tableless design can produce web pages with fewer HTML tags thus reducing page download times. Using external style sheets to position page elements means more mark up language may be cached and further reduce download times for subsequent pages using the same resources.

Poor implementation of tableless design can result in many more lines of code used per page element which can increase download time. Tables have a defined set of rules which are clear and concise while tableless design often involves working around browser inconsistencies.

The correlation between tableless design and download times is not significant. If implemented correctly, the bandwidth savings are generally minor at best. The use of WYSIYG editors or perhaps the competency of the web page's author has a much greater influence on page download times. It is perfectly possible to build a web page with tables that is lightweight.
 
Personally, I still see some use for tables, eg, creating forms. I am not using it for layout but I don't see why some people are so against using tables at all, as if it is a bane of internet. :confused:

People do tend to go a little over the top with the 'NO TABLES' mantra. There are still plenty of legitimate uses for tables within webpages. Like you, I don't see any point in using them for layout (in most cases - there will always be a job where you find yourself having to code your pages slightly differently from how you may want to) but there are still situations in which they're the best option. Tabular data, for example....
 
People do tend to go a little over the top with the 'NO TABLES' mantra. There are still plenty of legitimate uses for tables within webpages. Like you, I don't see any point in using them for layout (in most cases - there will always be a job where you find yourself having to code your pages slightly differently from how you may want to) but there are still situations in which they're the best option. Tabular data, for example....

I think you have put it right.

Putting tables in your website is fine, using it for the main layout isn't.

Tables have all sorts of downsides, like how screen readers can't process them in the right order.
 
Use CSS, it won't fail totally. Just don't expect the web to be as a magazine or image on Photoshop with perfect pixelmapping.

And the weirder stuff look in explorer the better, that's why people keeped using it in the first place.
 
People do tend to go a little over the top with the 'NO TABLES' mantra. There are still plenty of legitimate uses for tables within webpages. Like you, I don't see any point in using them for layout (in most cases - there will always be a job where you find yourself having to code your pages slightly differently from how you may want to) but there are still situations in which they're the best option. Tabular data, for example....

And that is the point: Use tables for what they are meant for. Semantically they are supposed to be tables of data that is best represented in cells.

The point isn't "don't use tables" - it's "don't use tables for what they weren't meant for"
 
We'll see if IE8 is all they promise, but I won't be holding my breath.

IE 8 does fully support Acid 2.

My site looks fine in CSS even in IE 6 you just have to be careful with designing it, Internet Explorer 6/7 don't like display:inline block for example, but you can usually work around it.

Still no XHTML support.

Not fully as per the spec, but it does work, ASP.NET defaults to creating XHTML pages.
 
Still no XHTML support. No support for the opacity filter hack anymore (in IE 8 mode), yet Microsoft hasn't implemented CSS3 opacity either :rolleyes:

I'm glad that you're not holding your breath!

IE8 parses my xhtml site, but manages to be the only browser (including the other IEs) that can't lay it out properly. So much for CSS standards improvement. I guess they still have quite a few months to get it right, but I'm not holding my breath either.
 
http://www.w3schools.com/HTMLDOM/default.asp

w3scools is a great reference for learning anything to do with standards based web design.

Standards are great, but w3schools doesn't always tell you which standards you might as well ignore because of poor browser support, like the css min-height rule. It took me a while to realize that just because it's a standard doesn't mean you can use it. Once you become aware of this, you'll spend less time beating your head against the wall trying to make some specific technique work that should be valid according to standards, and find other standards compatible techniques that will solve your problem, even if they may not be as elegant.
 
... using the SGML parser.

So, XML and HTML are SGML applications, right? and xhtml is designed to be backwards compatible with html, correct? Does microsoft's sgml parser not understand the xml empty tag syntax, ie. <link (...) />? Other than the empty tag, I'm not aware of any xhtml that should not be able to be successfully parsed by an sgml parser. If I'm wrong, please let me know.
 
No, XHTML is not SGML. These few links should help to explain what's happening a little (oversimplification: The browser treats the XHTML as broken HTML/SGML and does its best to fix it). While at present you can usually feed XHTML into an SGML parser without major issues, it's still good to know that it's happening, and that it may possibly break in the future (although I agree that it's unlikely).

I'm guilty of feeding XHTML into the SGML parser myself, so I'm by no means innocent either :)

I guess that the point I was trying to make is that all other major browsers understand XML, but IE still doesn't.
 
So anyway, here I am in Kompozer with my Navigation Bar "pages" set up as php includes... and now I come down to a really basic question.

What should I use instead of tables for my php Navbar?
I could whack a table in there right now, fill it up with linked words, and have a right little mess of a "normal" navbar table linking into all my pages.

But how would I do the same thing with CSS or Direct Object Model (DOM)?

I'm thinking of having a top site-wide Navbar (linking to the main "Chapters" of my site) and a left-side Navbar for each chapter, linking to the pages of that chapter. EG:

Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5

Chapter 1
Pages 1
Page 2
Page 3
Page 4


So each page will have the TOP Website wide Navbar, and then one of the side Chapter Pages navbars

Any ideas?
 
The CSS (and semantic) way generally is to use a list of links and style it appropriately. You can find an example at my site (see my profile) as I use a ul list and style it to be a horizontal navigation menu. From the CSS you'll make the li tags inline so they go horizontal.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.