The title attribute

Scripsit Adrienne Boswell:

If the comment is imporant enough, it should be included
either in the paragraph itself, a footnote, or end note. Example:
p>Cats are good ^{<a href="#note1" title="Jump to
note">1</a>} companions.</p
p id="note1" class="notes">1. Rolo in particular</p

Even this is questionable. First, the title attribute contains a
predicate verb - always suspicious, usually a symptom of clickhereitis.
Second, when the footnote is short, you might just as well copy it into
a title attribute if you have one, so the user does not need to follow
the link when he... er... doesn't need it: title="Note: Rolo in
particular.". Third, a superscript 1 is really small, often
unnoticeable, and hard to hit especially if you have a motoric
disability. Finally, this would create the display

Cats are good ¹ companions.

It looks odd, and if you remove the space before the superscript 1, then
it looks like associated with "good" only. Better:

Cats are good companions. [1]

More on footnotes and endnotes in HTML:
http://www.cs.tut.fi/~jkorpela/www/fn.html

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

Jukka K. Korpela <jkorpela (AT) cs (DOT) tut.fi> wrote:

More on footnotes and endnotes in HTML:
http://www.cs.tut.fi/~jkorpela/www/fn.html

I was reading (some of) that the other day in a different context.

Unfortunately, between them HTML/CSS have no adequate way of handling
such notes.

Footnotes in HTML are really endnotes, not footnotes. Footnotes in a
book appear at the bottom of the page you're reading, where your eye can
flick to them with great ease.

I loathe endnotes, they incense me. I hate having to read a book with my
fingers plugged into the back of a chapter, trying to keep track of
references while trying to follow an argument or a description. As far
as the usability of books is concerned, endnotes are an idiotic idea.

On screen, the best solution would be sidenotes, but there are plenty of
irritations and difficulties in that.

Daniele

Scripsit D.M. Procida:

Footnotes in HTML are really endnotes, not footnotes. Footnotes in a
book appear at the bottom of the page you're reading, where your eye
can flick to them with great ease.

Well, not with great ease, but easier than endnotes.

I loathe endnotes, they incense me.

It depends, but for the most of it, they're pointless. On the web, they
often work better than in a book, if you use (well, simulate) a two-way
link: the user clicks on an endnote indicator, reads the endnote, and
clicks back (if he gets the idea). And a title attribute might help in
deciding whether the note is worth reading.

On screen, the best solution would be sidenotes, but there are plenty
of irritations and difficulties in that.

Actually footnotes _would_ work, when presented in a separately
scrollable small sub-window. But frames are almost never used for such
purposes, where they might actually be useful.

Sidenotes might be even better, but indeed they are problematic in their
own way. In practice, you would end up with using a table, in a
semi-structural (or maybe fully structural) way: a column of normal
content paragraphs, and a parallel column with sidenotes or empty cells.
And you would run into difficulties when you would like to present an
endnote that is much longer than the paragraph that it is associated
with.

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

On 12/20/2007 1:47 PM, Jukka K. Korpela wrote:

Scripsit Adrienne Boswell:

If the comment is imporant enough, it should be included
either in the paragraph itself, a footnote, or end note. Example:
p>Cats are good ^{<a href="#note1" title="Jump to
note">1</a>} companions.</p
p id="note1" class="notes">1. Rolo in particular</p

Even this is questionable. First, the title attribute contains a
predicate verb - always suspicious, usually a symptom of clickhereitis.
Second, when the footnote is short, you might just as well copy it into
a title attribute if you have one, so the user does not need to follow
the link when he... er... doesn't need it: title="Note: Rolo in
particular.". Third, a superscript 1 is really small, often
unnoticeable, and hard to hit especially if you have a motoric
disability. Finally, this would create the display

Cats are good ¹ companions.

It looks odd, and if you remove the space before the superscript 1, then
it looks like associated with "good" only. Better:

Cats are good companions. [1]

More on footnotes and endnotes in HTML:
http://www.cs.tut.fi/~jkorpela/www/fn.html

For Web pages, I generally use end notes. If my page is broken into
sections, I put the end notes for a section at the end of that section,
not at the end of the page.

If there is only one note for a section, I don't use a note number.
Instead, I make a link to the note out of the content. In your example,
the entire sentence "Cats are good companions." is short enough to place
the entire sentence in the anchor.

On the other hand, see my <http://www.rossde.com/PGP/index.html>, where
the end note is at the actual end of the page and the anchor is on the
"circle-R" registered trademark symbol. There, the note applies to the
<h1></h1> content at the top of the page and thus not to any section;
therefore, it's at the bottom of the page. The note applies to the
trademark. which is why the "circle-R" is the content of the anchor.

When I have several end notes for a section, I might use *, **, ***,
etc; or I might use numbers. For an example of the latter, see the
table under <http://www.rossde.com/PGP/pgp_keyserv.html#pubserv>. In
the case of the table in my
<http://www.rossde.com/internet/Webdevelopers.html#developers>, however,
all links are to the same block of end notes; thus, there are neither
asterisks nor numbers.

Yes, end notes are annoying in a book. However, with hypertext,
navigating back and forth between the main body and the notes is less
bothersome. Another altnerative is to place all the notes on a separate
page, launching that page in a separate window or tab when the link to
the first note is selected. I do that, not for notes, but for term
definitions in my <http://www.rossde.com/internet/int_tools.html> (as
explained in the fourth, indented paragraph on that page).

What is annoying are the temporary popups (tooltips?) that appear in
some Web pages as the cursor travels over certain areas of content. At
<https://personal.vanguard.com/us/home>, select the link for "News
center" on the left (small font, below some news titles). When the News
& Media Center page is fully loaded, move your cursor over the article
titles in the center. If you happen to be reading the item on the left
and your cursor accidentally drifts over one of the titles in the
center, the popups cover what you are trying to read. While footnotes
and endnotes can be ignored, these cannot; and they are damned annoying.

--
David E. Ross
<http://www.rossde.com/>

Natural foods can be harmful: Look at all the
people who die of natural causes.

Adrienne Boswell wrote:

Gazing into my crystal ball I observed "Petr Vileta"
stoupa (AT) practisoft (DOT) cz> writing in news:fkck5o$1o2k$1 (AT) ns (DOT) felk.cvut.cz:

a name="text1" title="This is comment for text1"><p>this is
text1....</p></a> <a name="text2" title="This is comment for
text2"><p>this is text2....</p></a


[...]
2. An inline element cannot contain a block element. The a element is
inline, and p is block.
I don't know if this is in compliance with RFCxyz ;-) but this work fine in

IE, Firefox, Opera and most other browsers (exclude text like e.g. lynx). You
can put any object(s) into <a></a> tag and this <a> can be name or link type.
I mean <a name=...> or <a href=...> When you use <a name=...> then you can
define some efects for example change background color or font color or type
in a:hover section in style, or when you use <a href=..> then user can click
on link anywhere in the included block (e.g. <p> or <div>)
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your
mail from another non-spammer site please.)

Please reply to <petr AT practisoft DOT cz>

Gazing into my crystal ball I observed "Jukka K. Korpela"
<jkorpela (AT) cs (DOT) tut.fi> writing in news:KpBaj.269342$oE5.70459
@reader1.news.saunalahti.fi:

Scripsit Adrienne Boswell:

If the comment is imporant enough, it should be included
either in the paragraph itself, a footnote, or end note. Example:
p>Cats are good ^{<a href="#note1" title="Jump to
note">1</a>} companions.</p
p id="note1" class="notes">1. Rolo in particular</p

Even this is questionable. First, the title attribute contains a
predicate verb - always suspicious, usually a symptom of
clickhereitis.
Second, when the footnote is short, you might just as well copy it
into
a title attribute if you have one, so the user does not need to follow
the link when he... er... doesn't need it: title="Note: Rolo in
particular.". Third, a superscript 1 is really small, often
unnoticeable, and hard to hit especially if you have a motoric
disability. Finally, this would create the display

Cats are good ¹ companions.

It looks odd, and if you remove the space before the superscript 1,
then
it looks like associated with "good" only. Better:

Cats are good companions. [1]

More on footnotes and endnotes in HTML:
http://www.cs.tut.fi/~jkorpela/www/fn.html

I agree with you completely, Jukka. I do not use them, especially since
I tend to ignore them on paper. Thank you for the enlightening
reference.

And Rolo really IS a good companion:
http://tinyurl.com/247zcz

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

..oO(Petr Vileta)

2. An inline element cannot contain a block element. The a element is
inline, and p is block.

I don't know if this is in compliance with RFCxyz ;-)

It violates the HTML spec, which is reason enough to _not_ do it.

but this work fine in
IE, Firefox, Opera and most other browsers (exclude text like e.g. lynx).

It doesn't matter if it _might_ work or not. A bug is a bug. And if it
doesn't work in Lynx or similar browsers, it should be a hint for you
that there's something wrong. It's never a good idea to rely on the
browser's forgiveness to cater for such bugs, since the results can be
completely unpredictable if the browser has to guess what the author
might have had in mind.

For you it might be absolutely clear how <a ...><p>...</p></a> should be
interpreted, for the browser it isn't that clear at all, because there
are different ways to solve this situation. Since it violates the DTD,
the browser is not bound to any spec and has the free choice what to do
with it.

If you use such broken code and run into trouble somewhere else - good
luck to find the reason for the error.

You
can put any object(s) into <a></a> tag and this <a> can be name or link type.

Yes, as long as these "objects" are inline elements.

I mean <a name=...> or <a href=...> When you use <a name=...

<a name="..."> is only necessary for the really old browsers. If you
don't care that much about them anymore, you can apply an ID to any
arbitrary element and use that as the target instead.

Micha

On 12/21/2007 8:35 AM, Michael Fesser wrote [in part]:

Petr Vileta wrote [also in part]:
but this work fine in
IE, Firefox, Opera and most other browsers (exclude text like e.g. lynx).

It doesn't matter if it _might_ work or not. A bug is a bug.

Yes, it's a bug.

The problem then becomes: What will you do if the browser bugs are
fixed and it doesn't work anymore?

In discussions at the W3C CSS Working Group, much heat and
teeth-gnashing is going on right now because some (apparently mostly
from Micro$oft) insist they don't want future developments to break Web
pages that are buggy. Buy why are they buggy? The bugs come from two
sources. Either MS's FrontPage and Word were used to create the pages,
or else so-called professional Web developers took advantage of
non-standard "features" in IE to achieve results that were not intended
in the HTML and CSS specifications.

Do it correctly now, or suffer the cost of repairing later. Those whose
implementations of dates were initially correct had no costs or risks of
breakage from the Y2K situation.

--
David E. Ross
<http://www.rossde.com/>

Natural foods can be harmful: Look at all the
people who die of natural causes.

Michael Fesser wrote:

.oO(Petr Vileta)

2. An inline element cannot contain a block element. The a element
is inline, and p is block.

I don't know if this is in compliance with RFCxyz ;-)

It violates the HTML spec, which is reason enough to _not_ do it.

but this work fine in
IE, Firefox, Opera and most other browsers (exclude text like e.g.
lynx).

It doesn't matter if it _might_ work or not. A bug is a bug. And if it
doesn't work in Lynx or similar browsers, it should be a hint for you
that there's something wrong. It's never a good idea to rely on the
browser's forgiveness to cater for such bugs, since the results can be
completely unpredictable if the browser has to guess what the author
might have had in mind.

For you it might be absolutely clear how <a ...><p>...</p></a> should
be interpreted, for the browser it isn't that clear at all, because
there are different ways to solve this situation. Since it violates
the DTD, the browser is not bound to any spec and has the free choice
what to do with it.

I disagree with you. If this is a bug why this bug is in all browsers (except

text like)? In addition to his I can anytime define <a> as block element and
W3C CSS2 documentation say this about it:

--- CITE ---
9.2.5 The 'display' property
'display'
Value: inline | block | list-item | run-in | compact | marker | table |
inline-table | table-row-group | table-header-group | table-footer-group |
table-row | table-column-group | table-column | table-cell | table-caption |
none | inherit
Initial: inline
Applies to: all elements
Inherited: no
Percentages: N/A
Media: all
--- CITE ---

Please take attention to "Applies to: all elements" ;-) So I can define
a.block {display: block;}
and use it for my purposes I I said. Anchors defined as block element are many
time used for popup menus. Look here
http://www.cssplay.co.uk/menus/dropdownfun.html
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your
mail from another non-spammer site please.)

Please reply to <petr AT practisoft DOT cz>

Petr Vileta wrote:

I disagree with you. If this is a bug why this bug is in all browsers
(except text like)? In addition to his I can anytime define <a> as block
element and W3C CSS2 documentation say this about it:

--- CITE ---
9.2.5 The 'display' property
'display'
Value: inline | block | list-item | run-in | compact | marker | table
| inline-table | table-row-group | table-header-group |
table-footer-group | table-row | table-column-group | table-column |
table-cell | table-caption | none | inherit
Initial: inline
Applies to: all elements
Inherited: no
Percentages: N/A
Media: all
--- CITE ---

You *may style* an A element to display as block, but that does not
reverse the invalidity of placing a block element within an inline
element and also regardless of whether or not browser parse such junk.
Look at the HTML "spec" that the DTD is based on

"<!ELEMENT A - - (%inline* -(A) -- anchor -->"
^^^^^^^^^^^

http://www.w3.org/TR/html4/struct/links.html#edef-A

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com