if non-working they can get up to $600-$700/month I believe… And up to $800 total if working + disability check in the US
If it will offer any kind of advantages in any situation, why not? I don’t believe in rules and going strictly “by the book”. I wouldn’t choose it and use it in every situation (if I would use it at all), nor do I do that with any CMS or framework—always choose what suits the purpose. It’s nice to have alternatives, isn’t it? Trying to always keep an open mind.
Precisely the reason I don’t used them for layout. Alos Paul O’B had a point about nested tables and newbies abusing them because it’s easy to do.
I don’t really care about W3’s opinions or discussions amongst themselves… It really makes no difference to me but I do worry that new developers will get in the game and produce large swaths of spaghetti table code where it isn’t necessary.
Which is why I know some people who’ve tried to make them out of old print heads from dot matrix printers.
While I haven’t examined the innards of dot matrix printers, I believe they would need to be modded quite a bit.
Yeh… the print head of a dot matrix is a line of 8 (i think) pins. Each character in braille is a 2x3 matrix… not going to be very easy!
Slightly off. Standard Braille is a 2x3 matrix, however refreshable braille displays are usually 2x4, why? Unicode.
A number of 24 pin printers (which were pretty common towards the end) have 3 offset rows of 6. use two pins at a time and just don’t use the center row…
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.
Versailles, Tue 22 Mar 2011 19:08:15 +0100, edited 19:12:00
[B]TABLE-based layouts are as elastic as CSS-based[/B]
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.
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:
[INDENT]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.[/INDENT]
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.
Versailles, Tue 22 Mar 2011 19:16:00 +0100, edited 19:17:50
What are your suggestions?
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.
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).
- 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).
- 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):
- 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);
- 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.
- 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
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.
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.
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:
[INDENT]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.[/INDENT]
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.
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).
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.
If we use the table for presentation it has not much more descriptive. For presentation content should be self descriptive.
Mariya, can you explain your thoughts some more, I don’t quite follow you.