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

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 "metainformation", it's already there when you have used
heading elements properly. The <link> thing 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

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 <a> and 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 <link> elements, which is what the discussion is about. It
cannot, since <link> markup 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/

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.

In article <inf0k.10069$_03.5546 (AT) reader1 (DOT) news.saunalahti.fi>,
"Jukka K. Korpela" <jkorpela (AT) cs (DOT) tut.fi> wrote:

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 <a> and 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 <link> elements, 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/>

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 <a> element, you hide
it from most visitors.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

In article <IlT0k.10950$_03.3936 (AT) reader1 (DOT) news.saunalahti.fi>,
"Jukka K. Korpela" <jkorpela (AT) cs (DOT) tut.fi> wrote:

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 <a> element, 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/>