Footnote style

[James A. Donald]

In a book, a footnote is presented at the bottom of the page, in a
slightly smaller type.

converting a book to html, pages are bottomless, so we can put the
footnote in a separate link, or create a footnote div class that
floats right.

Links are probably what the author would have used had he been writing
in html, but divs that float right are closer to the spirit of the
original work, and enables the footnote to be seen in context, as was
originally intended.

Html does not have any equivalent of a slightly smaller font - to get
a slightly smaller font we would have to specify the fonts of the main
document and also the font of the footnote class, which is bad.

How have other people solved this problem?

--
http://www.jim.com

[Alan J. Flavell]

On Fri, 21 Oct 2005, Dr John Stockton wrote:

I don't use anything that my browser does not understand;
Why ever not? Appropriate treatment of non-understood markup has been
codified ever since RFC1866. HTML4 isn't exactly new.

There are arguable reasons for not using <q>, but the mere fact that
you found a browser that doesn't support HTML4 is no justification for
not using HTML4.
and using something (believed to be) not known to IE6 would be even
more unreasonable.

On the contrary. IE disqualifies itself as a web-compatible browser on
quite a number of points, but its failure to support, for example,
<abbr> is no excuse for not marking up abbreviations with the
appropriate markup, which is <abbr>. IE does not come to any
additional harm than if the markup were not present; but competent web
clients can do useful things with that markup.

[Jukka K. Korpela]

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

There are arguable reasons for not using <q>, but the mere fact that
you found a browser that doesn't support HTML4 is no justification for
not using HTML4.
I would say that in this very case, it is, if the browser is commonly used
(or, for that matter, used by any considerable amount of people).

and using something (believed to be) not known to IE6 would be even
more unreasonable.

On the contrary. IE disqualifies itself as a web-compatible browser on
quite a number of points, but its failure to support, for example,
<abbr> is no excuse for not marking up abbreviations with the
appropriate markup, which is <abbr>.

Regarding <q>, the failure _is_ significant. The reason is that a
document's fundamental meaning may be changed if <q> tags are ignored,
just as it may be changed if quotation marks are removed.

Consider a paragraph that contains some direct quotation. In principle,
the W3C tells us*) to use <q> markup for inline quotes, though the W3C
itself doesn't do so. Suppose that we have text like the following: Joe
said: <q>Some words by Joe.</q> Here the text goes on. Now, if the browser
ignores the <q> markup, how do you know where the quotation ended,
i.e. what was Joe's words?

*) Clause 3.7 says in WCAG 1.0, at
http://www.w3.org/TR/WCAG10/#gl-structure-presentation
says: "Mark up quotations", and adds: "in HTML, use the Q and BLOCKQUOTE
elements to markup short and longer quotations".
Yet, W3C pages that violate this requirement carry the "WCAG 1.0" icon
claiming compliance to this guideline, among others. (For example, at
present, the W3C main page contains an inline quotation with no markup
but with ASCII quotation marks as delimiters.)
IE does not come to any additional harm than if the [<abbr>] markup were
not present; but competent web clients can do useful things with that
markup.

As well as harmful things, such as changing the font properties (as
suggested in the CSS2 specification, though luckily not implemented in any
browser) or underlining the abbreviation with a cryptic dotted line, even
in print media. Sadly enough, we see few if any useful things done with
<abbr> (using the title attribute's value in nonvisual rendering might be
an asset sometimes, if such values were generally useful). Part of this
is its inadequate definition. What is an abbreviation? ("HTML", "radar",
"e.g.", "Mr.", "kg", and "NaCl" might all be called abbreviations, but many
people and even organizations would disagree on this for some of them.)

The <abbr> markup has already been spoiled by inadequate definitions in the
specification as well as wrong implementations.
In that sense, IE6's ignorance is no argument against it.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Alan J. Flavell]

On Sat, 22 Oct 2005, Jukka K. Korpela wrote:

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

There are arguable reasons for not using <q>, but the mere fact that
you found a browser that doesn't support HTML4 is no justification for
not using HTML4.
I would say that in this very case, it is,

But you're disagreeing with the wrong point. I already said that
there are "arguable reasons for not using <q>".
Regarding <q>, the failure _is_ significant.
Yes, it is. But the reason for not using it is - because it was not
designed for graceful fallback.
The reason is that a document's fundamental meaning may be changed
if <q> tags are ignored, just as it may be changed if quotation
marks are removed.
Exactly. As I said, that is no justification for refusing to use, for
example, the <abbr> markup when it is the right one.
Consider a paragraph that contains some direct quotation.
Yes, yes, we agree that <q> doesn't work in that sense. What I was
arguing with was JRS's claim that he would never use an HTML4 markup
which isn't supported by his own browser. That is plain wrong, for
markups which do no other harm.

I normally avoid using <q> - but I avoid it because it's badly
designed, *even though* it's supported by "my own" browser.

IE does not come to any additional harm than if the [<abbr>]
markup were not present; but competent web clients can do useful
things with that markup.

As well as harmful things, such as changing the font properties (as
suggested in the CSS2 specification, though luckily not implemented
in any browser) or underlining the abbreviation with a cryptic
dotted line,

Yes, I modify the visual presentation of <abbr> elements, to call
attention to the associated title= attribute which I use to gloss the
abbreviation.
even in print media.

If I provided a separate print stylesheet, I could turn that off. None
of this detail is an argument against the general principle of using
<abbr> when it is the appropriate markup. Or any other well-defined
HTML markups which happen to be unsupported by one or other browser.

<q> is a rogue design, in terms of its fallback behaviour - we can
agree about that. There's a specific reason for not using it. But it
doesn't support the /general/ reason which JRS was promoting - and
which I am opposing.

best

[Dr John Stockton]

JRS: In article <Pi*******************************@ppepc56.ph.gla. ac.uk

, dated Sat, 22 Oct 2005 00:40:21, seen in news:comp.infosystems.www.au thoring.html, Alan J. Flavell <fl*****@ph.gla.ac.uk> posted :On Fri, 21 Oct 2005, Dr John Stockton wrote:

I don't use anything that my browser does not understand;
Why ever not? Appropriate treatment of non-understood markup has been
codified ever since RFC1866. HTML4 isn't exactly new.

Because if my browser does not understand it, I have no convenient way
of seeing whether it does what I want. Yesterday morning, I knew what
<q> is for; but the book is back in the library.

However, what I wrote was too strong; I do have <label> on some pages.
But I don't use, for getting an effect that I want to observe, anything
that my browser will not show me.
There are arguable reasons for not using <q>, but the mere fact that
you found a browser that doesn't support HTML4 is no justification for
not using HTML4.

and using something (believed to be) not known to IE6 would be even
more unreasonable.

On the contrary. IE disqualifies itself as a web-compatible browser on
quite a number of points, but its failure to support, for example,
<abbr> is no excuse for not marking up abbreviations with the
appropriate markup, which is <abbr>. IE does not come to any
additional harm than if the markup were not present; but competent web
clients can do useful things with that markup.

I don't write for W3, I write for people to read; therefore I'm not
concerned with IE's omissions, as long as it does what I want to do.
Possibly I could improve my pages by having forms which communicate
their contents externally, or by using Java, or by adding features
requiring other browsers ... . But I see no added value sufficient to
justify the effort.

IE *is* a Web-compatible browser, because such a high proportion of Web
users actually use IE, and such a high proportion of authors design for
IE, and perhaps for IE only. I can believe that it's not W3-compatible,
though.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
The Big-8 newsgroup management is attempting to legitimise its questionable
practices while retaining its elitist hegemony. Read <URL:news:news.groups>.

[Michael Stemper]

In article <Pi*******************************@ppepc56.ph.gla. ac.uk>, Alan J. Flavell writes:

(Mind you, I caught myself using <tt> far too liberally instead of
making a proper choice of <kbd>, <code> etc. when writing some
documentation yesterday. Must go back and re-do that when I get a
spare moment.)

Maybe you can clarify something. I've never been clear on the difference
in meaning between <kbd> and <code>, possibly since I use a keyboard to
type my code. How does on decide which element is more appropriate for a
given situation?

--
Michael F. Stemper
#include <Standard_Disclaimer>
"Writing about jazz is like dancing about architecture" - Thelonious Monk

[Jukka K. Korpela]

ms******@siemens-emis.com (Michael Stemper) wrote:

Maybe you can clarify something. I've never been clear on the difference
in meaning between <kbd> and <code>, possibly since I use a keyboard to
type my code. How does on decide which element is more appropriate for a
given situation?

May I?

<kbd> means keyboard input. This can be natural language text, arbitrary
characters, or computer code. You could use it e.g. in an instruction like
Type <kbd>foobar</kbd> into the Search box.

<code> means computer code, and I guess we can interpret this liberally:
it could be program source code, markup, style sheet, or command, for
example. You could use it when discussing code, e.g.:
You can use the <code>line-height</code> property in CSS to affect the
spacing between lines.

Sometimes it would be logical to use both markup for a piece of text.
I don't think there's any guideline on the way of nesting (i.e., which one
should be inner). Example:
Remember to finish your session with the <kbd><code>logout</code></kbd>
command.

There's usually no default difference between rendering of <kbd>, <code>,
and <tt>. You can _make_ a difference in CSS if you like. For example, you
could use different monospace fonts, or different colors, or just a little
reduced font size for <code>. Don't overdo such styling, though.

Some automatic translators (for human languages like English) recognize
<code> markup and leave its content unchanged - which is what you would
surely want if your text about CSS, for example, were translated from
English to French.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html