homepage Welcome to WebmasterWorld Guest from 23.20.28.193
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / HTML
Forum Library, Charter, Moderators: incrediBILL

HTML Forum

This 155 message thread spans 6 pages: < < 155 ( 1 2 [3] 4 5 6 > >     
Tables - What is so bad about them again?
SirTalksalot




msg:3704281
 9:49 am on Jul 22, 2008 (gmt 0)

Hi all,

I've had it driven into me for so long now that 'tables are for displaying data', and not to be used to format your page any more, and the way forward is forever CSS.

I've tried my best to stick with CSS, but I've always found it a massive pain in the ass compared to simply using tables. The text is still readble on a page, the links still work, what's the big deal?

In short, I'm thinking of making life a lot easier by simply reverting to tables for formatting, with a little CSS to tweak it. Is this really such a crime?

 

Trace




msg:3728015
 1:12 pm on Aug 21, 2008 (gmt 0)

I agree with all of the above. However, I would like to note - since the topic of server-side programming was brought up in the footnotes - that by using server-side includes to piece together pages (as I have described in a few other threads) a table layout can be made just as, if not more, maintainable than a CSS Div layout. I say more maintainable because as it currently stands CSS layouts are much harder to setup because of all the hacks involved - this will change with time of course. So - providing you have server-side programming - the only thing that CSS really has over tables is its correct semantics (which I never found to be a convincing argument by itself).

I'm speaking only from my personal experience as I don't know the type of environment you work in, but that quote above would make my job, and others around me, a living hell. I'm starting to think that all of your comments are derived from working on small micro-sites, where as in my case, sometimes we're 20 or 25 people working on the same project.

Skipping past what the conception department comes up with and what the Architects have planned out, all the programmers are given either a module or a section of a page to develop. They have absolutely no interest in how it will look in the end, simply that it works as per the specs.

The integrators are then supplied with straight no nonsense markup to work with. If it weren't for the standards/semantics, their job would be impossible to do. They have no control over what the scripts are rendering. If they were expected to make anything other than tabular data work inside a table, the back and forth between the integrators and programmers would drive everyone mad.

It's only logical to have the data/content/information be laid out properly (read: correctly) and use the intended CSS to do what it's meant to do.

No one will ever convince me that using tables for structure is either acceptable nor profitable.

csuguy




msg:3728030
 1:52 pm on Aug 21, 2008 (gmt 0)


I can only agree with that as long as you only work with table layouts. I have made up some CSS layouts (which, by the way, work even in IE6) that wouldn't be possible throught tables nor, fot that matter, any other markup construct.

There are certainly structures which can only be achieved with CSS. Personally - I am a fan of Hybrids. You get the structure of tables with the flexibility of CSS Divs. They offer you far more options in terms of layout VS just tables or just divs. And there maybe places where it is just plain extra work to use a table - and I'm not suggesting that they be used in those cases. But tables are flat out better at grid layouts - like if you need a horizontal row with multiple columns that all expand to the same height that have dynamically created content.


I can understand that. The only issue is that people stick with what doesn't work. It may also depend on each site's topics and audience, and most often there is quite a paradox here: users don't expect online shops to give them security instructions, but visitors to these kind of sites should take more measures to protect their security, since they are most likely transferring sensitive data to the site (payment details).

Here's the conflict: it DOES work for users, it does NOT work (as well) for developers. But users don't really care how hard a site is to develop - so long as it works. They don't care about security too much (depending on the site of course) - they trust the developers to make it secure. As long as developers are capable of delivering what they want, they don't care how hard it is to implement or maintain.


You seem quite sure about that, despite it doesn't match any real pattern: there hasn't been any browser version that lasted 10 years; but you are stating IE 6 will last at least 15 :o. Counting from the date when IE8 is finally released, I wouldn't expect more than one year for IE7 to extinguish, and maybe 2-3 years for IE6 to also die off. That still depends on how much should the usage % to drop to consider a browser to "die off": I know of some people who still run IE4, but I'm not targetting any of my web projects to support that.

Actually - if you see my last post - I said 5 to 10 years for IE6 ;) - and I believe that a reasonable estimate. This is centered around the fact that IE6 is the recommended (and default) browser for XP and 2000. I believe there are problems (if it even works) with IE7 on these computers. People aren't going to run out and buy new computers to support IE 8 - which will no doubt have the same compatibility issues as far as the OS is concerned - It's made for Vista. The reason its going to take 5 to 10 years for IE 6 to die off is because thats about how long its going to take for the vast majority of 2000's and XP's to be replaced by the general public. There are plenty of articles online talking about how the old 3 or 4 year replacement cycle for personal computers no longer (if it ever did) apply to us today. Rather - they estimate closer to 5 or 6 years before people start replacing their PCs. That leaves another 4 years for the remnant who just don't need or don't want to upgrade their computers. There will be a few after that who still have it, but 10 years is a reasonable estimate for how long it will take for it to - for the most part - die out. Personally - my PC with XP is only 3 years old so I won't be looking to replace it for another 5 to 7 years.

I like getting new computer stuff - but I hate replacing my old stuff ;).


With a good design and structuration, it doesn't take too much extra effort to achieve a very smooth degradation: for example, IE6 users would see the best IE6 could render, while IE8, Opera9.5x or Firefox3 users would see the same contents, with some layout and formatting improvements here and there. After that, informing the users about the fact they are seeing a "limited" version of the site is up to each one, and it depends on your needs, target audience, and so on. My point is not to require users to upgrade (maybe I should have stated this more clearly), but to reward those who do.

I see no need for degradation (unless your talking about REALLY old browsers). Quite frankly - there haven't been to many new features added over the HTML 4 lifespan, its mostly been about supporting the existing features. Most new features can be supported through alternative means (like the position:fixed). I haven't seen a design which can't be written to look just as nice in IE 6 as it does in IE 7 or FF 3. It might require some older, perhaps unsemantical, coding practices - but you can make it work.

You CAN do the degraded thing - but there are two problems with this:
1) If it isn't degraded to the point that its a hassel or till it looks ugly, people won't care.

2) If it is degraded to that point - people will leave for a site that does support IE.

Trying to force your average users to upgrade (even for unnecessary features which can be made to work without an upgrade) is a bad approach and should only be implemented if absolutely necessary. Build around them - not around the current standards which are for the future anyways. If its your own site - do what you want of course - but don't harm your client's clients ;).

csuguy




msg:3728036
 2:06 pm on Aug 21, 2008 (gmt 0)


I'm speaking only from my personal experience as I don't know the type of environment you work in, but that quote above would make my job, and others around me, a living hell. I'm starting to think that all of your comments are derived from working on small micro-sites, where as in my case, sometimes we're 20 or 25 people working on the same project.

You are correct that I've never worked on really large projects like that. I usually work alone or in smaller groups of 3 to 4 people. If I were doing a MASSIVE site - that would certaintly influence my design implementation.

My first E-Commerce site that I did - I did by myself. It had 700+ items - all of which I had to scan and upload to a database with relevant data from about 5 large catalogs. I had to do all of the PHP coding for a custom shopping cart and hook it all up to Paypal. It was a fun project - but it took forever 0.o, sure wish I had some help on that one. I'm sure this is small in comparison to the sites you work on though - if they require 20+ people.


It's only logical to have the data/content/information be laid out properly (read: correctly) and use the intended CSS to do what it's meant to do.

No one will ever convince me that using tables for structure is either acceptable nor profitable.

The problem is that the CSS isn't supported for Grid Layouts. If you can design in such a way to get away without tables (which isn't to difficult most of the time) great. But to try to use CSS to do grid layouts ... its just not worth it. But - again - I'm speaking from working on projects which are probably quite a bit smaller than what your working with - which is definitely an important consideration.

When working on large projects - standards are a must (EDIT: though this doesn't necessarily mean W3C standards ;) ). I don't think that tables - so long as they are done properly - would be a problem in large projects. But its definitely easier if you don't have to worry about layout markup in such large projects.

Herenvardo




msg:3728182
 5:30 pm on Aug 21, 2008 (gmt 0)

Here's the conflict: it DOES work for users, it does NOT work (as well) for developers.

Actually, it doesn't work for neither users nor developers. Ok, on the standards-compliance part, which is what we developers first look at, it works for users because it only affects developers, and, as you stated, they won't care if it takes titanic efforts to make a site work well in their browser, as long as it works. But there are other issues, specially security, which should be a good enough reason for users to upgrade. Just letting users know about the improvements they would get if upgraded, and how to upgrade if they chose so, shouldn't hurt. Actually, it will show the users how much do you care about them (and, considering that websites are often the first point of contact between bussinesses and clients, that could even make the difference for a user picking that site instead of competitors "hey, does folks really care about me! Better than [Competitor X here] that just cares about my payment info being correct. :)").
My maxim is to always put the users first, and do what's best for them (not only in the web context, I'm also a software developer and I also apply the maxim on that field); but this means that when the user doesn't really know what's best for her/him, you need to explain it in a way s/he will understand. For my this is always the very first design principle; if it's not among your principles list, I will respect your position/philosophy, so feel free to ignore this whole paragraph.

Actually - if you see my last post - I said 5 to 10 years for IE6 ;)

Ouch, I'm blind (honestly, maybe I should not keep posting at 3-4 a.m.). Yes, I just reviewed the thread and saw it.
Still, I don't expect IE 6 to last more than 2 or 3 more years (and this is regardless of IE8's release date). That's because this is the time in which I expect Win 2k to die off (see my thougths on Win XP later in this post).

This is centered around the fact that IE6 is the recommended (and default) browser for XP and 2000.

This fact is not much a fact. For 2k, the default is IE5.something, and IE6 is the highest you can install there. For XP, indeed, IE6 is the default (except XP SP3 which, AFAIK, raises the default to IE7). Recommended... by who? Microsoft always recommends they latests products (obvious, they have to sell them after all); so I'd like to know what's the source of such "recommendation".
I believe there are problems (if it even works) with IE7 on these computers.

Have you, at least, tried it? Of course you are free to choose which browser to use but, as a web developer, it'd be good to know which browsers work on which systems. I can tell you that I've been running IE7 on a XP SP2 (recently updated to SP3) 2-years-old laptop (it's not my main browser, but I often use it to know how it works). Furthermore, I had it working on a 10 year old computer (P3-667Mhz, 256Mb RAM, and 8Mb ATI Video card (hey, I used to feel proud of having that video card! :))). About IE8 I've just installed the beta and run it twice (only on the laptop, I don't have anymore my old box), so I can't say too much, but the UI is almost identical to that of IE7, the installation is noob-proof with a few customization options (it even detected Opera and Firefox in my system and offered me to import settings and bookmarks from either :o) that you are allowed to simply skip and leave at the defaults.
People aren't going to run out and buy new computers to support IE 8

Of course they aren't. But every computer that can run IE7 can run IE8 as well (although it's supposed to require some more RAM, the official memory requirements doesn't make too much sense).

You CAN do the degraded thing - but there are two problems with this:
1) If it isn't degraded to the point that its a hassel or till it looks ugly, people won't care.

2) If it is degraded to that point - people will leave for a site that does support IE.


That's exactly the point of degrading gracefully: I'll exemplify this with my current methodology (I know it takes a lot of extra effort, but the current sites I'm working on deserve it :P ). I use server scripting, which opens up a lot of potential, and I take the most I can from it, specially in the content negotiation part. The relevant part of the script begins by parsing the Accept and, to a lesser extent, the user-agent headers sent by the client, and infers from there one of these values: "legacy", "quirks", "std", "future". Then the content (which is mostly hosted in a database) is sent to the output using that value conditionally: browsers such as lynx or anything accepting only "text/plain" will trigger the "legacy" mode, getting a minimalistic layout using nothing else than headers, paragraphs, and anchors, literally (up to the point that the content is perfectly readable even if the source is shown in a text environment). The "quirks" mode (actually, I internally call "ugly", but "quirks" would be much more descriptive) is triggered by IE up to 5.x (inclusive) and other browsers of similar "age" and produces HTML transitional with some CSS (it doesn't use <font>, but it renders the layout via tables and even iframes when needed, and only handles "font formatting" via the CSS; I even use <sup><a ...>...</sup> for footnotes). The "std" mode is triggered by anything claiming to accept "application/xml+xhtml", and produces XHTML1.1 + CSS, tinkering the CSS as much as needed if testing in the major browsers reveals any inconsistency. Finally, the "future" mode can only be found by adding a parameter to the query string, and serves highly semantic XHTML2 + CSS Level 3 (actually, just CSS2.1 plus the "stable" modules of level 3, but that's enough to take "class" and "id", and even side stuff such as section numbering, entirely out of the markup), and I'm planning to make it be triggered by the few browsers that already can handle it. The next step I still have to take is to create CSS's for non-usual medias, such as aural browsers or hand-held devices.
That's content negotiation + graceful degradation at its finest and, for most "real-world" cases (the sites where I'm doing this don't fall in the "real world" category), it's undenniably a needless overkill :P but it shows how much can be achieved: you can make legacy browsers work, quirk browsers look good, and most-compliant browsers look awesome with semantic content.

If its your own site - do what you want of course - but don't harm your client's clients ;)

Indeed, the site's where I'm doing this are my own. When working for someone else, most often I have to work on already built sites, and I adapt myself to the existing methodology (if I found an HTML 3.2 site, however, I would strongly encourage the owner to create a new one from scratch, reusing content but not even a single tag of markup). The last time I had to build a new site (it was a remake from a 3.2 site, btw, but explicitly asked by the owner), IE6 was something new and I used tables for layout; simply because it'd be best for the users, which is what ultimately matters.

As a side comment, for big-team projects, I also think that separation of concerns is essential for good interaction between the parts developed by different "sub-teams" or individuals.

Regards,
Herenvardo

Small Website Guy




msg:3728319
 7:06 pm on Aug 21, 2008 (gmt 0)

You shouldn't avoid DIVs because you don't want to learn about DIVs and CSS.

That said, as someone who knows a lot about DIVs and CSS, I find that it's impossible to do multi-column variable-length cross-browser-compatible layouts without tables. Firefox and IE treat floating DIVs differently, but are quiet consistent with tables. The CssZenGarden website is not relevant to real world sites with dynamic data, because the content of the Zen website never changes. You might find that a lof of designs would break if you doubled or halved the amount of text in some of the DIVs.

ronin




msg:3728497
 12:55 am on Aug 22, 2008 (gmt 0)

Dear me, not this old chestnut >;->

Two points:

1) Why does no-one ever ask what's wrong with laying out pages using unordered lists? That's possible too with a bit of persistence. Any argument for laying out pages using tables (apart from: "Because I already know how to do it and it seems to work in every user agent I've tried") also applies to laying out pages using unordered lists.

Come to think of it, why not just create huge sections of your page in Photoshop and display them all as images? That works in most browsers too!

2) Forr thoze hu doe nagri with yuzing standerds becoz uther methods werk just as well, wy do yu insist on tryin tu spell wurds according to defined spelling rools? Yu mite az well jus rite the way it sowns, no? Aft arool it werkz pritty much wen yu reed it bak, no? Wy bothar withaving tu lern how to spel stuff? Spelit how yu wont! (Shakspere did!)

Herenvardo




msg:3728528
 2:22 am on Aug 22, 2008 (gmt 0)

Come to think of it, why not just create huge sections of your page in Photoshop and display them all as images? That works in most browsers too!

Because people use Flash instead :P But I get your point, and I agree with for the very same reasons I press Alt+Left on my keyboard everytime I read "This site requires Flash" or "This is a Flash site" ;) .

2) Forr thoze hu doe nagri with yuzing standerds becoz uther methods werk just as well, wy do yu insist on tryin tu spell wurds according to defined spelling rools? Yu mite az well jus rite the way it sowns, no? Aft arool it werkz pritty much wen yu reed it bak, no? Wy bothar withaving tu lern how to spel stuff? Spelit how yu wont! (Shakspere did!)

If you are speaking seriously, then I 100% disagree. However, if you are being sarcasting (and I think quite obvious you are), then I 99% agree. Note the emphasis on 99% :o

(I was thinking on leaving the post just as that, and give all of you some time to try to figure out where's the missing 1%. Nop, there is no rounding error ;))

Readability is a very good argument in favor of the semantic approaches and of the separation of concerns philosophy (which, while vastly overlapping, are still different concepts). But, let's put a counter-example / metaphor which illustrates the justification of tables for layout:

Let's suppose we need to write an essay or an article about something (I'll use essay from now on for this analogy); and there is a concept that is essential for the meaning or purpose of the essay.
The essay would actually represent a website; the concept represents the site's inherent layout (which in this case would be a grid/table layout), and the purpose of the site is to provide an interface for the user to browse the contents, which inherently relies on the layout).

It's quite obvious that we should use the right word and spelling for the concept, isn't it? But let's suppose, for this metaphor, that for some reason the correct word for that concept, as defined by the dictionary, is only understood by some of the intended audience; and most of them use a slang term for the concept. Also, most of the audience understands the slang term, even while some know it is not the correct wording.
Following with the metaphor, the right word and spelling would be the CSS table-related properties; the slang term would be the <table> and related tags; and the audience would represent the site's users and their browsers.

We face some different options:

  1. Be absolutelly correct and precise: most people won't understand the whole essay, but it will be correct after all. This represents the approach of using the CSS properties that are meant for tables, despite IE users won't be able at all to view the site (I have felt tempted to do that recently on one of my sites, where correctness, semantics, and compliance are priorities)
  2. Use some alternate wording that everybody happens to understand. Although a bit verbose, the essay is understood by everybody. This matches the case of using CSS-based workarounds, like absolute positioning or floating elements. It takes some extra coding and lots of extra testing, but will work in all major browsers.
  3. Use the slang term, straight-away: that's what everybody understand. This represents the case of using tables, which is what every browser can handle.
  4. Use the correct term, and add the slang term in a parenthesis or footnote, or even create two versions of the document, one using the correct wording and the other using the slang term. This matches the different degrees of content-negotiation that can be handled on the server side to make everybody happy.

Which option would you take might depend on the context of the essay. If rather than an essay what you are doing is some kind of advertising, then the slang term can work. If the essay is something about the importance of using correct words and spellings, then using the slang is unacceptable. There are infinity of grays in between.
Finishing with the metaphor, the advertising approach matches most commercial businesses, whose only purpose is to advertise some products and enable the users to buy them. The oposite extreme would be a website about the importance of semantic markup, standards compliance, or separation of concerns. Like with the essay metaphor, there are lots of sites in the "gray" area, which do not fall in any of the extreme categories.

Regards,
Herenvardo
The signature is not part of the metaphor :P

ronin




msg:3728760
 10:41 am on Aug 22, 2008 (gmt 0)

That's a phenomenally good analysis. I'm very impressed with how well you've just critically dissected my fundamentalist perspective using the analogy of readability/interoperability.

Well done.

I tend to think in academic terms, so, to me, all web pages are academic documents - consequently, any use of scrappy short-hand or slang (ie. table-based layouts) is just... clumsy.

csuguy




msg:3729422
 1:23 pm on Aug 23, 2008 (gmt 0)

Sorry for taking so long to load - I've been busy helping my parents move and so I haven't found too much time over the past few days.


Just letting users know about the improvements they would get if upgraded, and how to upgrade if they chose so, shouldn't hurt. Actually, it will show the users how much do you care about them (and, considering that websites are often the first point of contact between bussinesses and clients, that could even make the difference for a user picking that site instead of competitors "hey, does folks really care about me! Better than [Competitor X here] that just cares about my payment info being correct. :)").
My maxim is to always put the users first, and do what's best for them (not only in the web context, I'm also a software developer and I also apply the maxim on that field); but this means that when the user doesn't really know what's best for her/him, you need to explain it in a way s/he will understand. For my this is always the very first design principle; if it's not among your principles list, I will respect your position/philosophy, so feel free to ignore this whole paragraph.

I somewhat agree - but I still feel that the vast majority of users will either ignore it - or even be annoyed with the new banner and the degradation (if they have an older and newer comp to access your site with). The fewer banners advertising stuff, for good or not, the better - and the more sites I go to stay the same no matter what computer I'm using the better. I feel that 1) it's a waste of time (even if you gotta a couple converts its not going to speed up the time it takes for these browsers to die out) and 2) the extra work it creates is not worth it nor ideal. Going out of your way to make it degrade is wrong IMHO.

Furthermore, I just got a new development job - and my employer has a Windows '98! Not a good idea to make it degrade for them ;).


Ouch, I'm blind (honestly, maybe I should not keep posting at 3-4 a.m.). Yes, I just reviewed the thread and saw it.
Still, I don't expect IE 6 to last more than 2 or 3 more years (and this is regardless of IE8's release date). That's because this is the time in which I expect Win 2k to die off (see my thougths on Win XP later in this post).

This fact is not much a fact. For 2k, the default is IE5.something, and IE6 is the highest you can install there. For XP, indeed, IE6 is the default (except XP SP3 which, AFAIK, raises the default to IE7). Recommended... by who? Microsoft always recommends they latests products (obvious, they have to sell them after all); so I'd like to know what's the source of such "recommendation".

I know the feeling - I'm posting at 6Am myself. I've had like 4 or 5 hrs sleep (normal for me unfortunately) and now I've gotta go on a 4+ hr car drive to help my parents move :/. Anyways, I was mistaken - its not that its recommended for XP - but for all Window OS's prior to XP. IE7 and 8 are for XP+Vista. Anyways, just because the technology is out there doesn't mean a thing - people don't upgrade. They don't like it, they don't want it. Hence you still will run a number of people who use 98 like my new employer. Again - I said it would only take 5 to 10 years for IE6 to go away, which really isn't a long time. 5 years for the majority of IE6 users to upgrade and 10 years for those remnant holding on to older computers (like they do for 98) to upgrade or become a super small demographic so that you don't have to code for them anymore (like people who use version 4 browsers today - no one cares that they use it, they're not programming for 'em).

Then there's IE7 - most people are not going to upgrade browsers. For the longest time - I thought I had IE6 on my laptop (mostly because I use FF to search the web). I knew quite well IE7 was out and I had no plans to upgrade. And I'm a developer! How much more so are non developers not going to care and see it as an unnecessary hassel? So long as it works - they aren't going to want to upgrade. I expect IE 7 to have at least as long as a life span as IE 6 has had.


That's exactly the point of degrading gracefully: I'll exemplify this with my current methodology (I know it takes a lot of extra effort, but the current sites I'm working on deserve it :P )...

0.o Way too much work and counter-productive in every way, IMO.


Indeed, the site's where I'm doing this are my own. When working for someone else, most often I have to work on already built sites, and I adapt myself to the existing methodology (if I found an HTML 3.2 site, however, I would strongly encourage the owner to create a new one from scratch, reusing content but not even a single tag of markup). The last time I had to build a new site (it was a remake from a 3.2 site, btw, but explicitly asked by the owner), IE6 was something new and I used tables for layout; simply because it'd be best for the users, which is what ultimately matters.

Exactly - having it work for the user is what ultimately matters. I also believe that users should get the same experience at any site and should not recieve a degraded form of a site unless it is impossible to make some feature work with an older browser. To purposefully make it degrade is... wrong. "Graceful" degradation is rarely graceful - especially for users who see your website with older vs newer browsers.


As a side comment, for big-team projects, I also think that separation of concerns is essential for good interaction between the parts developed by different "sub-teams" or individuals.

I agree completely. Making a website as modular as possible - especially for big-team projects - is essential to getting a website up and running. It's still important for smaller projects, but it will never get up and running if the groups are properly separated and using proper standards (again - this doesn't mean W3C standards, just standards for the company).

Ryan

Herenvardo




msg:3729602
 10:11 pm on Aug 23, 2008 (gmt 0)

Then there's IE7 - most people are not going to upgrade browsers.

Agreed: they aren't. Automatic Updates will upgrade it for them ;) I'm not sure, right now, if IE8 will be fetched by AU by default (IIRC, IE7 was shown as a "high priority" update on the update site when it was released, so it's expectable that IE8 will be automatically updated by Windows).

That's exactly the point of degrading gracefully: I'll exemplify this with my current methodology (I know it takes a lot of extra effort, but the current sites I'm working on deserve it :P )...
0.o Way too much work and counter-productive in every way, IMO.

Maybe I should have stated it clearer, but that's an example which has gone to an extreme. Quoting myself:
That's content negotiation + graceful degradation at its finest and, for most "real-world" cases (...), it's undenniably a needless overkill

Since it seems that this part was missed, I'll approach directly the "real world". First of all, if you need your site to render properly in IE7 or earlier, and your layout is indeed a table, then go ahead and use tables, because it's the only way it will really work on all the targeted browsers.

A more "real" example: have you seen some of those fancy CSS menus out there? They make interesting use of non-typical selectors to hide submenus and display them only when the corresponding item in the main menu is being hovered; but they don't work well in some browsers (for example, IE has had some issues with the handling of the :hover pseudo-class). There are some pages that add redundant javascript to ensure the menu behaves as it should (for example: the javascript handless it when the CSS is not recognized, and the CSS can be relied upon by most browsers when javascript is disabled); and they even add a bit of coding to check which browser is being used: if the browser can already handle the CSS, the javascript won't mess-up. Finally, any of those sites could (maybe some do, but I haven't seen any) use the <noscript> tag to provide alternative means of navigation when everything else fails. That's an example of graceful degradation: the page is designed in a way that it will use the best means available, but doesn't rely on only the best option and uses the "second best" when the first fails, and so on, until the last method (in this example, the noscript tag), which is supposed to be fail-safe.

Exactly - having it work for the user is what ultimately matters.

I have never said otherwise (at least, not literally :P you already replied on the thread where I "questioned" that). And I'll say again: on the average case, go ahead with tables for layout. Period. Until these non-compliant browsers die. If you can make it work with CSS cross-browser and it's worth the effort, then go ahead (for example, I can often achieve that because my layouts tend to be minimalistic and as simple as possible, just because that way the user will understand them at a glance).
Also, let's clear out what means using tables for layout: when you are using rowspan or colspan in ~50% or more of your cells, then that's probably layout. But if you are showing a list of products and your "layout" is putting a picture on the left, the details in the middle, and the price on the right, for example, that's not layout anymore: these contents have become tabular data on their very own. And beyond this example, there are many cases that, when building a table-based layout, the contents are effectivelly offered as actual tabular data. So, beyond a main table splitting into header, navigation, content, and footers (which is not really that bad), most of everything else can be semantically justified.
I also believe that users should get the same experience at any site and should not recieve a degraded form of a site unless it is impossible to make some feature work with an older browser.

It is when a feature cannot be made to work on older browsers when the page would need to degrade in such browsers. And it is the art of making everything else still work what I mean by gracefully. Of course, there are many sites that degrade needlessly and horribly. The same way there are sites that put something like <center><blink><h1><b>READ THIS!</centre></h1></b> (note the miss-spellings, the bad nesting, and the fatidic absence of </blink> ) (yes, there are still some sites with such aberrations; and some of them even try to sell "web design services"). But we are not discussing how horrible bad things are; we are trying to tell SirTalksalot whether or not what he is considering (going back to using tables) is a sin or not.

So, going to the starting topic of the thread, I have to say: SirTalksalot, go ahead: there is no sin. Tables for layout are currently justified and, while they have been used by sinners in the past together with other malefic tools (such as the transparent-gif-spacer), they are not a sin by themselves (I'd rather say they are a forced indulgence).

I know, I know, in theory tables for layout are bad. But in theory the URSS was going to outlast every other nation in the globle; in theory mankind should already have eradicated itself from the Earth; and, 6 centuries ago, in theory, the world was flat and if you crossed the Atlantic you'd reach the edge of the world and fall to the Abbyss.
Don't miss-interpret me: theory is indeed interesting, and I really like theory; but theory is just theory, and not practice. Quoting a famous theoric scientist "As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality." This applies to any kind of theory and its respective application field.

I think I'm missing something, but I can't figure out what is it, so that's all for now :P

Regards,
Herenvardo

[edited by: Herenvardo at 10:13 pm (utc) on Aug. 23, 2008]

tangor




msg:3729913
 1:11 pm on Aug 24, 2008 (gmt 0)

For bots and indexers to get to the content there is often node upon node to parse through, check the content, decide if it is layout of textual content and so on. It is labor intensive and since your content isn't really what the markup says it is you get a penalty (in theory)

Should stay out of this... I use both tables (existing pages from 1996) and css (all new pages since 2003) but as far as I can tell, bots have no problems ripping through a website, table or css. And I haven't heard of a smart bot, yet. I would be very intrigued in finding out more about smart bots because that's the one I want crawling my site. :)

albo




msg:3729966
 4:48 pm on Aug 24, 2008 (gmt 0)

I follow this thread with great fascination. I look forward to the thread on HTML5 vs XHTML2.

With all the great expertise here, I often wish I could deduce some human identities, so's I could read some tomes I suspect some of you have written. For now, I'm happy browsing the threads.

I peruse tables versus divs, thinking of the Samurai. And I think of the divitis with which some webmasters replace their tables. Does it end up, being worthwhile? For a gross example, I think with "relative" horror [pun intended] of blogger templates.

As for me, I lack your great creativity, so I have "dumbed down" one small site, to all of (1) handle AOL, (2) disabled readers, and (3) still appear in a manner somewhat attractive to modern browsers (600 or so member group of older folks in continuing education).

notsosmart




msg:3730051
 9:11 pm on Aug 24, 2008 (gmt 0)

Count me in with those who use tables and css for optimal content layout (of course my sites look butt-ugly, but that is neither here nor there).

I use the tables trick (does anyone else still use that?) to push content to the top over menus/etc and I am not about to stop now. It works - don't fix it.

I use css for all other styling possible.

If you took my css files out, my sites would like something out of the web, circa 1996. I have a sneaking suspicion that SEs like that. :-)

Herenvardo




msg:3730085
 11:53 pm on Aug 24, 2008 (gmt 0)

I have to mention a funny anecdote hapenned a few hours ago: I have been building a stylesheet to display tabular data, which is quite the opposite of what we are discussing here :P. And, most important: I had a good reason to do that. Can somebody guess the reason?

I use both tables (existing pages from 1996) and css (all new pages since 2003) but as far as I can tell, bots have no problems ripping through a website, table or css.

CSS should require less effort, but bots have been digesting tag-soup almost since they exist: they can cope with something as innocent as a table-based layout.

I look forward to the thread on HTML5 vs XHTML2

Is there any such thread? :o I've searched for it but just found some old threads of people trying to figure out what was going on. But it seems that there is interest in the topic, so I've tried to set up the field for a debate: [webmasterworld.com ]

Regards,
Herenvardo

csuguy




msg:3730118
 2:01 am on Aug 25, 2008 (gmt 0)


Can somebody guess the reason?

Employer demanded it? (only good one I can think of)

Herenvardo




msg:3730133
 2:51 am on Aug 25, 2008 (gmt 0)

Can somebody guess the reason?

Employer demanded it? (only good one I can think of)

Good try; but, honestly, I would never define that as a good reason (it'd rather be a silly employer) :P
It has been something much simpler (and maybe subtle): the data is in XML form, so a stylesheet is the simplest and cleanest way to convert it into something "browsable".
Conclusion: use tables for layout and stylesheets for tabular data? Well, I already said that the site I'm working on is not too "real world" :P

Regards

csuguy




msg:3730136
 3:25 am on Aug 25, 2008 (gmt 0)

XML data can be binded to html tables

Herenvardo




msg:3730142
 3:40 am on Aug 25, 2008 (gmt 0)

XML data can be binded to html tables

:o Really? How? And will that take less than my 4 CSS lines?
Now I'm in doubt.. are you speaking about XSL (which would still be, strictly speaking, a stylesheet)? Or is it one of these fancy features of mixing XML within XHTML? Or is it something else?

On the postitive side: the day you don't learn something new is a day you wasted; so thanks for helping me not to waste my day ;) :P

Regards,
Herenvardo

csuguy




msg:3730190
 5:46 am on Aug 25, 2008 (gmt 0)

I've never used pure XML myself - but I have a book on it that covers Binding. There are plenty of tutorials online you can use - just type in XML table binding.

I'll give you a short example. Here's the XML:


<? xml version="1.0">

<INVENTORY>
<BOOK>
<TITLE>My Favorite Book</TITLE>
<AUTHOR>Me, Myself, and I</AUTHOR>
<DESCRIPTION>Best book ever!</DESCRIPTION>
<PAGES>100</PAGES>
<PRICE>$50</PRICE>
</BOOK>

<BOOK>
<TITLE>My 2nd Favorite Book</TITLE>
<AUTHOR>That one guy</AUTHOR>
<DESCRIPTION>2nd Best book ever!</DESCRIPTION>
<PAGES>120</PAGES>
<PRICE>$45</PRICE>
</BOOK>

<BOOK>
<TITLE>My Most Hated Book</TITLE>
<AUTHOR>Some Loser</AUTHOR>
<DESCRIPTION>Tastes like salt</DESCRIPTION>
<PAGES>200</PAGES>
<PRICE>I'll slap you if you read this book</PRICE>
</BOOK>
</INVENTORY>

Now, in your HTML you need to load this xml document - similar to a CSS link tag. Here's the basic syntax:


<XML ID="theInventory" SRC="Inventory.xml"></XML>

Here's the table code used to display the xml data:


<table datasrc="#theInventory">
<!-- This row not required -->
<tr>
<th>Title</th>
<th>Author</th>
<th>Description</th>
<th>Pages</th>
<th>Price</th>
</tr>
<tr>
<td><span class="title" datafld="TITLE"></span></td>
<td><span class="author" datafld="AUTHOR"></span></td>
<td><span class="description" datafld="DESCRIPTION"></span></td>
<td><span class="pages" datafld="PAGES"></span></td>
<td><span class="price" datafld="PRICE"></span></td>
</tr>
</table>

This will work regardless of how many or how few items are in the XML document. Take that CSS Divs :D (although may work with CSS Divs.... not sure).

Anyways - look up 'XML DATABINDING TABLES' online and you'll find lots of info on it.

csuguy




msg:3730196
 5:48 am on Aug 25, 2008 (gmt 0)

*Note that you CANNOT bind to <td>s

amznVibe




msg:3730198
 5:50 am on Aug 25, 2008 (gmt 0)

It's simple really. When you have tabular data, use tables.
When you have lists, use css ol/ul

Marshall




msg:3730206
 6:02 am on Aug 25, 2008 (gmt 0)

It's simple really. When you have tabular data, use tables.

How true. However, what would you consider the contents of this page - tabular data?

I am not adding to the discussion here other than to say I find it ironic that it is taking place on a page with a 4.01 transitional doctype, tables, and depreciated tags - <font size="2" face="arial" color="#ffffff">, etc.

And have you noticed the PR for the "recent posts" page.

Just food for thought.

Marshall

swa66




msg:3730411
 12:46 pm on Aug 25, 2008 (gmt 0)

There is IMHO only one obstacle to CSS wiping out tables abused for layout aside of people not willign to change: Microsoft Internet Explorer

csuguy




msg:3730456
 1:40 pm on Aug 25, 2008 (gmt 0)

There are other issues - but that is the big one.

mipr




msg:3730577
 4:08 pm on Aug 25, 2008 (gmt 0)

most of what I'd argue against tables for layout has already been said by others, particularly regarding large projects and multiple developers. But another thing that bugged me about this topic was the fact that a lot of the arguments given against CSS simply aren't true.

It is entirely possible to have multiple column layouts using CSS (source-ordered!) with variable heights, backgrounds, headers, footers etc, that work cross-browser.

It's also remarkably easy to implement complex grid layouts with divs and CSS, that are far more flexible and reusable than tables, *if you know what you're doing*.

It seems a lot of the CSS 'knockers' need to actually learn more about CSS before they slate what you can and cannot do with it.

I'm not saying that applies to everyone of course.

csuguy




msg:3730681
 6:03 pm on Aug 25, 2008 (gmt 0)


It is entirely possible to have multiple column layouts using CSS (source-ordered!) with variable heights, backgrounds, headers, footers etc, that work cross-browser.

It maybe possible - but can you program with only divs and css a grid layout with a single row and mulitple cells that receive dynamically built content that are all equal height without using overflow? I'd like to see it. And that's without using display:table and display:table-cell, which neither works cross-browser nor do I consider it semantically correct.


It's also remarkably easy to implement complex grid layouts with divs and CSS, that are far more flexible and reusable than tables, *if you know what you're doing*.

Depends upon what your doing.

Ryan

Herenvardo




msg:3730775
 8:04 pm on Aug 25, 2008 (gmt 0)

Anyways - look up 'XML DATABINDING TABLES' online and you'll find lots of info on it.

It looks prety interesting. Although it takes more than my current 4-line CSS (note that I'm using only the CSS, there is no HTML code anywhere). Also, how does that work crossbroser? I had heard somethign about all this "data-islands" stuff, but AFAIK it was only supported on IE, and I have found no source stating otherwise (I guess I'll try that by hand on FF/Opera). As a side note, since I'm only using this (currently) to check my google sitemaps in a more human-readable form (I'm generating them dynamically, and need to check that the script pulls all of, and only, the relevant URLs, without throwing away my last bits of sanity), I can afford having it only working on FF, but it would be an issue if it only worked on IE. I'm not sure if this is straying too much off-topic, since it's still about tables and layouts :P.

It's simple really. When you have tabular data, use tables.
When you have lists, use css ol/ul

That's obvious (as long as you can differentiate between tabular data and lists, sometimes it's not an easy call), but it is not the main question.
The issue is about using tables for layout (when you probably have neither tabular data, nor list, but just a need of showing this here and that there).

It is entirely possible to have multiple column layouts using CSS (source-ordered!) with variable heights, backgrounds, headers, footers etc, that work cross-browser.

Define cross-browser. If you exclude IE (7 or earlier), for example, there are lots of amazing things you may achieve with CSS. On the oposite extreme, if you include arcaic browsers such as NN4 or IE3 (or even earlier versions), then there is nothing you can achieve with CSS that works on them, simply because these don't support CSS at all.
If you include mainstream browsers, and assuming you already have dealt with IE's DTD-based compliance-mode selection, then yes, it is entirely possible... and entirely painful.

It's also remarkably easy to implement complex grid layouts with divs and CSS, that are far more flexible and reusable than tables, *if you know what you're doing*.

Easy + cross-browser + CSS? I think this sum will throw an ArgumentException Can you show some example?

And that's without using display:table and display:table-cell, which works neither cross-browser nor do I consider it semantically correct.

Can you tell me what does it mean for CSS to be "semantically correct"? Isn't CSS purely presentational in goal, scope, and semantics? I mean, the only semantics of "display: table" would be "display this rendered as a table/grid". As long as this is what you mean, that's 100% semantically correct in CSS. And if you don't mean that, I wonder why you'd be using such a declaration.

As a side note, has somebody mentioned that XSLT works cross-browser1, 2 and allows rendering "whatever"? Of course, client-side XSLT has serious drawbacks 2 (specially in the field of SE indexing), and server-side XSLT would look to the client exactly as presentational HTML would, which fails for the entire purpose, except, maybe, maintainability.
1You'd have to serve the XML as either "text/xml" or, preferably, "application/xml", and with a <?xml-stylesheet ... ?> processing instruction attaching the XSLT sheet; but most modern browsers can handle that.
2 Of course, only XSLT 1.0 is widely supported, for XSLT 2 we'd have to wait a few more years.
3 AFAIK, if you use <output method="html"> the in the XSLT, the resulting html is then handled as in normal html rather than xml. So you would have draconic error handling for the source data and the stylesheet, but tag-soup indulgence for the resulting html (for example, you could have user-provided content marked as CDATA in the XML, and the final page will be rendered even if that content has something like "<b>asdf<i>qwerty</b>zxcv</i>"; but it will still crash if you messed up with your own XML or the XSLT (which means that you would immediately detect such issue if you test your files, which you should). So, you can get the best of draconic error handling (no chance to by-pass an error while testing) plus the sometimes needed indulgence of classic HTML (so no need to validate external content, just store it as CDATA).

Now that I think about it, server-side XML+XSLT, with <link rel="alternative" href="theXMLsource.xml"> seems quite interesting. Is there anybody who has tried this or something similar and can share some experiences?

Regards,
Herenvardo

csuguy




msg:3730845
 9:20 pm on Aug 25, 2008 (gmt 0)


It looks prety interesting. Although it takes more than my current 4-line CSS (note that I'm using only the CSS, there is no HTML code anywhere). Also, how does that work crossbroser? I had heard somethign about all this "data-islands" stuff, but AFAIK it was only supported on IE, and I have found no source stating otherwise (I guess I'll try that by hand on FF/Opera). As a side note, since I'm only using this (currently) to check my google sitemaps in a more human-readable form (I'm generating them dynamically, and need to check that the script pulls all of, and only, the relevant URLs, without throwing away my last bits of sanity), I can afford having it only working on FF, but it would be an issue if it only worked on IE. I'm not sure if this is straying too much off-topic, since it's still about tables and layouts :P.

I looked around on the subject and it appears to be an IE only attribute - though there are ways to simulate it with other browsers. I think they should make it a standard :D - but, like I said, I don't really use plain XML (or XHTML for that matter) so I'm not experienced enough in the area to debate it too much.


Can you tell me what does it mean for CSS to be "semantically correct"? Isn't CSS purely presentational in goal, scope, and semantics? I mean, the only semantics of "display: table" would be "display this rendered as a table/grid". As long as this is what you mean, that's 100% semantically correct in CSS. And if you don't mean that, I wonder why you'd be using such a declaration.

I made a thread on this topic in the CSS section. Basically - your putting a table (not a grid - a table) in your html. Your simply changing the location of where its declared a table/table-cell. Now - if your building an actual table with tabular data then its fine (though I don't see why you wouldn't just use a table then), but most people don't use it this way. Rather - they want the layout functionality of tables without being semantically incorrect. So they change where its declared a table and say its semantically correct ;).

I find it ironic and silly really.

Ryan

tedster




msg:3730881
 10:14 pm on Aug 25, 2008 (gmt 0)

What's interesting to me in this thread is that it was started by SirTalksalot -- but he isn't, others are.

I'm a pragmatist. I need to spend time wisely or I'm not doing right for my clients. I tried CSS positioning for layouts, and it just isn't business-worthy in most situations right now. Maybe someday. I still, occasionally, use a spacer.gif, too. 1 minute's work instead of 1 hour's worth of tweaking, you know? That's especially true when working with legacy code that someone else created.

I applaud all the adventurers who are blazing the trail to perfect separation of style and content. Let me know when it gets paved, please.

Herenvardo




msg:3730970
 1:03 am on Aug 26, 2008 (gmt 0)

Basically - your putting a table (not a grid - a table) in your html.

This is, in theory, wrong. And in practice, it is partially wrong; but there isn't too much practice on this subject thanks to IE... so your statement is mostly wrong :P .
When using <table>, you are indeed puting a table in your HTML, row by row. When using CSS, you are only putting some rendering instructions, most often separated from the content to be rendered (either in a <style> tag, or in a external file). So, essentially, you are putting nothing on your HTML. The "table" will only be created when rendering the document, and by then it is already a grid rather than a table (because on most 2D visual displays, the natural mode to render a table is as a grid). If we were speaking about trying to use something like
:before { content: "<td>"; } :after { content: "</td>"; }
I would consider your argument more valid; although the above code wouldn't work (the document needs to be already parsed before CSS can be applied, so the values would be displayed rather than rendered; special characters would probably require scaping (I'm not sure about this), and the browsers that don't support display:table also don't support neither "content:" nor the :before and :after selectors, so it'd be quite pointless).
if your building an actual table with tabular data

Whatever the content is, CSS doesn't care. Whether it's tabular data, a cooking recipe, or a pixel-by-pixel description of an image to be used as alternative text, it doesn't matter. Within CSS, there are elements, attributes, and classes; and those have content. What this content is has no relevance in CSS; how this content will be rendered is what CSS cares for.

However, if you find yourself (in an hipotetic future where display:table is suported) forcing <div>s in your code just to use this property, then I'll agree with you that something's wrong. However, on that future we'll already have either XHTML2 or HTML5, so we'll have the <section> element (currently both specs include it, and it's not likely to be removed from neither), and something like this (it'd probably need to be a bit more elaborate to be useful)
section { display: table-row; }
section section { display: table-cell }
seems fine to me. Your html has sections and subsections, and your CSS describes how to display them. Each language is being used for what it's for.
In summary:
HTML is for structure/semantics; and <table> is for tabular data.
CSS is for presentation/layout; and display:table is for tabular layouts.

I still, occasionally, use a spacer.gif, too. 1 minute's work instead of 1 hour's worth of tweaking, you know? That's especially true when working with legacy code that someone else created.

spacer.gif is an aberration... but if you are working with legacy code, especially if it would really take one hour of tweaking to get CSS work in there, then the code is most probably aberrational by itself, so go on! It's like spitting in a highway vs spitting in a polluted river: spitting by itself is considered ugly, but on the river won't be noticed as much as in a highway ;)

Regards,
Herenvardo

wheel




msg:3730996
 1:41 am on Aug 26, 2008 (gmt 0)

I read the first and last page of this thread. i assume the intervening 8 pages were the same? :).

What a lot of folks miss is that it makes pretty much no difference to the end user which route you take. The average user has never even heard of tables or css. The average user only knows if it works or not. I caught my brother in law yesterday typing in 'www.somedomainc.com' into google search to go to a site. To these folks, tables vs. css make absolutely no difference.

So pick which one works best for you, for the job.

personally I prefer css because I believe it to be the more technically correct, cleaner approach that's easier to update. But given my knowledge of css, tables get the job done faster.

This 155 message thread spans 6 pages: < < 155 ( 1 2 [3] 4 5 6 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / HTML
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved