Forum Moderators: mack
Stephen
I wrote this trying to convince a friend to switch:
"CSS gives you the ability to cut down all that nasty code, cut down the page size, separate style from content, make the page load faster for visitors, avoid tag redundancy throughtout your page, have standards compliance, make it easier for spiders to crawl your page, put content at the top of the page to help with spiders/search engine crawling, let visitors have printer friendly pages without having to make duplicate pages, use external stylesheets to style elements on all pages, create fluid layouts, create redesigns easily, let you have control over all properties of any element on the page, much better border control, and I can probably keep going for a few more lines but I think the point is made."
He did, and is happy I convinced him :)
But if you still don't want to make the switch to a complete CSS layout, at least use CSS to get the table tags down as much as possible. If you need to use tables, just use them for the structure or "skeleton" of the site.
Nothing wrong with tables. Some people are trying to go all out with the whole CSS2 thing.. tables are the best bet.
Nothing wrong with tables? Eh?
You mean apart from..
The only good time to use a <table> tags is when you actually want a table of information (like a timetable for instance).
Otherwise, yes, tables for layout are "bad" and should be avoided if possible.
scockerham its good that you are learning how to code by hand - its the best way to get maximum flexibility and the best understanding of how your site works.
The fastest way to learn all the commands? I wish I knew.
Probably lots of experimenting, keep reading these forums (especially the CSS one), download the CSS and HTML4.01 specs from the W3C [w3.org] and keep them handy.
Columns are used to specify different type of information. (Age, sex, address, photo)
Rows are used to arrange that information in individual records (John, Carla, Jules, Martha)
Hope it helps.
(tables) are not accessible to screen readers
This is untrue. As long as a table linearises without problems i.e. the table content makes sense when read in the order it appears in the html, there will be no problems.
Tables do not usually present a problem for screen readers. Try it out for yourself with the downloadable Jaws trial.
Looking back in time, tables were original implemented for data and for magazine type column layouts. The "tables were only meant for data" meme is a myth. :)
You may find that using tables results in a more robust, more compatible design for the browsers your visitors use.
As long as a table linearises without problems i.e. the table content makes sense when read in the order it appears in the html, there will be no problems.
And if your using a table for layout then what are the chances of that exactly? Very little I would have thought.
tables were original implemented for data and for magazine type column layouts. The "tables were only meant for data" meme is a myth
Looking back in time, tables were introduced in html 3.2 in 1997 and even in those bad old days they were warning against using them for layout..
"[tables] can be used to markup tabular material or for layout purposes. Note that the latter role typically causes problems when rending to speech or to text only user agents." - from [w3.org...]
These days HTML is supposed to be about pure semantics and document structure, thats why tags like <center>, <font>, <b>, <i> etc have been deprecated and thats also why tables should only be used for tabular data.
I'm just trying to put the pragmatic side here: there's what the w3c say, and there's what works in the real world.
For most web sites trying to be "semantic" will be a complete waste of time - unless there is some reson to use semantic markup eg sector-specific widely implemented industry standard DTDs, which there isn't. So currently everyone's making up their own semantics, which rather defeats the point (I'll stop now to prevent this thread going wildly off-topic :))
Tables usually linearise ok - try it out for yourself with a screen reader or text only UA
I have done. :) I downloaded IBM HomePage Reader which is quite a popular screen reader to demonstrate to my client just how badly some of their competitor websites handled screen readers. One of the problem was that they had used tables for layout so you got weird things happening: like the heading for one section followed by the text for another because they had used code like this..
<table>
<tr><td>Heading One</td><td>Heading Two</td>/tr>
<tr><td>Story One</td><td>Story Two</td>/tr>
</table>
Properly marked up tabular data works okay because it has proper column and row headings for the screen reader to use when identifying its position in the table (e.g. it might say "Product: Widgets", "Colour: Blue", "Number: 5")
For most web sites trying to be "semantic" will be a complete waste of time
I completely disagree. I'm not talking about producing a site in your own XML dtd. I'm just talking about having style seperated from content and using HTML that correctly reflects the document structure by using the right tags (e.g. <h1-6>, <strong>, <em>, <p>, <ul>, <address>, <label> etc)
This is definitely NOT a waste of time. First of all, spiders love it: there is a high content:code ratio and proper tags mean proper interpretation. Secondly, your site starts working on new devices without you doing anything (my current project looks great on a PDA and I've never specifically coded anything to handle it). Thirdly, its so flexible: you can change the look of your site from a single file and you can offer your readers multiple looks depending on their needs.
sector-specific widely implemented industry standard DTDs, which there isn't
HTML4.01 Strict [w3.org] works for me pretty well. :)
<table>
<tr><td>Heading One
Story One</td>
<td>Heading Two
Story Two</td>/tr>
</table>
Would present no problems. This imho is the more common real world layout eg main content and nav bar.
It's a shame you chose Homepage Reader as this is not widely used among folks with visual impairments (possibly not at all: it doesn't read emails, OS dialogs, Word docs etc so is a bit useless). Most use Jaws with IE for browsing. Homepage reader may interpret your tabular data markup, but Jaws doesn't AFAICR. I strongly urge you to try it out.
Good HTML markup and CSS result in good pages: semantics don't come into it. Using <b> rather than <strong>, <i> rather than <em> will increase your content:code ratio ;)
BTW the html 4 spec does not specify any semantic markup eg what is the standard for marking up breadcrumbs? Are breadcrumbs part of a document or just presentational elements? etc
So I s'pose the answer to the original question is: some folks think it's fine to use tables, some folks think it really is not! :)
For example, the example of the heading and the story use for table is a good one. This could quite easily be classed as tabular data.
However, I belive that scockerham was probably referring to an overall page design using tables. In this case, you generally get a very high spreading of content around the cells, with little of the order that is evident in the example you cited.
When tables are used for page design, screen reader users have difficulties in associating information. CSS is perfect for this, as it allows for the seperation of design and content. scockerham, I'm afraid that there is no hard an fast rule. Some people agree with non-table based layouts, and some disagree.
The point about semantics is being taken out of context. The tags mentioned give no real meaning to the text contained in them, so there are no real semantics on the page. However, these tags do have important value in accessiblity, usability and search engine friendliness.
The idea of the Semantic web as put forward by Tim Berners-Lee is still in a theoretical state. To achieve this a set of schemas need to be created to give meaning to page. This meaning is for use by agents, which in turn allows users to search (using the agents) for information and receive intellegent results.
The tags mentioned give no real meaning to the text contained in them
I'd disagree there. I'd say all Strict tags give some meaning to the text that they contain. Surely thats the point.
Using <b> rather than <strong>, <i> rather than <em> will increase your content:code ratio
Depends how you count it really - its the same number of tags and attributes, just a different number of bytes. ;)
I'd disagree there. I'd say all Strict tags give some meaning to the text that they contain. Surely thats the point.
I don't know. We may be disagreeing on semantics here ( ;) ), but surely the tags mentioned give emphasis and weight to text, but no real meaning?
<strong> says to me that the text is important or carries weight in some way - it does not give any real meaning to or explaination of the text it applies to.
The purpose of HTML is to define meaning in terms of document structure.
"this text is important" (em,strong)
"this is a header" (h1-6)
"this is a table" (table)
"this is a quote [from this source]" (q,blockquote)
"this is a link to something" (a)
etc
What is actually in these tags is largely irrelevant (provided it complies with the DTD).
Likewise if you had an product catalog with an XML schema it might define meaning in terms of a product..
<product>
<name>Widgets</name>
<colour>Blue</colour>
<size>Quite Big</size>
</product>
But it doesn't tell you what a widget is or why its quite big and blue.
hope I'm making sense here...
