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.com/stanio/more/horoskop.html>. The text is
in Bulgarian and is some kind of entertaining poetical horoscope.
I've used <LINK rel="Bookmark"to create a meta-TOC for the
document. Reading the definition of the "Bookmark" link type [1] in
the HTML spec I haven't actually got if I'm using it correctly.
[1] <http://www.w3.org/TR/html401/types.html#type-links>
--
Stanimir
23  2935 
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
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.com/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. 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
Scripsit Stanimir Stamenkov:
I've used <LINK rel="Bookmark"to 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/
Thu, 29 May 2008 13:34:56 +0300, /Jukka K. Korpela/:
Scripsit Stanimir Stamenkov:
>I've used <LINK rel="Bookmark"to 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
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.com/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
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/
On 29 May, 15:26, "Jukka K. Korpela" <jkorp...@cs.tut.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 "accessibility
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.
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!
Scripsit Andy Dingley:
On 29 May, 15:26, "Jukka K. Korpela" <jkorp...@cs.tut.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 "accessibility
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/
On 29 May, 16:42, "Jukka K. Korpela" <jkorp...@cs.tut.fiwrote:
Scripsit Andy Dingley:
On 29 May, 15:26, "Jukka K. Korpela" <jkorp...@cs.tut.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 "accessibility
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.
On 2008-05-29, Andreas Prilop <pr********@trashmail.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.
In article
<Pi*******************************@s5b004.rrzn.u ni-hannover.de>,
Andreas Prilop <pr********@trashmail.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
In article <E9*****************@reader1.news.saunalahti.fi> ,
"Jukka K. Korpela" <jk******@cs.tut.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/>
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
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 "metainformation", 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/
In article <Td*****************@reader1.news.saunalahti.fi> ,
"Jukka K. Korpela" <jk******@cs.tut.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/>
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 <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
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/
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 <in******************@reader1.news.saunalahti.fi >,
"Jukka K. Korpela" <jk******@cs.tut.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/>
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/
In article <Il******************@reader1.news.saunalahti.fi >,
"Jukka K. Korpela" <jk******@cs.tut.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/> This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: FAQ server |
last post by:
-----------------------------------------------------------------------
FAQ Topic - I have <a href="javascript:somefunction()"what ... ?...
|
by: matheussousuke |
last post by:
Hello, I'm using tiny MCE plugin on my oscommerce and it is inserting my website URL when I use insert image function in the emails.
The goal is: Make it send the email with the URL...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
