Bad? Or not? (But I think I already know...)

[The Plankmeister]

Is doing this bad:

<h3>Some title or other...<a href="#pagetop">back to top</a></h3>

I have a feeling it is... My problem is I'm using CSS to style the H3 into a
block that spans the whole containing element. I would like the <a> to
appear next to the title, but I'm sure this is bad practice (for screen
readers and heading-level navigation etc etc)

So... is it acceptable to do this:

<span><h3>Some title or other...</h3><a href="#pagetop">back to
top</a></span>

Or does nesting the <h3> in a <span> do something horrible to the document
structure?

Comments, please! :)

P.

[Barry Pearson]

Matthias Gutfeldt wrote:
[snip]

LINK is a very old standard - it was part of HTML2, and some browsers
(e.g. Lynx) have been supporting it for many years. What is 'emerging'
is the more mainstream browsers that support it, and the awareness in
HTML authors for its usefulness.
Thanks for the information. What is unclear to me is what the standard set of
rel values are, and what they conventionally mean.

Different sources identify different sets of values. W3C doesn't appear to
mention "home", but it does mention "start", for example, while others have
"home" and "top". Some other sources mention "search" and "find". MSDN
mentions "appendix" but some other sources don't.

Also, it appears important to have consistent use, but the descriptions are
ambiguous. For example, many web sites have a "site map", with that specific
name. The nearest rel value appears to be "index". Is this the convention?

I note that Opera appears to have chosen a fixed set and then makes them
active or grey depending on what it finds in the document. Its set appears to
be (in order):
Home Index Contents Search Glossary Help First Previous Next Last Up Copyright
Author.
Sander explains the situation, and the many advantages of LINK, in his
article: <http://www.euronet.nl/~tekelenb/WWW/LINK/index.html>

[snip]

Is this (just over half way down that page) the most comprehensive list,
including alternatives names for the same thing? It maps almost 1-to-1 with
the Opera set, except that Opera also has "Glossary".

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Alan J. Flavell]

On Tue, 21 Oct 2003, Barry Pearson wrote:

Sander explains the situation, and the many advantages of LINK, in his
article: <http://www.euronet.nl/~tekelenb/WWW/LINK/index.html>

Is this (just over half way down that page) the most comprehensive list,

The "most comprehensive" list that I know of is in the source code for
Lynx (currently it's http://lynx.isc.org/current/lynx2-8-5/src/HTML.c ).
But that would need to be tempered with a look at the suggestions in
the HTML4.01 spec, and with what's implemented in the various
browsers mentioned by Sander and by the resources that he cites (Nahrath,
Gutfeldt).

But don't worry - if you use a "link rel" which isn't explicitly
supported, it will do no harm, and in Mozilla, at least, it will turn
up on its "More..." list (and that includes "link rel=More", by the
way ;-)

Has someone mentioned yet that in recent Mozilla versions you turn
this option on with View->Show/Hide->Site Navigation Bar

[Barry Pearson]

Alan J. Flavell wrote:

On Tue, 21 Oct 2003, Barry Pearson wrote:

> Sander explains the situation, and the many advantages of LINK, in
> his article: <http://www.euronet.nl/~tekelenb/WWW/LINK/index.html>

Is this (just over half way down that page) the most comprehensive
list,

The "most comprehensive" list that I know of is in the source code for
Lynx (currently it's http://lynx.isc.org/current/lynx2-8-5/src/HTML.c
). But that would need to be tempered with a look at the suggestions
in
the HTML4.01 spec, and with what's implemented in the various
browsers mentioned by Sander and by the resources that he cites
(Nahrath, Gutfeldt).

But don't worry - if you use a "link rel" which isn't explicitly
supported, it will do no harm, and in Mozilla, at least, it will turn
up on its "More..." list (and that includes "link rel=More", by the
way ;-)

[snip]

I'm not worried about "harm". What I really want is a browser-independent set
of simple rules for specifying such links.

For example, I would hate to put rel="start" and find that some browser didn't
recognise that as a synonym for "home" and so didn't activate that button /
icon / menu. I would hate to find myself the only person in the world to use
rel="index" to point to my site map instead of some other sort of index. And I
probably need to know whether to say "home" or "Home".

This is one of those cases where creativity is bad, and boring old consistency
& convention is good. I think I can see 5 or 6, possibly more, that I could
make good use of. But it isn't simply "does browser X support links? It is
"this is the set of rel-values that conforms to W3C and are handled
consistently by the maximum set of browsers, and here is the conventional way
they are being used in practice". Otherwise aren't we just generating "link
soup" based on competing browsers?

As a starter, here is an attempt to see if there is any common set in the
sources. "iCab" is the set of values in the source at the top of this article,
and numbers 1 to 12 are the same as that document. "Opera button" is simply
the name shown by the button. I haven't investigated what values of rel map
onto it, but I'm GUESSING that the word itself will map. "W3C" is a subset of
the "link" values at W3C, but I gave up after a while (see "14") because some
of the values were not intended for this purpose (eg. "Stylesheet"), and I
don't know which were. I'm really also just guessing that the "iCab" sets
really are synonyms or near synonyms. (See, for example, "1", where the Opera
button & the W3C words are different, but both in the same "iCab" set).

1. iCab: home, start, top; Opera button: Home; W3C: Start
2. iCab: contents, TOC; Opera button: Contents; W3C: Contents
3. iCab: begin, first; Opera button: First; (W3C: none)
4. iCab: prev, previous; Opera button: Previous; W3C: Prev (& Previous)
5. iCab: next; Opera button: Next; W3C: Next
6. iCab: end, last; Opera button: Last; (W3C: none)
7. iCab: up; Opera button: Up; (W3C: none)
8. iCab: index; Opera button: Index; W3C: Index
9. iCab: find, search; Opera button: Search; (W3C: none)
10. iCab: help; Opera button: Help; W3C: Help
11. iCab: copyright; Opera button: Copyright; W3C: Copyright
12. iCab: author, made; Opera button: Author; (W3C: none)
13. (iCab: none); Opera button: Glossary; W3C: Glossary
14. Some extra W3C values that I'm not sure about.
15. Some extra MSDN DHTML values that I'm not sure about (see below).

I'm still a bit uncertain about the conventional mapping. For example, is
"index" really the value to use for the typical "site map"? Perhaps by default
it could be, but then also be used for more localised indexes?

I can't remember where I came across the following link. Presumably one of
there sources here directly or indirectly linked to it. But it is worth
repeating, since it is from MS (although DHTML):
http://msdn.microsoft.com/workshop/a...erties/rel.asp

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Brian]

Barry Pearson wrote:

Different sources identify different sets of values. W3C doesn't
appear to mention "home", but it does mention "start"
The www is sadled with certain unfortunate conventions. One is the
use of "home" to mean the browser start-up page *and* a site's welcome
or start page. At least in the browser, calling that "start" would
have been better. After all, what does "home" have to do with the
page a browser loads when first launched?

Another is "index," the common file root name that web servers look
for and deliver when a directory is requested. The problem is that
"index.html" (or .php or ...) is (almost?) never an index in the book
sense. I wish they had settled on "default" instead.

Well, we're stuck with the conventions we have.
while others have "home" and "top".
I'd avoid confusing things further by using "home" as a link rel. I
use "start" instead.
Some other sources mention "search" and "find".
I use "search" since that is more commonly used in English to refer to
a document search page.
MSDN mentions "appendix" but some other sources don't.
As Alan Flavell said, using links that aren't listed can't do harm. At
worst, they won't show up in some browsers like Opera. And of course
none will show up in MSIE/Win.
the descriptions are ambiguous. For example, many web sites have a
"site map", with that specific name. The nearest rel value appears
to be "index". Is this the convention?

The convention is, as I discussed above, a bit confusing. Again, I
wouldn't make matters worse by confusing "index" with "site map."
"index" should be for an index of a document or collection of
documents. In general, use link in the most logical way, irrespective
of what browser-x might do with it. The author's job is to make the
content accessible; it's up to the ua to do something sensible with it.

--
Brian
follow the directions in my address to email me

[Barry Pearson]

Brian wrote:

Barry Pearson wrote ...

[snip]

I'd avoid confusing things further by using "home" as a link rel. I
use "start" instead.

I've found the following page, which shows the sort of comparative information
I was after. It agrees with you:
http://homepages.paradise.net.nz/tom...ink_Types.html
Some other sources mention "search" and "find".

I use "search" since that is more commonly used in English to refer to
a document search page.

Indeed. It isn't in the W3C list, unfortunately.

[snip]

the descriptions are ambiguous. For example, many web sites have a
"site map", with that specific name. The nearest rel value appears
to be "index". Is this the convention?

The convention is, as I discussed above, a bit confusing. Again, I
wouldn't make matters worse by confusing "index" with "site map."
"index" should be for an index of a document or collection of
documents. In general, use link in the most logical way, irrespective
of what browser-x might do with it. The author's job is to make the
content accessible; it's up to the ua to do something sensible with
it.

I agree with that principle - but what IS "the most logical"? It certainly
isn't obvious. These are words that can be interpreted in man different ways.
I may think that "home" is THE standard word used across the world for the
basic www.domainname/ entry point, the UA developer may think differently and
expect "start" or "top" to be used, and this may be shown to the user as
"Top", even though the user may actually agree with me, or with "start". If I
use "home" and you use "start", they will both map onto "Home" in Opera, but
onto different things, "Top" and "More", in Firebird. I am not aware of a
simple set of rules such as "if you want to indicate the basic
www.domainname/ entry point use "X", if you want to indicate your site map use
"Y".

What link "rel" value would you use for a site map? "Contents"? Very many
sites have a site map, and I'm sure many people use them when they are lost.
(I have a "site map & search" button on most pages for this reason). The page
at the top of this article that provides the table, and says that he uses
"Content", doesn't actually use "Content"!

Opera 7.2 buttons, and the rel-values that activate them (I guess
case-insensitive). I've noted differences from what I've read about iCab.

Home: home, start, top
Index: index
Contents: contents, toc
Search: search, find
Glossary: glossary (I've read that iCab doesn't recognise this)
Help: help
First: first, begin
Previous: prev, previous
Next: next
Last: last (iCab also has "end" here, Opera doesn't)
Up: up
Copyright: copyright
Author: author (iCab also has "made" here, Opera doesn't).

And here is the Mozilla Firebird 0.7 Navigation bar:

Top: start, top (not "home", which Opera & iCab have as synonyms)
Up: up
First: first, begin
Previous: previous, prev
Next: next
Last: last, end (like iCab, unlike Opera)
More: apparently anything not in the above list (eg. "home", "index",
"author"). If Firebird doesn't recognise it (eg. "zebra"!) it says "Table of
Contents".

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Alan J. Flavell]

On Tue, 21 Oct 2003, Brian wrote:

worst, they won't show up in some browsers like Opera. And of course
none will show up in MSIE/Win.
I think if you ask Jim Ley nicely, he'll have an installable script
or bookmarklet or such for that.

A modification of MS's own IE5 Web Accessories would do it.

(Yes, I know this doesn't scale - you can install such a component
yourself, but you can't rely on readers having the facility. Still,
look on it as an optional extra convenience, rather than a must-have,
and it'd be fine.)
The convention is, as I discussed above, a bit confusing.

Yup, I can only agree that the available selection of rel= terms is
quite a rag-bag, with no clear guiding concept. For what it's worth
(which probably isn't very much), the ones that I tend to use myself
are a selection of: rev=Made and rel= Prev, Up, Next, and More.
(Not forgetting Stylesheet, natch ;-)

But "More" isn't very well supported. On Mozilla, you have to go
"More> More> More" to get to it.

cheers

[Nick Kew]

In article <EV******************@newsfep2-win.server.ntli.net>, one of infinite monkeys
at the keyboard of "Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:

Thanks for the information. What is unclear to me is what the standard set of
rel values are, and what they conventionally mean.

A very confused area. Stop thinking "standard set".

FWIW, if I were implementing a browser, I'd just generate a menu of
whatever links the document includes, subject to content type[1].
So rel="Home" would generate a link labelled "Home" on the menu, etc.

As for how to present them to the user, these are in the <head> section
and hence not part of a page's visible data. The old RiscOS middle-
mouse-button popup menu could be an ideal presentation for a GUI browser.

[1] Content-types of interest should be a user-configurable option.
For example a normal user won't want to view CSS source, but
a developer may. So we don't normally display links to text/css,
but we have a user option to do so.

--
Nick Kew

In urgent need of paying work - see http://www.webthing.com/~nick/cv.html

[Barry Pearson]

Nick Kew wrote:

In article <EV******************@newsfep2-win.server.ntli.net>, one
of infinite monkeys at the keyboard of "Barry Pearson"
<ne**@childsupportanalysis.co.uk> wrote:

Thanks for the information. What is unclear to me is what the
standard set of rel values are, and what they conventionally mean.

A very confused area. Stop thinking "standard set".

FWIW, if I were implementing a browser, I'd just generate a menu of
whatever links the document includes, subject to content type[1].
So rel="Home" would generate a link labelled "Home" on the menu, etc.

[snip]

The essence of this discussion is "standardisation". Here is the document (by
Sander Tekelenburg) identified earlier in this thread, and here is an extract
from it:
http://www.euronet.nl/%7Etekelenb/WWW/LINK/index.html

<extract>
Wouldn't it be great if the Web would have some form of universal 'traffic
signs'? A scheme that would allow visitors to easily and quickly navigate
through Web sites. Wouldn't it be great if browsers would have some kind of
build-in sensor, that would be able to tell visitors where to find the
homepage to a site, where to find an index, where to find a help page, or a
search page? No matter what Web site is being visited? A system capable of
visualising a Web site's structure. A system where, no matter how deep a
visitor has travelled inside a Web site, he can still find his way without a
blink. And wouldn't it be great if such a system would not stand in the way of
a Web site's unique presentation of content? Surely that would be the best of
both worlds: to have both universally understood navigation and unique
presentation of content at the same time.

Well, have I got news for you: there is such a system. And it has been around
for quite a while now. The HTML 2.0 standard, which dates back to November
1995, already included the LINK element. The LINK element offers WWW authors a
way to define a few 'standard links' - links to the kind of places that most
Web site's structures use, such as a homepage, a help page, the next or
previous page, the parent document, a page offering contact information, etc.
Almost every Web site uses at least some of those pages. And they're usually
the most essential pages.
</extract>

If we buy into this, the point is that the way a particular UA renders the
links to these pages on your web sites, mine, Alan's, Brian's will be the
same. (It will be different from how a different UA renders them, but that is
a different matter). If it is a button marked "Home" in one, it should be the
same in all. Or an icon of a house. Or whatever.

The problem is that we appear to be nearly there, but not quite. I've
identified the following sorts of problems. (Others are also aware of them).

1. Ambiguous definitions: we may all agree that we all have similar pages that
provide a structured comprehensive list of all the key pages. But do we say
"index" or "contents" (or "toc")? We should use the same word, because we have
agreed the pages are conceptually the same, and UAs treat these different
words differently. The W3C definitions are a bit fuzzy. I suspect a good word
the typical site map is "contents" (or "toc") but will everyone else use the
same word?

2. Near synonyms: for many of our pages we may want a link to the typical
entry point to the web site. We may all agree that our entry points are
similar enough to have the same link rendering in UAs, but depending on
whether we use "start" or "top" or "home" we may get different results.
(Firebird doesn't treat "home" as a synonym for the others, although Opera and
others do). W3C only mentions "start" (of these words), and the definition
appears close enough to recommend it as the word to use. Opera will then
render it "Home", and Firebird will then render it "Top"!

3. Non-standard words: there is, for example, no W3C link word equivalent to
"search". It is OK to use extra words (you are supposed to identify a profile
for it) but really we ought all use the same word. And we can't use W3C to
resolve conflicts. We can look at UAs and see what they do. That suggests
using "search" instead of alternatives such as "find", because there may be
more consistency.

I have just uploaded the following page, based on my recent reading and
investigation. It suggests some recommendations for authors. It is incomplete
and not suitable for a long stay on the web, so I will delete this page during
December. Anyone is free to use the contents as they choose.
http://www.barry.pearson.name/test/links.htm

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Barry Pearson]

Matthias Gutfeldt wrote:
[snip]

LINK is a very old standard - it was part of HTML2, and some browsers
(e.g. Lynx) have been supporting it for many years. What is 'emerging'
is the more mainstream browsers that support it, and the awareness in
HTML authors for its usefulness.

Sander explains the situation, and the many advantages of LINK, in his
article: <http://www.euronet.nl/~tekelenb/WWW/LINK/index.html>

And I have a list of browsers that support LINK:
<http://www.gutfeldt.ch/matthias/translation/LINK/ENaddendum.html>.
It's slightly outdated and doesn't mention e.g. Safari.

[snip]

I have just uploaded the following page, based on my recent reading and
investigation. It suggests some recommendations for authors. It is incomplete
and not suitable for a long stay on the web, so I will delete this page during
December. Anyone is free to use the contents as they choose.
http://www.barry.pearson.name/test/links.htm

All I really want here is a set of guidelines for myself that will be
consistent with what others do and render sensibly in typical UAs. I will wait
to see if there is any reaction to this before changing any of my pages to add
links.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Steve Pugh]

"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:

I have just uploaded the following page, based on my recent reading and
investigation. It suggests some recommendations for authors. It is incomplete
and not suitable for a long stay on the web, so I will delete this page during
December. Anyone is free to use the contents as they choose.
http://www.barry.pearson.name/test/links.htm

All I really want here is a set of guidelines for myself that will be
consistent with what others do and render sensibly in typical UAs. I will wait
to see if there is any reaction to this before changing any of my pages to add
links.

I've a few comments, not entirely coherent.

The W3C list is no big deal, it is merely provided in the HTML spec as
a list of common values and there is no attempt to enforce to via the
DTD. Yes, values on this list have a better chance of being supported
by new browsers, but, for example, Opera looked at what other browsers
supported when it added <link> support.

Home, Start, Top.
I prefer Home.
To my mind Start is closer to a synonym for First than for Home. The
W3C definition does specify a 'collection of documents' rather than a
site. Sometimes a site will consist of more than one collection of
documents.
I also dislike Top as it implies a hierarchical structure which not
all sites have.
Up to know I've used Home but as that buries the link in Mozilla I may
switch to Top where the site structure is hierarchical.

In theory we should be able to do something like this:
rel="home start" but neither Opera nor Lynx recognises links like
this, even when their preferred version comes first.
(Note that this is why some people get hot under the collar about
"shortcut icon" and "alternate stylesheet" - they should be identical
to two links with one of the two keywords apiece.)

Difference between (Table of) Contents and Index.
Think about a book. The Table of Contents comes at the front and the
Index at the back. So linking Contents to the 'home' page of a site of
section and Index to the site map is an entirely valid choice.

Look at how I use Contents and Index on pages like
http://steve.pugh.net/SFSFW/a/13/peter.html
(Not all pages in that site have <link>s as yet and there may also be
a few errors).

If you look at the source of that page you'll see that there are two
Index links as I have two indices that contain references to that
article. Lynx will display two links, using the title attributes as
labels. But Opera and Mozilla will only display the first one
encountered. As all the articles on that site are in one, two or three
indices but all are in the same one, so that one gets listed first.

For some link types (mostly the rarely used ones such as Chapter)
Mozilla does support multiple links, but Opera ever does.

If the link contains a fragment identifier <link rel="search"
href="index.html#search"> then Opera ignores the fragment and just
loads the page. Annoying but rarely critical.

Author and Made.
Made should always be a rev="made" which means that it can be easily
combined with author: <link rev="made" rel="author"
href="mailto:we*******@example.com">. For some pages such as the
article mentioned above I split them so that rev is still a mailto
link to myself but author is a link to the author's index entry (which
may also contain a short biog in the future).

Other than Made, rev links are not used by browsers but may be used
some hypothetical super-smart hypertext indexing engine. I sometimes
add rev relationships to rel links I already have in there, but I
don't add purely rev links.

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

[Jim Ley]

On Wed, 22 Oct 2003 14:04:24 +0100, Steve Pugh <st***@pugh.net> wrote:

Home, Start, Top.
I prefer Home.
To my mind Start is closer to a synonym for First than for Home.
I think we should not read too much into these words, if they are
meant to apply to the web, then the English definition should have
little relevance - the web is not an English medium.
(Note that this is why some people get hot under the collar about
"shortcut icon" and "alternate stylesheet" - they should be identical
to two links with one of the two keywords apiece.)

It's bad to overload the LINK so that it includes things which are
meant to be shown to users, and things which only apply to machines,
since that means UA's which don't understand shortcut icon, or
alternate stylesheet would be constucting links for the users which
they will not be able to understand.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Steve Pugh]

ji*@jibbering.com (Jim Ley) wrote:

On Wed, 22 Oct 2003 14:04:24 +0100, Steve Pugh <st***@pugh.net> wrote:

Home, Start, Top.
I prefer Home.
To my mind Start is closer to a synonym for First than for Home.

I think we should not read too much into these words, if they are
meant to apply to the web, then the English definition should have
little relevance - the web is not an English medium.

If the values are to be taken as random strings of characters with no
meaning beyond the effect they have in browsers then we need a
definitive list of what they do mean. And as this thread has
demonstrated no such list exists.

As I said the W3C definition of Start can be taken to mean the home
page of a site or just the start of set of pages depending on context.

In the absence of a title attribute the rel value will be displayed by
Lynx and for non-preset values by Mozilla as well, so these values
will be seen by humans in some circumstances. Obviously authors of
non-English web pages need to use the title attribute even for even
the simplest link types.

Maybe title should be mandatory for link elements.

(Note that this is why some people get hot under the collar about
"shortcut icon" and "alternate stylesheet" - they should be identical
to two links with one of the two keywords apiece.)

It's bad to overload the LINK so that it includes things which are
meant to be shown to users, and things which only apply to machines,
since that means UA's which don't understand shortcut icon, or
alternate stylesheet would be constucting links for the users which
they will not be able to understand.

True. But nearly a decade too late.

Beside the piunbt, but at the moment does any browser other than
Mozilla do anything with link types that it aren't on a preset list?
Mozilla does of coure understand bith icons and stylesheets, but
future developments along similar lines would cause exactly the
problem you describe.

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

[Brian]

Steve Pugh wrote:

Home, Start, Top.
I prefer Home.
To my mind Start is closer to a synonym for First than for Home. The
W3C definition does specify a 'collection of documents' rather than a
site. Sometimes a site will consist of more than one collection of
documents.
I also dislike Top as it implies a hierarchical structure which not
all sites have.
You wouldn't consider an entry point to be the top?
(Note that this is why some people get hot under the collar about
"shortcut icon" and "alternate stylesheet" - they should be identical
to two links with one of the two keywords apiece.)
Another unfortunate idea that mucks up the link element.
Difference between (Table of) Contents and Index.
Think about a book. The Table of Contents comes at the front and the
Index at the back.
Well, not necessarily. French books typically place the toc in the
back. And in the context of the web, where something is located is
irrelevant.

ToC is a structured list of contents; topics are usually listed in the
same order that they appear in the text.

Index is an alphapbetical list of topics.
So linking Contents to the 'home' page of a site of
section and Index to the site map is an entirely valid choice.
I really don't think so. ToC should not link to the home page unless
the home page contains a ToC. And a site map is not an index.
Look at how I use Contents and Index on pages like
http://steve.pugh.net/SFSFW/a/13/peter.html
Upon quick inspection, looks like a good use of them.
For some link types (mostly the rarely used ones such as Chapter)
Mozilla does support multiple links,

Ditto for bookmarks and alternate.

--
Brian
follow the directions in my address to email me

[Brian]

Steve Pugh wrote:

Beside the piunbt

I tried two acronym searches, and both came up empty. What does
piunbt mean?

--
Brian
follow the directions in my address to email me

[Steve Pugh]

Brian <us*****@julietremblay.com.invalid-remove-this-part> wrote:

Steve Pugh wrote:

Beside the piunbt

I tried two acronym searches, and both came up empty. What does
piunbt mean?

Point. Good typo, I blame the paper cut on the end of my finger. ;-)

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

[Steve Pugh]

Brian <us*****@julietremblay.com.invalid-remove-this-part> wrote:

Steve Pugh wrote:

Home, Start, Top.
I prefer Home.
To my mind Start is closer to a synonym for First than for Home. The
W3C definition does specify a 'collection of documents' rather than a
site. Sometimes a site will consist of more than one collection of
documents.
I also dislike Top as it implies a hierarchical structure which not
all sites have.
You wouldn't consider an entry point to be the top?

Only for a mine. ;-)

And thanks to search engines any page can be an entry point. I
wouldn't assume that the home page is the only entry point, or even
the best one, and I certainly wouln't assume that it's in anyway on
top of the other pages. But maybe Jim's right and I'm reading too much
into the English meanings of the words.

Difference between (Table of) Contents and Index.
Think about a book. The Table of Contents comes at the front and the
Index at the back.

Well, not necessarily. French books typically place the toc in the
back. And in the context of the web, where something is located is
irrelevant.

ToC is a structured list of contents; topics are usually listed in the
same order that they appear in the text.

But on the web there isn't always an order so some other structure
applies.
Index is an alphapbetical list of topics.
Usually, yes. Whether a list of publications sorted by some form of
publication number is in alphabetical order or not and/or is an index
or not is getting into levels of pedantry where even I don't want to
go.

Hmm, why is
http://www.ecma-international.org/pu...s/Stnindex.htm
an Index and
http://www.ecma-international.org/pu...s/Standard.htm
a List? Or do we trust any body that uses the word "Organigram" with a
straight face to make a sensible distinction?

So linking Contents to the 'home' page of a site of
section and Index to the site map is an entirely valid choice.

I really don't think so. ToC should not link to the home page unless
the home page contains a ToC.

Depends on the home page - many are, many aren't. To go back to the
book analogy many of the more technical books I own have a 'Contents
at a Glance' type page that list the main sections on a single page
and then have a full Table of Contents spread over several pages. A
web site will often take a similar structure with the home page being
the former and the site map the latter. In that case rel="TOC" would
go to the site map but rel="contents" could go to either. But the
browsers treat those as synonyms so that distinction is false.
And a site map is not an index.

Again it depends.Some site maps are alphabetical and so would meet
your criteria. Others are not but site maps do often serve similar
functions to indices. On the web we have Find in page functions in our
browsers so the need for alphabetical listing to facilitate easy
look-up is reduced, sometimes, maybe.

To go back to the lovely ECMA their site map is (mostly) organised
alphabetically.

I now have no idea what if anything I'm arguing. I'll just go and have
a little lie down.

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

[Jim Ley]

On Wed, 22 Oct 2003 15:31:49 +0100, Steve Pugh <st***@pugh.net> wrote:

If the values are to be taken as random strings of characters with no
meaning beyond the effect they have in browsers then we need a
definitive list of what they do mean. And as this thread has
demonstrated no such list exists.
True, but trying to construct that list on arguments about what the
words mean to you doesn't take things further along the road to them
being useable.
True. But nearly a decade too late.

Not really, there's so little consistent implementation either by
clients or authors, it wouldn't be that hard to simply conclude it's
not constructive to use it.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Brian]

Steve Pugh wrote:

Brian wrote:

Steve Pugh wrote:

Beside the piunbt

I tried two acronym searches, and both came up empty. What does
piunbt mean?

Point. Good typo, I blame the paper cut on the end of my finger. ;-)

Wow. That must me the mother of all paper cuts! :-D

--
Brian
follow the directions in my address to email me

[Alan J. Flavell]

On Wed, 22 Oct 2003, Steve Pugh wrote:

And thanks to search engines any page can be an entry point. I
wouldn't assume that the home page is the only entry point, or even
the best one, and I certainly wouln't assume that it's in anyway on
top of the other pages. But maybe Jim's right and I'm reading too much
into the English meanings of the words.

The way I look at it is this, roughly speaking.

Sure, the reader can arrive at any page, e.g via a search engine, and
their interests might then take them in any direction. No essential
hierarchical structure there, and I sure don't want the author to try
to force me in through the front door and down through some
pre-programmed maze before I can get at the content. (I know little
more infuriating than those vendor sites who insist on demanding your
country, your industry sector, your inside leg measurement... before
they'll admit to having any kind of products.)

On the other hand, the author probably has a mental picture of his/her
own site, and if there's a hierarchy to it, then the reader *might* (I
say *might*) be interested to know what that structure is, to help
find their way around.

In that sense, the author is offering potentially useful orientation
by using the terms Up, Home/Start, Prev/ious, Next, and so on, in
their link navigation. Even though the reader may not choose to go
that way.

But an index of topics is at least as useful, if not more so, than a
structure index: the one by no means substitutes for the other.

I won't even try to offer examples - realising only too well that my
own web pages are a relatively unstructured patchwork. :-}

[Nick Kew]

In article <3f**************@news.cis.dfn.de>, one of infinite monkeys
at the keyboard of ji*@jibbering.com (Jim Ley) wrote:

It's bad to overload the LINK so that it includes things which are
meant to be shown to users, and things which only apply to machines,
since that means UA's which don't understand shortcut icon, or
alternate stylesheet would be constucting links for the users which
they will not be able to understand.

Not really. The browser should base it's decision on whether to present
a link to the user on the type="..." attribute of a <link>.

type="text/html" or "text/plain", yes. type="text/css", no.
Unless of course the user sets something different in Preferences.

--
Nick Kew

In urgent need of paying work - see http://www.webthing.com/~nick/cv.html

[Jim Ley]

On Wed, 22 Oct 2003 21:40:19 +0100, ni**@fenris.webthing.com (Nick
Kew) wrote:

In article <3f**************@news.cis.dfn.de>, one of infinite monkeys
at the keyboard of ji*@jibbering.com (Jim Ley) wrote:

It's bad to overload the LINK so that it includes things which are
meant to be shown to users, and things which only apply to machines,
since that means UA's which don't understand shortcut icon, or
alternate stylesheet would be constucting links for the users which
they will not be able to understand.

Not really. The browser should base it's decision on whether to present
a link to the user on the type="..." attribute of a <link>.

type="text/html" or "text/plain", yes. type="text/css", no.
Unless of course the user sets something different in Preferences.

Perhaps yes, do the UA's that actually implement do so? I know my
implementation doesn't.

application/rdf+xml
application/xhtml+xml
image/svg+xml

Or PDF or whatever - for alternative versions of pages etc. There's
lots of these some useful to the user, some not.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Alan J. Flavell]

On Wed, 22 Oct 2003, Nick Kew wrote:

Not really. The browser should base it's decision on whether to present
a link to the user on the type="..." attribute of a <link>.
hmmm. I know I'm expected to provide that for stylesheets, probably
for good reason, but what about the navigational stuff which we're
discussing chiefly here?
type="text/html" or "text/plain", yes.

Suppose <link rel="Next"> (taking just a f'rinstance) points to a
negotiated content type, what would you expect me to put in the link?

cheers

[Barry Pearson]

Steve Pugh wrote:

"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote: [snip] I've a few comments, not entirely coherent.

[snip]

I won't respond point by point. I believe you have advanced my views on this a
lot. It will take me some time to absorb & apply them. But I'll probably
follow at least some of your examples throughout my pages.

I am convinced that a valuable opportunity for an extra level of standardised
navigation is being eroded. But perhaps most of those who have responded on
this topic also believe that. I suspect that both Opera & Mozilla have made
decisions that are unfortunate. Perhaps both of them should have separated
"home" and "top" in a better way. Perhaps both should have their separate
buttons for these, at a "peer" level to one-another. Some extra similarity
might have reinforced certain practices.

This is one of those cases where there is no "right" decision, but what is
important is that everyone should do the same thing. Like all driving on the
same side of the road - it doesn't matter which.

Thank you.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/