...

View Full Version : <td>'s Greater Meaning?



bluephoenix
01-09-2003, 03:47 AM
Last question for the evening, I promise :)

My sister is learning HTML and she asked me what does <tr> and <td> stand for... I told her I assumed <tr> was was table row, but as for <td> I haven't got a clue.

Anyone?

jkd
01-09-2003, 04:01 AM
Table data. Contrary to common practice, tables hold data, and are not presentation tools.

Table-based layouts are usually disaster for accessibility, and totally slaughters any semantic meaning to HTML.

mouse
01-09-2003, 04:51 AM
Now Bluephoenix, your misssion if you choose to accept it, is work out what <TH> means :D



...okay it's not hard.



Specifying text sizes in px seems to stuff things too, you can't enlarge or reduce text in IE unless it's pt (I assume).

nickbarresi
01-09-2003, 07:28 AM
<TR> is a new table row and <TD> comprises each data cell in a particular row...

nickbarresi
01-09-2003, 07:35 AM
Originally posted by jkd
Table data. Contrary to common practice, tables hold data, and are not presentation tools.


I'm just a newbie, but what the heck do you mean? Most sites I've seen use tables for presentation tools :confused:

jkd
01-09-2003, 08:13 AM
I meant just what I said. Tables were never meant for use as presentational elements. Nor should they be used as presentation elementsm as they tend to pose a severe problem with web accessibility, among other things.

I've been able to do most layouts I've seen with CSS and proper markup, and this includes layouts that use complex tables nested several layers deep.
(And when CSS3's column-related properties are standardized, multi-column layouts become that much easier.)

Spookster
01-09-2003, 09:27 AM
Originally posted by jkd
I meant just what I said. Tables were never meant for use as presentational elements. Nor should they be used as presentation elementsm as they tend to pose a severe problem with web accessibility, among other things.

I've been able to do most layouts I've seen with CSS and proper markup, and this includes layouts that use complex tables nested several layers deep.
(And when CSS3's column-related properties are standardized, multi-column layouts become that much easier.)

And that severe problem would be??? Tables work just fine for doing layouts. Don't confuse the newbies now.

Layouts using nothing but positioned layers are not very accessible for screenreaders. Wouldn't you consider that a "severe problem" as well? Hmmm? :cool:

brothercake
01-09-2003, 10:29 AM
The problem with screenreaders and tables is that the readers don't know whether to read across or down; depending on the table content, one or the other might make more sense, but the reader can't know that.

But this applies to any table - whether it's presentational or a true data-table; so ditching table layouts because of that one issue is not the obvious conclusion it might seem.

I'll echo Spookster's point - although this is a potential problem, it quickly pales compared to the problems with positioned-div based layouts; even today, these are very difficult to implement x-browser, due to a variety of inconsistencies and bugs; impossible if you factor in legacy browsers like ns4 and ns3. Table layouts are okay; try making this page without them ...

Something to work with - a very basic table layout like this:

<table align="left" width="20%"> ... left nav bar ... </table>
<table width="80%"> ... main content ... </table>

is no more of a problem for screenreaders than the same layout in DIVs.

Really .. design itself is what cause screenreader problems. Their ideal page has no styling or layout at all, but is simply linear text in headings and paragraphs. Ideally, we'd all be making our pages in pure XML and serving user-preferenced data presented any way they want. But one thing at a time, eh :rolleyes:

jkd
01-09-2003, 08:04 PM
Straight from the HTML 4.01 specification (http://www.w3.org/TR/html4/struct/tables.html#h-11.1):


Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.


I'd like to believe the people who created HTML know what they are talking about.

brothercake
01-09-2003, 08:16 PM
They know what they're talking about; that doesn't mean their designs are completely right, or that their assumptions are correct. ie - "this may present problems" - which doesn't mean it will, only that the potential is there.

I hear a lot of talk about what "might be a problem for screenreaders" but who here actually uses a screenreader to test their layouts? I do, and I can tell you from experience that table-based layouts are not inherently problematic when used intelligently.

I have no particular affinity with tables over any other element; they're just so damn useful. Show me a realistic alternative and I could be persuaded to change my mind ...

As a side note - it is dangerous to treate the w3c like they always know best. What about "px" defined font sizes - afaik the standards aren't implicit about whether these should be resizeable or not. We all know in hindsight that they should be, but the initial ambiguity means that early adopters (ie, ns4) implemented it as fixed - because the priorities at that time were more eye-candy features for the sake of easier corporate branding which the commericalisation of the web was demanding. So many or most of us have "grown up" using non-resizeable text without even realising it.

To adopt an attitude that you shouldn't use something for anything other than its original purpose seems rather short-sighted to me. Guitar amplifiers were never designed to be deliberately distorted; but where would rock music be without it ...

jkd
01-09-2003, 08:18 PM
Originally posted by Spookster
Layouts using nothing but positioned layers are not very accessible for screenreaders. Wouldn't you consider that a "severe problem" as well? Hmmm? :cool:

How can you possibly say that? A correctly done CSS-layout, when all the style is removed (content is read from top to bottom regardless), remains very readable, logical, and easy for any user agent to present to the user.

A table layout's structure is more often than not, completely out of synch from the logical order of content. This makes it a pain for blind people, as the content order no longer makes sense as it did in the visual representation.

And besides, tables were never meant for presentation. If you do write table-based layouts, you aren't writing correct HTML. Do you use an axe to put a nail throuh a board? No, you use a hammer. Do you use a table to present a webpage? No, you use CSS.
Completely different tools for specific jobs.

jkd
01-09-2003, 08:28 PM
Originally posted by brothercake
To adopt an attitude that you shouldn't use something for anything other than its original purpose seems rather short-sighted to me. Guitar amplifiers were never designed to be deliberately distorted; but where would rock music be without it ...

What about separation of content and presentation? Tables wreck that, as the presentation is inherently dependent on the markup.

HTML is not a layout language. Never was, never will be. There are well-defined semantics to each tag, not well-defined presentation. Show me where in the specs does it say that a <select> should render as a dropdown menu? It says a <select> creates a menu, which is defined as:


Menus offer users options from which to choose. The SELECT element creates a menu, in combination with the OPTGROUP and OPTION elements.


A user-agent can choose however the heck it wants to render that.
Same is true for many other tags.

Phip
01-09-2003, 08:32 PM
Originally posted by mouse
Now Bluephoenix, your misssion if you choose to accept it, is work out what <TH> means :D



...okay it's not hard.



Specifying text sizes in px seems to stuff things too, you can't enlarge or reduce text in IE unless it's pt (I assume).


Table Header, no?

Roelf
01-09-2003, 09:14 PM
Originally posted by Phip
Table Header, no?

Correct, i see you learned from the above discussion :D

Tails
01-09-2003, 09:17 PM
Does anybody ever use <TBODY> and <COLGROUP> tags? I never see any tutorial cover them, so I'll tell you what they do. You know how TD inherits bgcolor, etc from TR, and that from TABLE which gets bg from BODY. Here's a more complex level of tabling:

<TABLE>
<COLGROUP>
<COL>
<TR>
<TD></TD>
</TR>
</COL>
</COLGROUP>
<TBODY>
<TR>
<TD></TD>
</TR>
</TBODY>
</TABLE>

Each tag here can have some attribute like bgcolor That tree is an example of how some less known tags can override their parent tags. Also, note that COLGROUP has higher priority than TBODY. These tags can save you lots of space if used wisely. As in "making each first cell in a group of rows in a table a certain color". CSS2 can also define this more, but I don't know any browser that implements it.

brothercake
01-09-2003, 09:18 PM
Originally posted by jkd
What about separation of content and presentation? Tables wreck that, as the presentation is inherently dependent on the markup.

Well yes ... and no. I mean, browsers which don't support tables will render a 3-column table layout exactly the same as a 3-column div layout.

I totally agree about wanting to seperate content and layout ... but ... well surely the epiphany of that is to keep the data in XML - if that's the situation, then what does it matter? We could go back to using <font> tags inside the XSLT and we'd still have total seperation of layout and content :D

mordred
01-09-2003, 11:54 PM
Interesting discussion about the pros and cons of <table> layouts in HTML. Personally, a purely CSS layout gives me most of flexibility should I decide to switch the arrangement of my layout. Just change in a central stlye sheet some positioning values and that's it. Far more difficult to achieve when your layout is forced into a table, when you can't simply say the "the left column is now right of the right-most column" without going through each tag and manually rearranging the layout.

On the other hand, tables are somewhat an easy-to-use and common metaphor for the design of layouts. Print layout programs often have a UI that enables you to work in a grid that's quite easily associated with a HTML table. And although CSS is fine and widely supported nowadays, some layouts are just not easy and quick to do in pure CSS. How would you make a layout that consists of two parallel columns which stand beside each other, each has a different background color and both have the same height, depending on the most textual content in one? I'm eager to know if there's an easy way to do it only in CSS without resorting to background graphics. For such a scenario, why refuse tables?

The semantic nature of HTML is indisputable. Well, at least that's what it has been thought for by the inventors. But HTML *is* used as an layout language today, because it simply is the language that makes the browser render a web page. Granted, we don't need to use spacer images any longer (unless were supporting NN4), but that doesn't mean that a table is totally useless for layout purposes. In the end, it's the user that uses a design. And usually he doesn't care a lot if it's HTML, XHTML or XML beneath it - just for the same reason you don't rate a Picasso worse if it's painted on canvas than on recycable paper.

Just wanted to say that the issue is just a little bit more complex than breaching the intent of a semantically correct document structure. :)

bluephoenix
01-10-2003, 02:34 AM
Ah, I seemed to have struck a sensitive nerve amongst people... but discussion is good.

I've been doing webdesign for the past 5-6 yrs, and I'm far from being an expert but I've made and learned from a few mistakes. Here's my thoughts on tables.

They're there, we might as well use them. If planned and used correctly, they're not going to overscroll to the right nor confuse readers.

I've seen sites that use style sheets instead of tables and the formating is totally destroyed if you change the defult size of your font. Whereas if were set up in a table, then it'd all expand proportionally and wouldn't wouldn't be cutting intoeach other... And even so, If I'm hard of seeing and I crank up my font size, I have to expect that I might have to scroll a bit to the right once in a while (and no, I'm not being biased; sure I like my screen set at 1024x768, but I have a wireless keyboard and sometimes I'l lsit on the bed across the room and will have to smack the resolution down to 600x480.)

When you're designing a personal website, sure, use all the cool stuff you can.. .but if you're aiming for accessibilty, I don't think CSS is flawless on IE3.

SVG is better than gifs... but what mainstream browsers support them natively?

Yes, the new technologies have to be utilized before they catch on... I love CSS and SVG and SMIL and MathML and XML and whatnot just as much as the next guy, and laboriously pour over the W3 spcs. But when it comes to something that has to be accessible, bottom line you have to push the cool stuff aside and go for the lowest common denominator.

Tables work on IE3, CSS2 does not.

There... that's my two cents.

(and for the record, I do like stylesheets. They make my life a hell of a lot easier.)


and um... TABLE HEAD.

:)

CRASH_OVERRIDE
01-10-2003, 03:15 AM
[see below entry (double post), sorry;)]

CRASH_OVERRIDE
01-10-2003, 03:19 AM
I have used tables throughout all of my web designing, and they have almost always given me problems (fixible, yes). But what jkd said has me now... DIVs and SPANs can do as much, if not more than tables can do. Although, tables have always been better for displaying news update tables, data islands, etc..I think. :) and bluephoenix made a good point about the font size setting thing & CSS, but you can always make your font sizes unchangable.


Originally posted by bluephoenix
Tables work on IE3, CSS2 does not.

Who uses IE 3.0 anymore anyway? Unless your old grandma is surfing the web and doesnt know squat bout PC's, I would say IE3 is near extinct. u p d a t e :thumbsup:

jkd
01-10-2003, 03:32 AM
Originally posted by CRASH_OVERRIDE
and bluephoenix made a good point about the font size setting thing & CSS, but you can always make your font sizes unchangable.

No you can't. A proper text zoom (such as the one in Mozilla) resizes ALL text, even px-defined ones. 125% of 10px is 12.5px. IE not doing that is pretty stupid, considering how easy it is to implement.

And text-zooming is not any more a problem in properly done layouts than it is in a table-based layout. There are properties that control word-wrapping, min/max widths, etc.

CRASH_OVERRIDE
01-10-2003, 04:06 AM
And jkd reinforces his case...
nice metaphors everyone:D

Spookster
01-10-2003, 07:31 AM
Originally posted by jkd
How can you possibly say that? A correctly done CSS-layout, when all the style is removed (content is read from top to bottom regardless), remains very readable, logical, and easy for any user agent to present to the user.

Have you ever actually used a screenreader? I do much development for a large university that requires the sites to be completely accessible by screenreaders. I use nested tables for layout and screen readers don't have a problem with it. I originally tried to use layering for layout and fancy menu systems and such and the screen readers freaked out and couldn't properly read the pages. Not to mention the Bobby software which is similar to HTML validators but for screenreaders always red flagged using positioned layers in the pages.

Just remember there is a big difference between what you read in a book and what actually happens in the real world. The W3C is not a bible.

Personally I think the people that develop these screenreader software need to get with the times and develop smarter software because it is often a pain to have to constrain a design to be within a screenreaders capability.

Just out of curiosity I ran w3c's site through Bobby and it failed miserably. :)

jkd
01-10-2003, 08:15 AM
Originally posted by Spookster
Just out of curiosity I ran w3c's site through Bobby and it failed miserably. :)

W3C's site has always been a little behind the times. Until recently it even used a table-based layout :eek:. Now it uses CSS to do everything, and even makes use of tag semantics (like <map> to define the site map, etc), though the document structure is still not entirely "accessible".
(They should go content first, then A-Z column, then that 3rd column - they could interchange A-Z and the 3rd column though).

nickbarresi
01-10-2003, 10:17 AM
Hey can you guys show me what you're talking about? Maybe some links that use CSS for layout, etc.

brothercake
01-10-2003, 10:34 AM
Originally posted by jkd
W3C's site has always been a little behind the times.

Not to mention butt ugly :D

That's cool though; horses for courses and all that. It's just that in the commercial arena, a certain amount of corporate branding is required. The w3c site may exemplify best practise in many ways, but in other ways it sucks badly.

Don't have much else to say on this except a quick note to bluephoenix - imo XML is not too new to be useful; client-side transformation/DOM manipulation arguably is, but the underlying XML/Transform paradigm is very strongly established. Personally, I foresee a not-very-distant future where most web pages are written in XML, and transformed on the server into client-specific output (such as HTML).

And to CRASH ... if "DIVs and SPANs can do as much, if not more than tables can do" then look at this example (http://www.brothercake.com) In the middle - those nine blocks of text - how can that be done, and correctly aligned within the document as a whole, in pure, non-absolutely positioned CSS? Not to be argumentative ... if you have a way I'd really like to know.

Tails
01-14-2003, 09:13 PM
Does anybody ever use <TBODY> and <COLGROUP> tags? I never see any tutorial cover them, so I'll tell you what they do. You know how TD inherits bgcolor, etc from TR, and that from TABLE which gets bg from BODY. Here's a more complex level of tabling:

<TABLE>
<COLGROUP>
<COL>
<TR>
<TD></TD>
</TR>
</COL>
</COLGROUP>
<TBODY>
<TR>
<TD></TD>
</TR>
</TBODY>
</TABLE>

Each tag here can have some attribute like bgcolor That tree is an example of how some less known tags can override their parent tags. Also, note that COLGROUP has higher priority than TBODY. These tags can save you lots of space if used wisely. As in "making each first cell in a group of rows in a table a certain color". CSS2 can also define this more, but I don't know any browser that implements it.

applesauce
01-15-2003, 06:54 PM
Hey can you guys show me what you're talking about? Maybe some links that use CSS for layout, etc.

here's a great one:

http://glish.com/css/

ez4me2c3d
01-16-2003, 01:34 AM
everyone (well, most of you) has a good point.

IMO it's who are you designing the site for? target audience.

I am in the military and travel around alot. My web page is for my family to keep up with my life even if I am around the world and back. they don't run ie3, nor opera, or any other browser other then ie5+. None of my family is blind and they certainly dont care if i misuse tables when designing my layout.

now I know my site doesn't mean much or anything at all to the world, but target audience is what im saying.

how many of you offer translations on your page for every single language spoken? I bet none of you.

so why worry about something as small as using tables for layout when there are bigger fish to fry. like filling your site with some interesting content that hasn't been written about a billion times over on the web.

EDIT: im pro table layout

krycek
05-05-2003, 03:28 PM
OK guys, Matt (missing-score) just drew my attention to this thread.

I'm coming down heavily on the side of jkd here :D and as something for you to dissect and dismember and generally look at, take a gander at my site SOAPI (http://www.soapi.com).

OK I know not a lot is happening there right now, but the point is the it uses pure CSS, and not a table in sight! :p

Now, I can open my SOAPI site from lynx and view it all perfectly, navigate fine, etc. etc. Whereas if I come to CF in lynx, for example, it's a nightmare...

This serves to show how well a CSS-based layout degrades. The best thing, in my opinion, is not accessibility to screen-readers - in my mind that's a good side-effect, but I've never used a screen-reader in my life and I couldn't care less about them ;) IMHO the best thing is the way different stylesheets can be used to transform the content for a variety of purposes... simply for different skins; or for different media such as screen and print; or many other things.

I don't see why a good designer should not use a CSS-based layout. It has so many advantages compared to using tables instead. :)

::] krycek [::

brothercake
05-05-2003, 03:33 PM
Old thread mate ... even I've changed my mind by now ;)

http://www.codingforums.com/showthread.php?s=&threadid=16799
http://www.codingforums.com/showthread.php?s=&threadid=13083

for similar discussions ...

krycek
05-05-2003, 04:26 PM
Damn you missing-score!!! :p

I didn't read the date... I assumed that because he messaged the link to me, it was a recent discussion... lol...

(/me makes a mental note to read the dates of posts in future!) :p

::] krycek [::



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum