Non-list items in lists

D.M. Procida kirjoitti:

Links to an index no more items of table data than they are list items -
they are navigation furniture.

I agree that in your case this would be true.

Have you considered using only one "Back to list index" link instead of
many? Say including it in the bottom of the page, but positioning it via
CSS fixed to the viewport?

This would have the benefit of not:

1) distracting from the actual content
2) staying on the way when tabbing through links
3) disturbing the use of speech-based user agents
4) polluting the document with repeated links
5) messing with them semantics

And, of course, you'd want to hide it from printed media

Simplified example:

<div style="position:fixed;right:1em;bottom:1em">
<a href="#index">To list index.</a></div>

--
Best wishes,
Osmo

On Mon, 12 Oct 2009 19:42:49 +0100,
real-not-anti-spam-address (AT) apple-juice (DOT) co.uk (D.M. Procida) wrote:

I'd be looking at putting the data in a database and delivering it to
the user as they require, sorted by some query.

It is being pulled from a database, sorted by kind, then by date (and
grouped by year).

Another view offers "Selected key publications" - the academic's chosen
top eight items.

Later we can get as clever as we like with this information, but while
other views of the same data may turn out to be useful for numerous
other particlar purposes, the long complete list is still required, and
for the time being, will be the definitive view.

The complete list is one thing and a selected view (generated by a
query linked from the index) is another. There is no point in
indexing the long list since it exists, as you say, to be the
definitive list.
--
Geoff Berrow (Put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs www.ckdog.co.uk/rfdmaker

In article
<1j7kkhw.1905h0g1crvyumN%real-not-anti-spam-address (AT) apple-juice (DOT) co.uk>,
real-not-anti-spam-address (AT) apple-juice (DOT) co.uk (D.M. Procida) wrote:

dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In the suggestion for it being a list item, the argument is quite clear:
it is *not* part of the list (going by your own sketch of the data
(people in years)), it is not part of the type of things the list items
are. But you cannot make this judgement in relation to a table a priori
without knowing what the nature of the table is. You are simply jumping
to conclusions on this...

....
a table with a column dedicated to repeated links to the same anchor is
not using that column for tabular data, or table-related data.

It's just using the column as a handy layout scheme for that orphaned
navigation furniture that hasn't anywhere to go in the logical scheme.

Repetition in one cell is not the only way to convey information that
relates to items in other cells, that is what span is for.

1990 Smith
1990 Brown
1990 Fish
....

1990 could *span* the row-names. The table headings, explicit or
understood are the big clue: <th>Year</th><th>name</th>. You can
vertical align the dates to middle or even have an imaginative
background image in addition, repeated-y as reminder.

Following the same plan, another column could be the link to the index.
A search the list link is logically an item that relates to the list in
one of the columns. You might even organise different search links to
different parts of the list (there may be hundreds or more of names in
some years?). It is a column unrelated only if you have an over-brittle
view of what HTML tables are.

It's just using the column as a handy layout scheme for that orphaned
navigation furniture that hasn't anywhere to go in the logical scheme.

That is not a true description. If you wanted to give more information
about a group of names, you might do this in another column. You would
not complain that it was "just using a column for layout". The situation
is not logically different if you want to inform your audience that all
these names can be searched from some index and it becomes especially
pertinent if you fashion the index to relate to particular years and
names in some order within those years.

I have heard people trying hard to explain the model of HTML tables for
tabular data for quite some time now and I have yet to see one set of
criteria that covers all the logically legitimate HTML tables that can
exist. We all know clearly bad cases of what using tables for *mere*
layout is. This is far from that.

Truth is, everything depends on exactly what you are doing, the numbers
of names matter! If you really have a big lot and the dates are
important groupings, then perhaps you might *fix* the index so it stays
in sight for visual browsers. You can use margins to create a page
column and have the list in it or the lists or the table with dates.
And, if you feel uncomfortable about a third column in a table for links
to index, use absolute positioning to have the actual search facility
(or index) present at all times.

You can incorporate the index into the table itself. Headings can be
used to function as user tools. There are many ways to skin this cat and
it depends on *quite* what the material is. Not that you are asking, but
if the material is what I think it is, I would likely do it this way:

A search box and a horiz list like

1990|1991|... (which are links to parts of a table or list).

Underneath is the table (or vertical lists and sublists) with IDd parts
to be targets for the index above. I would likely not have a huge table
all on one page but something more human scale (just the 1990s) and the
user goes to other pages to see other parts of the data. Human users are
likely to come interested in only some bits, not all the details. The
index is a strip at the top. It is a constant navigation on each page.
Use an include. Use CSS to highlight the present 1994 or 1994-1997
depending on how you fashion your index and table.

--
dorayme

dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

It's just using the column as a handy layout scheme for that orphaned
navigation furniture that hasn't anywhere to go in the logical scheme.


That is not a true description. If you wanted to give more information
about a group of names, you might do this in another column.

Except I don't "want to give more information about a group of names". I
was looking for a place in which to place some list navigation
furniture, a link to an index for the list.

This is not information about the items in the list. The list will lose
no imformation if those links are omitted. The idea was simply to
provide a little bit of user-interface to make navigating the page
easier.

Daniele

In article
<1j7mdhn.qf57go1sk7diqN%real-not-anti-spam-address (AT) apple-juice (DOT) co.uk>,
real-not-anti-spam-address (AT) apple-juice (DOT) co.uk (D.M. Procida) wrote:

dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

It's just using the column as a handy layout scheme for that orphaned
navigation furniture that hasn't anywhere to go in the logical scheme.


That is not a true description. If you wanted to give more information
about a group of names, you might do this in another column.


Except I don't "want to give more information about a group of names".

You want to give information to the user about how to search this group
of names and, so far, I have seen no argument that says a table should
not carry some or all of these facilities that are essentially *about*
communicating information concerning this data to a user. Tables already
carry information on how to read its parts (that is what headers are
for, that is what some styling is best for too).

The table I am envisioning is a mensch of a thing, not some pansy toy
that conforms to some brittle Walt Disney idea of what an HTML table
should be.

Anyway, I can see you will not be convinced. I know when I am beaten!

--
dorayme