Imagine a long nested list of items, or a long definition list, prefaced
with an index to that list.

To make it easier to use, you might want to put a link to "List index"
at various points in the list, perhaps at each major group in the list:
        
        List of members by birth date

        1990    Back to list index
                *       Joe Bob
                *       Bobo
                *       Dede Wilkes
        1991    Back to list index
                ...
        1992    Back to list index
                ...

Where to put this link? It's not itself a list item, and it's certainly
not part of a definition term, but there doesn't seem to be anywhere
else suitable.

If these links go into list items, then anything parsing the list will
find items called things like "1990 (Back to list index)".

Daniele

On 12 Oct, 09:31, real-not-anti-spam-addr...@apple-juice.co.uk (D.M.
Procida) wrote:
> Imagine a long nested list of items, or a long definition list, prefaced
> with an index to that list.
>
> To make it easier to use, you might want to put a link to "List index"
> at various points in the list, perhaps at each major group in the list:

> Where to put this link?

Simple: Inside <li class="foo" >, because that's all you have to work
with as a permissible element at that location. The alternative is to
split the list container <ul> into multiples, which isn't great.

Yes, you now have two classes of <li> element within the same list.
Get over it and deal with it, because it's HTML and that's just all
you've got to work with.

There's also the question of whether to mark the content of the <li>
up as either minimal markup to support formatting

<li class="list-index-item" ><span class="foo-1" >1990</span>    <span
class="foo-2" >Back to list index</span></li>

or else to use something more structure-based (this is just a starter
for this simple example)
<li class="list-index-item" ><h3>1990</h3>    <div>Back to list index</
div></li>

Remember that the content model inside <li> is %flow;, so you can go
wild in there. Although there's a general reluctance to put anything
more than a bare string inside <li>, this is a false constraint and
there's no reason to limit yourself.


BTW - Are you involved with the forthcoming Dorkbot @ Chapter?

Andy Dingley  wrote:

> > Imagine a long nested list of items, or a long definition list, prefaced
> > with an index to that list.
> >
> > To make it easier to use, you might want to put a link to "List index"
> > at various points in the list, perhaps at each major group in the list:
> 
> > Where to put this link?
> 
> Simple: Inside <li class="foo" >, because that's all you have to work
> with as a permissible element at that location. 
>
> Yes, you now have two classes of <li> element within the same list.
> Get over it and deal with it, because it's HTML and that's just all
> you've got to work with.

Indeed. I find myself increasingly frustrated by the number of things I
need to get over and deal with because of limitations within HTML.

> Remember that the content model inside <li> is %flow;, so you can go
> wild in there. Although there's a general reluctance to put anything
> more than a bare string inside <li>, this is a false constraint and
> there's no reason to limit yourself.

Yes - though that wouldn't work if you were dealing with a <dt>, if
that's the place where it would be sensible to display your non-list
item. 

> BTW - Are you involved with the forthcoming Dorkbot @ Chapter?

Do you mean <http://www.chapter.org/17160.html>? Thanks, I wasn't even
aware of it until just now - I shall definitely pay a visit.

Daniele

In article 
,
 Andy Dingley  wrote:

> On 12 Oct, 09:31, real-not-anti-spam-addr...@apple-juice.co.uk (D.M.
> Procida) wrote:
> > Imagine a long nested list of items, or a long definition list, prefaced
> > with an index to that list.
> >
> > To make it easier to use, you might want to put a link to "List index"
> > at various points in the list, perhaps at each major group in the list:
> 
> > Where to put this link?
> 
> Simple: Inside <li class="foo" >, because that's all you have to work
> with as a permissible element at that location. The alternative is to
> split the list container <ul> into multiples, which isn't great.

Simple alright! Trouble is it is desperate, unsemantic and unnecessarily 
defeatist.  

OP wants to make a list. He wants it to be a nice usable list. He wants 
users to be able to understand and negotiate it. It does not matter if 
he or a thousand others are fixated on all this being possible within in 
a list. It cannot be done with *just* a list (no matter with classes) 
and it is the wrong tool for the job. 

An HTML table of data is a way to organise lists, links to indexes are 
quite the sort of data that might appropriately go into a column and 
relate to groups of rows.

-- 
dorayme

On 12 Oct, 10:58, real-not-anti-spam-addr...@apple-juice.co.uk (D.M.
Procida) wrote:

> Indeed. I find myself increasingly frustrated by the number of things I
> need to get over and deal with because of limitations within HTML.

HTML does "text content for web pages". It doesn't do structured
documents. If you must have those, there's DocBook or DITA. If you're
stuck in a HTML world like the web, then that's the situation and we
have to deal with it.

Progress beyond this would seem to depend on XML (as XML),
namespacing, and toasting marshmallows over the heat of a roaring
Arjun  8-)

D.M. Procida wrote:

> Imagine a long nested list of items, or a long definition list,
> prefaced with an index to that list.

I imagine that a long list, especially one that needs an index, is split 
across several web pages. The problem vanishes in a puff of logic.

Okay, you might still wish to have, as one version of some material, a long 
list on one page e.g. because it's something that someone might want to 
print or save locally in a comfortable way. Fine. So make it one list and 
don't try to make it any more usable, as the usable way (for most purposes) 
is to divide it into several pages.

> To make it easier to use, you might want to put a link to "List index"
> at various points in the list,

It doesn't make it any more easier, just as "Back to top" links are worse to 
useless, as explained at
http://www.cs.tut.fi/~jkorpela/www/totop.html

> Where to put this link? It's not itself a list item, and it's
> certainly not part of a definition term, but there doesn't seem to be
> anywhere else suitable.

That's logical, since it's not a logical, structural part of the list but an 
attempt to create possibilities for actions - to do very primitive 
resemblance of programming.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

Jukka K. Korpela  wrote:

> I imagine that a long list, especially one that needs an index, is split
> across several web pages. The problem vanishes in a puff of logic.
> 
> Okay, you might still wish to have, as one version of some material, a long
> list on one page e.g. because it's something that someone might want to
> print or save locally in a comfortable way. Fine. So make it one list and
> don't try to make it any more usable, as the usable way (for most purposes)
> is to divide it into several pages.

It's a long list of academic publications (in the humanities, you get to
have a paper to your name if you sat in your freezing garret writing it.
In medicine, you get tou have your name on it if the work was done in
your lab, by your students, by your researchers, by your colleague who
owed you a favour, by your best friend, by the guy down the hall whom
you spotted coming out of a restaurant with a woman who wasn't his wife,
and possibly, if you managed to slip into the research office and scrawl
your name on the folder).

Anyway, it's a long list, and for various reasons, not one I think would
usefully be split up.

> > To make it easier to use, you might want to put a link to "List index"
> > at various points in the list,
> 
> It doesn't make it any more easier, just as "Back to top" links are worse to
> useless, as explained at
> http://www.cs.tut.fi/~jkorpela/www/totop.html

I think some of those are really important, but I think you need to
distinguish between:

*       "back to top" (or worse, "^" etc)
*       non-list content such as "Index" links in lists

because they present different issues.

Daniele

On Mon, 12 Oct 2009 18:59:39 +0100,
real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:

>Anyway, it's a long list, and for various reasons, not one I think would
>usefully be split up.

I must admit that my first thought was, how useful is such a list?

I'd be looking at putting the data in a database and delivering it to
the user as they require, sorted by some query.
-- 
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

D.M. Procida wrote:

> It's a long list of academic publications
[...]
> Anyway, it's a long list, and for various reasons, not one I think
> would usefully be split up.

I think you're saying it's a write-only list that just "needs" to be there, 
and nobody is really expected to use it for anything, except to find errors, 
perhaps. If it were meant to be useful, it would - on the Web - be turned 
into a simple (or non-simple) data base so that people could make various 
queries and quickly get the info they are looking for

> [...] I think you need to
> distinguish between:
>
> *       "back to top" (or worse, "^" etc)
> *       non-list content such as "Index" links in lists
>
> because they present different issues.

I don't think they are that different. The latter does to a list what "back 
to top" does to a page.

If it's a long list (that needs an index etc.), then there should hardly be 
any other content on the page, so the "Index" link would really go to the 
start of the page.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

Geoff Berrow  wrote:

> On Mon, 12 Oct 2009 18:59:39 +0100,
> real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:
> 
> >Anyway, it's a long list, and for various reasons, not one I think would
> >usefully be split up.
> 
> I must admit that my first thought was, how useful is such a list?
> 
> 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.

Daniele

Jukka K. Korpela  wrote:

> > It's a long list of academic publications
> [...]
> > Anyway, it's a long list, and for various reasons, not one I think
> > would usefully be split up.
> 
> I think you're saying it's a write-only list that just "needs" to be there,
> and nobody is really expected to use it for anything, except to find errors,
> perhaps. If it were meant to be useful, it would - on the Web - be turned
> into a simple (or non-simple) data base so that people could make various
> queries and quickly get the info they are looking for

To be honest, I think how it will be used will evolve once it's
delivered, and more sophisticated requirements will emerge, especially
as people realise just what we can do with this information. For now
though, we need to start with this list.

> > [...] I think you need to
> > distinguish between:
> >
> > *       "back to top" (or worse, "^" etc)
> > *       non-list content such as "Index" links in lists
> >
> > because they present different issues.
> 
> I don't think they are that different. The latter does to a list what "back
> to top" does to a page.

'Index' (unlike 'back to top' or '^') has semantic content. It makes
sense even if it's the first thing the user sees on that page (unlike
'back to top'). It's not referring to an arbitrary position on the page
(which may or may not have anything useful on it), but to particular
information information on it.

However, the points you make about the pollution of lists with non-list
information hold for both, and I think they sway the case against having
'Index' links, despite the usability advantages they'd offer for many
users.

Daniele

Gazing into my crystal ball I observed
real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) writing in
news:1j7ho2q.1st0ef0h0ue0jN%real-not-anti-spam-address@apple-
juice.co.uk:

> Jukka K. Korpela  wrote:
> 
>> > It's a long list of academic publications
>> [...]
>> > Anyway, it's a long list, and for various reasons, not one I think
>> > would usefully be split up.
>> 
>> I think you're saying it's a write-only list that just "needs" to be
>> there, and nobody is really expected to use it for anything, except
>> to find errors, perhaps. If it were meant to be useful, it would - on
>> the Web - be turned into a simple (or non-simple) data base so that
>> people could make various queries and quickly get the info they are
>> looking for 
> 
> To be honest, I think how it will be used will evolve once it's
> delivered, and more sophisticated requirements will emerge, especially
> as people realise just what we can do with this information. For now
> though, we need to start with this list.
> 
>> > [...] I think you need to
>> > distinguish between:
>> >
>> > *       "back to top" (or worse, "^" etc)
>> > *       non-list content such as "Index" links in lists
>> >
>> > because they present different issues.
>> 
>> I don't think they are that different. The latter does to a list what
>> "back to top" does to a page.
> 
> 'Index' (unlike 'back to top' or '^') has semantic content. It makes
> sense even if it's the first thing the user sees on that page (unlike
> 'back to top'). It's not referring to an arbitrary position on the
> page (which may or may not have anything useful on it), but to
> particular information information on it.
> 
> However, the points you make about the pollution of lists with
> non-list information hold for both, and I think they sway the case
> against having 'Index' links, despite the usability advantages they'd
> offer for many users.
> 
> Daniele
> 

If you take a look at [http://www.w3.org/TR/html401/struct/links.html] 
the first thing you see is a line that has "index" in it.  As you go 
further and further down the page, should you want to go to the index, 
you need simply hit the Home button on your keyword, and be taken to the 
top of the page where the link to the index is.

-- 
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

On 12 Oct, 19:42, real-not-anti-spam-addr...@apple-juice.co.uk (D.M.
Procida) wrote:

> 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.

I'd certainly agree that the long complete list is the way to go - for
one thing, single-dimension linear scrolling is easy on the web.
Paging is really only beneficial when the volume of a list becomes too
great to download, not to read in a single view window.

I'd be careful with semantic markup here, quite possibly using XHTML
rather than XML to do so, and using embedded Dublin Core, Bath
Profile, RDFa or other non-HTML cataloguing metadata, embedded right
onto the readable page to make a lightweight XML web service to expose
this bibliography. <link rel="..." > is worth looking at too.  You
might even look at FOAF markup to describe relations between authors,
publications and your bibliographic index.

In article ,
 dorayme  wrote:
[snip]
> 
> OP wants to make a list. He wants it to be a nice usable list. He wants 
> users to be able to understand and negotiate it. It does not matter if 
> he or a thousand others are fixated on all this being possible within in 
> a list. It cannot be done with *just* a list (no matter with classes) 
> and it is the wrong tool for the job. 
> 
> An HTML table of data is a way to organise lists, links to indexes are 
> quite the sort of data that might appropriately go into a column and 
> relate to groups of rows.

Actually, I was going to suggest this based on the original post.
Either that, or split the data into a series of lists with sub-level
headings between them. The original post example looked like a table:

>         1990    Back to list index
>                 *       Joe Bob
>                 *       Bobo
>                 *       Dede Wilkes
>         1991    Back to list index
>                 ...
>         1992    Back to list index
>                 ...

So, either (a) a table with first column for year and second column for
entries (as rows or a list within a single cell?) or (2) a set of

   <div id="1990">
     <h2>1990</h2>
     <ul>....</ul>
   </div>

etc.

On Mon, 12 Oct 2009 21:40:16 +1100, dorayme
 wrote:

>An HTML table of data is a way to organise lists, links to indexes are 
>quite the sort of data that might appropriately go into a column and 
>relate to groups of rows.

I think some people have slavishly followed this idea of not using
tables so zealously that when an application that might well be marked
up logically using a table does come along, they move heaven and earth
to avoid it.

-- 
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 <1j7gv91.15g9afnonmaomN%real-not-anti-spam-address@apple-juice.co.uk>,
real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:

> Imagine a long nested list of items, or a long definition list, 
> prefaced
> with an index to that list.

Could this help? Javascript list manager:
http://www.benjaminkeen.com/software/smartlists/

In article ,
 David Stone <no.email@domain.invalid> wrote:

> In article ,
>  dorayme  wrote:
> [snip]
> > 
> > OP wants to make a list. He wants it to be a nice usable list. He wants 
> > users to be able to understand and negotiate it. It does not matter if 
> > he or a thousand others are fixated on all this being possible within in 
> > a list. It cannot be done with *just* a list (no matter with classes) 
> > and it is the wrong tool for the job. 
> > 
> > An HTML table of data is a way to organise lists, links to indexes are 
> > quite the sort of data that might appropriately go into a column and 
> > relate to groups of rows.
> 
> Actually, I was going to suggest this based on the original post.
> Either that, or split the data into a series of lists with sub-level
> headings between them. The original post example looked like a table:
> 
> >         1990    Back to list index
> >                 *       Joe Bob
> >                 *       Bobo
> >                 *       Dede Wilkes
> >         1991    Back to list index
> >                 ...
> >         1992    Back to list index
> >                 ...
> 
> So, either (a) a table with first column for year and second column for
> entries (as rows or a list within a single cell?) 

And, crucially, for the particular concern about the index link, *one* 
way to go is to have a third column with links to the index, everything 
depending on the details of the job. It is well known and understood 
that a column can span and relate as data to many rows.


> or (2) a set of
> 
>    <div id="1990">
>      <h2>1990</h2>
>      <ul>....</ul>
>    </div>
> 
> etc.
 
Yes, this would be a reasonable way too.

-- 
dorayme

dorayme  wrote:

> > > An HTML table of data is a way to organise lists, links to indexes are
> > > quite the sort of data that might appropriately go into a column and
> > > relate to groups of rows.
> > 
> > Actually, I was going to suggest this based on the original post.
> > Either that, or split the data into a series of lists with sub-level
> > headings between them. The original post example looked like a table:
> > 
> > >         1990    Back to list index
> > >                 *       Joe Bob
> > >                 *       Bobo
> > >                 *       Dede Wilkes
> > >         1991    Back to list index
> > >                 ...
> > >         1992    Back to list index
> > >                 ...
> > 
> > So, either (a) a table with first column for year and second column for
> > entries (as rows or a list within a single cell?) 
> 
> And, crucially, for the particular concern about the index link, *one*
> way to go is to have a third column with links to the index, everything
> depending on the details of the job. It is well known and understood 
> that a column can span and relate as data to many rows.

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

Daniele

In article 
<1j7kgtc.u36j2b1l6urflN%real-not-anti-spam-address@apple-juice.co.uk>,
 real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:

> dorayme  wrote:
> 
> > > > An HTML table of data is a way to organise lists, links to indexes are
> > > > quite the sort of data that might appropriately go into a column and
> > > > relate to groups of rows.
> > > 
> > > Actually, I was going to suggest this based on the original post.
...
> > > ... The original post example looked like a table:
> > > 
> > > >         1990    Back to list index
> > > >                 *       Joe Bob
> > > >                 *       Bobo
> > > >                 *       Dede Wilkes
> > > >         1991    Back to list index
> > > >                 ...
               ...
> > > 

> > And, crucially, for the particular concern about the index link, *one*
> > way to go is to have a third column with links to the index, everything
> > depending on the details of the job. It is well known and understood 
> > that a column can span and relate as data to many rows.
> 
> Links to an index no more items of table data than they are list items -
> they are navigation furniture.
> 

First, it does not follow that because something is part of navigation 
furniture, it cannot or should not be rendered in a table. An always 
visible equivalent to a drop down menu can perfectly semantically and 
legitimately be made as a table rather than lists and sublists or rather 
than just lists and sublists. This is not something I am recommending 
for all situations. But it is not logically wrong.

Second, it does not follow that because some things might be navigation 
furniture, that they cannot be part of some table where the purpose of 
the table is to display more than very narrow information (for example, 
*just* navigation matters)

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, seemingly unable to imagine or grasp that a 
table can be legitimately manufactured to show all kinds of 
relationships between items of different kinds.

-- 
dorayme

"dorayme"  wrote in message 
news:doraymeRidThis-92E510.18281614102009@news.albasani.net...
> In article
> <1j7kgtc.u36j2b1l6urflN%real-not-anti-spam-address@apple-juice.co.uk>,
> real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:
>
>> dorayme  wrote:
>>
>> > > > An HTML table of data is a way to organise lists, links to indexes 
>> > > > are
>> > > > quite the sort of data that might appropriately go into a column 
>> > > > and
>> > > > relate to groups of rows.
>> > >
>> > > Actually, I was going to suggest this based on the original post.
> ...
>> > > ... The original post example looked like a table:
>> > >
>> > > >         1990    Back to list index
>> > > >                 *       Joe Bob
>> > > >                 *       Bobo
>> > > >                 *       Dede Wilkes
>> > > >         1991    Back to list index
>> > > >                 ...
>               ...
>> > >
>
>> > And, crucially, for the particular concern about the index link, *one*
>> > way to go is to have a third column with links to the index, everything
>> > depending on the details of the job. It is well known and understood
>> > that a column can span and relate as data to many rows.
>>
>> Links to an index no more items of table data than they are list items -
>> they are navigation furniture.
>>
>
> First, it does not follow that because something is part of navigation
> furniture, it cannot or should not be rendered in a table. An always
> visible equivalent to a drop down menu can perfectly semantically and
> legitimately be made as a table rather than lists and sublists or rather
> than just lists and sublists. This is not something I am recommending
> for all situations. But it is not logically wrong.
>
> Second, it does not follow that because some things might be navigation
> furniture, that they cannot be part of some table where the purpose of
> the table is to display more than very narrow information (for example,
> *just* navigation matters)
>
> 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, seemingly unable to imagine or grasp that a
> table can be legitimately manufactured to show all kinds of
> relationships between items of different kinds.

Well said.

This antithipy agains tables has gone too far. Sure, don't use one for 
purely "layout" purposes. But use one where it is the best (or only) thing 
in the bag to use.

I have a page that is only "navigation". It's a table. The rows of the table 
are the other pages to be navigated to. The columns of the table are: A very 
short description of the company whose details may be found on that page, a 
"thumbnail" (actually a company logo) and the link to the page, wrapped 
around the company name. This is very demonstrably a table. It is also very 
demonstrably "navigation". Try doing that with a list.

Tools are there to be used. Don't use your keyboard to support a peice of 
wood whilst sawing. Use your saw *table*.

dorayme  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, seemingly unable to imagine or grasp that a 
> table can be legitimately manufactured to show all kinds of 
> relationships between items of different kinds.

What I am seemingly unable to imagine or grasp, while I am sure it's a
very interesting subject, is not really the point here. 

Let's leave aside all the examples of legitimately-manufactured tables,
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.

Daniele

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@apple-juice.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@apple-juice.co.uk>,
 real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:

> dorayme  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  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@apple-juice.co.uk>,
 real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:

> dorayme  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