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

[Stanimir Stamenkov]

Re: Indicate document fragments with &lt;LINK rel=&quot;Bookm ark&quot;&gt;

Sat, 31 May 2008 09:28:11 +0300, /Jukka K. Korpela/:

No. That's like saying that a book can contain a ToC that is visible
only when viewing with special glasses, because anyone who would benefit
from a ToC can be assumed to have acquired such glasses.

O.k. Because I've noticed you often require real examples, in this
case I've decided not to put a TOC in the content because I've
actually copied it from a Word document which a wanted to replicate
in HTML. I've just wanted to enhance it with HTML meta-info without
bothering the original content.

--
Stanimir

[Jukka K. Korpela]

Re: Indicate document fragments with &lt;LINK rel=&quot;Bookm ark&quot;&gt;

Scripsit Stanimir Stamenkov:

Sat, 31 May 2008 09:28:11 +0300, /Jukka K. Korpela/:
>

>No. That's like saying that a book can contain a ToC that is visible
>only when viewing with special glasses, because anyone who would
>benefit from a ToC can be assumed to have acquired such glasses.

>
O.k. Because I've noticed you often require real examples,

Well, generally anyone who asks a question needs to specify what the
question is really about, or to give "the real example", to get an
answer that is useful for that purpose.

in this
case I've decided not to put a TOC in the content because I've
actually copied it from a Word document which a wanted to replicate
in HTML.

What kind of a reason is that? If the HTML document serves a purpose,
its structure should be decided on the basis of that purpose, not its
origin, or the format from which it was converted.

I've just wanted to enhance it with HTML meta-info without
bothering the original content.

Everything I wrote applies quite independently of this additional
description. In fact, an HTML document needs a ToC more than a Word
document does, since for a well-written document (which uses heading
styles properly), a Word user can get the ToC if he knows how to do that
and quite a few users know it.

Regarding "metainformatio n", it's already there when you have used
heading elements properly. The <linkthing adds very little to that in
practice, but a real ToC is actually useful.

--
Jukka K. Korpela ("Yucca")

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

[Sander Tekelenburg]

Re: Indicate document fragments with &lt;LINK rel=&quot;Bookm ark&quot;&gt;

In article <Td60k.9832$_03 .4305@reader1.n ews.saunalahti. fi>,
"Jukka K. Korpela" <jkorpela@cs.tu t.fiwrote:

Scripsit Sander Tekelenburg:
>

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

If they would, wouldn't they be using a browser that supports <link>
by now?

>
No. That's like saying that a book can contain a ToC that is visible
only when viewing with special glasses, because anyone who would benefit
from a ToC can be assumed to have acquired such glasses.

TV broadcasts in colour are only available to those who use a colour TV,
but still work fine for those who use a greyscale one, to whom the extra
information is 'hidden'.

[...]

If you compare a web page to a book, then <headmight
correspond to the cover pages. But a ToC of a book is in the contents
part, where it belongs.

I thought the thread was about single documents of a mere two pages or
longer. I don't see how a comparison to books applies.

[...]

Duplication of content is not wrong when done properly. [...]
For a well-organized non-fiction non-ad page (and for many fiction and
ad pages too), a ToC is a crucial key to understanding the scope,
purpose, and structure of the page.

That's far less dogmatic than you sounded earlier. We might actually
agree then -- I too think that in certain situations the pros of an
in-<bodyTOC certainly outweigh the cons.

Note that a no-nonsense ToC, implemented using <aand lists, can easily
be made hierarchic as needed and presented with indentations that
indicate the section, subsection, etc., structure.

Right. That's how iCab presents headings.

[Some background info: I'm generally of the opinion than, when possible,
it is far more useful to solve problems on the UA end, than to have each
and every individual Web publisher come up with their own unique
solution. Solving problems in the UA provides end users with far more
consistency and thus ease of use.
Similarly, Web publishers tend to concentrate on 'hip' stuff and forget
about basics, like good headings.]

[... <link>]

Being an empty element,
it suffers from the fundamental design flaw of hiding data in
attributes.

I'm not aware of strong arguments against 'hiding' certain data. Calling
it "hiding" even obscures the argument, given that it is entirely
dependant upon the UA (as chosen and configured by the user), what data
is in fact hidden and what is not, never mind just *how* hidden.

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

[Stanimir Stamenkov]

Re: Indicate document fragments with &lt;LINK rel=&quot;Bookm ark&quot;&gt;

Sat, 31 May 2008 16:39:40 +0300, /Jukka K. Korpela/:

Scripsit Stanimir Stamenkov:
>

>in this
>case I've decided not to put a TOC in the content because I've
>actually copied it from a Word document which a wanted to replicate
>in HTML.

>
What kind of a reason is that? If the HTML document serves a purpose,
its structure should be decided on the basis of that purpose, not its
origin, or the format from which it was converted.

The original Word document serves its purpose without having
in-content TOC - that's my rationale. A user may have only a Word
viewer which I'm not sure is capable of presenting the document map,
but I don't really know that.

>I've just wanted to enhance it with HTML meta-info without
>bothering the original content.

>

[...]

Regarding "metainformatio n", it's already there when you have used
heading elements properly. The <linkthing adds very little to that in
practice, but a real ToC is actually useful.

Regarding the headings information already marked up I've once
filled an enhancement request for the Mozilla's Link Toolbar [1].
Because I haven't found similar support in browsers I've decided to
put the extra redundant(?) links as meta information, which could be
used by whoever can. And of course when I write bigger document I
surely include a TOC in its contents.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=202958

--
Stanimir

[Jukka K. Korpela]

Re: Indicate document fragments with &lt;LINK rel=&quot;Bookm ark&quot;&gt;

Scripsit Sander Tekelenburg:

TV broadcasts in colour are only available to those who use a colour
TV, but still work fine for those who use a greyscale one, to whom
the extra information is 'hidden'.

It sounds like you never watched TV programs on a black and white TV
when the broadcasts were in color.

I thought the thread was about single documents of a mere two pages or
longer. I don't see how a comparison to books applies.

A book compares to a web page: it is a single document, though books are
generally longer.

>Note that a no-nonsense ToC, implemented using <aand lists, can
>easily be made hierarchic as needed and presented with indentations
>that indicate the section, subsection, etc., structure.

>
Right. That's how iCab presents headings.

But not <linkelements , which is what the discussion is about. It
cannot, since <linkmarkup cannot express a hierarchy. Neither can it
express section names properly, in general, since no internal markup is
possible there.

I'm not aware of strong arguments against 'hiding' certain data.

Data in attributes is a design flaw that would not have been made if
HTML had really been based on SGML (principles and techniques). To begin
with, when you start putting data, e.g. just a section name, in an
attribute value, you immediately restrict yourself to using plain text
there.

--
Jukka K. Korpela ("Yucca")

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

[Ed Mullen]

Re: Indicate document fragments with &lt;LINK rel=&quot;Bookm ark&quot;&gt;

Jukka K. Korpela wrote:

Scripsit Sander Tekelenburg:
>

>TV broadcasts in colour are only available to those who use a colour
>TV, but still work fine for those who use a greyscale one, to whom
>the extra information is 'hidden'.

>
It sounds like you never watched TV programs on a black and white TV
when the broadcasts were in color.

What is your point with this comment?

--
Ed Mullen

http://edmullen.net

In some cultures what I do would be considered normal.

[Sander Tekelenburg]

Re: Indicate document fragments with &lt;LINK rel=&quot;Bookm ark&quot;&gt;

In article <inf0k.10069$_0 3.5546@reader1. news.saunalahti .fi>,
"Jukka K. Korpela" <jkorpela@cs.tu t.fiwrote:

Scripsit Sander Tekelenburg:

[...]

It sounds like you never watched TV programs on a black and white TV
when the broadcasts were in color.

I did, actuallly. Although I don't see what your point is.

I thought the thread was about single documents of a mere two pages or
longer. I don't see how a comparison to books applies.

>
A book compares to a web page: it is a single document, though books are
generally longer.

Yeah, length was my point.

Note that a no-nonsense ToC, implemented using <aand lists, can
easily be made hierarchic as needed and presented with indentations
that indicate the section, subsection, etc., structure.

Right. That's how iCab presents headings.

>
But not <linkelements , which is what the discussion is about.

No. The discussion is about whether and how to provide a TOC for
shortish single documents. One argument I provided against adding a TOC,
in certain situations, is that well chosen headings, which authors
should bother to provide anyway, can function as a TOC. I gave iCab's
handling of headings as an example, to show that this is practice, not
mere abstract theory. (Not to mention that users can quickly scroll
through documents to scan all headings.)

[...]

I'm not aware of strong arguments against 'hiding' certain data.

>
Data in attributes is a design flaw that would not have been made if
HTML had really been based on SGML (principles and techniques). To begin
with, when you start putting data, e.g. just a section name, in an
attribute value, you immediately restrict yourself to using plain text
there.

True. That's one of the reasons I've argued for killing @alt:
<http://esw.w3.org/topic/HTML/ABetterAlt>. But I don't see how this has
anything to do with "hiding". Exactly what is hidden how?

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

[Jukka K. Korpela]

Re: Indicate document fragments with &lt;LINK rel=&quot;Bookm ark&quot;&gt;

Scripsit Sander Tekelenburg:

The discussion is about whether and how to provide a TOC for
shortish single documents.

That might be _your_ definition of topic, but the discussion has been
general, not limited to "shortish" documents.

(Not to mention that users can
quickly scroll through documents to scan all headings.)

If the page is longer than fits on screen at a time, then the user
normally needs to do something to scan all headings, e.g. to press the
Page Down key as many times as needed (and many people do things in a
clumsier way, like using the mouse).

But I don't see how this [data in attributes]
has anything to do with "hiding". Exactly what is hidden how?

When you e.g. put a section name into a title="..." attribute of <link>,
as opposite to putting it into the content of an <aelement, you hide
it from most visitors.

--
Jukka K. Korpela ("Yucca")

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

[Sander Tekelenburg]

Re: Indicate document fragments with &lt;LINK rel=&quot;Bookm ark&quot;&gt;

In article <IlT0k.10950$_0 3.3936@reader1. news.saunalahti .fi>,
"Jukka K. Korpela" <jkorpela@cs.tu t.fiwrote:

Scripsit Sander Tekelenburg:
>

The discussion is about whether and how to provide a TOC for
shortish single documents.

>
That might be _your_ definition of topic, but the discussion has been
general, not limited to "shortish" documents.

The OP asked about single documents, to which you added a threshold of
"two printed pages".

[...]

But I don't see how this [data in attributes]
has anything to do with "hiding". Exactly what is hidden how?

>
When you e.g. put a section name into a title="..." attribute of <link>,
as opposite to putting it into the content of an <aelement, you hide
it from most visitors.

That's not hiding. That's leaving it up to the user what is presented
(and how). Just like anything else in Web pages (consider ad blockers,
pop-up blockers, javascript blockers, etc.).

Yes, today it probably means a majority of users won't even know that
data is available. But that's because of the UAs they use. Not because
Web publishers actively hide data from users, as you seem to be saying.
Web publishers do not have such power. Only users do, whether they make
use of that or not.

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