printing "sidenotes" in IE6/7

[Ben C]

Scripsit dorayme: [...]

When
one finds it convenient to use a table, it is not too hard to
find arguments. I thought yours not too bad. I still think mine
was good.

I think yours is much worse. There is no correspondence between the
navigation "column" and the content "column". The navigation column could be
described as one by N matrix, but it would be rather illogical to consider
the content as another "column", except purely for layout.

My table, on the other hand, exhibits genuine tabular relationships: the
text and the notes run in parallel. Each note relates to piece particular
text (in a cell). What could be _more_ tabular (assuming you haven't got the
odd idea that only numbers can be tabulated)?

For me the essence of a table is that it represents some function of two
inputs. So, for example, if I have "foods" in the rows, and "vitamins"
in the columns, I can lookup how much vitamin A in a carrot, or C in an
apple by reading the values of the function from the table.

Annotating text with notes doesn't really have this characteristic,
although you could probably stretch the idea.

But, to answer your question, the table of vitamins and foods is
something that is more tabular.

 

[Jukka K. Korpela]

Scripsit JWS:

I found out what was the matter now: as selector I had used the
"its child" property:

div > p {margin: 0;}

but it seems that IE does not understand "its child".

IE 6 does not recognize the selector div > p, so it ignores the entire rule.
IE 7 recognizes it, though only in "Standards Mode".

So wherever possible I now avoid "its child";

That's a good practical principle at present.

Yes.. it also seems IE does not understand the p+p ("two
consecutive paragraphs") selector, which handles the "first
paragraph" problem automatically.

Similarly, p+p is supported in IE 7 in Standards Mode, not otherwise in IE.

I do not have an ideological position in this, but.. tables are so
"square". If a sidenote is taller than its accompanying paragraph,
display of the next paragraph is pushed down until the sidenote
finishes. This is not so nice; sidenotes waste space (or paper)
anyway, and such wastage should not be made worse if it can be
avoided.

That's a problem with tables, and an asset. But you could organize the table
so that one cell in the left column contains _one or more_ paragraphs,
including all paragraphs before the next paragraph to which a note is
attached. This would imply that a gap is created in the left column only if
you have some relatively short text with a long sidenote and then
(immediately or after short texts) some other text that has a sidenote. In
such a case a gap is more or less necessary anyone.

This would been slightly illogical markup, since you would have

<tr><td>text</td> <td>note</td> </tr>

so that "text" contains first the paragraph that the note relates to, then
perhaps one or more other paragraphs. In an attempt to please the purists
(including my puristic self), we might write as follows:

<tr><td>text 1</td> <td rowspan="2">note</td> </tr>
<tr><td>text 2</td> </tr>

but I don't think it would really be an improvement in logical structure.

 

[JWS]

That's a problem with tables, and an asset. But you could
organize the table so that one cell in the left column contains
_one or more_ paragraphs, including all paragraphs before the
next paragraph to which a note is attached.

Well.. all things considered.. I've come to a conclusion.

The content of my page is Linux-oriented; only about 14 % of
the visitors use IE. I'll redesign it to make it IE-compatible
wherever I can (like avoiding ">" and "+" in selectors, by
creating some extra classes).

But changing from css layout to table layout, just to enable
printing in IE, is too much (i.e. too much work now, and too much
work in the future while maintaining the page). I'll just use a
"conditional comment" (if that's what it's called) to make
everything "ragged right" for IE users, with @media print. That
will produce acceptable (although IMHO not optimal) printing
behaviour for these users.

Thanks all, and especially Yucca, for the stimulating discussion.

Jan

 

[dorayme]

Scripsit dorayme:


Sounds like a hopeless case.


A page is a page. Either your page contains tabular data, or it doesn't.


I think yours is much worse. There is no correspondence between the
navigation "column" and the content "column". The navigation column could be
described as one by N matrix, but it would be rather illogical to consider
the content as another "column", except purely for layout.

I imagine almost everyone thinks my defence of a left col as
navigation and a right col as content as tabular is bad and
hopeless! I think it is still a thing of truth and beauty and
general unimportance. So much so, that I will repeat it here and
make it clearer for anyone interested.

First, let me say I do not use tables for such on any new
projects - and that I think it generally a bad idea. But it is
not quite as bad as some people think and certainly not for the
reason of the mantra that tables on a per page basis should show
a clear tabular relationship across the table row by row etc as
in classic paradigms.

Your statement "A page is a page. Either your page contains
tabular data, or it doesn't." is a statement about what you see
as crucially relevant. My view is that there is a deeper table
that will simply not be seen if you stick so solidly to the earth
this way. Dr Johnson once kicked a stone and said "I refute it
thus!" when challenging Bishop Berkeley about the nature of the
material world. It is generally considered a poor argument in
spite of the good doctor likely being more right than the good
bishop.

The argument is quite simple but it requires one to see that the
real and far more important table in a site that has 2 cols, left
nav and right content is a three dimensional one and is as big in
one dimension as the site itself. Once you see it this way,
suddenly there is grip for hanging a tabular relationship.

In the left col: about Deborah, about Fred, about George with
"about Deborah" highlighted in some way to indicate current. In
the right col, spiel about Deborah. Now, if you merely look at
the Deborah page, you will say that the "about Fred" link has no
tabular relationship to the actual right content. Indeed, you
would be right. But in the table I am thinking of, this link has
a direct tabular relationship to the right content on the "about
Fred" page. All the pages are part of the 3-D table.

I know some people will say it is ridiculous to redefine the
common meaning of table in this way, that it is a trick. But in
truth, when authors use a table for this particular layout
purpose, I say it is more in accordance with what they are
actually doing, it is a better description, a truer account of
their general reasonableness.

All this is not to be confused with some sort of licence to use
tables as layout generally. In so many convoluted table designs,
no such defence as above is available and I have no reason to
concoct one.

 

[Jukka K. Korpela]

Scripsit Ben C:

For me the essence of a table is that it represents some function of
two inputs.

Markup is about relationships, not functions and input. A table is a data
structure, not a function. A table is logically a list of lists with the
same number of items and with some meaningful relationship across the inner
lists so that the n'th items in inner lists have some connection with each
other. For example, a simple table of results in a game, with names and
points scored by each player, is a two-item list where the n'th item of the
first list and the n'th item in the second list are connected so that the
former contains the name of a player and the latter the result of that
player. This is a logical (or abstract) structure and need not have any
visual manifestation; the table might be internal to a data base so that you
can only ask for a result by the player name and get a single result.

Similarly, a structure consisting of a list of paragraphs and a list of
annotations to them is a table purely logically. Admittedly, none of the
cells in it is a simple name-like thing, as the player names, by which you
could make queries. But this depends on the nature of the content.

So, for example, if I have "foods" in the rows, and
"vitamins" in the columns, I can lookup how much vitamin A in a
carrot, or C in an apple by reading the values of the function from
the table.

(Off-topic: Carrots don't contain vitamin A; they contain provitamins from
which vitamin A may be produced by humans and other eaters.)

Besides, you could use lookup on the other columns as well, e.g. to find out
which food contains most vitamin C, or more than 50 mg / 100 g of it, or
something like that. You could do this with a program if you open the HTML
table in MS Excel for example. Some day some browser vendor might even get
the wild idea of letting users manipulate tables in a spreadsheet manner.

Annotating text with notes doesn't really have this characteristic,
although you could probably stretch the idea.

There is no need to _stretch_. Lookup issues are not essential in tablehood,
and they depend on the nature of the content, among other things. For prose
content, you would just need different lookup methods, such as looking for
paragraphs (or notes) containing some specific words or patterns.

But, to answer your question, the table of vitamins and foods is
something that is more tabular.

It's a more typical table, but not more of a table.

 

[Ben C]

Scripsit Ben C:


Markup is about relationships, not functions and input.

Functions and input _are_ relationships.

A table is a data structure, not a function.

I see no distinction at this level of abstraction (c.f. why many
programming languages use parentheses or brackets both for array
indexing and function calls).

A table is logically a list of lists with the same number of items and
with some meaningful relationship across the inner lists so that the
n'th items in inner lists have some connection with each other. For
example, a simple table of results in a game, with names and points
scored by each player, is a two-item list where the n'th item of the
first list and the n'th item in the second list are connected so that
the former contains the name of a player and the latter the result of
that player.

This is a logical (or abstract) structure and need not have any
visual manifestation

Certainly. Not to be confused with "table" in "display: table" which is
of course a completely different use of the word from "table" in
<table>.

 

[dorayme]

A table is logically a list of lists

A table certainly contains lists. It may even contain a list of
lists. But, I am having trouble believing it is (logically) a
list of lists. I am not sure. But I cannot rule it out as there
may be a way of so arguing your statement.

A list of lists in the sense in which we have become familiar on
this newsgroup would perhaps be a nested list. A nested list
further details or shows associations of particular list items in
the nest.

In a simple table, I can almost persuade myself:

Deborah 28
Fred 39
Alice 84

looks logically to display the same content and relationships as

Deborah
28
Fred
39
Alice
84

But you only have to add another column in addition to age, say,
place of birth, to experience difficulties in this.

So, I would say that a table is something basic in the scheme of
things or at least it is not easily reduced in thought to the
notion of lists (though you are quite right to think they are an
essential part of the idea). A table, like no other thing,
displays relationships. It can have or have implied, captions and
headings and these play a crucial role.

But, as I say, it is possible someone might argue your statement
in a persuasive way that at the moment eludes me.

 

[dorayme]

I know some people will say it is ridiculous to redefine the
common meaning of table in this way, that it is a trick. But in
truth, when authors use a table for this particular layout
purpose, I say it is more in accordance with what they are
actually doing, it is a better description, a truer account of
their general reasonableness.

dorayme, when you talk like this, you make people like Pugh think
you are on drugs, people like Bergamot get infuriated and Korpela
will simply see it as babble. Be a good girl or boy or creature
or whatever you are and try not to frighten the horses so much.
Remember, you are on a public forum.

 

[dorayme]

dorayme, when you talk like this, you make people like Pugh think
you are on drugs, people like Bergamot get infuriated and Korpela
will simply see it as babble. Be a good girl or boy or creature
or whatever you are and try not to frighten the horses so much.
Remember, you are on a public forum.

Yes ok, I know what you mean. It is just that I think it is never
made very clear that there is a difference in kind and not merely
in degree between at least two types of uses for html tables for
non-paradigmatic tabular purposes.

In the one case, it is merely a device to arrange bits of the
page how the author wants, often for aesthetic or other
convenient purposes that do not include tabular motives. There
are especially good reasons for avoiding this.

But in the other case, there are tabular motives. The idea of the
3-D table was merely a device to bring this out. Another way of
putting it is that all the links in a navigational left column
can have a tabular relationship to items in a right col, but the
location of the right col is not on the same page but on another
page. This makes it a very different creature to the "purely for
display" table, it is much closer to the very idea of tabular
cross col mechanism that is at the heart of tables.

It is not a black and white thing. There are degrees and there
are complexities. Purists, like ideologues everywhere, are prone
to condemning with a very broad brush.

And if the sleepy heads on the north of this planets will not
come out to play with me, well, damn hell, I cannot expect anyone
in the southern hemi, meaning basically Africa, South America and
Australia to do so for the simple reason that on a Sat avo, they
are all at the footy or cricket. But you, dorayme, are always
prepared to talk to me.

 

[Ben C]

Yes ok, I know what you mean. It is just that I think it is never
made very clear that there is a difference in kind and not merely
in degree between at least two types of uses for html tables for
non-paradigmatic tabular purposes.

In the one case, it is merely a device to arrange bits of the
page how the author wants, often for aesthetic or other
convenient purposes that do not include tabular motives. There
are especially good reasons for avoiding this.

But in the other case, there are tabular motives. The idea of the
3-D table was merely a device to bring this out. Another way of
putting it is that all the links in a navigational left column
can have a tabular relationship to items in a right col, but the
location of the right col is not on the same page but on another
page. This makes it a very different creature to the "purely for
display" table, it is much closer to the very idea of tabular
cross col mechanism that is at the heart of tables.

It is not a black and white thing. There are degrees and there
are complexities. Purists, like ideologues everywhere, are prone
to condemning with a very broad brush.

The truth is a table (as opposed to a <table>) is _really_ a rectangular
grid. It can be used to represent various kinds of relationships, and so
those are what we're clutching at in our quest for the abstract table.

So long as the relationships aren't purely layout ("A should appear
to the right of B", etc.) anything goes really.

 

[dorayme]

The truth is a table (as opposed to a <table>) is _really_ a rectangular
grid. It can be used to represent various kinds of relationships, and so
those are what we're clutching at in our quest for the abstract table.

So long as the relationships aren't purely layout ("A should appear
to the right of B", etc.) anything goes really.

Yes, an html table is a special thing, distinct from the
varieties of tables in the print medium. Btw, Periodic tables of
physical elements are rarely actually rectangular! They meander a
bit and need a certain understanding on the part of the viewer to
read it right - often helped by colour coding.

One of the objections to the use of tables for layout is that
they are hard to maintain, another is that they do not have a
clear semantics when so used. I have heard it also said that it
is not as friendly on accessibility grounds. You must know by now
(without necessarily agreeing of course) that I regard a two col
table with nav in one col and content in the other (or something
similar) as a rather special case, having rights that mere run of
the mill table layout messes can never claim.

It is endlessly fascinating to me how hard some people go to
avoid such and go to endless trouble for it. I have been tending
not to use tables for this (tho I have not got around to changing
one site I have in this respect) because I rather like the idea
of "columns" not being so regular and "finishing together" in
website construction. I like what you can do with floats and
things. But I don't get the feeling some people enjoy it at all,
they seem, in their avoidence, like they are taking castor oil
for their own good! <g>

 

[Jukka K. Korpela]

Scripsit dorayme:

A table certainly contains lists. It may even contain a list of
lists. But, I am having trouble believing it is (logically) a
list of lists.

Note that my text continues, after the piece quoted above: "with the
same number of items and with some meaningful relationship across the inner
lists so that the n'th items in inner lists have some connection with each
other".

Thus, a table is _more_ than a list of lists, as explained above. We could
also describe this by saying that a table is a list of lists _in two ways_:
a list of rows, which are lists, and a list of columns, which are lists. But
there's still more: the relationship I mentioned above.

A list of lists in the sense in which we have become familiar on
this newsgroup would perhaps be a nested list.

If "nested list" means more than a list of lists, then it means a particular
_rendering_ of such a construct. Apparently, for a table, which is _more_
than a list of lists, namely with relationships across the lists, such
rendering is usually not optimal.

 

[dorayme]

Scripsit dorayme:


Note that my text continues, after the piece quoted above: "with the
same number of items and with some meaningful relationship across the inner
lists so that the n'th items in inner lists have some connection with each
other".

Thus, a table is _more_ than a list of lists, as explained above. We could
also describe this by saying that a table is a list of lists _in two ways_:
a list of rows, which are lists, and a list of columns, which are lists. But
there's still more: the relationship I mentioned above.

In my post to which you reply, I had hoped to make clear that I
thought that a table, in a logical sense, contains lists. And
that there are relationships between the list items. And that a
table is special in that it does exhibit these relationships. So
far all is agreed. I just think it is a little confusing to
describe the table as being, logically, a list of lists as if
somehow it is a list, the list items being lists. Perhaps it is a
simple terminological query.

If "nested list" means more than a list of lists, then it means a particular
_rendering_ of such a construct. Apparently, for a table, which is _more_
than a list of lists, namely with relationships across the lists, such
rendering is usually not optimal.

Perhaps this is what I was worried about and more, I was thinking
that it would be perhaps impossible, not just impractical, to
represent a table as a complex list. But it is a difficult matter
to think through. Certainly little practical hangs on it.