Opera 7.23 doesn't show me inner tables
Mariusz Jedrzejewski
I'll be very grateful if somebody can explain me why my Opera 7.23
(runing under linux) doesn't show me inner tables. Using below code I
can see only "inner table 1". There is no problem with other browsers
(I checked it under Konqueror).
Thank you in advance for your help.
Regards.
/Mariusz
<HTML>
<HEAD>
</HEAD>
<BODY>
<TABLE BORDER=1 WIDTH=800 ALIGN="center">
<TR ALIGN="center">
<TD ALIGN="left" WIDTH=100>
<TABLE BORDER=1 ALIGN="left" WIDTH=100%>
<TR ALIGN="left" WIDTH=100%><TD ALIGN="left">inner table 1</TD></TR>
</TABLE>
<TABLE BORDER=1 ALIGN="left" WIDTH=100%>
<TR ALIGN="left" WIDTH=100%><TD ALIGN="left">inner table 2</TD></TR>
</TABLE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>
David Dorward
> I'll be very grateful if somebody can explain me why my Opera 7.23
> (runing under linux) doesn't show me inner tables. Using below code I
> can see only "inner table 1". There is no problem with other browsers
> (I checked it under Konqueror).
<snip code>
Your HTML is invalid, so you can't know if its a fault with the code, or a
fault with the user agent. Its best to eliminate the measurable problem
first.
Additionally, there should be no reason to use nested tables... unless you
are abusing them for non-tabular purposes:
http://www.allmyfaqs.com/faq.pl?Tableless_layouts
--
David Dorward <http://dorward.me.uk/>
Barry Pearson
> Hi,
> I'll be very grateful if somebody can explain me why my Opera 7.23
> (runing under linux) doesn't show me inner tables. Using below code I
> can see only "inner table 1". There is no problem with other browsers
> (I checked it under Konqueror).
I think it is the "width=100%" on the first inner table that causes it to take
up all the available space. (How can you have 2 tables each taking 100% of the
space?) I just changed the widths of the inner tables to "50%" and Opera
showed both.
ps: It is nothing to do with whether or not this is a layout table! And nested
tables are often a good idea, and can be used for reasons other than layout.
--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Barry Pearson
> Mariusz Jedrzejewski wrote:
>> Hi,
>> I'll be very grateful if somebody can explain me why my Opera 7.23
>> (runing under linux) doesn't show me inner tables. Using below code I
>> can see only "inner table 1". There is no problem with other browsers
>> (I checked it under Konqueror).
> [snip]
>
> I think it is the "width=100%" on the first inner table that causes
> it to take up all the available space. (How can you have 2 tables
> each taking 100% of the space?) I just changed the widths of the
> inner tables to "50%" and Opera showed both.
Whoops, my mistake! You can have 2 at 100%, of course, because they should
follow one-another, they should not be inline. But - after changing the widths
to 50%, I did see both on Opera, side by side, so the answer appears to be
there somewhere. (If you changed them to, say, 90% & 90%, you would see just a
bit of the second one in Opera. It appears that IE & Opera are treating them
as inline somehow, while others don't).
I suggest you start from clean mark-up - there is a lot of redundant stuff
there which is confusing things.
Brian
in opera.*]
Barry Pearson wrote:
>
> nested tables are often a good idea
I've yet to see one good idea executed with tested tables. Perhaps
I've been looking in the wrong places.
> and can be used for reasons other than layout.
...such as?
--
Brian
follow the directions in my address to email me
Joel Shepherd
>
> I've yet to see one good idea executed with tested tables. Perhaps
> I've been looking in the wrong places.
Anything particularly wrong with this application (transitional markup
excepted)?
<http://www.cv6.org/ship/armament.htm>
--
Joel.
Brian
> Brian wrote:
>
>> I've yet to see one good idea executed with tested tables.
>
> markup excepted)?
>
> <http://www.cv6.org/ship/armament.htm>
Strict is preferable, but even keeping the dtd, one could improve the
markup of the tables. There are no th elements, but there should be.
For example,
<td>Projectile Weight:</td> should probably be <th>Projectile
Weight:</th>. And
<tr>
<td class="s">5/38-10/38</td>
<td class="s">10/38-10/41</td>
<td class="s">10/41-2/42</td>
<!-- etc. -->
</tr>
All of these td elements are table headers, and should be marked up as
such. And they should probably be marked up inside a thead element.
But you were no doubt following up my point about nested tables being
bad practice. Here's my on-topic reply: After a cursory look "under
the hood," it appears that the site author used tables for layout. The
*nested* tables -- some of them, at least -- contain tabular data. But
the outer tables do not contain tabular data.
Look at it this way. There are several td elements that contain images
of browning guns. Pick one. Now find it's table header cell.
Barry Pearson
> [x-posting trimmed to ciwah, since this reply does not really belong
> in opera.*]
>
> Barry Pearson wrote:
>>
>> nested tables are often a good idea
>
> I've yet to see one good idea executed with tested tables. Perhaps
> I've been looking in the wrong places.
Perhaps. Or perhaps we have different opinions about what are good ideas. I
evaluate ideas using engineering principles.
I have an advantage that I don't have a hang-up about layout tables. Simple
layout tables can be be accessible, efficient, effective, flexible, robust,
future-proof, and easy to author. Statements to the contrary don't stand up to
scrutiny.
If I have used a layout table, and between half and 2/3rds of my pages do, I
sometimes use a table for tabular data within them. Or sometimes the table
within them is on the dividing line between layout & tabular data. For
example, I have columns of <td> buttons that have <th> headers for sets of
them because the links come in sets.
>> and can be used for reasons other than layout.
>
> ...such as?
Consider a table with (say) a column for a date then one for extracts from
articles or reports, hence showing a sequence. The extracts may have tables.
Here is an example (the big table with green header cells, not the layout
tables). The page was created a long time ago, so I wouldn't engineer it the
same now. But there is a nested table at 1999-12-06.
http://www.childsupportanalysis.co.uk/information_and_explanation/computer/parliament_old.htm
Brian
> Brian wrote:
>
>> Barry Pearson wrote:
>>
>>> nested tables are often a good idea
>>
>> I've yet to see one good idea executed with tested tables.
>> Perhaps I've been looking in the wrong places.
>
> Perhaps. Or perhaps we have different opinions about what are good
> ideas. I evaluate ideas using engineering principles.
uh huh. Is that some arcane science, or could you elaborate on this
evaluation process of yours?
> I have an advantage that I don't have a hang-up about layout
> tables.
(You have a *dis*advantage that...)
Do you also support using <blockquote> to indent text? How about using
<h2> to change font size and weight?
> Simple layout tables can be be accessible, efficient, effective,
> flexible, robust, future-proof, and easy to author.
Layout tables are an (ab)use of an element to achieve the formatting
effects of certain browsers.
Barry Pearson
> Barry Pearson wrote:
>> Perhaps. Or perhaps we have different opinions about what are good
>> ideas. I evaluate ideas using engineering principles.
>
> uh huh. Is that some arcane science, or could you elaborate on this
> evaluation process of yours?
I assume that you accept the value of engineering. (Engineering is a
systematic approach to trying to achieve required output qualities within the
constraints of the project). I assume that you are asking about which methods
I use for cases like this. (It would be better to talk about "methods" or
"processes" than "science", in this context).
I base my approach on OPENframework. (I am familiar with other methods too).
This uses an abstract system architecture, then applies a set of methods to
achieve the desired qualities of the system. It isn't magic - much of it is a
comprehensive set of checklists to ensure that you have applied your prior
knowledge, and the extra knowledge you have to gain for the purpose, in a
systematic way. (I don't know if the system architecture books are still on
sale. The methods were only ever available as part of the training courses.
You do *not* want to get me started on a training course, unless you can spend
a week in a classroom! I have delivered the training courses in several places
around the world, including Silicon Valley!)
What we are trying to do is make decisions among various ways of doing things.
Let's keep this on-topic, so we are trying to judge whether layout tables or
tableless layouts or hybrids or something else is better for a given project.
I'll translate the standard terms into web site terms.
We need to know what "better" means. It doesn't have an absolute meaning - it
has to be evaluated according to the criteria of the key players. We have to
ensure that the decision is reasonable for each of these people. And for a web
site, and its pages, the (4) key players are:
- The senior managers/owners of the organisation that is exploiting the web
site for business purposes.
- The content designers and authors responsible for achieving the managers'
aims.
- The people (perhaps webmasters) who have to keep it up and running.
- The users, typically (but not only) the clients of business organisation.
We need to know what they are judging. It isn't the whole (8-box) system,
because much of it doesn't change with the layout technique. (We are not
trying to evaluate TCP/IP!) We appear to be evaluating:
- The architectural/structural approach. (Guiding principles of mark-up &
CSS).
- The tools available to the content designers and authors. (Authoring tools,
etc).
- The tools available to the users. (Browsers, visual & non-visual).
The quality judgements fall into the following (5) categories, all of which
can apply to each of the things we are judging, and all of which are relevant
to the key players in their different ways.
- Do the techniques make the material available in the required range of
circumstances? (Eg. on a mobile phone, if that is what the managers require).
- Are the results usable/accessible to the target audience? (This really needs
experimental evaluation).
- Is the performance adequate? (Download time. First rendering time.
Response-time for forms, etc).
- What about security? (I don't think it makes much difference here).
- What is the potential for change? This is one of the most important
qualities. CSS Positioning is claimed to deliver this. In practice, that is a
"big lie". It rarely offers more dramatic layout changes, purely via CSS
changes, than providing a mirror-image of the page. Other changes tend to need
mark-up or content changes.
What are the project constraints/parameters that have to be satisfied?
- Cost. (Would extra authoring cost be better spent on, say, promotion?)
- Risk. (Judge this for all of the key players).
- Time.
- Asset-building. (Does the development build re-usable assets?)
In order to help evaluate approaches, I built a whole range of pages, using
different techniques, so that I could compare them according to all the above
criteria. I have posted URLs to some of these on various occasions. I have now
uploaded all except 3 of them (I'm still trying to make those presentable)
with an index & summary at:
http://www.barry.pearson.name/articles/layout_5_3/
Another thing I did was take a 30-day trial of IBM Home Page Reader to see
what such pages "appeared" like using a non-visual browser.
Ultimately, the judgements are somewhat subjective. How can I judge whether a
blind person elsewhere has the same experience that I have when rendering a
page? There are still lots of judgement-calls, of course. As I said, this
isn't magic. But the above 3-dimensional checklist reduces the number of
issues I've overlooked, and focuses the mind on what matters. What matters
aren't my prejudices or yours, not my pre-conceived ideas or yours, but the
practical realities now, and (via "potential for change") in the future. The
method typically undermines pre-conceived ideas! Don't do engineering if you
want to cling to views that cannot be supported by evidence, or that are
irrelevant to what is being attempted.
Simple layout tables can work very effectively. Output qualities. Project
parameters. They are an inevitable, and valuable, part of the future.
>> I have an advantage that I don't have a hang-up about layout
>> tables.
>
> (You have a *dis*advantage that...)
In what way can avoiding a hang-up be a disadvantage? No - it is an advantage.
It enables me to use techniques that satisfy all the important players,
according to the above method.
As far as I am concerned, a layout table is only "wrong" (in a given case) if
it doesn't match the required engineering qualities. And it happens that
layout tables typically match them very well! They can be accessible,
effective, usable, fast, secure, future-proof, flexible, and cheap to
implement & support.
> Do you also support using <blockquote> to indent text? How about using
> <h2> to change font size and weight?
Before I started to use CSS, yes (except for the <h2> bit!). Now I have built
a set of re-usable rules to achieve much better results. For example:
- I have class called "blocklist". It takes a <ul> and renders it somewhat
like a <blockquote>. It does what before I used <blockquote> for.
- I have a class called "section" which wraps a header and its associated
content and indents them, in a nested way. This helps make structured mark-up
better presentationally.
http://www.barry.pearson.name/articles/templates/extra_effects.htm
>> Simple layout tables can be be accessible, efficient, effective,
>> flexible, robust, future-proof, and easy to author.
>
> Layout tables are an (ab)use of an element to achieve the formatting
> effects of certain browsers.
The formatting is defined in the "visual formatting model" by W3C. Claims that
HTML is layout-neutral are an attempt to re-write history - a "big lie".
W3C didn't invent tables. They first appeared in the Mosaic Alpha-8 version in
December 1994. I defy you or anyone here to provide evidence that they were
*not* intended for layout purposes. Even if that wasn't the initial intention,
I defy you or anyone here to provide evidence that the originators of tables
were at all upset when layout tables "took off" during 1995/6.
And I defy you or anyone here to provide evidence that CSS1 and CSS2 were
intended to avoid the need for layout tables. I don't believe that was on the
agenda. So why should anyone believe that they can do what they were not
intended to do?
Brian
> Brian wrote:
>
>> Barry Pearson wrote:
>
> We have to ensure that the decision is reasonable for each of these
> people. And for a web site, and its pages, the (4) key players are:
> exploiting the web site for business purposes.
So, how is a site about medieval Latin "exploiting the web...for
business purposes?"
> The quality judgements fall into the following (5) categories, all
> of which can apply to each of the things we are judging, and all of
> which are relevant
> In order to help evaluate approaches, I built a whole range of
> pages, using different techniques
> Ultimately, the judgements are somewhat subjective. How can I judge
> whether
I guess applying "engineering principles" to table layout isn't very
useful, then?
Barry Pearson
> Barry Pearson wrote:
>>
[snip]
>> Ultimately, the judgements are somewhat subjective. How can I judge
>> whether
>
> I guess applying "engineering principles" to table layout isn't very
> useful, then?
It is very useful indeed. But only to people with enough of a brain that they
are still prepared to make judgements instead of needing a method to make
their decisions for them.
My statement above could be used for driving a car too. There are systematic
ways of driving that vastly reduce the risk of accidents, and improve the
situation for other road users. But judgements such as "that other car is far
enough away for me to manoeuvre without interfering", or "now is the time to
apply the brakes in order to stop on this damp road before the lights", are
somewhat subjective. The starting point is to choose to think about those
judgements, instead of acting blindly. Then decision-making improves with
experience.
The single most useful part of this method (which has been applied across many
technical systems) is that it looks at the system from 4 carefully-selected
perspectives (enterprise management, application developer, system manager,
user) and makes judgements about 5 qualities (availability, usability,
performance, security, and potential for change). The full application of the
method can get "heavy", using usability labs, for example. That may sometimes
be needed. But it is unlikely that they are really needed here, because it
doesn't take much experimentation with a modern non-visual browser to realise
that use of simple layout-tables isn't the issue it is sometimes claimed to
be.
For interest, here is a paper I wrote a few years ago describing a business
method I developed that used such checklists, in this case exploiting the
qualities mentioned above. I resisted some pressure to build a spreadsheet
that produced numbers from the various matrices. I wanted the method to be
used for systematic and comprehensive consensus-building, not for blind
decision-making.
http://www.barry.pearson.name/papers/value_chain/
What I said there was: "... the Process is a tool to aid consensus and
decision making, not magic - whatever it says, professional people must
exercise their own judgement and not use the Nuremberg defence "I was only
obeying orders". If the resultant decision remains disliked, then they should
follow their judgement, and the Process has served its purpose by challenging
a position which has probably turned out to be robust."
I intended to convert what I wrote earlier into an article that I'll publish
on the web.
Brian
> Brian wrote:
>
>> Barry Pearson wrote:
>
>>> I have an advantage that I don't have a hang-up about layout
>>> tables.
>>
>> (You have a *dis*advantage that...)
>
> In what way can avoiding a hang-up be a disadvantage?
Person A: Jumping off a 2 story building is a bad idea.
Person B: I I have an advantage that I don't have a hang-up about
jumping off such buildings.
Person A: You have a *dis*advantage...
>> Do you also support using <blockquote> to indent text? How about
>> using <h2> to change font size and weight?
>
> Before I started to use CSS, yes (except for the <h2> bit!). Now I
> have built a set of re-usable rules to achieve much better results.
> For example:
Why have you stopped using them that way? <blockquote> used to create
an indentation is tantamount to using tables to lay out parts of a
page side by side. The results ought to be roughly equal.
> The formatting is defined in the "visual formatting model" by W3C.
> Claims that HTML is layout-neutral are an attempt to re-write
> history - a "big lie".
See the thread on <em> and italics in ciwah (thread: "proper use of
<cite>"), perhaps starting with message baBKb.764978$Fm2.732066@attbi_s04
> W3C didn't invent tables. They first appeared in the Mosaic Alpha-8
> version in December 1994. I defy you or anyone here to provide
> evidence that they were *not* intended for layout purposes.
Why don't you provide some evidence that they *were*?
> Even if that wasn't the initial intention,
In other words, you have no such evidence?
> I defy you or anyone here to provide evidence that the originators
> of tables were at all upset when layout tables "took off" during
> 1995/6.
What would this prove?
> And I defy you or anyone here to provide evidence that CSS1 and
> CSS2 were intended to avoid the need for layout tables. I don't
> believe that was on the agenda. So why should anyone believe that
> they can do what they were not intended to do?
In the absence of facts to the contrary, I'll continue to assert that
they were intended to markup tabular data. Just like I'll continue to
assert that <blockquote> was created to present block quotations. I'd
venture to guess that's why they're called <table> and <blockquote>,
and not, say, <layout> and <indent>.
Barry Pearson
> Barry Pearson wrote:
>> Brian wrote:
>>> Barry Pearson wrote:
>>>> I have an advantage that I don't have a hang-up about layout
>>>> tables.
>>>
>>> (You have a *dis*advantage that...)
>>
>> In what way can avoiding a hang-up be a disadvantage?
>
> Person A: Jumping off a 2 story building is a bad idea.
>
> Person B: I I have an advantage that I don't have a hang-up about
> jumping off such buildings.
>
> Person A: You have a *dis*advantage...
No one gets hurt using layout tables. People get delayed & frustrated *not*
using layout tables.
You got your analogy the wrong way round! Person A is suggesting that using
CSS-P is not good. Person B is *you*!
"Designing with CSS is sometimes like barreling down a crumbling mountain road
at 90 miles per hour secure in the knowledge that repairs are scheduled for
next Tuesday". (Al Sparber, Project Seven Development).
[snip]
>> W3C didn't invent tables. They first appeared in the Mosaic Alpha-8
>> version in December 1994. I defy you or anyone here to provide
>> evidence that they were *not* intended for layout purposes.
>
> Why don't you provide some evidence that they *were*?
Why? I just state that people who claim that tables were not intended for
layout are probably wrong, which they probably are. But they are welcome to
show evidence to the contrary. (I notice that you haven't attempted to do so).
>> Even if that wasn't the initial intention,
>
> In other words, you have no such evidence?
I'm not the one making claims about whether or not tables were intended for
layout. You and others are. (Without evidence, so far).
>> I defy you or anyone here to provide evidence that the originators
>> of tables were at all upset when layout tables "took off" during
>> 1995/6.
>
> What would this prove?
Using tables for layout is a brilliant idea, and helped to make the web the
interesting, useful, and successful system it is. There is no evidence that I
can find that tables were *not* intended for layout. There is no evidence that
I can find that using them for layout was a cause of dismay. It appears that
tables & layout went hand-in-hand from the start, and continued for several
years through the W3C "visual formatting model". It doesn't even matter
whether they were intended for layout - all that matters is the *consequence*
of using them for layout. (Lots of things use things that were not intended
for that purpose. It is part of our strength as human beings - it isn't a
weakness, or wrong!)
It is the people who claim otherwise who appear to have a problem. They appear
to be trying to re-write history. That is unwise. It is better to beat your
opponents before you try to rewrite history! The web is overwhelmingly
layout-table based, both in terms of the pages that have already been
published, and in terms of then pages published every day. And those pages are
successfully accessed right across the world. They still will be in the
decades to come. No one dare stop that!
>> And I defy you or anyone here to provide evidence that CSS1 and
>> CSS2 were intended to avoid the need for layout tables. I don't
>> believe that was on the agenda. So why should anyone believe that
>> they can do what they were not intended to do?
>
> In the absence of facts to the contrary, I'll continue to assert that
> they were intended to markup tabular data.
[snip]
Why would you assert something like that without supporting evidence? (Which
you haven't provided). Is that how you work - assert things without supprting
evidence?
Why? Doesn't that make you feel uncomfortable?
Alan J. Flavell
> Barry Pearson wrote:
>
> > W3C didn't invent tables.
True enough. The W3C didn't exist in 1993 (see Dave Raggett's HTML+
Internet Draft) http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.html
> > They first appeared in the Mosaic Alpha-8
> > version in December 1994.
No, they appeared in discussions which pre-dated Raggett's 1993 draft.
> > I defy you or anyone here to provide
> > evidence that they were *not* intended for layout purposes.
Do you, indeed? Interesting. Why is it so important to you to
obfuscate this topic?
> > I defy you or anyone here to provide evidence that the originators
> > of tables were at all upset when layout tables "took off" during
> > 1995/6.
>
> What would this prove?
Hmmm, interesting. A google search for "tables as layout" with 1995
produced:
problems with using tables as layout devices); ... Copyright
© 1995-2004 by Addison Wesley A division of Pearson Education ...
Honest, Guv!
> In the absence of facts to the contrary, I'll continue to assert that
> they were intended to markup tabular data. Just like I'll continue to
> assert that <blockquote> was created to present block quotations. I'd
> venture to guess that's why they're called <table> and <blockquote>,
> and not, say, <layout> and <indent>.
Makes sense to me. But there's no accounting for some.
cheers
Brian
>
> No one gets hurt using layout tables.
(Ab)using html elements for the presentation effects that they have in
certain browsers has hurt all of us. If tables had never been used for
layout, then it would be trivial to search for tabular data on
population changes in west Africa. If blockquote had never been used
for layout, then it would be trivial to search for pages that quoted
Noam Chomsky.
> People get delayed & frustrated *not* using layout tables.
People get frustated doing both, I'm sure.
> Why? I just state that people who claim that tables were not
> intended for layout are probably wrong,
You've reversed the burden of proof, with what appears to be circular
reasoning, i.e., tables were meant for layout because they are used
for layout. We can only be sure that the <table> element was meant for
tabular data, hence its descendent <td> for table data.
If it were a layout element, I'd expect we'd have <layout> with
perhaps descendents called <block> or some such thing.
> But they are welcome to show evidence to the contrary.
How about evidence of something more broad? HTML was not intended as a
layout language:
http://www.w3.org/Style/LieBos2e/history/
"The separation of document structure from the document's layout had
been a goal of HTML from its inception in 1990."
I searched for history and html, and found the following:
http://www.w3.org/Talks/WWW94Tim/
http://www.w3.org/History/1989/proposal.html
http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html
There are about the web and html as it existed in its infancy.
Presentation of any sort is rarely mentioned, and then it's either a
suggestion for appearance, e.g.,
"Address
This tag is for address information, signatures, etc, normally at the
top or bottom of a document. typically, it is italic and/or right
justified or indented."
or an explicit rejection of a defined appearance, e.g.,
"Paragraph
This tag indicates a new paragraph. The exact representation of this
(indentation, leading, etc) is not defined here, and may be a function
of other tags, style sheets etc."
Perhaps the one exception is
"Highlighting
The highlighted phrase tags may occur in normal text, and may be
nested. For each opening tag there must follow a corresponding closing
tag. NOT CURRENTLY USED."
But this seems to be the origin of <em>, with no explicit instructions
as to it's appearance. In any case, it appears to have been deprecated
early on.
> Using tables for layout is a brilliant idea, and helped to make the
> web the interesting, useful, and successful system it is.
To paraphrase something from a recent thread: restating a hypthesis is
not a substitute for proving that hypothesis.
> There is no evidence that I can find that tables were *not*
> intended for layout.
My bogosity meter is registering increased activity. Why are you
demanding that I prove a negative?
> Why would you assert something like that without supporting
> evidence? (Which you haven't provided). Is that how you work -
> assert things without supprting evidence?
<table> is for tables seems rather intuitive
<table> is for layout is not, and needs, imho, some evidence
Brian
>
> If tables had never been used for layout, then it would be trivial
> to search for tabular data on population changes in west Africa.
I just did a Google search for "table west africa population change"
The first 2 links were about west Africa, each with a <strong> element
containing "table of contents." But no tables of data.
The 3rd is a link to a publisher, again no tables.
We do find a table -- several, in fact! -- at the 4th and 5th hits.
Unfortunately, they are a pdf documents, and concern Australia and not
Africa.
The 6th link is another pdf file, this one about population changes in
Africa. Ah, but don't get your hopes up. It contains only a table of
contents, and no tables.
Onto to link 7. "table of contents" at the top. There is a table with
information, but no population figures. There is, though, a link to a
.zip file which may contain a table of population figures.
Link 8. An HTML file, with a table at the bottom. But not an html
table. It's an image, scanned from a book perhaps, and absolutely
unreadable on my laptop.
Link 9. No table of any sort.
Link 10. A table of contents.
All in all, not very useful results, I'd say.
Barry Pearson
> On Thu, 8 Jan 2004, Brian revealed that:
>> Barry Pearson wrote:
> True enough. The W3C didn't exist in 1993 (see Dave Raggett's HTML+
> Internet Draft) http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.html
>
>> > They first appeared in the Mosaic Alpha-8
>> > version in December 1994.
>
> No, they appeared in discussions which pre-dated Raggett's 1993 draft.
Thanks for that URL. I'm trying to find who said what, when. That is a useful
addition to my draft page:
"A brief history of tables"
http://www.barry.pearson.name/articles/layout_tables/history.htm
>> > I defy you or anyone here to provide
>> > evidence that they were *not* intended for layout purposes.
>
> Do you, indeed? Interesting. Why is it so important to you to
> obfuscate this topic?
[snip]
I'm interested in the facts. I have become sceptical of various statements
I've seen about what tables were intended for, what the effects of using them
are, etc. (My statement above was in response to stuff about tables *not*
being intended for layout. It doesn't matter much, because what matters is
"now" and "the future", but I'm curious).
Much of what is said doesn't stand up to scrutiny. This is important for me,
because I want to know what techniques are sensibly available for use. Can I
safely & reliably use layout tables? Will future browsers stop supporting
them? Given the immaturity of CSS positioning, partly because of lack of
features in CSS1 +2, and partly because of problems with just about all
browsers I've tried (not just IE), I want to know when to use which technique,
or when to mix them. (It may be important for others, too. That is for them to
decide, but I'll publish what I find in case anyone is interested).
I've seen statements about layout tables resulting in bloated size. So I built
a variety of test pages (see below), and compared them. Tables add perhaps 25
bytes per item being positioned - hardly "bloat" for a 3-column layout! I've
seen statements that they make pages inaccessible. So I tried using IBM's Home
Page Reader to see what their effect was. It wasn't layout tables that screwed
me up, it was new windows, Flash (actually, I chickened out), poor site
navigation, etc. I've seen statements about how inflexible layout tables are.
But in practice, if you resist the temptation to over-control the widths, they
are nicely adaptable to both the content and the viewport width. Surely those
are important things for a web site/page developer to know?
"Variations on the 5-box 3-column layout"
http://www.barry.pearson.name/articles/layout_5_3/
So when I recently did a significant amount of work on a couple of web sites,
in one case I used simple layout tables, and in the other (at much greater
development effort) indulged myself in developing some tableless-layout
templates. Those were appropriate choices for the different cases. I have both
a screwdriver and a hammer available!
"If all you have is a hammer, everything looks like a nail". (Traditional)
"If all you have is a screwdriver, everything may get screwed up". (Pearson,
2004)
Also (perhaps confirming your - justified - hatred of 3.2!):
W3C, HTML 3.2, "Tables ... can be used to markup tabular material or for
layout purposes".
http://www.w3.org/TR/REC-html32#table
Barry Pearson
> Barry Pearson wrote:
>>
>> No one gets hurt using layout tables.
>
> (Ab)using html elements for the presentation effects that they have in
> certain browsers has hurt all of us. If tables had never been used for
> layout, then it would be trivial to search for tabular data on
> population changes in west Africa. If blockquote had never been used
> for layout, then it would be trivial to search for pages that quoted
> Noam Chomsky.
As I said, "No one gets hurt using layout tables"!
[snip]
>> Why? I just state that people who claim that tables were not
>> intended for layout are probably wrong,
>
> You've reversed the burden of proof, with what appears to be circular
> reasoning, i.e., tables were meant for layout because they are used
> for layout. We can only be sure that the <table> element was meant for
> tabular data, hence its descendent <td> for table data.
I simply state that people who claim that tables were not intended for layout
are probably wrong. You could provide evidence to the contrary, if able.
[snip]
>> But they are welcome to show evidence to the contrary.
>
> How about evidence of something more broad? HTML was not intended as a
> layout language:
>
> http://www.w3.org/Style/LieBos2e/history/
>
> "The separation of document structure from the document's layout had
> been a goal of HTML from its inception in 1990."
Chuckle! I've read that page. I love the bit about Marc Andreessen's
conversion! I keep finding statements that didn't influence the web being
contradicted by statements and actions that did influence the web. And visual
formatting influenced the web.
> I searched for history and html, and found the following:
>
> http://www.w3.org/Talks/WWW94Tim/
> http://www.w3.org/History/1989/proposal.html
> http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html
>
> There are about the web and html as it existed in its infancy.
> Presentation of any sort is rarely mentioned, and then it's either a
> suggestion for appearance, e.g.,
Thank you for those URLs. They simply didn't say either way. And that is
typical. I'm wondering if the people making these statements, and writing the
specifications, and building the technologies, actually thought about this one
way or the other.
But I do think they simply took it for granted that the stuff would be
displayed visually. TBL talks about "diagrams with circles and arrows". The
"HTML tags" page talks about "displaying", with titles on "one line". Another
document talks about a "stream of lines" (up to 80 characters wide). Their
references to layout are simply dropped in casually, suggesting that it was
obvious to them.
HTML 3.2 explicitly stated that tables "can be used to markup tabular material
or for layout purposes".
[snip]
>> Using tables for layout is a brilliant idea, and helped to make the
>> web the interesting, useful, and successful system it is.
>
> To paraphrase something from a recent thread: restating a hypthesis is
> not a substitute for proving that hypothesis.
Would the web be the success it is if people had not used layout tables in
1995/6 to start to build more complex pages? I doubt it.
http://mercury.easternct.edu/d/duboisl/web/history/1996.html
>> There is no evidence that I can find that tables were *not*
>> intended for layout.
>
> My bogosity meter is registering increased activity. Why are you
> demanding that I prove a negative?
[snip]
It is perfectly possible to prove a negative! If you needed to, you could
prove to your nearest doctor that you were not a woman.
I suspect that you are talking about a different logical issue: "absence of
evidence is not evidence of absence". That is vastly different, and not what I
was expecting.
Ian Rastall
> As I said, "No one gets hurt using layout tables"!
I agree. I use tables for layout, even if it's not correct usage. I
sure do look forward to the day when there's better support for CSS,
though.
Ian
--
http://www.aspipes.org/
http://www.bookstacks.org/
http://www.learnsomethingnew.us/
Nick Kew
at the keyboard of "Barry Pearson" <ne...@childsupportanalysis.co.uk> wrote:
> As I said, "No one gets hurt using layout tables"!
Nonsense.
To take just one example, consider a layout table designed to give
columns of text (three or even four is not unusual). Now consider
a reader with low vision, who can only read large print and get 50
characters across the width of a screen. Because the layout table
is inflexible, it can't be sized down that far and you've got
lots of horizontal scrolling.
Or the common case of pixel-widths for text columns, which
routinely bugger me up.
Of course you can fix it with solutions like mod_accessibility,
but that only works because it gives users the option to linearise
the offending table.
> Thank you for those URLs. They simply didn't say either way.
Of course not. Noone had yet raised the possibility of abuse.
Noting your posting address, I could say by analogy: if children
were never neglected, it wouldn't enter anyone's head to have a
child support agency.
--
Nick Kew
In urgent need of paying work - see http://www.webthing.com/~nick/cv.html
Barry Pearson
> In article <W5GLb.537$sb.3...@newsfep1-win.server.ntli.net>, one of
> infinite monkeys at the keyboard of "Barry Pearson"
> <ne...@childsupportanalysis.co.uk> wrote:
>
>> As I said, "No one gets hurt using layout tables"!
>
> Nonsense.
>
> To take just one example, consider a layout table designed to give
> columns of text (three or even four is not unusual). Now consider
> a reader with low vision, who can only read large print and get 50
> characters across the width of a screen. Because the layout table
> is inflexible, it can't be sized down that far and you've got
> lots of horizontal scrolling.
In that case, it isn't the layout tables that are screwing things up. It is
the lack of flexibility. Tables can be flexible, and CSS-P can be inflexible.
The single built-in inflexibility of a table is that it puts things
side-by-side in the mark-up, while some CSS-P layouts do so in the CSS. (Even
that can be disabled, as Opera's "small screen mode" shows).
Here is one of the CSS-P 3-column layouts that I investigated, based on things
I found on the web. When I look at this via Firebird with the font size
wound-up a lot, I get superimposed text, a horizontal scrollbar, and just
about everything that people complain about in tables.
http://www.barry.pearson.name/articles/layout_5_3/tableless_flexible_00.htm
> Or the common case of pixel-widths for text columns, which
> routinely bugger me up.
The above CSS-P 3-column layout uses pixel-widths for text columns. So do
other CSS-P layouts around. In fact, CSS often gets focused on pixels. One
problem is that floating needs widths, and it is common to use px values. And
if you use absolute positioning instead, you risk superimposition.
People abuse CSS-P just as much as they abuse layout tables. I guess some of
my pages screw you up too - I tend to prefer 2 rather than 3 columns, but the
sidebar, typically used for site navigation, tends to be of the order of
180px. Then, whether I am using a layout table or CSS-P, the main column takes
up the rest of the viewport. I would welcome your views on the following,
because I don't deliberately go around screwing people up!
http://www.childsupportanalysis.co.uk/
http://www.barry.pearson.name/articles/templates/template_2_columns_right.htm
> Of course you can fix it with solutions like mod_accessibility,
> but that only works because it gives users the option to linearise
> the offending table.
I think that as a society we must make such technologies more widely
available. My "model" is to use use technology to increase the capability of
disadvantaged people, not to try to hinder development of things that run the
risk of leaving them behind.
>> Thank you for those URLs. They simply didn't say either way.
>
> Of course not. Noone had yet raised the possibility of abuse.
My conclusion is that at that time few people were really thinking about page
layout. They were so focused on moving information around that they neglected
human nature - which has a strong design/layout component. People will always
demand control of layout. The trick is to get a good balance between
satisfying the demands of the publisher and the needs of the users. I believe
that is best achieved by transmitting a higher level abstraction of the
publishers' desires than CSS currently provides. Layout tables are closer to
this than CSS1 & CSS2.
> Noting your posting address, I could say by analogy: if children
> were never neglected, it wouldn't enter anyone's head to have a
> child support agency.
Chuckle! Don't let people entangled with the CSA hear you say that! (I'm
childfree so it doesn't matter here).
The CSA is just the latest method in child support systems for at least the
last 4 centuries in the UK, since the first Poor Law. Child support (in the UK
& elsewhere, and down through the centries) always has 2 separate strands: to
relieve child poverty; and at minimum cost to the community at large.
http://www.childsupportanalysis.co.uk/information_and_explanation/world/history_uk.htm
"Neglect" is misleading. Many people paying child support were forced to be
apart from their children, and would rather be spending the money directly on
them. And if a separated father and mother share the care of the children
equally, and even earn the same amount (or the mother earns lots more), the
father will end up paying the mother, because of *explicit* sex-bias in the
UK's child support legislation.
Nick Kew
at the keyboard of "Barry Pearson" <ne...@childsupportanalysis.co.uk> wrote:
> The single built-in inflexibility of a table is that it puts things
> side-by-side in the mark-up,
s/single/critical/ in the above. It's exactly what I complain of.
> while some CSS-P layouts do so in the CSS.
Critical difference: CSS can be turned off.
> (Even
> that can be disabled, as Opera's "small screen mode" shows).
Yes indeed: Opera's small-screen mode is rather similar to
mod_accessibility's linearisation option, although the mechanics
of it are entirely different.
> Here is one of the CSS-P 3-column layouts that I investigated, based on things
> I found on the web. When I look at this via Firebird with the font size
> wound-up a lot, I get superimposed text, a horizontal scrollbar, and just
> about everything that people complain about in tables.
> http://www.barry.pearson.name/articles/layout_5_3/tableless_flexible_00.htm
You're on much firmer ground arguing that CSS is not the panacea for
every ill. FWIW, that page looks great in my "normal" browser (Konq) at
normal settings, but just narrowing the window too far messes it up
as it squeezes the middle column out. But there's still that crucial
difference: I as a user am empowered to turn it off, even if I don't
have the luxury of an advanced enabling technology like
mod_accessibility or Opera.
Look at that vs a 3-column table in Lynx. 3 text columns in
80-characters width is readable but not pretty, but your CSS page
linearises automatically and looks better. Reduce the size of
the Lynx terminal, and it becomes the difference between working
well and a total mess.
>> Or the common case of pixel-widths for text columns, which
>> routinely bugger me up.
>
> The above CSS-P 3-column layout uses pixel-widths for text columns. So do
Exactly. See above. Actually that does screw it up even in Konq:
Leaving out the middle part (just to get it into an 80-column usenet
post) I see:
Leftbar filler. Leftbar filler. Rightbar filler. Rightbar
Leftbar filler. Leftbar filler. filler. Rightbar filler.
Leftbar filler. Rightbar filler. Rightbar
filler.
... which looks a little bit like a design that's "gracefully degraded"
by words wrapping differently on my display to yours.
>> Of course you can fix it with solutions like mod_accessibility,
>> but that only works because it gives users the option to linearise
>> the offending table.
>
> I think that as a society we must make such technologies more widely
> available. My "model" is to use use technology to increase the capability of
> disadvantaged people, not to try to hinder development of things that run the
> risk of leaving them behind.
No disagreement there. Just over how to proceed, and it comes down to
that crucial issue of empowerment.
>> Of course not. Noone had yet raised the possibility of abuse.
>
> My conclusion is that at that time few people were really thinking about page
> layout. They were so focused on moving information around that they neglected
> human nature
This begins to look much clearer. I'm one of those people who detests
control and presentation freaks, and will (for example) refuse to use
a shop that plays muzak at me. I suspect that's not untypical of the
innovators who created the web before the deezyners and marketroids
came in and covered it in layers of crap.
On a personal level, I (we?) probably don't even mix with the presentation
freaks. Someone who wears warpaint or a stripey shirt and loud tie,
or (worse) stinks of perfume or aftershave, just makes me (at best)
nervous/edgy, and wanting to get away.
I guess you loved all those "millennium" projects too, so full of
glitz but lacking firm foundations? That bridge that swayed so
alarmingly as soon as people tried to walk across it - has to be
a great analogy for deezyner websites. So does the extra millions
they had to spend on it to make it fit to use.
Human nature for you, maybe. Not for me. I'd rather see systems that
work - whether they be websites or bridges - than have someone's ego
thrust in the way. Sure, there's a place for personal and artistic
expression (mine include singing in opera - surely one of mankinds
most absurd activities:-), but that place should never be where it
makes life difficult for people who don't choose to participate.
--
Nick Kew
Barry Pearson
> In article <cNWLb.259$U83.3...@newsfep1-win.server.ntli.net>, one
> of infinite monkeys at the keyboard of "Barry Pearson"
> <ne...@childsupportanalysis.co.uk> wrote:
>
>> The single built-in inflexibility of a table is that it puts things
>> side-by-side in the mark-up,
>
> s/single/critical/ in the above. It's exactly what I complain of.
I suspect you are complaining about the number of columns, rather than whether
or not it uses layout-tables.
>> while some CSS-P layouts do so in the CSS.
>
> Critical difference: CSS can be turned off.
So can tables. See below. If you don't like, turn them off! If you are using
technology that doesn't let you, get better technology! It is out there.
Or ... just hit the back button. You can't do this if you depend on the site,
for example if it is in any sense a "public service" site. But you can for the
rest. And even for the public service sites, it is probably rare that you are
compelled to use the site - there are always alternatives. The (valid)
complaint is that people with vision problems are discriminated against, not
that they can't access the services of the organisation. *No one* is forced to
use a web site, even for public service purposes! So *no one* is hurt -
perhaps inconvenienced, perhaps discriminated against, but not *hurt*. Their
(valid) case is discrimination, not hurt.
>> (Even
>> that can be disabled, as Opera's "small screen mode" shows).
This probably - actually inevitably - indicates where the future lies - better
& better technology for accessing content of all sorts, including that within
layout-tables. I estimate that at least 95% of web pages use layout-tables,
and at least 95% of new pages each day use layout-tables. I came to this
conclusion because I have spent a long time browsing the web using a style of
the form:
table { border: 1px dotted blue; }
I access *lots* of pages and *lots* of web sites each week, and hardly any of
them doesn't show with a blue dotted rectangle. It is very rare to find a news
site, or even a UK government site, that doesn't use layout-tables. "Wired",
of course, and "UKonline", but others are very rare. (I am desperately trying
to think of another! ESPN front page but not content, and ... er ...). I
actually believe the figure is closer to 99% than 95%. It has been the
dominant layout technique for about 8 years, and I suspect it will continue to
be for at least the next 8.
Therefore, user technology will (have to) adapt to match one of the most
important global information resources. It has no choice. And as it adapts,
this will reduce the pressure for change. I believe there is no credible
alternative. In other words, it is transforming the future direction, as well
as the current state, of the web. I hope that future techniques for proposing
page layouts build on layout-tables, not CSS.
These are not bad people. People who build and drive motorcars are not bad
people, even though this is an activity not really available to blind people.
(I'm a photographer ... a very discriminatory hobby. Some people are musicians
... ditto). We all have to accept the we are excluded from some activities
because of our reduced abilities. You *really* would not like to have laws
that would compel people to accept me into a choir!
[snip]
>> Here is one of the CSS-P 3-column layouts that I investigated, based
>> on things I found on the web. When I look at this via Firebird with
>> the font size wound-up a lot, I get superimposed text, a horizontal
>> scrollbar, and just about everything that people complain about in
>> tables.
>> http://www.barry.pearson.name/articles/layout_5_3/tableless_flexible_00.htm
>
> You're on much firmer ground arguing that CSS is not the panacea for
> every ill. FWIW, that page looks great in my "normal" browser (Konq)
> at
> normal settings, but just narrowing the window too far messes it up
> as it squeezes the middle column out. But there's still that crucial
> difference: I as a user am empowered to turn it off, even if I don't
> have the luxury of an advanced enabling technology like
> mod_accessibility or Opera.
Er ... luxury? I don't pay for Opera! And if I had to pay because of a
disability, perhaps I would petition the government to help me out.
> Look at that vs a 3-column table in Lynx. 3 text columns in
> 80-characters width is readable but not pretty, but your CSS page
> linearises automatically and looks better. Reduce the size of
> the Lynx terminal, and it becomes the difference between working
> well and a total mess.
Better than what? Here are some alternatives to that page - which of them
linearises worse than that one?
http://www.barry.pearson.name/articles/layout_5_3/
[snip]
>> The above CSS-P 3-column layout uses pixel-widths for text columns.
>> So do
>
> Exactly. See above. Actually that does screw it up even in Konq:
> Leaving out the middle part (just to get it into an 80-column usenet
> post) I see:
>
> Leftbar filler. Leftbar filler. Rightbar filler. Rightbar
> Leftbar filler. Leftbar filler. filler. Rightbar filler.
> Leftbar filler. Rightbar filler. Rightbar
> filler.
>
> ... which looks a little bit like a design that's "gracefully
> degraded"
> by words wrapping differently on my display to yours.
But what about the article? The page exists for the article, not the leftbar &
rightbar! (It is interesting how many CSS-P layouts linearise with the article
late rather than early!)
[snip]
>> I think that as a society we must make such technologies more widely
>> available. My "model" is to use use technology to increase the
>> capability of disadvantaged people, not to try to hinder development
>> of things that run the risk of leaving them behind.
>
> No disagreement there. Just over how to proceed, and it comes down to
> that crucial issue of empowerment.
>
>>> Of course not. Noone had yet raised the possibility of abuse.
>>
>> My conclusion is that at that time few people were really thinking
>> about page layout. They were so focused on moving information around
>> that they neglected human nature
>
> This begins to look much clearer. I'm one of those people who detests
> control and presentation freaks, and will (for example) refuse to use
> a shop that plays muzak at me. I suspect that's not untypical of the
> innovators who created the web before the deezyners and marketroids
> came in and covered it in layers of crap.
My web pages are all very passive. They don't have any active content, no new
windows, no attempts to control the browser, etc.
I don't see a problem with those people, as long as they are not responsible
for public service web sites. They should have the right to do so (and indeed
*do* have that right). Users have the right the hit the back-button. Now we
are all happy. I would condemn any initiative to restrict those people, as
long as their web sites were not in any sense public service sites.
But layout is *vitally* important. It can make the difference between whether
people can navigate round the site or not. See:
"Criteria for optimal web design (designing for usability)"
http://psychology.wichita.edu/optimalweb/print.htm
Also see:
<extract>
That strikes me as the Web's saving grace. With the Web poised to go from 4
million sites to 100 million in the next few years, as you note in your
article, the idea of enforcing usability rules will never get past the
"thought experiment" stage. However, as you are not merely a man of action but
also a theorist, I want to address why I think enforced conformity to
usability standards is wrong, even in theory. My objections break out into
three rough categories: creating a market for usability is better than central
standards for reasons of efficency, innovation, and morality.
</extract>
That was from: Clay Shirky, "An Open Letter To Jakob Nielsen"
http://www.shirky.com/writings/nielsen.html
[snip]
> I guess you loved all those "millennium" projects too, so full of
> glitz but lacking firm foundations? That bridge that swayed so
> alarmingly as soon as people tried to walk across it - has to be
> a great analogy for deezyner websites. So does the extra millions
> they had to spend on it to make it fit to use.
I laughed at them. That isn't how I work. I use sound engineering principles
to judge what I should do. I run with Flash & other active content switched
off. I just hit the back-button if necessary. So can anyone else, except for
public service sites.
I don't do glitz. I take the trouble to understand my target audience and
cater for them. Anyone outside my target audience is on their own - take it or
leave it. Their problem, not mine.
> Human nature for you, maybe. Not for me. I'd rather see systems that
> work - whether they be websites or bridges - than have someone's ego
> thrust in the way. Sure, there's a place for personal and artistic
> expression (mine include singing in opera - surely one of mankinds
> most absurd activities:-), but that place should never be where it
> makes life difficult for people who don't choose to participate.
I see a web comprising "implicit communities". When I publish my photographs,
I am in an implicit community of people with sight, possibly calibrated
monitors, who possibly don't have an language in common with me. We
communicate in images, not text. Anyone who decides they don't qualify can go
and pursue their own activities in their own implicit communities. We have no
responsibility, legally or ethically, towards such people. We don't damage the
web. We just use it, at our own expense.
But for other published material, I am publishing to a different implicit
community, with totally different criteria for access. All involving English,
in my case. And government sites have communities which are actually not
implicit, but comprise the citizens. But even then the scope typically stops
at the boundaries of the UK & its citizens.
Publishers only have limited responsibilities on the web. The trick is to
understand the limits.
Brian
Barry Pearson wrote:
>
> The (valid) complaint is that people with vision problems are
> discriminated against, not that they can't access the services of
> the organisation. *No one* is forced to use a web site, even for
> public service purposes! So *no one* is hurt - perhaps
> inconvenienced, perhaps discriminated against, but not *hurt*.
> Their (valid) case is discrimination, not hurt.
My bogosity meter just pinned. I suppose by analogy that no African
Americans were hurt because they were denied a seat on the bus.[1]
"Perhaps inconvenienced, perhaps discriminated against, but not *hurt*."
Really, you say some silly things. Tables abused for layout don't
reach out of the browser and pinch the user, so no, noone is *hurt* by
them.
But what's interesting is the admission:
> The (valid) complaint is that people with vision problems are
> discriminated against,
> So *no one* is hurt - perhaps inconvenienced, perhaps discriminated
> against
> Their (valid) case is discrimination
Discrimination -- one reason I don't abuse tables for layout.
[1]This is an international forum, and there's no reason for me to
assume that everyone knows about discrimination in public
tranportation in the southern U.S.: Prior to the 1950s, African
Americans were confined to seats in the back of city buses, and had to
give up even those seats to whites if the bus was full.
Barry Pearson
[snip]
> Really, you say some silly things. Tables abused for layout don't
> reach out of the browser and pinch the user, so no, noone is *hurt* by
> them.
I don't accept that "abused" is valid in this context. Using simple tables for
layout is typically sensible, valuable, effective, accessible, cost-effective,
and future-proof. See:
http://joeclark.org/book/sashay/serialization/Chapter10.html
<extract>
Tables prompt eye-gouging hissyfits among accessibility advocates and Web
designers of all stripes, whether oldschool or avant-garde. Both sides are
saddled with myths and both argue in large part from ideology. Let's do a
reality check, shall we?
Tables were introduced in HTML 3.2 back in 1997. (Not HTML 2.0. Netscape 2.0
supported tables, but they made their début in HTML 3.2. Very oldschool
indeed.)
Purists, take note: Even back then, tables were expressly permitted "to mark
up tabular material or for layout purposes." Web designers who used tables for
page layout were not violating the spec, working against the spirit of the
true, glorious Internet, sullying the swimming pool, or committing any kind of
sin.
Nested tables - tables within tables - have always been expressly permitted.
Back to the HTML 3.2 spec: "A cell can contain a wide variety of other block-
and text-level elements including form fields and other tables." The fact that
nested tables take longer to display in a graphical browser is surely
undesirable, but you cannot ascribe that behaviour to the inevitable effect of
illegal coding. Nested tables have always been legal.
The use of tables for layout has never been prohibited by the Web
Accessibility Initiative. You are not creating an inaccessible page if it
contains tables used for layout. You have committed no sin - necessarily. You
will not be forced to turn in your trackball and badge while WAI Internal
Affairs conducts an investigation. But you are not off the hook: You must code
tables properly, which, for layout tables, is not difficult at all.
In fact, the strongest condemnation of tables in the WAI is as follows: "Do
not use tables for layout unless the table makes sense when linearized."
Linearizing refers to running the contents of cells together with no row or
column structure. (How? In languages reading from left to right, start with
the top row and read left to right. Then, in each successive row, concatenate
cells in left-to-right order.)
The idée fixe that layout tables are guilty until proven innocent - that they
do not "make sense when linearized" by default, that you're doomed to labour
over them forever to get them working - is an urban legend. Take my word for
it: Having used the Web since the days of Mosaic, I can assure you that most
layout tables do make sense, whether rendered as graphical tables or when
linearized. You will nonetheless learn how to make even more sense with layout
tables in this chapter.
Using tables for truly tabular data is actually quite rare online. In the
immortal words of William Gibson, the street finds its own uses for things.
The use the street found for tables is graphic design, not data structure.
When you employ tables for layout, you can get away with minimal coding. Data
tables require significant markup skills that take a long time to acquire. On
the other hand, the information in data tables is intrinsically complex, and
print designers struggle to this day with the difficulty of typesetting tables
in existing desktop-publishing software. If no one's gotten data-table
creation right in desktop publishing, a technology nearly 20 years old, why
are we surprised that conditions are rough on the Web?
</extract>
> But what's interesting is the admission:
>
>> The (valid) complaint is that people with vision problems are
>> discriminated against,
>
>> So *no one* is hurt - perhaps inconvenienced, perhaps discriminated
>> against
>
>> Their (valid) case is discrimination
>
> Discrimination -- one reason I don't abuse tables for layout.
[snip]
That wasn't a comment about the effects of tables. Nick Kew was complaining
about problems caused by multiple columns. Layout tables are neutral. See Joe
Clark's stuff above.
Lauri Raittila
> Brian wrote:
> [snip]
> > Really, you say some silly things. Tables abused for layout don't
> > reach out of the browser and pinch the user, so no, noone is *hurt* by
> > them.
>
> I don't accept that "abused" is valid in this context. Using simple tables for
> layout is typically sensible, valuable, effective, accessible, cost-effective,
> and future-proof. See:
> http://joeclark.org/book/sashay/serialization/Chapter10.html
Well, 99% of times, tables are abused, instead of used the way I hope
that link is telling. I think that it is just as easy to use CSS based
And, according to my dictionary, abuse is correct term even if used well.
Sometimes end justifies means. And most times not.
> <extract>
> Tables prompt eye-gouging hissyfits among accessibility advocates and Web
> designers of all stripes, whether oldschool or avant-garde. Both sides are
> saddled with myths and both argue in large part from ideology. Let's do a
> reality check, shall we?
>
> Tables were introduced in HTML 3.2 back in 1997. (Not HTML 2.0. Netscape 2.0
> supported tables, but they made their début in HTML 3.2. Very oldschool
> indeed.)
CSS1 in 1996, but it was not enaugh.
I wonder if JSSS has been chosen instead of CSS, would stylesheets be
more used nowadays? After all, Microsoft never has had any interest in
internet exept making money.
> Purists, take note: Even back then, tables were expressly permitted "to mark
> up tabular material or for layout purposes."
And this quote from html3.2 goes on:
"Note that the latter role typically causes problems when rending to
speech or to text only user agents"
Too bad they didn't understant that it also causes problem when displayed
in graphical browsers in some conditions.
And, html3.2 was not spec in traditional sence. As it was done to
according to current situation, instead of for future. I think that's why
it is called "Reference Specification" instead "Specification"
> Web designers who used tables for
> page layout were not violating the spec, working against the spirit of the
> true, glorious Internet, sullying the swimming pool, or committing any kind of
> sin.
Well, neither is George Bush the dumber & Co breaking law when they
accuse Greenpeace with some historical law. The question if it is sin is
totally different matter.
> Nested tables - tables within tables - have always been expressly permitted.
Of course, as they are necessary for certain kinds of tabular data.
Something like this is not possible whitout using nested tables:
http://www.student.oulu.fi/~egea/timetable.html
> The use of tables for layout has never been prohibited by the Web
> Accessibility Initiative. You are not creating an inaccessible page if it
> contains tables used for layout. You have committed no sin - necessarily. You
> will not be forced to turn in your trackball and badge while WAI Internal
> Affairs conducts an investigation. But you are not off the hook: You must code
> tables properly, which, for layout tables, is not difficult at all.
True, tables are not necessarily syn, and neither is CSS layout
necessarily good accessibility.
> The idée fixe that layout tables are guilty until proven innocent - that they
> do not "make sense when linearized" by default, that you're doomed to labour
> over them forever to get them working - is an urban legend.
IMHO, that is exactly correct idée. *If* accessibility has been taken
account, table layout is not usually much worse than suitable CSS based
layout. But it needs to be proven. One way to prove it is to have such
table layout that it will work in my normal browsing situation. Most
sites fail that, at least if I don't use some powertools.
> Take my word for
> it: Having used the Web since the days of Mosaic, I can assure you that most
> layout tables do make sense, whether rendered as graphical tables or when
> linearized. You will nonetheless learn how to make even more sense with layout
> tables in this chapter.
You apparently never really used browser window sized less than 600px. Or
have really used lynx. Or you have lots of patience to scroll.
I have had big problems with table-layout and lynx. And table-layouts and
Opera. Neither problem was because browser was bad, but becase table
layout was very stupid.
> Using tables for truly tabular data is actually quite rare online.
OTOH, not using table for tabular data in web is even more rare. Almost
as rare as well done table layout.
> The use the street found for tables is graphic design, not data structure.
> When you employ tables for layout, you can get away with minimal coding.
Then why is it that site done with table layout usually takes at least
50% more code than one whitout?
Or do you mean that you can use wysinwyg program? Never seen any proper
code generated using wysinwyg in real use that has not been cleaned.
> Data
> tables require significant markup skills that take a long time to acquire.
OTOH, simple cases are very simple to learn.
> If no one's gotten data-table
> creation right in desktop publishing, a technology nearly 20 years old, why
> are we surprised that conditions are rough on the Web?
WWW has advantages over print media. Big ones. And specs are on right
tracks. Unfortunately, browsers aren't interested in implementing goodies
in html4 spec etc, because there is no way to know which is layout table
and which not.
And also because data tables are not that popular. They are not that
popular in print design either.
> > But what's interesting is the admission:
> >
> >> The (valid) complaint is that people with vision problems are
> >> discriminated against,
> >
> >> So *no one* is hurt - perhaps inconvenienced, perhaps discriminated
> >> against
> >
> >> Their (valid) case is discrimination
> >
> > Discrimination -- one reason I don't abuse tables for layout.
> [snip]
>
> That wasn't a comment about the effects of tables. Nick Kew was complaining
> about problems caused by multiple columns. Layout tables are neutral. See Joe
> Clark's stuff above.
Well, it doesn't make much sence to have normal table layout whiout
multible columns. Most used browsers don't linearize tables any case. So
people that can see, but badly, are discriminated against.
OTOH, you can't do 2 column layout that works well in small window
whitout tables any better than you can do with just tables.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.
Barry Pearson
> In article Barry Pearson wrote:
>> I don't accept that "abused" is valid in this context. Using simple
>> tables for layout is typically sensible, valuable, effective,
>> accessible, cost-effective, and future-proof. See:
>> http://joeclark.org/book/sashay/serialization/Chapter10.html
>
> Well, 99% of times, tables are abused, instead of used the way I hope
> that link is telling. I think that it is just as easy to use CSS based
There is a fact that some people may not like to see revealed. From the time
that Dave Raggett proposed tables in "HTML+" in November 1993, tables have
been intended to display cells in a horizontal + vertical grid. And from
that date tables cells have been proposed and defined to contain complex
material, including headers, paragraphs, lists, text, and other stuff. (Which
is one of the reasons why their tags and attributes have terms like "row" and
"col" - that isn't an accident!)
See:
"A brief history of tables"
http://www.barry.pearson.name/articles/layout_tables/history.htm
Every single proposal and standard and Recommendation from that time onwards
has continued this theme, as far as I know. Tables are designed to layout
complex things in a grid-formation. It isn't an accident - they were always
intended to work like that! The proposals were, and the browsers were. That is
the defined nature of the web.
The very latest proposals are for XHTML 2.0, which we won't even see for
years. And guess what - just the same! Tables are designed & intended to deal
with complex content, and put it into a rectilinear array in visual-mode. That
is the current official W3C position on XHTML 2.0.
[snip]
>> The use of tables for layout has never been prohibited by the Web
>> Accessibility Initiative. You are not creating an inaccessible page
>> if it contains tables used for layout. You have committed no sin -
>> necessarily. You will not be forced to turn in your trackball and
>> badge while WAI Internal Affairs conducts an investigation. But you
>> are not off the hook: You must code tables properly, which, for
>> layout tables, is not difficult at all.
>
> True, tables are not necessarily syn, and neither is CSS layout
> necessarily good accessibility.
>
>> The idée fixe that layout tables are guilty until proven innocent -
>> that they do not "make sense when linearized" by default, that
>> you're doomed to labour over them forever to get them working - is
>> an urban legend.
>
> IMHO, that is exactly correct idée. *If* accessibility has been taken
> account, table layout is not usually much worse than suitable CSS
> based layout. But it needs to be proven. One way to prove it is to
> have such table layout that it will work in my normal browsing
> situation. Most sites fail that, at least if I don't use some
> powertools.
I only quoted the above material from Joe Clark. I didn't write it. Joe (and
I) believe that most sites work, not fail.
How do we resolve this disagreement?
>> Take my word for
>> it: Having used the Web since the days of Mosaic, I can assure you
>> that most layout tables do make sense, whether rendered as graphical
>> tables or when linearized. You will nonetheless learn how to make
>> even more sense with layout tables in this chapter.
>
> You apparently never really used browser window sized less than
> 600px. Or have really used lynx. Or you have lots of patience to
> scroll.
[snip]
I didn't write that - Joe did. But I always access my pages at a lot less than
that! Including 240 pixel wide (with Opera).
Firebird is cr*ap less than 476 pixels. In fact, Gecko browser tend to be
cr*ap at small viewport widths. They lose the vertical scrollbar. Firebird
often doesn't provide a horizontal scrollbar!
The only narrow viewport widths I feel confident with are IE handling
table-layout. Perhaps Opera too. The rest are cr*p.
Alan J. Flavell
> There is a fact that some people may not like to see revealed.
It holds no fears for me...
> From the time that Dave Raggett proposed tables in "HTML+" in
> November 1993, tables have been intended to display cells in a
> horizontal + vertical grid.
Not quite. Tables have been intended to markup a logical
relationship; when the presentation situation is appropriate, it's
intended that the relationship would be depicted as a 2-dimensional
grid, but that's not a mandatory requirement of the logical markup.
> See:
> "A brief history of tables"
> http://www.barry.pearson.name/articles/layout_tables/history.htm
If I'm going to say anything at all about this, then I'm going to have
to be candid.
In this respect I think I can claim the following -
1. I do know a little bit about the topics on which I choose to
comment, and I do have quite strong personal opinions about them,
2. Ihappen to be the principal author of several peer-reviewed FAQs in
which I deliberately throttled-back on my personal opinions and
managed, as it seems, to express an answer in terms that gained
widespread acceptance in the communities to which the various FAQs
were addressed.
On that basis, I think I can comment from both sides: the
strongly-held personal opinion, and the opinion-neutral presentation
of the facts.
And on that basis, my evaluation of your writings on this topic would
have to be this, I'm afraid: you formed a strong personal opinion of
what the answer had to be, and then you selected your evidence in
order to support it.
> Every single proposal and standard and Recommendation from that time onwards
> has continued this theme, as far as I know. Tables are designed to layout
> complex things in a grid-formation.
They're designed to express a relationship which, in appropriate
circumstances, it's appropriate to present in a two-dimensional grid
relationship.
> It isn't an accident
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.
If, in fact, there _is_ no such relationship, other than the
designer's visual intentions, then the tabular markup becomes not just
useless, but actively counter-productive.
> - they were always intended to work like that! The proposals were,
> and the browsers were. That is the defined nature of the web.
I'm going to have to disagree. Keep in mind that there are two kinds
of W3C specification, and they're hard to keep apart, "thanks" to the
fact that the W3C is not an independent standards-making body but an
industry consortium funded by its members. Sometimes their
specifications merely document what their members' software is
currently doing, and sometimes they sketch out more abstruse ideas
about the fundamental basis of what's going on. Compare, if you will,
HTML/3.2(spit), a fairly disgusting codification of what the
then-big-two were up to at the time, with CSS1, a somewhat idealised
specification that those big-two never did quite get around to
implementing.
Now look at what happened since. Do I need to spell it out? OK,
probably spelling it out would be pointless anyway: those who
understand it already, don't need to hear it from me, and those who
still think it's pseudo-HTML DTP, wouldn't listen to me anyway, so I
might as well save my breath/keyboard.
have fun
Lauri Raittila
> Lauri Raittila wrote:
> > In article Barry Pearson wrote:
> [snip]
> >> I don't accept that "abused" is valid in this context. Using simple
> >> tables for layout is typically sensible, valuable, effective,
> >> accessible, cost-effective, and future-proof. See:
> >> http://joeclark.org/book/sashay/serialization/Chapter10.html
> >
> > Well, 99% of times, tables are abused, instead of used the way I hope
> > that link is telling. I think that it is just as easy to use CSS based
>
> There is a fact that some people may not like to see revealed. From the time
> that Dave Raggett proposed tables in "HTML+" in November 1993, tables have
> been intended to display cells in a horizontal + vertical grid.
Well. I can't imagine any other way to display tabular data than using
rows and cols. Can you?
> And from
> that date tables cells have been proposed and defined to contain complex
> material, including headers, paragraphs, lists, text, and other stuff.
Of course. Just because data is tabular doesn't mean it is otherwise
meaningless. If it has meanings, they should be marked.
> (Which
> is one of the reasons why their tags and attributes have terms like "row" and
> "col" - that isn't an accident!)
Well row and col are pretty widely used when talking about tabular data.
I can't understand what you mean by this. Of course they are called row
and col. What else could they be caller?
> See:
> "A brief history of tables"
> http://www.barry.pearson.name/articles/layout_tables/history.htm
>
> Every single proposal and standard and Recommendation from that time onwards
> has continued this theme, as far as I know. Tables are designed to layout
> complex things in a grid-formation. It isn't an accident - they were always
> intended to work like that! The proposals were, and the browsers were. That is
> the defined nature of the web.
There is correct use for headings etc in table. If you have long content
in your cells, they should be marked up correctly.
For example, if you have images in one col, and how to do it in other,
you could use list to mark up the procedure. This is not necessarily best
chois of markup, but it is right.
> The very latest proposals are for XHTML 2.0, which we won't even see for
> years. And guess what - just the same! Tables are designed & intended to deal
> with complex content, and put it into a rectilinear array in visual-mode. That
> is the current official W3C position on XHTML 2.0.
Of course. That has nothing to do with using them for layout. Every
version of HTML specs have dispiced tables, exept HTML2, that didn't have
them IIRC. I quoted you the part of HTML3.2 that said they shouldn't be
used for layout.
> >> Take my word for
> >> it: Having used the Web since the days of Mosaic, I can assure you
> >> that most layout tables do make sense, whether rendered as graphical
^^^^
Certainly not most.
> >> tables or when linearized. You will nonetheless learn how to make
> >> even more sense with layout tables in this chapter.
> >
> > You apparently never really used browser window sized less than
> > 600px. Or have really used lynx. Or you have lots of patience to
> > scroll.
> [snip]
>
> I didn't write that - Joe did.
Well, you quoted it so I supposed you actually thought this was what you
thought what is correct.
> But I always access my pages at a lot less than
> that! Including 240 pixel wide (with Opera).
Your pages. You apparently have not used them to surf random pages, or
have you? If you would, you would know you are wrong. I have surfed 1.5
years using 550px wide window, and it doesn't work at all with table
layouts, unless I fix them at client side. If they also use lots of
images, it makes it too much problem to fix it, so I either need to
scroll, change my window size, or ignore site. Latter happens more often.
> Firebird is cr*ap less than 476 pixels. In fact, Gecko browser tend to be
> cr*ap at small viewport widths. They lose the vertical scrollbar. Firebird
> often doesn't provide a horizontal scrollbar!
Never used Firebird, and only use Mozilla when testing my sites.
And this is exactly why you shouldn't use table layout.
It don't work on small viewport sizes. Neither does it work in big sizes.
The difference with CSS layout is that it works smaller window than table
layout, and bigger window that table layout. Of course it can't work on
extra small window either. But no webpage using table layout is usable in
less than 200px. If it is, there is no need to use tables for layout as
there is only one column. Having scrolbar don't usually help, as it is
pretty often that one needs to scroll it 9 times to read 5 lines of text.
I use many webpages in smaller than 200px window (the other side of the
screen, beside that 550px). To get table layouted stuff to fit it it need
to use Opera's small screen rendering mode, but that is not optimal. I
usually get better results using some extensive user stylesheet.
Unfortunately making such stylesheet for tablelayouted stuff is pretty
hard, as I need to get rid of the tables first, and try to get content in
sencible order.
Brian
>
> There is a fact that some people may not like to see revealed.
When I read a statement like that, I feel the need to get my bogosity
meter out (again).
> From the time that Dave Raggett proposed tables in "HTML+" in
> November 1993, tables have been intended to display cells in a
> horizontal + vertical grid.
> (Which is one of the reasons why their tags and attributes have
> terms like "row" and "col" - that isn't an accident!)
That is one twisted interpretation. The tag names are indeed useful
evidence. We have <table>, <tr> for table row, <col> for column, and
several other elements. But let's not forget the only table markup
element that can contain e.g. text, images, paragraphs, lists, etc.:
<td>, which stands for table data. That's *table data*. Say it once
with me. "Table data." Not <layout>. Not <left> or <right>. Table
data. I can't imagine how you can interpret the name of the element to
justify anything other than, well, table data.
A table used for layout does not put table data in <td> elements. It
uses <td> elements to enclose random bits of the document solely for
the layout effect it will have.
Whatever other baseless arguments you want to make in defense of
html markup misuse, this one about the names of table markup
elements is quite bogus indeed.
> How do we resolve this disagreement?
When you reach your senses? When you stop stubbornly insisting that
misusing html markup is a good idea?
I'm not holding my breath.
Barry Pearson
> On Fri, Jan 16, Barry Pearson inscribed on the eternal scroll:
>
>> There is a fact that some people may not like to see revealed.
>
> It holds no fears for me...
Good.
>> From the time that Dave Raggett proposed tables in "HTML+" in
>> November 1993, tables have been intended to display cells in a
>> horizontal + vertical grid.
>
> Not quite. Tables have been intended to markup a logical
> relationship; when the presentation situation is appropriate, it's
> intended that the relationship would be depicted as a 2-dimensional
> grid, but that's not a mandatory requirement of the logical markup.
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. His proposal says nothing
whatsoever about logical relationships. I can't find any early discussion of
tables that does. 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. It is explicit - not ambiguous. It is
systematically and relentlessly about displaying the material.
If you know of material that defined an early intention to use tables to
specify logical relationships, separate from the visual representation,
*please* point them out to me! I have spent lots of time trying to find it,
and haven't found it yet. (I keep wondering whether people are trying to
re-write history).
>> See:
>> "A brief history of tables"
>> http://www.barry.pearson.name/articles/layout_tables/history.htm
>
> If I'm going to say anything at all about this, then I'm going to have
> to be candid.
Good.
> In this respect I think I can claim the following -
>
> 1. I do know a little bit about the topics on which I choose to
> comment, and I do have quite strong personal opinions about them,
>
> 2. Ihappen to be the principal author of several peer-reviewed FAQs in
> which I deliberately throttled-back on my personal opinions and
> managed, as it seems, to express an answer in terms that gained
> widespread acceptance in the communities to which the various FAQs
> were addressed.
Been there, done that, got the T shirt. Maintaining FAQs can indeed be tricky!
(I received a death threat once).
> On that basis, I think I can comment from both sides: the
> strongly-held personal opinion, and the opinion-neutral presentation
> of the facts.
>
> And on that basis, my evaluation of your writings on this topic would
> have to be this, I'm afraid: you formed a strong personal opinion of
> what the answer had to be, and then you selected your evidence in
> order to support it.
Don't be afraid. Just show the evidence, and there is nothing to be afraid of.
Remember that *you* were the one who identified to me Dave Raggett's HTML+
draft that I quoted above.
http://groups.google.com/groups?selm=Pine.LNX.4.53.0401081950240.7880%40ppepc56.ph.gla.ac.uk
I can only use the sources I can find and be told about. You told me about
that one. Shouldn't I have used it? (Should I have acknowledged you? Sorry I
didn't).
I am trying to make this page (below) a high-quality source of information
about how tables, and especially layout-tables, developed on the web. I
wouldn't waste my time if I knew of an equivalent source, but I haven't been
able to find one. I have had to put this together from lots of different
sources, not all consistent with one-another.
http://www.barry.pearson.name/articles/layout_tables/history.htm
If there are errors, please (you and anyone else) tell me, with evidence. I'll
correct them.
If there are other sources I should use, please tell me about them. I'll use
them and link to them.
If it is the interpretation and opinion where you differ, then obviously that
is expected. But tell me of the differing interpretation and opinion based on
known facts, and I'll link to them. If there are a number of these, I'll
create a new page specifically for the purpose.
>> Every single proposal and standard and Recommendation from that time
>> onwards has continued this theme, as far as I know. Tables are
>> designed to layout complex things in a grid-formation.
>
> They're designed to express a relationship which, in appropriate
> circumstances, it's appropriate to present in a two-dimensional grid
> relationship.
And to lay it out in a grid. The layout comes across from Raggett's
description. The relationship bit doesn't. And indeed, for simple tables, the
same is true of subsequent Recommendations. The fuller table models talk about
how to represent the logical relationships. The simpler ones don't. And layout
tables use the simpler model.
My degree is in mathematical physics. I understand about logical relationships
in many dimensions. Which means that I can spot specifications that simply
don't talk about them! Raggett's doesn't. What early material does?
>> It isn't an accident
>
> 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.
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. It handled simple
layout tables well.
I have tried Opera 7.2 in "small screen mode" on many web sites, to see how
table layout maps onto 240px screens. And if they linearise well (see above),
it works well. Astonishingly well! ("New windows" fail, though).
> If, in fact, there _is_ no such relationship, other than the
> designer's visual intentions, then the tabular markup becomes not just
> useless, but actively counter-productive.
No - it does precisely what the author and the user want. It presents an
attractive page with key components just where the author intended them to be,
and the user wanted/needed them to be. I suggest you read:
Criteria for optimal web design (designing for usability), By Michael Bernard
http://psychology.wichita.edu/optimalweb/print.htm
Any scheme that doesn't enable an author to position material reliably
according to such research, and that doesn't deliver it reliably to users who
use default settings, is failing to communicate properly. It is *objectively*
bad.
>> - they were always intended to work like that! The proposals were,
>> and the browsers were. That is the defined nature of the web.
>
> I'm going to have to disagree. Keep in mind that there are two kinds
> of W3C specification, and they're hard to keep apart, "thanks" to the
> fact that the W3C is not an independent standards-making body but an
> industry consortium funded by its members. Sometimes their
> specifications merely document what their members' software is
> currently doing, and sometimes they sketch out more abstruse ideas
> about the fundamental basis of what's going on. Compare, if you will,
> HTML/3.2(spit), a fairly disgusting codification of what the
> then-big-two were up to at the time, with CSS1, a somewhat idealised
> specification that those big-two never did quite get around to
> implementing.
Raggett's table proposals were published in November 1993. They were based on
a WWW workshop in July 1993 and subsequent discussions on www-talk. I can't
find material about the workshop, and the www-talk archive has a "hole" in it
at that date. Can you or anyone help?
Was Raggett being pressured by the suppliers? (This was before W3C, of
course). It was more than a year before Mosaic provided tables even in an
Alpha version, and NN and IE were months after. I suspect that Raggett was
leading the browser suppliers, and certainly not trying to "document what
their members' software is currently doing".
> Now look at what happened since. Do I need to spell it out? OK,
> probably spelling it out would be pointless anyway: those who
> understand it already, don't need to hear it from me, and those who
> still think it's pseudo-HTML DTP, wouldn't listen to me anyway, so I
> might as well save my breath/keyboard.
I covered the topic of saying such as "the web is not DTP" in my article:
"Sayings":
http://www.barry.pearson.name/articles/layout_tables/sayings.htm
Steve Pugh
>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.
From the very first line of the section on tables <url:
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.html>
"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.
> His proposal says nothing whatsoever about logical relationships.
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 <st...@pugh.net> <http://steve.pugh.net/>
Neal
> It says nothing about "not" using tables for layout purposes?
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
> It says nothing about "not" using tables for layout purposes?
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
> "Barry Pearson" <ne...@childsupportanalysis.co.uk> wrote:
>
>>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.
>
> From the very first line of the section on tables <url:
> http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.html>
>
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
> I suggest you re-read Dave Raggett's proposal.
OK, we're discussing
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.html
> His proposal says nothing whatsoever about logical relationships.
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".
> I can't find any early discussion of tables that does.
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.
> 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.
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.
> > They're designed to express a relationship which, in appropriate
> > circumstances, it's appropriate to present in a two-dimensional grid
> > relationship.
>
> And to lay it out in a grid.
Of course - when that presentation is an appropriate one.
> The layout comes across from Raggett's description.
In the part where he's discussing rendering algorithms, indeed.
> The relationship bit doesn't.
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.
> >> It isn't an accident
> >
> > 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.
>
> 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.
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
Barry Pearson
> On Sat, 17 Jan 2004, Barry Pearson wrote:
>
>> I suggest you re-read Dave Raggett's proposal.
>
> OK, we're discussing
> http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.html
> 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.
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]
> 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.
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]
>> 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.
>
> 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.
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:
"OPENframework systems architecture"
(Check in the books for a name you recognise).
> 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.
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.
Alan J. Flavell
> Alan J. Flavell wrote:
> > 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.
[..]
> 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'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).
> 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'd rate Lie and Bos as the overall winners by now, but it was a long
and unnecessary slog IMNSHO.
> It is like getting to the moon - a massive blast-off, lots of
> course corrections, and tons of luck. And abandon regrets!
OK. But don't do that by trying to rewrite history.
> - What were the original intentions?
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 "application 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(deceased).
> They are interesting from a historical perspective.
No regrets - right?
> They are irrelevant for how we should behave today. We can't afford
> to re-fight lost battles.
We can't afford not to learn from them. We already lost a couple of
years, at least.
Barry Pearson
> On Mon, 19 Jan 2004, Barry Pearson wrote:
>>
> 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).
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 "architecture 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).
>> 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'd rate Lie and Bos as the overall winners by now, but it was a long
> and unnecessary slog IMNSHO.
>
>> It is like getting to the moon - a massive blast-off, lots of
>> course corrections, and tons of luck. And abandon regrets!
>
> OK. But don't do that by trying to rewrite history.
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.
>> - What were the original intentions?
>
> 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.)
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]
>> They are irrelevant for how we should behave today. We can't afford
>> to re-fight lost battles.
>
> We can't afford not to learn from them. We already lost a couple of
> years, at least.
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.
Reinier Post
>The reason not to use tables for markup is that it ruins the table as a
>meaningful markup.
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
>
> 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
> All this is *presentation* information, and none of it can be
> conveyed in HTML
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.
> HTML simply isn't a good representation language
Not sure what you mean by "representation language." HTML is a
semantic language, not a dtp application.
> for relational tables.
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)
http://www.tsmchughs.com/
Barry Pearson
> Neal wrote:
>
>>The reason not to use tables for markup is that it ruins the table as
>>a meaningful markup.
>
> 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.
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"
http://www.barry.pearson.name/articles/layout_tables/history.htm
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).
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.
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.