Barry Pearson scribbled something along the lines of:[color=blue]
> Ashmodai wrote:
>
> Before I answer your points, I'll repeat my statement that is under discussion
> here: "Right from their start in about 1993, tables were intended, inter alia,
> for laying out complex material in rows & columns".
>
> My reason for repeating this is that I suspect you mostly don't address that
> statement. You appear to be arguing against some other points. I intend to
> keep dragging this discussion back to that statement.[/color]
Please get some grip of the real world and begin to learn that you
cannot address every statement directly. In many cases the solution is a
LITTLE more complicated.
Try and address the statement "Computer games cause violence" directly.
Of course "In about 19993 tables were intended [..] for laying out
complex material in rows and columns", but the statement "right from
their start" implies they are still intended for that purpose, which is
not the case and that is what I'm proving to you.
<snip/>[color=blue]
> What has W3C got to do with this? Raggett published the HTML+ proposal in
> November 1993. W3C came into being in October 1994. W3C established the
> recommendation for HTML 3.2 in January 1997. It said tables "can be used to
> markup tabular material or for layout purposes". Tables *long* preceded W3C!
> They were proposed, and implemented, and took-off in the world, before W3C
> said anything useful about them.
>
> As far as I can tell, that 1993 Raggett proposal helped establish the table
> mark-up that was implemented in browsers in 1994/5, and was published in pages
> across the web in 1995/6, and hence was incorporated into the W3C HTML3.2
> recommendation in 1997.[/color]
If you accept the W3C as a standards authority, then you also have to
accept their standards.
With the release of HTML 3.2 the IETC's influence on the HTML language
ceased to exist. The W3C released an RFC [1] which obsoleted [2] the one
in which HTML 2.0 was specified. As of that point the W3C took care of
the development of the HTML language family as it previously did the
IETF by releasing the first HTML standard (HTML 2.0 wasn't the first
language, but the first released standard).
HTML 4.0 followed after HTML 3.2, then the HTML 4.01 standard replaced
HTML 4.0 and then the W3C released the first XHTML standard.
HTML 4.01 is therefore more important for the (up-to-date) definition of
what tables in HTML are meant to do than its predecessors.
<snip/>[color=blue][color=green]
>>Sure, "for layout purposes", it said that. However it also added the
>>following:
>>"Note that the latter role typically causes problems when rending to
>>speech or to text only user agents."[/color]
>
> So what? WAI sorted that out in April 1999.
>
http://www.w3.org/WAI/GL/wai-pr-issues#layout-tables
>
> Since April 1999, the only useful statement about layout tables is that they
> should linearise. And most do, apparently.
>
http://joeclark.org/book/sashay/seri...Chapter10.html[/color]
The full quote is "Authors should use style sheets for layout and
positioning. However, when it is necessary to use a table for layout,
the table must linearize in a readable order." [3]
Note that the last Working Draft to the WCAG 2.0 reads the following:
"structural elements and attributes are used as defined in the
specification"
If you use HTML 3.2, feel free to use layout tables, otherwise use them
for what the standard explicitly permits.
I will not go on about how you contradict yourself here in referring to
the W3C after implying the W3C can't define the purpose of tables as
they didn't invent them.
<snip/>
[color=blue][color=green]
>>
http://www.w3.org/TR/html4/struct/tables.html#h-11.1 reads:
>>"The HTML table model allows authors to arrange data -- text,
>>preformatted text, images, links, forms, form fields, other tables,
>>etc. -- into rows and columns of cells."
>>See how the mentioning of layout tables has been dropped.[/color]
>
>
> You appear to think that layout tables are somehow very different from other
> tables. Not true.[/color]
Yes they are. There's a semantic differences between a data table and a
layout table. If you use the table semantically, that's okay. If you
just use it to archeive a visual effect, that's not.
Tables may have a caption, headers, etc. However there is always a
semantic relationship between a cell and the row or a cell and a column.
If that isn't what you want, then don't use a table ferchrisakes.
It wouldn't make sense to have multiple paragraphs joined as an
unordered list simply because you want a dot in front of each paragraph
either.
[color=blue]
> They are simply *tables*! They are about laying out
> material, such as text, images, links, forms, form fields, other tables, etc,
> in rows and columns. Which is what I keep saying. (And what your quote above
> *also* said!)[/color]
Right. Simply tables.
There's a huge difference between arranging data and creating a visual
presentation. Wanna know which one? Arranging data is about arranging
them semantically, creating a visual presentation doesn't require that.
If you can create a visual presentation with correct semantics, that's
okay for me.
<snip summary="same quote as usual"/>[color=blue][color=green]
>>Now let's read a bit further:
>>"*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*."[/color]
>
> See above. WAI superceded that in April 1999.[/color]
See above. WAI 2.0 clarifies that.
[color=blue]
> And just look how stupid that W3C statement is! It is dated 24 December 1997.
> At that time, what CSS had been recommended? CSS1, of course. And what did the
> CSS1 recommendation say? "CSS1 does not offer: ... a layout language". So the
> HTML4 recommendation made a "should" statement that was *impossible* at the
> time![/color]
That was why in 1999 they removed it. W3C isn't stupid, they are just a
bit ahead of their time and their WGs also tend to interact a little too
little.
[color=blue][color=green]
>>If you're thinking this isn't important because SHOULD would define a
>>mere suggestion, please read the RFC's definition of SHOULD.[/color]
>
> See above - it appears to mean "we feel free to say "should" even though there
> is no recommendation on the planet capable of achieving that "should".[/color]
That's okay. That simply means you "should not do that, but if there's
no other way to do it, then please do it so" (which is the RFC
definition of SHOULD NOT / SHOULD anyway).
Now there is another way.
[color=blue]
> I suggest you read the page below. You will find that things were not as you
> believe they were:
> "A brief history of tables"
>
http://www.barry.pearson.name/articl...es/history.htm[/color]
I read it and I read some other parts of your site too. I also read the
claim the image layout you use would only be possible with three divs
and I don't agree.
http://www.barry.pearson.name/photog...99_09_08_3.htm
This is your code:
<div class="outer">
<div class="middle">
<div class="inner">
<h1><img src="ch99_09_08_3.jpg" height="617" alt="Buildings in Pudong
New Area, Shanghai, China" width="700"></h1>
</div>
</div>
</div>
Which is insane, because you use three divs and a block element for the
simply border effect.
Try using this:
<div class="border">
<h1><img src="ch99_09_08_3.jpg" height="617" alt="Buildings in Pudong
New Area, Shanghai, China" width="700"></h1>
</div class="border">
As you can see I've dropped the pointless two divs.
The point is that you only need to apply an outset border style to the
..border div and an inset border style to the h1 element.
Simply set a margin for the h1 or a padding for the div. If you want
another space between the h1 and the image, apply a margin or padding on
either of them.
Don't claim you know the standards if you don't know how to apply them.
I also noted you use a ridiculous table for the info to the image and
another one for the page info.
Please use a definition list for the image info. It is quite obvious a
definition list fits the purpose better than a table here.
If you read into the CSS spec a little you might also find a sane way to
do the page info table on the bottom without a table element.
[color=blue][color=green]
>>Also note that the Modularization of XHTML / XHTML 1.1 recommendations
>>and DTDs don't mention a layout function of tables anymore at all:
>>
http://www.w3.org/TR/xhtml-modulariz...s.html#sec_5.6.[/color]
>
> Who cares? Can't you see - layout tables use a *subset* of the standard table
> mark-up. As far as the recommendations are concerned, they are
> indistinguishable from other forms of table mark-up, (except, perhaps, for
> their simplicity). Therefore, they cannot be subjected to a different
> specification. So specifications cannot usefully talk about them.[/color]
No, you mistake the DTD for the recommendation here. Just because the
DTD's code says it may be any "flow" element or PCDATA, that doesn't
mean the content may be of any nature. The DTD itself cannot tell you to
use only semantic content, the human readable recommendation can.
That's why the WCAG for example isn't machine-validatable.
[color=blue]
> That is why they will *never* be discriminated against by browsers. Have you
> ever seen a reliable way of discriminating between a layout table and some
> other sort?[/color]
Have you ever seen a reliable way of discriminating between a landscape
picture and a porn image? No? Oh wonders.
Also note browsers will support tag soup for a long time, that means
they support even worse things than non-semantic markup.
[color=blue]
> Have you ever seen a business rationale showing why any bit of
> technology should be developed to support any such arbitrary discrimination?
> On the whole, the difference exists only in your mind. So the recommendations
> can't say anything about it.[/color]
The difference between semantics and presentation exist in people's
minds, yes, but semantic markup is a concept and recommendations can
enforce concepts.
[color=blue][color=green]
>>Note that it only says:
>>"This module declares element types and attributes used to provide
>>table markup similar to HTML 4, including features that enable better
>>accessibility for non-visual user agents."
>>Which refers to the HTML 4 recommendation on which I commented
>>earlier.[/color]
>
>
> Which was superceded in April 1999.
>
http://www.w3.org/WAI/GL/wai-pr-issues#layout-tables[/color]
Ah, yes? We're talking about Modularization of XHTML here. The latest
version is dated 2001. WCAG 1 on the other hand is dated 1999.
[color=blue][color=green][color=darkred]
>>>And, of course, this will continue into the future. The XHTML Table
>>>Module defines the content of a cell as "(PCDATA | Flow)*", which is
>>>pretty well anything.[/color]
>>
>>Yes and no. You failed to quote the normative introduction in the
>>current XHTML 2.0 draft:
>>
>>"The Tables Module provides elements for marking up tabular
>>information in a document."[/color]
>
>
> And does it define "tabular information" in a way that would enable any web
> technology to behave differently for tabular information versus any other
> sort? No! Anyone could mark-up whatever they like as a table, look you right
> in the eye and say "this is tabular information", and you would be totally
> impotent to do anything about it. This suggests that the concept of a layout
> table exists in your mind, and the minds of a few other people, but may not
> exist in the *real* world![/color]
Common sense dictates what can and cannot be tabular information.
There's nothing which stricly is tabular information, it's just a
question of whether it can be expressed within the sementics provided by
a table.
Having a page footer expressed as a table simply because it consists of
three columns doesn't carry any semantics.
[color=blue][color=green]
>>See that there's no meaning of anything which sounds like layout
>>anymore AT ALL.[/color]
>
>
> See above. XHTML is incapable of discriminating between various types of
> table. So the proposals cover them all.[/color]
See above. Does not.
[color=blue][color=green]
>>The fact about any kind of information can be tabular data doesn't
>>mean a table can serve a layout function. It just means the same as
>>what the HTML 4.01 spec read:
>>"The HTML table model allows authors to arrange data -- text,
>>preformatted text, images, links, forms, form fields, other tables,
>>etc.[..]"[/color]
>
>
> Yup! And it doesn't say anything that would rule out the use of tabes for
> layout purposes. There is *nothing* in W3C recommendations that says that you
> can only use table mark-up when there is a semantic relationship among the
> rows & columns. How could there be? It would be *impossible* to make the
> judgement![/color]
There's nothing in it that says you can use table for sole layout
purposes, either.
[color=blue]
> It would be like saying "paragraph can only be used where the content of the
> paragraph satisfies linguistic standards for paragraphs"! Of course that would
> be stupid! What <p>...</P> actually means is "treat that as you would a
> paragraph". And what <table>...</table> actually means is "treat this as you
> would a table".[/color]
Well, you wouldn't mark up an image or a table as a paragraph. Why would
you mark up a paragraph as a two-cell table then (other than just for
presentational purposes)?
[color=blue]
> If an author marks-up something as a table, what right has anyone or anything
> to decide otherwise? (Yes, they can express an opinion, of course).[/color]
You are mistaking following internet standards and conventions for
restricting the right to express one's opinion there.
If I see something that uses the semantic relations of a list, I can say
it is a list. If I see something that has the semantic relations of a
table, it is a table. If it's got the semantics of a pink squirrel, well
guess what I'll say.
You are free to write all you want to write, but you should not use
languages in a way different to how they are meant to be used.
If you want layout tables, please go ahead and write your pages
according to the HTML 3.2 standard or the HTML+ discussion document
even. If you don't like either, make your own language and call it "HTML
4.01 + Layout Tables" or whatever you want to call it.
XHTML explicitly allows you to make your own XHTML family member (i.e.
any language which is mostly XHTML can have the XHTML namespace). XML
even allows you to make your own markup language.
Go ahead! It's the direction most web authors might eventually look in
anyway.
[color=blue]
> [snip]
>[color=green][color=darkred]
>>>You can't, of course, because the evidence for what I said above is
>>>irrefutable. In fact, you don't even appear to be addressing my
>>>statement above. You appear to be attacking some totally different
>>>proposition.[/color]
>>
>>Well, I've pretty much pointed out why you're wrong by now.[/color]
>
> You haven't made a single point that refutes my statement "Right from their
> start in about 1993, tables were intended, inter alia, for laying out complex
> material in rows & columns".[/color]
See initial explanation on why I _can't_ directly address your statement.
[color=blue]
> [snip]
>[color=green][color=darkred]
>>>"Right from their start in about 1993, tables were intended, inter
>>>alia, for laying out complex material in rows & columns".[/color]
>>
>>They were intended to provide a means to present tabular data and were
>>_allowed_ to be used as a means to provide a layout. They are not
>>anymore and with every recommendation they have been restricted to
>>data (not layout) more and more.[/color]
>
>
> Not true. And until someone can identify a way of discriminating between
> different types of tables, it *can't*, and *won't*, ever be true.[/color]
As I said, it's about semantics.
[color=blue]
> Layout tables are tables. It is as simple as that.[/color]
Layout tables CAN be tables. They mustn't. They are if they carry the
semantic relations of a table. If they don't, then not.
[color=blue]
> [snip]
>[color=green][color=darkred]
>>>Until you can supply counter-evidence, of course you are wasting
>>>your breath! You would need, first, to address my statement, and
>>>second, to provide evidence that contradicted it. I believe such
>>>evidence doesn't exist.[/color]
>>
>>Counter-evidence provided. Statement addressed. Evidence exists.[/color]
>
>
> See above. You haven't provided a single bit of counter-evidence. Because it
> doesn't exist! I'll repeat my statement: "Right from their start in about
> 1993, tables were intended, inter alia, for laying out complex material in
> rows & columns".[/color]
I will hire a contract killer if you dare repeating a quote instead of
bringing up actual evidence in response to a statement again.
I have a peaceful suggestion tho.
We apparently agree that layout tables are tables in the presentational
sense. That is, they look table-ish. We also might agree that a table is
a table if its elements have a semantic relationship which is like the
one of table elements.
Could we therefore conclude that layout tables -- although their
validity can legally be questioned because the W3C's working groups
contradict each other there a little -- are tables in the HTML 4.01 (or
XHTML for that matter) sense (or 'have the table nature' ::snikers::)
only if they are used according to their semantics, whether they (also)
lay out a website or not?
I'm not saying you are essentially wrong. I'm saying neither of us
essentially right, but I still insist that layout tables should (looking
at the direction the recs are going and the semantic web activity) be
avoided where possible (i.e. where not essential for backwards
compatibility or other reasons like avoiding excessive DIVitis) and
slowly abandoned once CSS reaches a (widely supported) state in which
the same layout can easily be archieved without them.
Do we agree enough to stop this nonsense there?
[1]
http://www.rfc-editor.org/rfc/rfc2854.txt (issued by the W3C)
[2]
http://www.w3.org/MarkUp/ :
"Note that with the release of RFC 2854, RFC 1866 [i.e. HTML 2.0] has
been obsoleted and its current status is HISTORIC."
[3]
http://www.w3.org/TR/WCAG10-HTML-TECHS/#tables-layout
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/ 
