HTML WG approve tables for presentational purposes

[rguy84]

What are your suggestions?

[awasson]

This is full false. There is no reason at all to put a lot of WIDTH in TABLEs, oppositely, you can put less of them than in CSS-based layouts. Details to follow.

I don't believe you can prove your argument that "you can put less of them (WIDTH) than in CSS-based layouts" to achieve that same results but I'm happy to look at your reasoning.

[Michel Merlin]

How TABLE-based layouts can easily be ridded from their drawbacks

Only superficial, and very bad, reasons made people hate TABLE-based layouts, and ban them. The problem is that most authors, out of laziness either of themselves or of the available tools (e.g. DW), fail to make efficient use of TABLE intermediate child elements (particularly TBODY, THEAD, TFOOT, COL, COLGROUP); as a consequence they add myriads WIDTH (and eventually HEIGHT) tags to each low level element instead of applying them to the right level, or even better, instead of trusting the user agent for efficiently and appropriately giving the right width to each element (which in facts all main user agents are doing quite well, in particular with no more CPU or bandwidth consumption).

1. 1st widely spread flaw, authors and editors tend to pepper their HTML documents with myriads of WIDTH (and FONT) tags, applied to each low-level element. This is IMO an error, as shown by the facts that, in most existing pages, just removing all fixed WITH tags (you most often need to retain the percent widths) will get you a page that not only displays as pretty, clean and clear as before, or even better, but in addition becomes an elastic layout (i.e. a layout that will gently adapt to the available width offered by the media).
2. 2nd widely spread flaw, FONT, BACKGROUND attributes (family, size, image, color, style, etc), as well as PADDING, WIDTH or HEIGHT if necessary, are too often applied on each TD, instead of to the right level element (TR, COL, THEAD, TBODY, TFOOT).

Correcting the 2 main flaws above, would get you a page significantly lighter in volume and load time, prettier, cleaner, more elegant, more reliable whatever the media (from any window or tab on a desktop screen, to Letter/A4 print, to tiny mobile device), hence would remove most of the commonly perceived drawbacks of TABLE layouts, and almost entirely remove any reason to ban table layouts.

Oh yes, to achieve this you still need a bit of care (that is unfortunately badly lacking everywhere), for instance to give images the appropriate sizes (and accordingly link them to their own originals). Remember that this is easy: you only need to state EITHER the width OR the height of each image, user agent will properly adapt the other; and you can state it in CSS, hence usually a small number of times for your whole document.

Correcting this situation on a large scale would only imply IMO that editors (starting with DW, but also following with the much more modest ones as Outlook Express) get the following basic corrections (or improvements):

1. the WYSIWYG editing view, that already shows the invisible elements ("DISPLAY: none", "VISIBILITY: hidden", etc), also should show the TABLE limits (so far I have to put "border=1" in all my TABLE tags to make for this);
2. the same WYSIWYG view should offer ways to select either the cell contents (or other elements as SPAN, DIV, etc), or the cells themselves, or the TR, or the COL, or the COLGROUP, or the THEAD, TBODY, or TFOOT, or a selected ensemble of such intermediate elements, so to enable the author to easily, conveniently, hence quickly, apply whatever they want to exactly this selection, no more, no less.
3. the same view should offer a simple way to topple the TABLE (i.e. to swap cols and rows) or to rotate it 90, 180, 270 degrees.

Also, editors and browsers should apply what was initially intended to THEAD and TFOOT (i.e. they should remain visible at top or bottom of the viewport when the TBODY scrolls up or down, no matter how long is this TBODY); W3C should complete THEAD and TFOOT with TLEFT and TRIGHT (special COL intermediate elements that would remain inside the viewport even when the TBODY is wider).

Versailles, Tue 22 Mar 2011 19:33:20 +0100, edited 19:35:20

[rguy84]

Michel, While your suggestion would make code neater, it would not solve the accessibility problem. Screen readers tell people where they are in the table, which is somewhat hard and annoying to navigate. Which leads to the whole point of a table is used for data not a layout.

[Stevie D]

TABLE or CSS for layout must be chosen by AUTHOR, NOT by W3C

All W3C has to do is to make both solutions as efficient as possible, which implies unambiguous (hence unified), easy (hence simple and clear), and reliable (hence carefully thought, designed, implemented, before any enforcement). To which I add a few little suggestions below.

You seem to have forgotten what the W3's purpose is. It exists to formalise the language of the internet and promote best practice. Denouncing layout tables and telling people to use correctly applied CSS and semantic HTML is exactly what they should be doing.

TABLE-based layouts are as elastic as CSS-based

A 1st problem is that most available editors, because unable to handle TABLE intermediate elements (THEAD, TFOOT, TR, COL, COLGROUP, etc) and selections, and short of more synthetic views and tools, are forced to put a lot of FONT, WIDTH, etc, tags on low-level elements (TD, DIV, SPAN, etc) across the document.

Not sure what that's got to do with layout tables, which shouldn't have <thead> or any other such structures to them, even if you allow them to exist at all. Yes, all WYSINWYG editors are crap at producing good quality HTML and CSS, no-one is denying that. But there's no reason why they have to produce table-based crap rather than div-based crap.

As a result, a 2nd problem is that many people assume that a TABLE layout MUST be peppered with plenty WIDTH, HEIGHT, BACKGROUND, PADDING (and FONT etc) tags; e.g. ChangeProposals/NoLayoutTable states:

Device independence
It is relatively easy to make pages written with CSS-based layouts work well on devices with differing screen widths, such as mobile phones, automatically. In general, table-based layouts are much harder to do this on, as they tend to use precise dimensions, and often break in odd ways if things are resized unexpectedly.

This is full false. There is no reason at all to put a lot of WIDTH in TABLEs, oppositely, you can put less of them than in CSS-based layouts. Details to follow.

Again, you're putting the cart before the horse. Yes, most editors go heavily for fixed dimensions in their tables (including word processors like MSWord), and it can take a lot of bludgeoning to get them to go flexible. But that is nothing to do with the rights and wrongs of layout tables.

[Stomme poes]

This is full false. There is no reason at all to put a lot of WIDTH in TABLEs,

I call bull on this one: My tables don't have any freaking WIDTH garbage in them (because I freaking know how to write damn HTML code), and they STILL DON'T FIT ON MOBILES (unless they can zoom, and then they zoom the hell out, making the whole thing freaking USELESS because then the text inside is MICROSCOPIC).

WHY? Because tables have ROWS and ROWS don't WRAP. If they do, I ain't never seen it.
No, tables don't fit on mobiles, or on anything else with a screen the size of a mouse turd, UNLESS you're lucky enough to have a mobile browser that scrolls. And they don't all do that (for some freaking reason tho hell if I know why).

[Paul O'B]

for instance to give images the appropriate sizes (and accordingly link them to their own originals). Remember that this is easy: you only need to state EITHER the width OR the height of each image, user agent will properly adapt the other; and you can state it in CSS, hence usually a small number of times for your whole document.

If you meant (or you can state it in css (and not in the image)) then I would strongly advise against this as the image dimensions must be in the image tag or the browser won't know how much space to allocate until the image is loaded.

This results in a number of unwanted side effects such as the page waiting for the image to load so that it can be placed but more usually the page keeps on loading other content and once the image dimension is known it is then inserted back into the page causing an ugly re-flow because the rest of the page was already drawn. Firefox is especially bad at this and in fact on occasions leaves elements overlapping until the page has been revisited or refreshed. This is a common issue we see in the forums and why there is long standing faq about it.

Sorry if that wasn't what you meant as it seemed slightly ambiguous and I may have got the wrong end of the stick.

instead of to the right level element (TR, COL, THEAD, TBODY, TFOOT).

The col element unfortunately can legally only take 4 properties.

* border
* background
* width
* visibility

You cannot apply padding and other properties to it unfortunately although it would be useful.

Similarly the other elements you mention above are good for targeting inner elements via context but should not really have styles applied to themselves.

With good coding practices you can make tables cleaner and more acceptable but as Stomme mentioned above their biggest flaw is that a table row can never wrap.

Although table should not be used for layout I'm not averse to using them when there is no better technique available but these days that is few and far between.

What we don't need is a return to the bad bad old days of nested tables and spacer gifs. It's a slippery slope and we should encourage css first and tables only as a last resort. Once you waiver and say "yes that's fine" then you open the floodgates.

[Stomme poes]

Suzanne Taylor does a test of role=presentation:
Presentation

(layout tables only so far)

[mariya]

If we use the table for presentation it has not much more descriptive. For presentation content should be self descriptive.

[rguy84]

Mariya, can you explain your thoughts some more, I don't quite follow you.

[Stormrider]

I think the title of this thread is a little misleading. Tables for presentational purposes haven't really been 'approved' - they've just been changed from 'must not use' to 'should not use' with some suggestions to help older sites improve their accessibility without a complete rewrite.

[Michel Merlin]

CSS apply to all HTML, including TABLEs, DIVs, etc

We shouldn't IMO oppose "TABLE-based" and "CSS-based". Any proportion of a layout, from 0% to 100%, can be "TABLE-based"; the remaining could be called "DIV-based", but is neither more nor less "CSS-based"; TABLEs are NOT replaced with CSS, but with other HTML elements, mostly DIVs. And above all, bad layouts can be done with or sans CSS, with or sans TABLE, with or sans DIV, with or sans any particular tool. Especially if one spends too much time scolding others on forums hence keeps too little for learning, thinking or writing efficient sites; said Amadou Hampaté Ba: "A calabash, full, can receive no fresh water" (IOW, "who knows all learns nothing").

(rguy84 Tue 22 Mar 2011 19:22 GMT, #54)
...the accessibility problem. Screen readers tell people where they are in the table, which is somewhat hard and annoying to navigate. Which leads to the whole point of a table is used for data not a layout.

Giving Accessibility an absolute priority over all other human needs is unjust. Look around, in people there you will probably find many who are NOT impaired; in the impaired, you will find many who do NOT use "screen readers" (a dubious name: I am personally a screen reader...); in the screen readers, NOT all will ALWAYS "tell people where they are in the table"; even the ones that do, there is no reason to decide that they will never get smarter; no reason either that they act differently for TDs and for DIVs: if they don't tell "Left-Floated DIV"; "Both-cleared center DIV", and so on, then why do they need to tell it in TABLEs?

(Stevie D Tue 22 Mar 2011 19:24 GMT, #55)
(W3) exists to formalise the language of the internet and promote best practice. Denouncing layout tables and telling people to use correctly applied CSS and semantic HTML is exactly what they should be doing.

So, W3 is right even if denied by the people? Where comes that divine right from? I never went to the poll station for W3.

Not sure what that's got to do with layout tables, which shouldn't have <thead> or any other such structures to them, even if you allow them to exist at all. Yes, all WYSINWYG editors are crap at producing good quality HTML and CSS, no-one is denying that. But there's no reason why they have to produce table-based crap rather than div-based crap.

1. I never saw anyone wanting to force WYSIWYG (please spell it right) editors to produce table-based "rather than" div-based "crap". I see OTOH a lot of people (in facts, the whole horde of the web ayatollahs, as usual acting as a solid troop and blindly sticking with their mantras) wanting to force them to produce only div-based "crap".
2. According to popular wisdom, tables do present (figures, words, phases, paragraphs, images, as well as all other sorts of data); please just think of it seriously. There is no reason why W3 would be right and the people wrong.
3. In the posts you thought you were replying to, you would see that the intermediate elements (or at least the easiest: TR and COL) can be really efficient if correctly used.

Yes, most editors go heavily for fixed dimensions in their tables (including word processors like MSWord), and it can take a lot of bludgeoning to get them to go flexible. But that is nothing to do with the rights and wrongs of layout tables.

This is precisely what I said, so your "you're putting the cart before the horse" doesn't apply (IMO).

(Stomme poes Tue 22 Mar 2011 20:52 GMT, #56)
tables have ROWS and ROWS don't WRAP... tables don't fit on mobiles

1. DIV don't wrap either. Only contents inside wrap, and this, in TDs or DIVs as well. However I agree that, as Paul O'B clearly re-stated on Tue 22 Mar 2011 21:44 GMT, "a table row can never wrap". And I also agree that this is "(tables') biggest flaw". Up to each to design and choose TABLEs or DIVs, how many and how wide each, and so on. Making laws and rules constraining web designers is not necessarily the best way to get sites that please the most visitors. Notice BTW that this very forum (e.g. this page, HTML WG approve tables for presentational purposes - page 3), after being still heavily "TABLE-based" in March, got rewritten in "DIV-based", which brought little improvements on the user side, according to comments. Personally I don't write in "TABLE-based", and I sometimes spend the time to convert "TABLE-based" to "DIV-based", but I am strongly opposed to impose any such rule to others, and I must acknowledge (even if politically incorrect) that, when building fluid layouts (which I always do), DIVs often eat more time than TABLEs.
2. What doesn't fit on a small screen is large amount of visual information; what fits is small amount. And this, in TDs or DIVs as well.

(Paul O'B Tue 22 Mar 2011 21:44 GMT)
the image dimensions must be in the image tag or the browser won't know how much space to allocate until the image is loaded

Putting WIDTH and/or HEIGHT inside the IMG tag or in deported CSS produces the same result.

a number of unwanted side effects such as the page waiting for the image to load so that it can be placed

My advice is just to state ONE OF width or height. In that case, when the image gets replaced with another one with a different ratio, it still renders undistorted; and when the browser can't get the image (from connection or cache), it will apply the dimension you stated and take a default value (usually zero or near) for the other. I most often set the WIDTH, so the placeholder shrinks nicely in height but not in width. In the usual way (stating both, as you recommend), it would display a rectangle with the full height, which I don't prefer (nor hate). The moving of elements that occurs when the browser gets data only after it has started rendering, is a common adaptation that surely also occurs in your choice, rather natural and not so much disturbing, and infrequent enough IMO.

Sorry if that wasn't what you meant...

Thank you a lot for caring for others, even when you disagree and don't know them. I know, I shouldn't spend space "metooing" or "thanking", but this has gone so rare that I feel I must here.

You cannot apply padding and other properties to (the COL element) unfortunately although it would be useful...

I do apply them regularly:

<TABLE border=1>
<STYLE>.Desc {PADDING: 0 5px; COLOR: red; BACKGROUND: silver}</STYLE>
<COLGROUP><COL><COL class=Desc><COL align=right></COLGROUP>
<THEAD bgColor=#e4e4e4>
  <TR><TH>Name</TH><TH>Description</TH><TH>Price</TH></TR></THEAD>
<TBODY>
  <TR><TD>DH02</TD><TD>women's dress</TD><TD>$19</TD></TR></TBODY></TABLE>

You also said:

the other elements you mention above are good for targeting inner elements via context but should not really have styles applied to themselves

Please give arguments, I found none.

Versailles, Mon 14 Nov 2011 00:58:00 +0100

[deathshadow60]

We shouldn't IMO oppose "TABLE-based" and "CSS-based". Any proportion of a layout, from 0% to 100%, can be "TABLE-based"; the remaining could be called "DIV-based", but is neither more nor less "CSS-based"

That plays to something a dearly departed friend of mine used to say. "The people who just made endless nested tables for no good reason today just make endless nested DIV for no reason" -- to which I responded "Crap code is crap code, doesn't matter what tags you use".

Giving Accessibility an absolute priority over all other human needs is unjust.

BULLCOOKIES if you plan it right -- and planning it right is the entire point of semantic markup as it's not placing an absolute priority on it so much as *SHOCK* using the markup to say what things are, so you can address as many human needs SIMULTANEOUSLY as possible without any extra effort... which is why the 'its more work' you'll hear from some folks is a lame duck excuse not to bother with it... I mean accessibility to content by letting the user agent best adjust the content to fit is the ENTIRE REASON T.B.L. made HTML in the first place.

DIV don't wrap either.

I think you completely missed the point there -- multiple DIV or other block-level tags can be made to wrap; by floating them, by making them inline-block, by sending them to mobile WITHOUT floats to change a multi-column layout into a single column one. This is something you can't do to a table even by setting TD to display:block; (reliably... some browsers will let you do it, but the results are... unpredictable) That's one of the reasons to use DIV instead of tables when it's not tabular data -- being able to send different layout to the same markup.

Putting WIDTH and/or HEIGHT inside the IMG tag or in deported CSS produces the same result.

Deported? You're exiling it to another country? If you're trying to say width/height in a external stylesheet functions the same as the WIDTH and HEIGHT attributes on an image... no it doesn't. The attribute is applied long before the image or the external CSS is loaded, helping prevent FOUC and/or reflow when the image or CSS loads. This is particularly true when dealing with idiotic browser engines (yes Gecko, I'm looking at you) that try to reflow/render after every property instead of waiting for the entire CSS file to be loaded.

I do apply them regularly:

then your Tables are busted in Firefox. Pretty notorious unaddressed bug given it's now a teenager.
https://bugzilla.mozilla.org/show_bug.cgi?id=915

Though you're example.... bgColor and no quotes around values? REALLY? REALLY? Really... What was that I always say about vomiting up HTML 3.2 and slapping a tranny doctype on it?

[Paul O'B]

I do apply them regularly:

<TABLE border=1>
<STYLE>.Desc {PADDING: 0 5px; COLOR: red; BACKGROUND: silver}</STYLE>
<COLGROUP><COL><COL class=Desc><COL align=right></COLGROUP>
<THEAD bgColor=#e4e4e4>
  <TR><TH>Name</TH><TH>Description</TH><TH>Price</TH></TR></THEAD>
<TBODY>
  <TR><TD>DH02</TD><TD>women's dress</TD><TD>$19</TD></TR></TBODY></TABLE>

The only "allowed" values for the col element are as I stated in my above post.
i.e.

* border
* background
* width
* visibility

Other properties are not defined for those elements and therefore browsers should not apply them. However some naughty browsers have decided that they will accept other values and IE6 and 7 will also accept padding and color. All other modern browsers will not accept those extra properties so it makes sense to avoid using them. Historically you may have got away with using them when IE6 had 95% of the market share but times have changed and IE6/7 are now the minor and least used browsers so you are missing the bigger audience.

You also said:

the other elements you mention above are good for targeting inner elements via context but should not really have styles applied to themselves

Please give arguments, I found none.

For browser compatibility it is best to style the inner elements although I will agree that sometimes those elements can be styled themselves as long as care is taken to check they work cross-browser. For instance I often see attempts to add borders or padding to table-rows and the user wonders why nothing happens.

[Michel Merlin]

Accessibility; DIV and TABLE wrap same way; W3-recognized vs cross-browser-tested

(deathshadow60 Mon 14 Nov 2011 08:57 GMT, #63)
I mean accessibility to content by letting the user agent best adjust the content to fit is the ENTIRE REASON T.B.L. made HTML in the first place

You apparently take here the word "accessibility" in its normal due meaning in EN, FR and most plain languages. Sure I should have written mine with quotes (« Giving "Accessibility" an absolute priority... ») to outline that I was (reluctantly) respecting those whom I was replying to, by using the fashionable twisted meaning (particularities for the impaired ones); however this was IMO quite clear if you read me in my context.

BTW, the HTML when exploding in 1993, was conceived very intelligently (with TBL surely deserving the great part usually attributed to him), with great care to keep simple, clear, logical, instinctive; and the founding concept was IMO the "hyper-text" and "hyperlinks". Separating presentation and meaning (as you seem to imply with your "letting the user agent best adjust the content") came much later and IMO is NOT in the same spirit of logical, reasonable, simple, clear design. More later if necessary.

That's one of the reasons to use DIV instead of tables when it's not tabular data

I admit to writing too fast my "DIV don't wrap either", yet this is no reason to write "I think you completely missed the point there", that does NOT apply more IMO to me than to you or others. I simply wrote too fast and momentarily confused "wrap" with "get line-broken" (see below), and my wrong writing was tacitly yet efficiently denied in the following of that same post of mine, where I also pointed the more precise and accurate writings from others: please Ctrl+F "wrap" in this page and see how well this was said by Stomme poes (22 Mar 20:52 GMT, #56, "ROWS don't WRAP") and Paul O'B (22 Mar 21:44 GMT, #57, "a table row can never wrap"). So, resuming the whole:

• words, TABLEs, DIVs, and all other HTML block elements, don't normally get cut (IOW line-broken; see syllabification), but do wrap. Sure contents inside these HTML elements "flows" thus can make the element itself adjust in height and width, but the element itself does NOT get cut.
• THEAD, TBODY, TFOOT, TR, TD, as sub-elements of TABLE, do NOT wrap.

Deported?

My context showed clearly IMO that I was comparing WIDTH and/or HEIGHT placed "inside the IMG tag" (thus as attributes), as opposed to placed farther (thus as properties), no matter whether in STYLE tags in the same page or in separate CSS files. Context also showed that I was replying to the phrase from Paul O'B that I carefully quoted (no superfluous or omitted useful characters), please refer to that context.

then your Tables are busted in Firefox. Pretty notorious unaddressed bug given it's now a teenager. https://bugzilla.mozilla.org/show_bug.cgi?id=915

thanks for pointing this. Yes I didn't test this in FF. Running the same test today with adding width and height attributes in COL #1 ("<COL width=60 height=100>") turns the following results:

• in ie6, everything tested in COL (as attributes: align. width, height; through class=Desc: PADDING, COLOR, BACKGROUND) works excepted height (that logically should work, since it does in TD).
• in Chrome (15.0.874.121m), only width and BACKGROUND work.

Though you're example.... bgColor and no quotes around values? REALLY? REALLY? Really... What was that I always say about vomiting up HTML 3.2 and slapping a tranny doctype on it?

Votes from the People, no matter through poll stations or their wallets, are IMO not less valuable than decisions from a small group as W3; checking what actually works in real world of the majority of the People is IMO not less valuable or important than what is compliant to this or that official rule or statement. So, thanks for your pointing above something that does fail in real world; OTOH, "bgColor and no quotes" (which does work everywhere with no problem at all, and that for this reason is used in plenty sites and programs) is OK for me.

(Paul O'B Mon 14 Nov 2011 10:03 GMT, #64)
For browser compatibility it is best to style the inner elements although I will agree that sometimes those (NBMM: intermediate) elements can be styled themselves as long as care is taken to check they work cross-browser

Yet, if considering what actually (instead of theoretically) works (see above), many web designers or editors (like DW) could e.g. very often (no matter using attributes in final tags or properties in STYLE or CSS) replace a large number of TD stylings with a reduced numbers of TR stylings, or with an even further reduced number of COL stylings.

Versailles, Thu 17 Nov 2011 17:07:00 +0100

[awasson]

@Michel Merlin: I think the meat of the discussion re table vs. non-table as per recommendations from W3C boils boils down to a desire for standard methods and best practices for writing/rendering HTML markup. Tables were originally intended for tabular data but they were handy for presentation when browser engines were in their infancy and CSS support was scarce so we used them. It's been a bit of an upward battle but I would guess it's been about eight years since I've had to use a table for presentational purposes. I'm pretty certain I wasn't an early adopter and there are lots of developers who were making the move as the web matured. If I take a look around at the current web landscape, current trends, mobile devices, browsers, etc... I can't imagine a reason to use a table for presentation. Can you?

[felgall]

One thing to remember is that the only HTML abd CSS standards are those with respect to what the browsers should support.

The standards say nothing whatever about what people creating web pages shoudl actually use. This will always be a subset of what the standards allow the browsers to support since many of the things that browsers are required to support are for the purpose of being compatible with the junk that people have produced over the years that worked in now obsolete browsers and which has never been fixed to comply with more modern practice. Just look at how many web pages still use a transitional HTML 4 doctype indicating that their web page still uses tags from HTML 3.2 that were deprecated in 1997 when HTML 4 was first released.

That browsers still need to support HTML 3.2 has been clearly recognised by those developing the HTML 5 standard not only in the recognition that these antiquated pages may be using tables for layout but also in the fact that all of the tags marked as deprecated in HTML 4 which therefore ought to have been completely removed in HTML 5 have had their status changed from deprecated to obsolete in order to retain them as outdated not to be used tags in HTML 5 where the deprecated status that they had in HTML 4 indicated that not only were they outdated and not to be used in HTML 4 but that they were also supposed to be completely removed in HTML 5. HTML 5 has stopped using the term deprecated and uses obsolete instead in recognition that these long outdated tags which in any other language would have fallen out of use long ago will never go away and so will continue to need to be supported by browsers in the future even though they were replaced well ovedr ten years ago.

This might also help to make it more obvious to people creating pages as to which tags they shouldn't be using as a lot of people don't appear to understand that deprecated means "obsolete and to be deleted in the next version so start replacing it now so that you get rid of it before support for it is dropped".

[Michel Merlin]

A few sites still use TABLEs for presentation

(Thu 17 Nov 2011 18:41 GMT, #66)
I can't imagine a reason to use a table for presentation. Can you?

My case doesn't count, but there are a few ones who do:

1. http://forum.hardware.fr/hfr/reseaux..._1.htm#t550801
2. http://www.htchd2forum.com/new-board...&#39;#msg31501
3. http://forums.france2.fr/france2/On-...1.htm#t1656737
4. http://www.crash-aerien.aero/forum/u...1.html#p273090
5. http://www.lesnumeriques.com/legrand...0_1.htm#t25827
6. http://gendarmes-en-colere.forum2dis...endarme#482668
7. http://forum.notebookreview.com/acer...ml#post7685775
8. http://www.1.fm/Forum/tabid/60/aff/1...fault.aspx#673
9. http://forums.thoughtsmedia.com/f398...tml#post740962
10. http://www.google.com/support/forum/...5dc24ec9202e1c
11. http://news.google.fr
12. http://forums.techarena.in/software-...ent/971830.htm
13. http://www.htmlcodetutorial.com/form...AREA_WRAP.html
14. http://bytes.com/topic/html-css/answ...-wrap-text-css
15. http://www.tizag.com/htmlT/htmltextarea.php
16. https://www.google.com/search?q=do+a+barrel+roll
17. http://www.amazon.com/dp/B005SY30I2
18. http://www.amazon.com/gp/cart/view.html
19. http://www.w3.org/People/Berners-Lee
20. http://www.santelog.com/modules/conn...cheur_6859.htm
21. https://wikimediafoundation.org/wiki/Home
22. http://www.escalade-aventure.com/tri...-desmaison.php
23. http://web.developpez.com/actu/38797...ttre-au-regime
24. http://www.forumfr.com/f517-developpement-web.html
25. http://www.nytimes.com/books/97/05/1...kes-worst.html
26. http://www.nytimes.com/2011/10/23/wo...pagewanted=all (insideNYTimesBrowser)
27. http://www.pbs.org/wgbh/pages/frontl...ies/media.html
28. http://www.rizzoliusa.com/book.php?isbn=9780847834020
29. http://allworldphone.com/satellite-dish.htm
30. http://www.codingforums.com/showthread.php?t=243752
31. http://www.webdeveloper.com/forum/sh...d.php?t=253305
32. http://forums.techguy.org/hardware/6...age-100-a.html
33. http://www.technicaltalk.net/index.p...ic,3834.0.html
34. http://www.daniweb.com/web-development/31
35. http://www.lufthansa.com/online/port...nodeid=2011003
36. http://www.databasejournal.com/featu...le.php/3927541
37. http://www.webdesignerforum.co.uk/fo...tml-javascript
38. https://bugzilla.mozilla.org/show_bug.cgi?id=448842
39. http://www.hobbyfarms.com/food-and-k...l-cookies.aspx
40. http://www.techspot.com/vb/topic173496.html
41. https://www.google.com/calendar/render?pli=1
42. http://htmlhelp.com/reference/html40/tables/table.html
43. etc, etc, etc

Are you going to tell them all to drop tables? and explain them their sites will be better and easier to build and maintain then?

Adding a few examples where "tabular data" and "non-tabular data" are intertwined in the same space:

1. http://www.ovh.com/fr/hebergement_mutualise
2. http://vlib.org/Physics

Also, see just one example where TABLE makes presentation easier, in Logo + Full-remaining-width Banner (compare and test DIV and TABLE versions).

My very 1st post in this thread replies in advance to your post right in its title, TABLE or CSS for layout must be chosen by AUTHOR, NOT by W3C, that just got confirmed in felgall Thu 17 Nov 2011 19:44 GMT, #67.

Versailles, Fri 18 Nov 2011 00:28:10 +0100

[awasson]

Actually, they could change over and probably will at some point. There is no reason they have to use tables, Just because it's what you have done up until now doesn't mean you should reject progress and better ways of doing things. I've built loads of sites using tables over my career but as the technologies matured, so did my work.

As far as "easier" goes... It depends on your skill level. Sure it's easy to whip open dreamweaver, drop a multi-column, multi-row table in and start manipulating it with joined rows/columns to get it to work but if you're used to doing complex layouts in CSS/HTML, you might find it's easier to do without tables. I know I do and I find it much easier to get browser consistency too.

[Michel Merlin]

awasson 17 Nov 23:41 GMT (#69), I don't see who you are replying to (unless you addressed me without reading me). Please tell it, otherwise posting it under my post is misleading.

Given the precedents I guess unrelated nitpicking intended to disparage instead of answering or questioning may go on endlessly, so I don't promise to continue replying. Please readers don't rely on clever 2nd-hand implying, but read original posts instead (while remembering that even they are regularly altered on all forums world-wide in their contents or context, be it only by removal of posts, preventing replies, or else).

Versailles, Fri 18 Nov 2011 01:07:00 +0100

[Paul O'B]

[/LIST]Also, see just one example where TABLE makes presentation easier, in Logo + Full-remaining-width Banner (compare and test DIV and TABLE versions).

Forgive me but I couldn't resist the challenge

Here's my CSS version that took approx 1 minute to code.

<div><img alt="RFI" src="http://www.rfi.fr/sites/rfi.fr/themes/rfi/logo.png" width="79" height="90"><a href="#"></a></div>

div {
	height:90px;
	overflow:hidden;
	position:relative;
	margin:0 0 1em;
}
div a {
	background:#475223 url(http://s0.2mdn.net/1016711/1103_LH_FR_JETTY_WEB_728x90.gif) no-repeat 0 0;
	position:absolute;
	width:999em;
	height:90px;
	bottom:0;
	margin:0 0 0 5px;
}

Works back to ie6 no problem, is valid (unlike your div version with the badly nested anchors) and much smaller html than the table version. It all depends what you are familiar with. Tables do have some useful properties and for some layouts they are certainly easier but the other 99% of the time you don't have to resort to them other than for tabular data.

[awasson]

awasson 17 Nov 23:41 GMT (#69), I don't see who you are replying to (unless you addressed me without reading me). Please tell it, otherwise posting it under my post is misleading.

Given the precedents I guess unrelated nitpicking intended to disparage instead of answering or questioning may go on endlessly, so I don't promise to continue replying. Please readers don't rely on clever 2nd-hand implying, but read original posts instead (while remembering that even they are regularly altered on all forums world-wide in their contents or context, be it only by removal of posts, preventing replies, or else).

Versailles, Fri 18 Nov 2011 01:07:00 +0100

I think you know that my post was in answer to yours. I would have thought that it was obvious by the content. Never-the-less, now you know. You don't need to answer. I was just pointing out that the list of links you posted do not have to be table layouts and your point about tables being easier was objective (ie: an opinion) and that with experience and time this observation may change.

[awasson]

After some ocnsideration, there is one place where I can find that tables are appropriate or easier to use than CSS layout techniques. I've been doing a lot of work with CMS systems and many components that provide a grid type of view will use tables to create the grids. I could re-engineer the components so that they produce a CSS layout replacing the table markup with CSS table elements but it's more cost effective for my clients to leave well enough alone.

[Stevie D]

After some ocnsideration, there is one place where I can find that tables are appropriate or easier to use than CSS layout techniques. I've been doing a lot of work with CMS systems and many components that provide a grid type of view will use tables to create the grids. I could re-engineer the components so that they produce a CSS layout replacing the table markup with CSS table elements but it's more cost effective for my clients to leave well enough alone.

So you're using bad markup to ameliorate a bad system, because it's too complicated to get a CMS working properly? And people wonder why I have to spit over my shoulder every time I say "CMS"...

[Michel Merlin]

Thanks Paul

(Fri 18 Nov 2011 00:34 GMT, #71)
Here's my CSS version that took approx 1 minute to code.

Thanks a lot (This is another DIV version, which, with my DIV and TABLE versions, are 3 CSS versions). I spent the time to complete it so to make it working, and posted it under mine 2, see Logo + Full-remaining-width Banner by Paul O'B

Versailles, Fri 18 Nov 2011 15:25:30 +0100