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.
[B]CSS apply to all HTML, including TABLEs, DIVs, etc[/B]
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”).
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?
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.
- 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”.
- 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.
- 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.
This is precisely what I said, so your “you’re putting the cart before the horse” doesn’t apply (IMO).
- 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 “I biggest flaw[/I]”. 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, [URL=“http://www.sitepoint.com/forums/showthread.php?742753-HTML-WG-approve-tables-for-presentational-purposes/page3”]HTML WG approve tables for presentational purposes - page 3](http://www.sitepoint.com/forums/showthread.php?742753-HTML-WG-approve-tables-for-presentational-purposes/page3#post4840275)), 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.
- 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.
Putting WIDTH and/or HEIGHT inside the IMG tag or in deported CSS produces the same result.
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.
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.
I do apply them regularly:[INDENT]
<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>
[/INDENT]
You also said:
Please give arguments, I found none.
Versailles, Mon 14 Nov 2011 00:58:00 +0100
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”.
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.
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.
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.
then your Tables are busted in Firefox. Pretty notorious unaddressed bug given it’s now a teenager.
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?
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:
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.
Accessibility; DIV and TABLE wrap same way; W3-recognized vs cross-browser-tested
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 "[URL="http://en.wikipedia.org/wiki/Hypertext"]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.
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 ([URL=“http://www.sitepoint.com/forums/showthread.php?742753-HTML-WG-approve-tables-for-presentational-purposes/page3#post4840229”]22 Mar 20:52 GMT, #56, “ROWS don’t WRAP”) and Paul O’B ([URL=“http://www.sitepoint.com/forums/showthread.php?742753-HTML-WG-approve-tables-for-presentational-purposes/page3#post4840275”]22 Mar 21:44](http://en.wikipedia.org/wiki/Tim_Berners-Lee) 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.
My context showed clearly IMO that I was comparing WIDTH and/or HEIGHT placed “inside the IMG tag” (thus as attributes[/I]), as opposed to placed [I]farther[/I] (thus as [I][URL=“http://www.w3schools.com/cssref/pr_dim_width.asp”]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.
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.
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.
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
@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?
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”.
[B]A few sites still use TABLEs for presentation[/B]
My case doesn’t count, but there are a few ones who do:[LIST=1]
[]http://forum.hardware.fr/hfr/reseauxpersosoho/Reseaux/heure-internet-lettres-sujet_23303_1.htm#t550801
[]http://www.htchd2forum.com/new-board-23/‘must-see-video!!’'#msg31501
[]http://forums.france2.fr/france2/On-n-est-pas-couche/defalvard-pulvar-audrey-sujet_25344_1.htm#t1656737
[]http://www.crash-aerien.aero/forum/un-avion-de-l-armee-de-l-air-chilienne-s-ecrase-en-mer-t19861.html#p273090
[]http://www.lesnumeriques.com/legrandforum/avis/Ordinateurs-Composants/ordinateur-portable/ordinateur-timelinex-portable-sujet_3360_1.htm#t25827
[]http://gendarmes-en-colere.forum2discussion.net/t22403p720-si-c-est-vrai-j-aurais-eu-honte-d-etre-ce-gendarme#482668
[]http://forum.notebookreview.com/acer/491169-acer-timelinex-3820tg-backlit-keyboard-mod-51.html#post7685775
[]http://www.1.fm/Forum/tabid/60/aff/1/aft/404/afv/topic/Default.aspx#673
[]http://forums.thoughtsmedia.com/f398/neohand-weather-center-1-08-a-67499.html#post740962
[]http://www.google.com/support/forum/p/Chrome/thread?tid=495dc24ec9202e1c
[]http://news.google.fr
[]http://forums.techarena.in/software-development/971830.htm
[]http://www.htmlcodetutorial.com/forms/_TEXTAREA_WRAP.html
[]http://bytes.com/topic/html-css/answers/627827-how-wrap-text-css
[]http://www.tizag.com/htmlT/htmltextarea.php
[]https://www.google.com/search?q=do+a+barrel+roll
[]http://www.amazon.com/dp/B005SY30I2
[]http://www.amazon.com/gp/cart/view.html
[]http://www.w3.org/People/Berners-Lee
[]http://www.santelog.com/modules/connaissances/actualite-sante-depigmentation-de-la-peau-les-pieges-de-la-blancheur_6859.htm
[]https://wikimediafoundation.org/wiki/Home
[]http://www.escalade-aventure.com/trilogie-jorasses-gousseault-desmaison.php
[]http://web.developpez.com/actu/38797/jQuery-va-se-mettre-au-regime
[]http://www.forumfr.com/f517-developpement-web.html
[]http://www.nytimes.com/books/97/05/18/reviews/960514everest-takes-worst.html
[]http://www.nytimes.com/2011/10/23/world/africa/in-his-last-days-qaddafi-wearied-of-fugitives-life.html?pagewanted=all (insideNYTimesBrowser)
[]http://www.pbs.org/wgbh/pages/frontline/everest/stories/media.html
[]http://www.rizzoliusa.com/book.php?isbn=9780847834020
[]http://allworldphone.com/satellite-dish.htm
[]http://www.codingforums.com/showthread.php?t=243752
[]http://www.webdeveloper.com/forum/showthread.php?t=253305
[]http://forums.techguy.org/hardware/622796-solved-cpu-usage-100-a.html
[]http://www.technicaltalk.net/index.php/topic,3834.0.html
[]http://www.daniweb.com/web-development/31
[]http://www.lufthansa.com/online/portal/lh/th/specials/booking?nodeid=2011003
[]http://www.databasejournal.com/features/mysql/article.php/3927541
[]http://www.webdesignerforum.co.uk/forum/24-css-xhtmlhtml-javascript
[]https://bugzilla.mozilla.org/show_bug.cgi?id=448842
[]http://www.hobbyfarms.com/food-and-kitchen/bull-cookies.aspx
[]http://www.techspot.com/vb/topic173496.html
[]https://www.google.com/calendar/render?pli=1
[]http://htmlhelp.com/reference/html40/tables/table.html
[*]etc, etc, etc
[/LIST]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:[LIST=1]
[]http://www.ovh.com/fr/hebergement_mutualise
[]http://vlib.org/Physics
[/LIST]Also, see just one example where TABLE makes presentation easier, in [B]Logo + Full-remaining-width Banner[/B] (compare and test DIV and TABLE versions).
My very 1st post in this thread replies in advance to your post right in its title, [B]TABLE or CSS for layout must be chosen by AUTHOR, NOT by W3C[/B], that just got confirmed in [B]felgall [/B] [URL=“http://www.sitepoint.com/forums/showthread.php?742753-HTML-WG-approve-tables-for-presentational-purposes/page3#post4995512”]Thu 17 Nov 2011 19:44 GMT, #67.
Versailles, Fri 18 Nov 2011 00:28:10 +0100
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.
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
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.
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.
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”…
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 [B][URL=“http://www.sitepoint.com/forums/showthread.php?797765-How-can-I-get-a-browser-wide-banner-and-use-a-repeating-graphic-element-for-it#post4996139”]Logo + Full-remaining-width Banner by Paul O’B
[/B]Versailles, Fri 18 Nov 2011 15:25:30 +0100
Nope… It’s working fine and the markup is valid. It’s because whoever created the particular module that puts out the markup thinks it’s ok to use tables for this data. Arguably it is ok too because generally these modules are used to create a grid of serialized links.
- I could preprocess the output if I wanted to be that critical but I don’t see how the additional cost would benefit my clients.
One thing to remember is that there are now some browsers that do not allow the table borders to be turned off (there’s at least one browser for mobile devices that does this) and so if a table is used for layout then it will be extremely obvious in those browsers where the cell borders run through the page content.
CHRISTMAS ON A CRACKER that’s some fist-full of ugly code in that thread. Mein gott where’s that nun with the metal yardstick I learned coding from when you need her. (I’m looking at that and depending on the images and contnet wonder why it even has an IMG tag).
Let’s see if I can make sense of the rest of your post… Apologies but I’m having great difficulty deciphering your posts… Almost as much trouble as I have with your DECADE OUT OF DATE code… from what I’m seeing your HTML looks about as good as my French.
Then you need to learn more about HTML and why it exists. One of the entire reasons it was created was that at the time no two possible devices had the same capabilities – a situation we still have today. Back then you had screens ranging from 22x21 text only to 1280x1024 fully addressable… you had daisy wheel printers, line printers, teletypes, and a whole host of other devices in use to which you might send a document. One of the entire core purposes of HTML was that no matter what the device, the output could be customized to the target without losing meaning. Didn’t matter if it was a C=64, a NeXT workstation, a DEC Rainbow, VT-100 Terminal, Model 33 Teleprinter, or some massive supercomputer that hadn’t even been dreamed up yet, you could customize the output thanks to the markup saying what things ‘are’, and then letting the user agent best determine how to show it.
Which is why TBL’s prototype browser actually had what today we’d call “user stylesheets”… customizing for screen capabilities or print capabilities… the idea being that user agents (browsers) not web developers would be the ones to determine how to best present the meaning of the markup. It’s why the specification is still filled with “would, could, may, might, typically” and not a whole lot of “should” or “must”.
Sorry, but that feels remarkably like it should be one of the lame excuses for not being a web professional…i[/i]
Not following rules or guidelines set down as best practices just makes more work for anyone stuck trying to maintain it, and quite often wastes bandwidth… yes, wastes it because external style is cached across pages; markup is not. (another of the reasons separation of presentation from content is a good thing).
Sleazing out HTML 3.2 with late 90’s style presentational markup is nothing more than crapping out the page any old way, and it does cost in terms of ease of maintennance, speed of development, consumption of bandwidth, and a whole host of other issues – which is WHY that approach to coding is repeatedly given a kick in the crotch by anyone with even the most basic understanding of how this stuff works. Sleazy shortcuts and decade out of date methodologies are sleazy shortcuts and decade out of date methodologies – no matter how you color them.
Just because something works doesn’t mean it won’t bite you in the backside eventually.