Opera 7.23 doesn't show me inner tables

Backorder UK domains or auction your own with UKBackorder.uk. Our platform offers a seamless process to secure expiring domains and sell your own UK domains through auctions. No catch, no fee.

**Steve Pugh** · Jul 20 '05, 05:22 PM

Re: Opera 7.23 doesn't show me inner tables

"Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
[color=blue]
>I suggest you re-read Dave Raggett's proposal. This is the point I am trying
>to make. Although people say the sort of things you have just said, when I go
>the the sources, they say something different.[/color]

From the very first line of the section on tables <url:
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.htm l>

"Tables are specified using the TABLE element. This allows you to
define a caption and to differentiate header and data cells."

"header and data cells"? Sounds like data tables to me.
[color=blue]
> His proposal says nothing whatsoever about logical relationships.[/color]

It says nothing about using tables for layout purposes.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve@pugh.net > <http://steve.pugh.net/>

**John W.** · Jul 20 '05, 05:22 PM

Re: Opera 7.23 doesn't show me inner tables

Steve Pugh <steve@pugh.net > wrote:
[color=blue]
>"Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
>[color=green]
>>I suggest you re-read Dave Raggett's proposal. This is the point I am trying
>>to make. Although people say the sort of things you have just said, when I go
>>the the sources, they say something different.[/color]
>
>From the very first line of the section on tables <url:
>http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.htm l>
>
>"Tables are specified using the TABLE element. This allows you to
>define a caption and to differentiate header and data cells."
>
>"header and data cells"? Sounds like data tables to me.
>[color=green]
>> His proposal says nothing whatsoever about logical relationships.[/color]
>
>It says nothing about using tables for layout purposes.
>[/color]
It says nothing about "not" using tables for layout purposes?

John OO
--
<http://webcel.nl/> webshopsoftware + more

"Time is what prevents everything from happening at once"
- John Archibald Wheeler -

**Neal** · Jul 20 '05, 05:22 PM

Re: Opera 7.23 doesn't show me inner tables

On Sun, 18 Jan 2004 12:02:16 +0100, John W. <no_spam@web cel.enel> wrote:
[color=blue]
> It says nothing about "not" using tables for layout purposes?[/color]

It also says nothing about not using p elements with CSS to emulate a
list. Yet I'm sure you don't advocate that.

This is compelling in demonstrating the W3C's attitude, though. From
http://www.w3.org/TR/CSS2/selector.html :

"CSS gives so much power to the "class" attribute, that authors could
conceivably design their own "document language" based on elements with
almost no associated presentation (such as DIV and SPAN in HTML) and
assigning style information through the "class" attribute. Authors should
avoid this practice since the structural elements of a document language
often have recognized and accepted meanings and author-defined classes may
not."

While this is not directly analogous to the concept of mis-applying table
markup to layout, it does show that the W3C would rather authors use the
markup in a meaningful way. This says that even if we can use span to
create a whole vocabulary of inline elements, we should not because it
won't have accepted meaning.

Now it's reasonable to assume that the table element was invented to make
tables, unless other compelling evidence exists. That evidence being
absent, it would seem that the meaning of table is a table.

I attempted to post the other day, and I have not seen it, so apologies if
I repeat myself. But the reason I do not allow my girlfriend to shave her
legs with my face razor is, while it will work, it ruins it for my
application. I don't grind spices in my coffee grinder because while the
spice grinds very well my coffee tasteds terrible afterward.

The reason not to use tables for markup is that it ruins the table as a
meaningful markup.

**Alan J. Flavell** · Jul 20 '05, 05:22 PM

Re: Opera 7.23 doesn't show me inner tables

On Sun, 18 Jan 2004, John W. wrote:
[color=blue]
> It says nothing about "not" using tables for layout purposes?[/color]

I don't think it says anything about not using tables instead of <ul>
or <ol> or <dl>, all of which I've seen done in practice (I think it's
a bad idea, just in case there's any doubt).

In the past I've also use a floated single-celled table for supplying
side-notes. I thought it was a bad idea in theory at the time, but
pragmatically it was the best that could be done back then; nowadays
one would obviously use a floated <div>. I don't suppose Raggett
*said* anything against using tables for that, either, in his actual
draft, but that doesn't necessarily mean he supported such a (mis)use.

One really can't expect a specification, draft or otherwise, to
enumerate all possible (mis)uses of that specification.

**kchayka** · Jul 20 '05, 05:22 PM

Re: Opera 7.23 doesn't show me inner tables

Steve Pugh wrote:[color=blue]
> "Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
>[color=green]
>>I suggest you re-read Dave Raggett's proposal. This is the point I am trying
>>to make. Although people say the sort of things you have just said, when I go
>>the the sources, they say something different.[/color]
>
> From the very first line of the section on tables <url:
> http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.htm l>
>
> "header and data cells"? Sounds like data tables to me.[/color]

It is also glaringly obvious from the examples on the page that the
intended use is for showing tabular data in a 2-dimensional grid. No?

--
To email a reply, remove (dash)un(dash). Mail sent to the un
address is considered spam and automatically deleted.

**Alan J. Flavell** · Jul 20 '05, 05:22 PM

Re: Opera 7.23 doesn't show me inner tables

On Sat, 17 Jan 2004, Barry Pearson wrote:
[color=blue]
> I suggest you re-read Dave Raggett's proposal.[/color]

OK, we're discussing

Tables

http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.html

[color=blue]
> His proposal says nothing whatsoever about logical relationships.[/color]

Not in so many words, it's true. It's based on some kind of tacit
understanding of what a "table" is, without attempting to define it
theoretically; however, the examples that are offered are most
definitely examples of what one could call (somewhat circularly!)
"tabular data".
[color=blue]
> I can't find any early discussion of tables that does.[/color]

And I can't find any early discussion of tables that doesn't.

There was a discussion at the 1994 WWW conference in which we see
brief mention of the possibility of laying-out mathematical formulae
by using <table> markup, but that possibility is rapidly set aside in
favour of something else. (Google for html+.workshop. notes )

In 1995 we find Raggett producing a demonstration of the Arena browser
which contains in part some tabular data (an address book), but the
other part is a pure layout, of materials which bear no obvious
relationship to each other. I.e superficially supporting your
contention: http://www.w3.org/Arena/tour/tables2.html

This is presented as "Using tables for flexible layout", as if it
might be a rather new idea for exploiting the previously-drafted table
markup. You'll likely say (but can't prove) that the idea had been
there all along. I'll be inclined to say (but can't prove) that all
the discussion about table markup, the CALS model, SGML compatibility,
automatic rendering algorithms with just maybe the possibility for
author-supplied rendering hints, accessibility to other browsing
situations, and so on, was tacitly based on a common understanding
that they knew what a "table" was in principle, and were primarily
discussing how to mark up something that they'd already be willing to
agree was a table.
[color=blue]
> His description is about defining new HTML features, "tables", in
> order to layout the content of the cells in a horizontal by vertical
> grid on displays.[/color]

His description is about marking-up content with HTML markup, and the
implementation issues for browsers to render that markup, optionally
using presentation hints. This is the standard theme of HTML: markup
the content at the server side; render the content in accordance with
the browsing situation at the client side. Please, don't try to
conflate the two parts, or you discard the very essence of HTML.
That's where the Big Two went wrong, and drifted into a situation that
gave us presentational pseudo-HTML DTP and HTML3.2(spit), and wasted a
couple of years that *could* have been spent developing stylesheets.
[color=blue][color=green]
> > They're designed to express a relationship which, in appropriate
> > circumstances, it's appropriate to present in a two-dimensional grid
> > relationship.[/color]
>
> And to lay it out in a grid.[/color]

Of course - when that presentation is an appropriate one.
[color=blue]
> The layout comes across from Raggett's description.[/color]

In the part where he's discussing rendering algorithms, indeed.
[color=blue]
> The relationship bit doesn't.[/color]

In the 1993 draft, he offers just two examples, both of which are
clearly expressing relationships. I'd say that carries some kind of
message.

In the 1995 Arena practical demonstration he offers (in effect) two
examples, one of which clearly expresses relationships, about which he
makes no specific comment; and for the other he goes out of his way to
comment that it is "Using tables for flexible layout", with additional
comment to that effect in the material itself: "This example shows how
you can use tables to layout text and images in a flexible way".
^^^^^^^

(it doesn't say "this is what tables are for", it "shows how you can
use tables [for doing this]". See the difference?)

My interpretation: he assumed that readers would understand what a
table was, without special explanations, but needed to have
tables-for-layout explained as if they were a special case, not part
of common knowledge and experience; and that was in 1995.
[color=blue][color=green][color=darkred]
> >> It isn't an accident[/color]
> >
> > I don't disagree. But: when the presentation situation makes a visual
> > grid impractical, the *intention* was to present the relationships in
> > some alternative way.[/color]
>
> Indeed. I don't think anyone is arguing with this. I have tried IBM's Home
> Page Reader to see what it would do, and it linearises.[/color]

So it does, which isn't much help when trying to understand what
relationship was being expressed in the table. But again we seem to
have the tail wagging the dog. The fact that IBM HPR linearises
tables does not in itself prove that tables are intended for visual
layout.

The WAI discussions have gone into some detail to try to distinguish
between tabular relationships on the one hand, and tables-for-layout
on the other, and to act usefully in both cases. It can be done only
imperfectly, and it would have been better if the problem had not been
created in the first place. But this posting isn't supposed to be
about advocacy, but rather about what the historical evidence might
mean. And I think I've had enough for today.

all the best

**John W.** · Jul 20 '05, 05:22 PM

Re: Opera 7.23 doesn't show me inner tables

"Alan J. Flavell" <flavell@ph.gla .ac.uk> wrote:
[color=blue]
>On Sun, 18 Jan 2004, John W. wrote:
>[color=green]
>> It says nothing about "not" using tables for layout purposes?[/color]
>
>I don't think it says anything about not using tables instead of <ul>
>or <ol> or <dl>, all of which I've seen done in practice (I think it's
>a bad idea, just in case there's any doubt).
>
>In the past I've also use a floated single-celled table for supplying
>side-notes. I thought it was a bad idea in theory at the time, but
>pragmaticall y it was the best that could be done back then; nowadays
>one would obviously use a floated <div>. I don't suppose Raggett
>*said* anything against using tables for that, either, in his actual
>draft, but that doesn't necessarily mean he supported such a (mis)use.
>
>One really can't expect a specification, draft or otherwise, to
>enumerate all possible (mis)uses of that specification.[/color]

introducing again:[color=blue]
> Steve Pugh's reference to :
> <http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.htm l>[/color]

Because only untill much later somebody found out that tables could be
applied for layout i find that a reference to the above mentioned URL
was not very useful, hence my remark :-)

Because i think that it is quite safe to assume that in 1993 nobody
even thought about applying the possibilities of <table> for layout
purposes because webpages were supposed to be 1 column only.

Read from the W3C WD from 1996:
<http://sunhe.jinr.ru/docs/w3c/TR/WD-layout.html>
<q>
Introduction
Until recently Web browsers have rendered HTML documents as single
column scrolling windows.

Authors have been given very limited means to control the placement of
features in the window.

Traditional page-layout authoring tools for desktop publishing allow
you to create and move and resize document frames.

You can then view and alter properties of these frames, e.g. the
background color and the style of borders if any.

You may also be able to drag and drop objects onto frames, and to move
and resize the objects relative to the frame on which they have been
attached.
</>

As N2 was introduced Beta/1995 and Final/1996, it is therefore quite
possible that immediately after the release of N2 the first websites
were produced including table_layout in the frames and far ahead of
the release HTML 4.0, 1998/9 including the frame-specs.

Blooberry timeline:
- HTML 4.0 draft (evolved from Cougar) released - July, 1997
- HTML 4.0 becomes W3C proposed recommendation - November, 1997
- HTML 4.0 becomes W3C recommendation - December, 1997
- HTML 4.0 revised and certified W3C recommendation - April, 1998

A development which must now be regarded as a developing horrorstory
to most of the readers of this ng :-)

<on a sideline>
you can safely use a hammer to hammer a screw into a wall,
but it's useless to try to use a screwdriver to screw a nail into a
wall :-)
</>
The screw and nail being the content, the question remains in the case
of <table> versus CSS: which is the hammer and which is the
screwdriver :-)

Also very interesting is that with CSS2 the following table-related
properties: -border-collapse-, -border-spacing-, -caption-side-,
-empty-cells- and -table-layout- were introduced because -border-,
-width- and -height- were found not to be sufficient :-)

BTW I find the whole tread most interesting and amusing.

John OO
--
<http://webcel.nl/> webshopsoftware + more

"Time is what prevents everything from happening at once"
- John Archibald Wheeler -

**Barry Pearson** · Jul 20 '05, 05:23 PM

Re: Opera 7.23 doesn't show me inner tables

Alan J. Flavell wrote:[color=blue]
> On Sat, 17 Jan 2004, Barry Pearson wrote:
>[color=green]
>> I suggest you re-read Dave Raggett's proposal.[/color]
>
> OK, we're discussing
> http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.html[/color]
[snip][color=blue]
> His description is about marking-up content with HTML markup, and the
> implementation issues for browsers to render that markup, optionally
> using presentation hints. This is the standard theme of HTML: markup
> the content at the server side; render the content in accordance with
> the browsing situation at the client side. Please, don't try to
> conflate the two parts, or you discard the very essence of HTML.
> That's where the Big Two went wrong, and drifted into a situation that
> gave us presentational pseudo-HTML DTP and HTML3.2(spit), and wasted a
> couple of years that *could* have been spent developing stylesheets.[/color]

I remember those browser battles, and "this page is best viewed with X - click
here to download". Yeuk! But without those browser battles, would the web have
taken-off as it did? I don't believe there was *ever* a viable path from the
purest vision behind the web to an ideal implementation of it. We don't live
in a world where it is useful for students to say "if only everyone learned to
like one-another, we wouldn't have wars". They are literally right - but
totally irrelevant. And perhaps they will eventually grow up.

As GBS said: "Reasonable people adapt themselves to the world. Unreasonable
people attempt to adapt the world to themselves. All progress, therefore,
depends on unreasonable people". There are people on the playing field trying
to make things happen, and there are those on the sidelines saying "you
shouldn't play this game like that". Guess who has most influence in the
world?

I believe people need visions. You probably have them. So do I. We shouldn't
expect for a second that our visions will just happen. Instead, at each stage,
we should be saying "we are here, where should we be, do I need to revise my
previous vision, now what do I do next to nudge things in the right
direction?" It is like getting to the moon - a massive blast-off, lots of
course corrections, and tons of luck. And abandon regrets!

In a world of 6 billion people, why should 100 people who are not contributing
vast amounts of money expect to make dramatic changes? Only if what they doing
is what the 6 billion people show they want, not what the 100 people
themselves want.

[snip][color=blue]
> My interpretation: he assumed that readers would understand what a
> table was, without special explanations, but needed to have
> tables-for-layout explained as if they were a special case, not part
> of common knowledge and experience; and that was in 1995.[/color]

Hm! Then perhaps he was seriously mistaken! The problem is that for decades
before that, we all knew about computerisation of N-dimensional arrays. We all
used programming languages that supported them, and could render 2-dimensional
slices through them. Some of us could integrate in 3N (or 6N) dimensions,
where N was the number of molecules in a gas. (Thermodynamics ). I believe many
of us could spot a layout-scheme, rather than a semantic/logical scheme, a
mile away. If HTML+ was ever a semantic mark-up scheme, it would have been
pretty obvious. For one thing, it wouldn't have been 2-dimensional! Or have
mark-up explicitly named (<tr>) for row-primary. Those are a layout
constraints.

If HTML+ had said the following, I might have believed that it was truly
concerned with logical/semantic mark-up rather than layout:

<array><awrap >
<ad> ... </ad>
<ad> ... </ad>
</awrap>
<awrap>
<ad> ... </ad>
<ad> ... </ad>
</awrap></array>

That is a possible concise 2-dimensional simplification of an N-dimensional
logical/semantic mark-up language. A 3-dimensional (1 x 1 x 1 array) version
might have said:

<array><awrap>< awrap>
<ad> ... </ad>
</awrap></awrap></array>

[snip][color=blue][color=green]
>> Indeed. I don't think anyone is arguing with this. I have tried
>> IBM's Home Page Reader to see what it would do, and it linearises.[/color]
>
> So it does, which isn't much help when trying to understand what
> relationship was being expressed in the table. But again we seem to
> have the tail wagging the dog. The fact that IBM HPR linearises
> tables does not in itself prove that tables are intended for visual
> layout.[/color]

True. There are several issues being conflated here. I have tried to
disentangle them, but perhaps I have also added to the confusion. (Sorry).

- What were the original intentions? They are interesting from a historical
perspective. They are irrelevant for how we should behave today. We can't
afford to re-fight lost battles. (But history is still interesting! That is
why I am maintaining a page on the subject).

- How do things behave today, and in the future? This is what matters. Authors
are trying to communicate with users. The rest is infrastructure. The main 5
(or so) boxes on a pages are vitally important to users. So they should also
be important to authors. Get those right, and the rest is detail in
comparison. Sort out the handful of things at the top of your document tree,
and the rest is twiddling. How should we do that, with "industrial strength"?

- When in doubt, go back to the specification. I assume we all wish that all
browsers conformed to specification! (We can't say "conform to all
specifications - except where I disagree with them!") So, what do the
specifications say is data for tables? "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". (HTML 4.0 & 4.01).

- Use a checklist to evaluate options. I use the following - do a Google
search on:
"OPENframew ork systems architecture"
(Check in the books for a name you recognise).
[color=blue]
> The WAI discussions have gone into some detail to try to distinguish
> between tabular relationships on the one hand, and tables-for-layout
> on the other, and to act usefully in both cases. It can be done only
> imperfectly, and it would have been better if the problem had not been
> created in the first place. But this posting isn't supposed to be
> about advocacy, but rather about what the historical evidence might
> mean. And I think I've had enough for today.[/color]

I agree with "... not been created in the first place ..."! But I can't find
any indication that those people actually cared about page-layout! It appears
to have been a blind-spot. I worry that it is *still* a blind-spot. Anyone who
cared about where the main 5 (or so) boxes on a page ended up wouldn't have
delivereed any current version of (X)HTML, nor either CSS1 or CSS2. Until they
start realising that this matters, and needs a suitable abstraction and
language, we will continue as we are - for decades.

--
Barry Pearson

Backorder UK domains or auction your own with UKBackorder.uk. Our platform offers a seamless process to secure expiring domains and sell your own UK domains through auctions. No catch, no fee.

**Alan J. Flavell** · Jul 20 '05, 05:23 PM

Re: Opera 7.23 doesn't show me inner tables

On Mon, 19 Jan 2004, Barry Pearson wrote:
[color=blue]
> Alan J. Flavell wrote:[color=green]
> > That's where the Big Two went wrong, and drifted into a situation that
> > gave us presentational pseudo-HTML DTP and HTML3.2(spit), and wasted a
> > couple of years that *could* have been spent developing stylesheets.[/color][/color]
[..]
[color=blue]
> But without those browser battles, would the web have taken-off as
> it did? I don't believe there was *ever* a viable path from the
> purest vision behind the web to an ideal implementation of it.[/color]

We'll never know. But the concept of a (separate) stylesheet was
already well established in many areas (Word processors, DTP packages,
not to mention non-computer publishing). The benefits relative to a
conflated content-with-presentation soup were already known. To me it
just served as a demonstration of "those who refuse to learn from
history are condemned to repeat it". Arena was doing a primitive form
of stylesheets; indeed Viola was also based on a kind of stylesheet,
before Mosaic set a different agenda - and MS decided to copy them
("bugwards compatible" was the slogan at the time, as I recall).
[color=blue]
> As GBS said: "Reasonable people adapt themselves to the world.
> Unreasonable people attempt to adapt the world to themselves. All
> progress, therefore, depends on unreasonable people". There are
> people on the playing field trying to make things happen, and there
> are those on the sidelines saying "you shouldn't play this game like
> that". Guess who has most influence in the world?[/color]

I'd rate Lie and Bos as the overall winners by now, but it was a long
and unnecessary slog IMNSHO.
[color=blue]
> It is like getting to the moon - a massive blast-off, lots of
> course corrections, and tons of luck. And abandon regrets![/color]

OK. But don't do that by trying to rewrite history.
[color=blue]
> - What were the original intentions?[/color]

What follows is hopelessly over-simplified, but I hope it's not
actually wrong.

The _original_ original intentions a la T.B-L were what you saw in
HTML classic: a pragmatic sprinkling of pointy brackets, and no
particular presentation. The intention was to be able to present the
same content meaningfully on a graphical display and on the
then-current character cell terminals, with a view to wider
accessibility as things developed. So: presentation was the job of
the browser designer. (And we still saw that e.g in the Cello
browser, last release 1994.)

Then along came a few guys who knew SGML and wanted to tidy things up
by making HTML be a fairly simple "applicatio n of SGML". Which led to
RFC1866/HTML2.0. I think it would have been they who brought the more
abstract concepts relating to structural elements, and pushed forward
the ideas which we find in HTML+ and HTML3.0(decease d).
[color=blue]
> They are interesting from a historical perspective.[/color]

No regrets - right?
[color=blue]
> They are irrelevant for how we should behave today. We can't afford
> to re-fight lost battles.[/color]

We can't afford not to learn from them. We already lost a couple of
years, at least.

**Barry Pearson** · Jul 20 '05, 05:23 PM

Re: Opera 7.23 doesn't show me inner tables

Alan J. Flavell wrote:[color=blue]
> On Mon, 19 Jan 2004, Barry Pearson wrote:[color=green]
>>[/color][/color]
[snip][color=blue]
> We'll never know. But the concept of a (separate) stylesheet was
> already well established in many areas (Word processors, DTP packages,
> not to mention non-computer publishing). The benefits relative to a
> conflated content-with-presentation soup were already known. To me it
> just served as a demonstration of "those who refuse to learn from
> history are condemned to repeat it". Arena was doing a primitive form
> of stylesheets; indeed Viola was also based on a kind of stylesheet,
> before Mosaic set a different agenda - and MS decided to copy them
> ("bugwards compatible" was the slogan at the time, as I recall).[/color]

I agree with the basic principle. It is vital to separate the various
concerns. In the early 1980s I developed a laser-printer driver for WordStar
3. It had a mark-up scheme to enable me to develop complex diagrams and have
them printed cleanly. (Using WordStar 3!) I had something like a stylesheet
scheme to change the basic behaviour of my driver, which in turn was triggered
by WordStar 3 mark-up. I won't call this a cascade, but there are
resemblences.

But ... a brilliant (and quirky) colleague used it to publish "floor plans"
and "crossword puzzles". This was not intended use. Should I have taken
umbrage? No. There is a "core" that really matters, and there is the rest that
doesn't. My driver influenced the refitting of a 12-story office-suite, for
the better - should I have objected?

For decades I worked for a fanatical "technology centre" in a company. I had
the power to trash anyone's brilliant ideas with the mere statement "it isn't
architectural". I could now switch on "architectu re mode" and trash just about
anything you say. I could cause you to realise that it was vitally important
which foot to place on the floor first in the morning.

But I grew up. It *was* important to be architectural at the start, because we
(100s of people) were building a mainframe operating system that was going to
be evolved over *decades*. We knew that we had to fight off the managers and
marketers to establish the basic infrastructure. And we did indeed get it
right, in a way that (say) Windows got it wrong. I doubt if your tax records,
held on systems that I helped to design, leak much. (Every UK tax record
passes - or at least did at one time - through code that I once had design
control over! Ponder).
[color=blue][color=green]
>> As GBS said: "Reasonable people adapt themselves to the world.
>> Unreasonable people attempt to adapt the world to themselves. All
>> progress, therefore, depends on unreasonable people". There are
>> people on the playing field trying to make things happen, and there
>> are those on the sidelines saying "you shouldn't play this game like
>> that". Guess who has most influence in the world?[/color]
>
> I'd rate Lie and Bos as the overall winners by now, but it was a long
> and unnecessary slog IMNSHO.
>[color=green]
>> It is like getting to the moon - a massive blast-off, lots of
>> course corrections, and tons of luck. And abandon regrets![/color]
>
> OK. But don't do that by trying to rewrite history.[/color]

One of my aims is to document history. (There is enough re-writing going
elsewhere). It is impossible to document history while capturing the feelings
and all of the discussions of those involved. Those end up being guesswork.
But a conference has an output, and I want to identify the output. Person X
may have lost a debate, and may spend decades wanting to overturn the debate,
but there is a limit to what I can capture.
[color=blue][color=green]
>> - What were the original intentions?[/color]
>
> What follows is hopelessly over-simplified, but I hope it's not
> actually wrong.
>
> The _original_ original intentions a la T.B-L were what you saw in
> HTML classic: a pragmatic sprinkling of pointy brackets, and no
> particular presentation. The intention was to be able to present the
> same content meaningfully on a graphical display and on the
> then-current character cell terminals, with a view to wider
> accessibility as things developed. So: presentation was the job of
> the browser designer. (And we still saw that e.g in the Cello
> browser, last release 1994.)[/color]

Indeed. I both understand this, and realise (with 20:20 hindsight) why it was
doomed to fail. It may have worked on a different planet, but not one
populated by Homo sapiens.

(Sorry: <i lang="la">Homo sapiens</i>)

The main 5 boxes (or so) on the display are vitally important. Research shows
this. Yet I can't find any clues that the parents of the web realised this.
They appear to have thought that simple "structure" (h1 ... h6 ... p) was what
mattered. Sad!

And I believe those "5" boxes (at least 2, but less than 10) are the drivers
for the current holy war. The parents of the web developed CSS to handle what
happened within such a box, but no one ever devised a language to transmit an
abstraction of the placement of those 5 boxes. (Or tell me where it is).

[snip][color=blue][color=green]
>> They are irrelevant for how we should behave today. We can't afford
>> to re-fight lost battles.[/color]
>
> We can't afford not to learn from them. We already lost a couple of
> years, at least.[/color]

True. And the current holy war between advocates of CSS-P, and people using
layout tables (who mostly don't even know there is a debate going on!) is
wasting more time.

We should be reviewing where we are now. Trying to achieve a consensus for
where we want to be. And trying to see the (achievable) steps to get there.

--
Barry Pearson

http://www.barry.pearson.name/articles/layout_tables/history.htm

Backorder UK domains or auction your own with UKBackorder.uk. Our platform offers a seamless process to secure expiring domains and sell your own UK domains through auctions. No catch, no fee.

**Reinier Post** · Jul 20 '05, 05:23 PM

Re: Opera 7.23 doesn't show me inner tables

Neal wrote:
[color=blue]
>The reason not to use tables for markup is that it ruins the table as a
>meaningful markup.[/color]

But tables aren't very useful for that, anyway.
The <TABLE> element and its descendants don't convey the kind of
information you need for "real", relational. tables: cell types
(is column 3 always an integer?), sortedness (in relational tables,
the rows are unordered, but they can be sorted by some criterion,
e.g. alphabetically by the third column, when displayed), subselection
and spreading of table data across several pages ("give me the top 200
entries only, and wrap them across as many pages you need, inserting
next and previous buttons as appropriate". All this is *presentation*
information, and none of it can be conveyed in HTML, which means that
HTML simply isn't a good representation language for relational tables.

As far as I can see, from a conceptual point of view, a <TABLE> and the
elements it contains are basically <DIV>s with specific defaults on
how to display them, defaults that can in fact be expressed in CSS1 in
a more elegant and useful way, and therefore, really should be, unless
you run into browsers that don't support the relevant part of CSS.

--
Reinier

**Brian** · Jul 20 '05, 05:23 PM

Re: Opera 7.23 doesn't show me inner tables

Reinier Post wrote:[color=blue]
>
> The <TABLE> element and its descendants don't convey the kind of
> information you need for "real", relational. tables: cell types (is
> column 3 always an integer?), sortedness[/color]
[color=blue]
> All this is *presentation* information, and none of it can be
> conveyed in HTML[/color]

HTML is not a relational database application. It is a markup
language. As you probably already know, a database application like
MySQL can perform database functions, and php can extract that tabular
information into appropriate html, though.
[color=blue]
> HTML simply isn't a good representation language[/color]

Not sure what you mean by "representa tion language." HTML is a
semantic language, not a dtp application.
[color=blue]
> for relational tables.[/color]

It works for me. When I markup table data, then view it in e.g.
Mozilla, the presentation conveys the table in a meaningful way,
showing the relationship between columns and rows.

--
Brian (follow directions in my address to email me)

Home - TS McHughs Irish Pub & Restaurant

http://www.tsmchughs.com/

**Barry Pearson** · Jul 20 '05, 05:24 PM

Re: Opera 7.23 doesn't show me inner tables

Reinier Post wrote:[color=blue]
> Neal wrote:
>[color=green]
>>The reason not to use tables for markup is that it ruins the table as
>>a meaningful markup.[/color]
>
> But tables aren't very useful for that, anyway.
> The <TABLE> element and its descendants don't convey the kind of
> information you need for "real", relational. tables: cell types
> (is column 3 always an integer?), sortedness (in relational tables,
> the rows are unordered, but they can be sorted by some criterion,
> e.g. alphabetically by the third column, when displayed), subselection
> and spreading of table data across several pages ("give me the top 200
> entries only, and wrap them across as many pages you need, inserting
> next and previous buttons as appropriate". All this is *presentation*
> information, and none of it can be conveyed in HTML, which means that
> HTML simply isn't a good representation language for relational
> tables.[/color]
[snip]

The basic specification of tables (since late 1993) is precisely as you say.
It is explicitly and unambiguously presentational (layout) mark-up. In spite
of later attempts to re-write history!

"A brief history of tables"

HTML 4.0 added semantic mark-up to tables. It is a bold attempt to bolt
semantic mark-up onto presentational mark-up. I think it gets close to what we
would have had if tables had originally been intended to be semantic rather
than layout mark-up. It made the best of a bad job. (It would have been much
better to bolt layout & presentation onto semantic mark-up - but that didn't
happen).

Tables in HTML documents

http://www.w3.org/TR/1998/REC-html40-19980424/struct/tables.html

It is instructive to consider what we would have had if tables (or more likely
"arrays") had ever been designed to support 2 or more semantic dimensions,
instead of being intended to render things in rows and columns on a display.

Error 500 (Server Error)!!1

http://groups.google.com/groups?selm=yeVOb.44%24p05.38%40newsfep1-gui.server.ntli.net

But we don't have to worry! The original intentions will never interfere with
us. What we have to ask is "what will be the fate of my next web page?"

That is a separate discussion.

--
Barry Pearson