Indicate document fragments with <LINK rel="Bookmark">

**Andreas Prilop** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

On Wed, 28 May 2008, Stanimir Stamenkov wrote:

I want to find out whether the following usage of the "Bookmark"
link type is o.k. An example could be seen at
<http://www.geocities.c om/stanio/more/horoskop.html>

No. Use REL="Section" instead. Examples:

http://www.unics.uni-hannover.de/nhtcapri/multilingual1.html

http://www.unics.uni-hannover.de/nhtcapri/bidirectional-text.html

And note: Most (?) browsers don't support this kind of LINK.

--
In memoriam Alan J. Flavell

http://groups.google.com/groups/search?q=author:Alan.J.Flavell

**Stanimir Stamenkov** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

Wed, 28 May 2008 10:50:51 +0200, /Andreas Prilop/:

On Wed, 28 May 2008, Stanimir Stamenkov wrote:
>

>Subject: Indicate document fragments with <LINK rel="Bookmark">

>
And note: Most (?) browsers don't support this kind of LINK.

At least Lynx, SeaMonkey and Firefox with Link Widgets [1] extension
support it. AFAIK, IE and Safari don't support any LINKs and Opera
has very limited support, IMO.

[1] https://addons.mozilla.org/en-US/firefox/addon/2933

--
Stanimir

**Stanimir Stamenkov** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

Wed, 28 May 2008 10:50:51 +0200, /Andreas Prilop/:

On Wed, 28 May 2008, Stanimir Stamenkov wrote:
>

>I want to find out whether the following usage of the "Bookmark"
>link type is o.k. An example could be seen at
><http://www.geocities.c om/stanio/more/horoskop.html>

>
No. Use REL="Section" instead. Examples:

http://www.unics.uni-hannover.de/nhtcapri/multilingual1.html

http://www.unics.uni-hannover.de/nht...onal-text.html

I'm not convinced I should use "Section", either.
<http://www.w3.org/TR/html401/types.html#type-links>:

*Section*
Refers to a document serving as a section in a collection of
documents.

The given definition leads me to think the "Section" link gives an
URL for a document serving as starting document of a section of
documents the current one is part of. Something like:

Start
Section 1
Subsection 1.1
Subsection 1.2
Section 2
Subsection 2.1
Subsection 2.2
Subsection 2.3 (current)
Section 3
Subsection 3.1

Both "Bookmark" and "Section" definitions are equally ambiguous for
use as in-document bookmarks for me, but this may be just because
I'm not native English speaker and I can't get it right.

--
Stanimir

**Jukka K. Korpela** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

Scripsit Stanimir Stamenkov:

I've used <LINK rel="Bookmark"t o create a meta-TOC for the
document.

I think that's rather far from the intended use of rel="Bookmark", which
is rather obscure. Moreover, for most users, such <linkelements are
useless. Even if they use a browser that technically supports them, they
may not notice them or may not understand what they are for.

A simple alternative is to include a real ToC as a list of links (<a>
elements). You e.g. use CSS to make a small box on the side of the
normal content.

--
Jukka K. Korpela ("Yucca")

http://www.cs.tut.fi/~jkorpela/

**Stanimir Stamenkov** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

Thu, 29 May 2008 13:34:56 +0300, /Jukka K. Korpela/:

Scripsit Stanimir Stamenkov:
>

>I've used <LINK rel="Bookmark"t o create a meta-TOC for the
>document.

>
I think that's rather far from the intended use of rel="Bookmark", which
is rather obscure. Moreover, for most users, such <linkelements are
useless. Even if they use a browser that technically supports them, they
may not notice them or may not understand what they are for.
>
A simple alternative is to include a real ToC as a list of links (<a>
elements). You e.g. use CSS to make a small box on the side of the
normal content.

I didn't want to include a TOC in the content, but I've found such
links greatly help viewing the document in the Lynx browser -
following the link for a specific section aligns its start at the
top of the screen while if one just scrolls starting at the
beginning of the document some sections may get broken across pages
making reading of a specific section somewhat less comfortable.

--
Stanimir

**Stanimir Stamenkov** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

Thu, 29 May 2008 01:35:01 +0300, /Stanimir Stamenkov/:

Wed, 28 May 2008 10:50:51 +0200, /Andreas Prilop/:

>On Wed, 28 May 2008, Stanimir Stamenkov wrote:
>>

>>I want to find out whether the following usage of the "Bookmark"
>>link type is o.k. An example could be seen at
>><http://www.geocities.c om/stanio/more/horoskop.html>

>>
>No. Use REL="Section" instead. Examples:
> http://www.unics.uni-hannover.de/nht...ilingual1.html
> http://www.unics.uni-hannover.de/nht...onal-text.html

>
I'm not convinced I should use "Section", either.
<http://www.w3.org/TR/html401/types.html#type-links>:
>

>*Section*
> Refers to a document serving as a section in a collection of
>documents.

>
The given definition leads me to think the "Section" link gives an URL
for a document serving as starting document of a section of documents
the current one is part of.

O.k. Reading the "Chapter", "Section" and "Subsection " definitions
once more, comparing the wording to the "Contents" and seeing how
the last one is used in the HTML 4.01 specification [1] itself (the
cover page) I tend to think "document" in these definitions does not
need to be a separate document but could be just fragment in the
current one. So I'm agreeing with Andreas' suggestion, after all.

--
Stanimir

**Jukka K. Korpela** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

Scripsit Stanimir Stamenkov:

I didn't want to include a TOC in the content, but I've found such
links greatly help viewing the document in the Lynx browser -

Don't you think the great majority that does not use such browsers would
benefit from the links, too? You can achieve that simply by using links,
i.e. <aelements. If desired, you can suppress them on printing, using
simple CSS.

The <linkelement is (except for the specific use of referring to an
external stylesheet) dead for most practical purposes. It was never
properly designed (as the vagueness of the "specifications " indicates),
and browsers didn't implement it. "We asked them to implement <link>,
but they misheard it as <blink>."

--
Jukka K. Korpela ("Yucca")

http://www.cs.tut.fi/~jkorpela/

**Andy Dingley** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

On 29 May, 15:26, "Jukka K. Korpela" <jkorp...@cs.tu t.fiwrote:

Don't you think the great majority that does not use such browsers would
benefit from the links, too?

No! That's one of the key principles of the W3C's view of web design.

If it's not _harmful_ to other users who don't support a feature (and
this could include inflicting excessive volume upon them) then there's
no reason why a feature should be avoided, just because only a few can
benefit from it.

If a feature is _necessary_ to make use of a site (either navigation,
or more frequently JavaScript) then the site overall should provide
some alternative means by which to achieve the same result. This
doesn't mean quite the same thing as literal duplication of a feature
though. It's certainly not a reason to avoid features with partial
support. Note that I wrote "site" here, not "page". Alternative pages
with different approaches are a valid technique, where appropriate.

In the extreme case, this often gives rise to an "accessibil ity
ghetto" or a "print-friendly page", both of which are bogosities
perpetrated by the semi-clued. Although we wish to support the same
notions and end-results, these are rarely valid reasons to split the
"accessible " or "printable" content's implementation from the
mainstream content. The techniques of web design allow both to be
incorporated together with automatic fallbacks within the same page.

**Andreas Prilop** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

On Thu, 29 May 2008, Andy Dingley wrote:

If it's not _harmful_ to other users who don't support a feature (and

^^^ ^^^^^

this could include inflicting excessive volume upon them) then there's
no reason why a feature should be avoided, just because only a few can

^^ ^^^^^^^

benefit from it.

There are too many negations in this sentence.
I do not understand it.

Write plain English!

Thank you!

**Jukka K. Korpela** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

Scripsit Andy Dingley:

On 29 May, 15:26, "Jukka K. Korpela" <jkorp...@cs.tu t.fiwrote:
>

>Don't you think the great majority that does not use such browsers
>would benefit from the links, too?

>
No!

Are you saying that the great majority that does not use browsers that
support <link(for example, all IE users) would not benefit from links
to different parts of a page - in circumstances where links are supposed
to be useful to Lynx users?

That's one of the key principles of the W3C's view of web design.

Which one? The right one, or the wrong one?

If it's not _harmful_ to other users who don't support a feature (and
this could include inflicting excessive volume upon them) then there's
no reason why a feature should be avoided, just because only a few can
benefit from it.

I do not disagree with Andreas Prilops comment on too many negations
there. But anyway, what is really your answer to my question? Are you
saying that it is better to implement a feature in a manner that is
useful to a fraction of users only, when there is an extremely simple
and obvious manner to make it accessible to all?

In the extreme case, this often gives rise to an "accessibil ity
ghetto" or a "print-friendly page", both of which are bogosities
perpetrated by the semi-clued.

Aren't you digressing a bit? The issue was about making it possible to
access different parts of a page quickly, and there is a simple approach
that is maximally accessible (and requires no separate "print-friendly"
page).

As a rule, a page that is longer than, say, two printed pages should
have a table of content. This is essential not only to internal
navigation but also for giving a quick idea of the content of the page.
And a list of links (<aelements) is superior to all hackish or
too-theoretical alternative approaches.

--
Jukka K. Korpela ("Yucca")

http://www.cs.tut.fi/~jkorpela/

**Andy Dingley** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

On 29 May, 16:42, "Jukka K. Korpela" <jkorp...@cs.tu t.fiwrote:

Scripsit Andy Dingley:
>

On 29 May, 15:26, "Jukka K. Korpela" <jkorp...@cs.tu t.fiwrote:

>

Don't you think the great majority that does not use such browsers
would benefit from the links, too?

>

No!

>
Are you saying that the great majority that does not use browsers that
support <link(for example, all IE users) would not benefit from links
to different parts of a page - in circumstances where links are supposed
to be useful to Lynx users?

Of course not, that's what I referred to in the next para.

The point is that these techniques aren't _exclusive_. Therefore I
can use a useful technique whenever it's useful for _anyone_, without
limiting myself to only techniques that everyone can use.

If I also need to make the site usable and accessible by providing
alternatives for these users, then I should provide those
_in_addition_.

Are you
saying that it is better to implement a feature in a manner that is
useful to a fraction of users only, when there is an extremely simple
and obvious manner to make it accessible to all?

That would depend on the relative merits of each technique. If there
is an equally good and accessible technique, then by all means use it.
If there is a better and less accessible technique (i.e. <link>) then
use that. Support the platforms needing accessible methods as
necessary, but don't avoid other techniques just because not everyone
has access.

In the extreme case, this often gives rise to an "accessibil ity
ghetto" or a "print-friendly page", both of which are bogosities
perpetrated by the semi-clued.

>
Aren't you digressing a bit?

No. Merely reminding the reader that techniques can be combined on the
same page, there's no need for "shadow sites", one with and one
without. This bogus technique is popular amongst people who think it's
needed for decent printing, which is thus a familiar example.

**Ben C** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

On 2008-05-29, Andreas Prilop <prilop1234@tra shmail.netwrote :

On Thu, 29 May 2008, Andy Dingley wrote:
>

>If it's not _harmful_ to other users who don't support a feature (and

^^^ ^^^^^

>this could include inflicting excessive volume upon them) then there's
>no reason why a feature should be avoided, just because only a few can

^^ ^^^^^^^

>benefit from it.

>
There are too many negations in this sentence.
I do not understand it.

I think he means the same harmful users should be avoided if they
support a feature for a reason because that way everyone benefits.

**dorayme** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

In article
<Pine.GSO.4.63. 0805291658020.1 5248@s5b004.rrz n.uni-hannover.de>,
Andreas Prilop <prilop1234@tra shmail.netwrote :

On Thu, 29 May 2008, Andy Dingley wrote:
>

If it's not _harmful_ to other users who don't support a feature (and

^^^ ^^^^^

this could include inflicting excessive volume upon them) then there's
no reason why a feature should be avoided, just because only a few can

^^ ^^^^^^^

benefit from it.

>
There are too many negations in this sentence.
I do not understand it.
>
Write plain English!
>
Thank you!

If users who lack support are not hurt, then go for it if it benefits
others.

--
dorayme

**Sander Tekelenburg** · Jun 27 '08, 07:16 PM

Re: Indicate document fragments with <LINK rel="Bookm ark">

In article <E9A%j.8877$_03 .8750@reader1.n ews.saunalahti. fi>,
"Jukka K. Korpela" <jkorpela@cs.tu t.fiwrote:

[...]

Are you
saying that it is better to implement a feature in a manner that is
useful to a fraction of users only, when there is an extremely simple
and obvious manner to make it accessible to all?

I see nothing extremely simple or obvious about relying on users to be
able to handle everything you shove in their face. As a Web publisher
one needs to constantly balance pros and cons -- find the appropriate
threshold.

[...]

As a rule, a page that is longer than, say, two printed pages should
have a table of content. This is essential not only to internal
navigation but also for giving a quick idea of the content of the page.

For such short documents, an (inline) TOC may well confuse more users
than help them. Well chosen headings probably work much better in such a
case. User agents can list all headings, and allow the user to directly
jump to either one. iCab, for instance, does: <http://icab.de/>.

And a list of links (<aelements) is superior to all hackish or
too-theoretical alternative approaches.

Sounds way too dogmatic to me. My view is that the great majority of
sites overloads the great majority of users with content about which
they have no idea what it is, whether it is potentially useful to them,
or whether to ignore it. (Even on relatively simple/clean sites as
Google, many people aren't aware of the difference between the search
results and ads, for example.)

In general, forcing useful 'extras' upon users is likely to have the
adverse effect of what you mean to achieve.

User friendly applications try to balance this -- shove the stuff that
is likely the most useful to the most users in their face, and 'hide'
other possibilities from them.

--
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Indicate document fragments with <LINK rel="Bookmark">

Indicate document fragments with <LINK rel="Bookmark">

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment