 | |
Non-list items in lists
HTML Writing HTML for the Web (comp.infosystems.www.authoring.html)
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: Non-list items in lists -
10-12-2009
, 06:20 PM
|
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 |
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.
Quote:
|
[...] 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. |
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
#12
| |||
| |||
|
|
Jukka K. Korpela <jkorpela (AT) cs (DOT) tut.fi> 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 |
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
#13
| |||
| |||
|
|
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. |
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.
#14
| |||
| |||
|
|
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. |
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:
Quote:
|
1990 Back to list index * Joe Bob * Bobo * Dede Wilkes 1991 Back to list index ... 1992 Back to list index ... |
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.
#15
| |||
| |||
|
|
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. |
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
#16
| |||
| |||
|
|
In article <doraymeRidThis-2EFA6C.21401612102009 (AT) news (DOT) albasani.net>, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> 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?) |
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.
Quote:
|
or (2) a set of div id="1990" h2>1990</h2 ul>....</ul /div etc. |
--
dorayme
#17
| |||
| |||
|
|
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. |
they are navigation furniture.
Daniele
#18
| |||
| |||
|
|
dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> 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. |
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
#19
| |||
| |||
|
|
In article 1j7kgtc.u36j2b1l6urflN%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: 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. |
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*.
#20
| |||
| |||
|
|
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. |
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
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.