By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,709 Members | 1,650 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,709 IT Pros & Developers. It's quick & easy.

Footnote style

P: n/a
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
Sep 26 '05 #1
Share this Question
Share on Google+
55 Replies


P: n/a
James A. Donald wrote:
In a book, a footnote is presented at the bottom of the page, in a
slightly smaller type. <snip> 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.
Yes, that is bad. Use CSS.
How have other people solved this problem?


Try this:

span.footnote { float: right; font-size: 85%; }

<p>This is a paragraph of content<sup>1</sup>... blah blah
<span class="footnote">1. Footnote goes here.</span>
blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah</p>

--
-bts
-When motorcycling, never follow a pig truck
Sep 26 '05 #2

P: n/a
--
On Mon, 26 Sep 2005 03:53:45 GMT, "Beauregard T. Shagnasty"
Try this:

span.footnote { float: right; font-size: 85%; }

<p>This is a paragraph of content<sup>1</sup>... blah blah
<span class="footnote">1. Footnote goes here.</span>
blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah</p>


That is very helpful, but what I really wanted to ask is, is this a
good idea - is this how other people solve the problem of footnotes,
rather than how do other people get an appropriate font-size for a
footnote.

--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
QIvDtZsFGJNItifRrlh50rxKN941WQUBPyNqVvqw
4ZIhDsWRAq1v4LOmAYo3UfrWzyMhg4EwNPooqIIlU
--
http://www.jim.com
Sep 26 '05 #3

P: n/a
James A. Donald wrote:
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.


You can _not_ specify the main font and specify a _percentage_
of whatever that size happens to be for the footnotes.

Footnotes can mostly be avoided on the web by giving each its
own little .html file, linked to by the main exposition. No
need to clutter the page. Let the _reader_ decide whether it
will come up as a replacement page, a new tab, or a popup.

You could try a separate column, but that limits how large the
visitor can make the text of the main exposition, and the
footnote column is likely to have large amounts of unused space
in it.

Besides, the web itself is largely interlinked notes that
reference each other. What's important over here is just a
footnote to someone over there. Relativity of relevance rules.
You're denying visitors the ability to easily bookmark just the
footnote. You can use real footnotes, but it seems quaint and
outdated.
--
mbstevens
http://www.mbstevens.com/

Sep 26 '05 #4

P: n/a
Tim
On Sun, 25 Sep 2005 20:38:54 -0700, James A. Donald sent:
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.


Standard warning about smaller fonts on a low resolution device (i.e. just
about all VDUs) being hard to read not withstanding, have you not heard of
the small element?

e.g. <p>Normal text <small>with a bit smaller text</small>.</p>

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

Sep 26 '05 #5

P: n/a
James A. Donald wrote:
Html does not have any equivalent of a slightly smaller font


<small>...</small>

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Sep 26 '05 #6

P: n/a
In message <6q********************************@4ax.com>, James A. Donald
<ja****@echeque.com> writes
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


I've recently been converting a hundred-or-so articles from 40-year-old
journals for a local historical/archaeological society.

The first thing that I took into account is that not everyone is going
to be able to 'see' the pages; some will 'hear' them, some will 'feel'
them.

The concept of using a superscript number, therefore, wasn't going to be
sufficient (you're going to need good ears to hear a numeral suddenly
appearing out of a maze of words).

So, let's take a (fictitious) example.

"...... and was consistent as the elevation suggested1. (The '1' being
superscript in the printed version.)

I tended to code this as:

"........ and was consistent as the elevation suggested. <a
href="#References"><span class="hideit>See reference</span> [1].</a>

The sighted user would see:
"...... and was consistent as the elevation suggested.[1].

(With [1] coloured and underlined as a link, as per convention.)

The non-sighted user would hear:
"...... and was consistent as the elevation suggested. See reference 1.

'See reference 1' would be spoken in a 'links' voice, and would also
appear in that form if the user asked for a 'list of links'.

The footnotes were grouped at the end of the page under a suitable
heading.
E.g. <h2>REFRERENCES.</h2> which could be accessed easily if a user
switches to 'headings navigation' mode.

I experimented with putting hidden 'return' links at the end of each
individual reference in the list, but found the amount of work didn't
(at the time) justify it.

I'm not sure I have the best solution -- but it seems to work.

Regards.

--
Jake (ja**@gododdin.demon.co.uk -- just a 'spam trap' mail address)
Sep 26 '05 #7

P: n/a
On Mon, 26 Sep 2005 04:59:48 GMT, mbstevens
Besides, the web itself is largely interlinked notes that
reference each other. What's important over here is just a
footnote to someone over there. Relativity of relevance rules.
You're denying visitors the ability to easily bookmark just the
footnote. You can use real footnotes, but it seems quaint and
outdated.


So you are arguing that when a book is adapted to this medium,
footnotes should become links. And if the user wants to see a link in
context, he (not I) should pop it up.
--
http://www.jim.com
Sep 26 '05 #8

P: n/a
James A. Donald
How have other people solved this problem?

Jake I've recently been converting a hundred-or-so articles from 40-year-old
journals for a local historical/archaeological society.

The first thing that I took into account is that not everyone is going
to be able to 'see' the pages; some will 'hear' them, some will 'feel'
them.

The concept of using a superscript number, therefore, wasn't going to be
sufficient (you're going to need good ears to hear a numeral suddenly
appearing out of a maze of words).

So, let's take a (fictitious) example.

"...... and was consistent as the elevation suggested1. (The '1' being
superscript in the printed version.)

I tended to code this as:

"........ and was consistent as the elevation suggested. <a
href="#References"><span class="hideit>See reference</span> [1].</a>
I assume the css code for your span class "hideit" is
span.hideit {
height : 0;
width : 0;
overflow : hidden;
position : absolute;
}

But there is a risk some browsers will display the "See reference"

The sighted user would see:
"...... and was consistent as the elevation suggested.[1].

(With [1] coloured and underlined as a link, as per convention.)

The non-sighted user would hear:
"...... and was consistent as the elevation suggested. See reference 1.

'See reference 1' would be spoken in a 'links' voice, and would also
appear in that form if the user asked for a 'list of links'.

The footnotes were grouped at the end of the page under a suitable
heading.
E.g. <h2>REFRERENCES.</h2> which could be accessed easily if a user
switches to 'headings navigation' mode.

I experimented with putting hidden 'return' links at the end of each
individual reference in the list, but found the amount of work didn't
(at the time) justify it.


In my case the footnotes are obviously intended to be read in context,
so I suppose I should put in a back reference, but indeed it seems too
much work - user can use the back arrow in his browser. We should not
unnecessarily duplicate the capabilities already built into the web.

--
http://www.jim.com
Sep 26 '05 #9

P: n/a
On Mon, 26 Sep 2005, James A. Donald wrote:
So you are arguing that when a book is adapted to this medium,
footnotes should become links. And if the user wants to see a link
in context, he (not I) should pop it up.


This may be a difference between marginal notes, and footnotes in the
strict sense of the term. Some books have both. Some books even have
three categories - marginal notes, notes at the foot of each page, and
supplementary notes at the back (not including the literature
references! Four?).

At least, with a decent web browser, the user has the option to open
additional resources in a separate window or tab, at their discretion
and convenience. I'm not keen on the author trying to second-guess
how I'd want to browse, although I'm well aware of the regular chorus
of "but, but, readers don't know how to use their browsers". Well, if
that's what the chorus think, why aren't they helping their readers to
learn?

all the best
Sep 26 '05 #10

P: n/a

James A. Donald wrote:
On Mon, 26 Sep 2005 04:59:48 GMT, mbstevens
Besides, the web itself is largely interlinked notes that
reference each other. What's important over here is just a
footnote to someone over there. Relativity of relevance rules.
You're denying visitors the ability to easily bookmark just the
footnote. You can use real footnotes, but it seems quaint and
outdated.


So you are arguing that when a book is adapted to this medium,
footnotes should become links. And if the user wants to see a link in
context, he (not I) should pop it up.


You could combine two solutions (compare blogs, with recent articles on
the front page but also accessible by "permalink").

As far as one system goes, my favorite as a reader is to put everything
on one page, with links to anchors. This will not work if the document
is so long that just rendering it takes a long time. This makes the
document easily downloadable, easily printable.

Sometimes I will read a text, and then read through the footnotes once
I am done with the text. It would help me if the footnotes were
together in sequence and backlinked to the text. As before, this need
not be the unique system; it could be combined with popups,
one-footnote-per-page, or whatever.

Sep 26 '05 #11

P: n/a
James A. Donald wrote:
In a book, a footnote is presented at the bottom of the page, in a
slightly smaller type. 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?


This page illustrates the way I do it .....

http://jp29.org/adc1938.htm

...... I do not worry about footnote (or gloss) text size when I write
for the Web.

Sep 26 '05 #12

P: n/a
In message <b4********************************@4ax.com>, James A. Donald
<ja****@echeque.com> writes
James A. Donald
> How have other people solved this problem?
Jake
I've recently been converting a hundred-or-so articles from 40-year-old
journals for a local historical/archaeological society.

The first thing that I took into account is that not everyone is going
to be able to 'see' the pages; some will 'hear' them, some will 'feel'
them.

The concept of using a superscript number, therefore, wasn't going to be
sufficient (you're going to need good ears to hear a numeral suddenly
appearing out of a maze of words).

So, let's take a (fictitious) example.

"...... and was consistent as the elevation suggested1. (The '1' being
superscript in the printed version.)

I tended to code this as:

"........ and was consistent as the elevation suggested. <a
href="#References"><span class="hideit>See reference</span> [1].</a>
I assume the css code for your span class "hideit" is
span.hideit {
height : 0;
width : 0;
overflow : hidden;
position : absolute;
}


Something similar .... one of many methods of using CSS to hide text
from a CSS-enabled browser (or repositioning the text 1000 px away from
the viewport is another) while still allowing an Assistive Technology UA
to announce it.
But there is a risk some browsers will display the "See reference"
Only in browsers without a CSS capability; and in those cases it really
doesn't matter much anyway IMO.
The sighted user would see:
"...... and was consistent as the elevation suggested.[1].

(With [1] coloured and underlined as a link, as per convention.)

The non-sighted user would hear:
"...... and was consistent as the elevation suggested. See reference 1.

'See reference 1' would be spoken in a 'links' voice, and would also
appear in that form if the user asked for a 'list of links'.

The footnotes were grouped at the end of the page under a suitable
heading.
E.g. <h2>REFRERENCES.</h2> which could be accessed easily if a user
switches to 'headings navigation' mode.

I experimented with putting hidden 'return' links at the end of each
individual reference in the list, but found the amount of work didn't
(at the time) justify it.


In my case the footnotes are obviously intended to be read in context,
so I suppose I should put in a back reference, but indeed it seems too
much work - user can use the back arrow in his browser. We should not
unnecessarily duplicate the capabilities already built into the web.

That's OK if the footnotes aren't grouped at the end of the page under a
general 'References' heading.

I guess that using a user-requested pop-up window is another way of
handling footnotes?

Regards.
--
http://www.jim.com


--
Jake (ja**@gododdin.demon.co.uk -- just a 'spam trap' mail address)
Sep 26 '05 #13

P: n/a
James Pickering wrote:
James A. Donald wrote:
In a book, a footnote is presented at the bottom of the page, in a
slightly smaller type.

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?


This page illustrates the way I do it .....

http://jp29.org/adc1938.htm

..... I do not worry about footnote (or gloss) text size when I write
for the Web.


Here is another example page:

http://jp29.org/blackhawk.htm

Sep 26 '05 #14

P: n/a
On Mon, 26 Sep 2005 03:53:45 GMT in
comp.infosystems.www.authoring.html, Beauregard T. Shagnasty favored
us with...
James A. Donald wrote:
In a book, a footnote is presented at the bottom of the page, in a
slightly smaller type.

<snip>
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.


Yes, that is bad. Use CSS.


Why is <small> not deprecated, I wonder?

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you
Sep 26 '05 #15

P: n/a
Stan Brown wrote:
On Mon, 26 Sep 2005 03:53:45 GMT in
comp.infosystems.www.authoring.html, Beauregard T. Shagnasty favored
us with...
Yes, that is bad. Use CSS.


Why is <small> not deprecated, I wonder?


I wonder that myself...

--
-bts
-When motorcycling, never follow a pig truck
Sep 26 '05 #16

P: n/a
On Mon, 26 Sep 2005, Stan Brown wrote:
Why is <small> not deprecated, I wonder?


It is indeed a strange oversight that HTML has no
de-emphasis markup as such, and we have to make do
with something overtly presentational instead.

Sep 26 '05 #17

P: n/a
James A. Donald wrote:
So you are arguing that when a book is adapted to this medium,
footnotes should become links.
A link, certainly.
And if the user wants to see a link in
context, he (not I) should pop it up.


"pop it up"?

There are a number of ways to present such notes. A couple I've
used are (a long time ago - in a long-outdated article)
http://www.webthing.com/tutorials/login.html and (more recently)
the margin-notes implementation in the articles at
http://www.apachetutor.org/ . Feel free to use any of those
techniques you think appropriate.

--
Nick Kew
Sep 26 '05 #18

P: n/a
On Mon, 26 Sep 2005 16:20:17 +0100, in
comp.infosystems.www.authoring.html , "Alan J. Flavell"
<fl*****@ph.gla.ac.uk> in
<Pi******************************@ppepc56.ph.gla.a c.uk> wrote:
On Mon, 26 Sep 2005, James A. Donald wrote:
So you are arguing that when a book is adapted to this medium,
footnotes should become links. And if the user wants to see a link
in context, he (not I) should pop it up.
This may be a difference between marginal notes, and footnotes in the
strict sense of the term. Some books have both. Some books even have
three categories - marginal notes, notes at the foot of each page, and
supplementary notes at the back (not including the literature
references! Four?).


ISTM that footnotes et. al. are an attempt to make a static medium
hypertexted. This is what web pages were set up to deal with and is
exactly the kind of thing you change when putting paper material on
the web Questions of small font or italic entirely miss the point.
Those little numbers are links to other information, they should be
hypertext links.
At least, with a decent web browser, the user has the option to open
additional resources in a separate window or tab, at their discretion
and convenience. I'm not keen on the author trying to second-guess
how I'd want to browse, although I'm well aware of the regular chorus
of "but, but, readers don't know how to use their browsers". Well, if
that's what the chorus think, why aren't they helping their readers to
learn?


Again, where the other information is opened is not the point, the
point is that you go from one set of info to the related set.

--
Matt Silberstein

Do something today about the Darfur Genocide

Genocide is news | Be A Witness
http://www.beawitness.org

"Darfur: A Genocide We can Stop"
www.darfurgenocide.org

Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
Sep 26 '05 #19

P: n/a
--
James A. Donald wrote:
So you are arguing that when a book is adapted to
this medium, footnotes should become links. And if
the user wants to see a link in context, he (not I)
should pop it up.

Constantinople: You could combine two solutions (compare blogs, with
recent articles on the front page but also accessible
by "permalink").

As far as one system goes, my favorite as a reader is
to put everything on one page, with links to anchors.
This will not work if the document is so long that
just rendering it takes a long time. This makes the
document easily downloadable, easily printable.


This is a long document, so has to be translated to a
tree with the leaves of the tree in a doubly linked
list, hence not easily downloadable or printable.

I am coming to the view that the document should be
divided into natural units, each a fair bit longer than
a single screenful of html, with footnotes etc on the
bottom of these natural units in slightly smaller print,
as if they were pages and footnotes in the original
(though they will each correspond to roughly two or
three pages of original printed text on average) with
clickable links that move you to the footnote, or back
from the footnote to the text. Since the original is a
classic, it is worth staying as faithful to the original
as is reasonable in a new and different medium.

This however means that many of these natural units will
have several footnotes, which is bad, while the original
exercised great care to ration footnotes to one per
page. Perhaps this is more acceptable when footnote
backlinks are enabled.

--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
Y1KIMDPY2VBfRfrvvU+lBK9RUZ5nz+0jyh+Gi+LU
4en5qcVl+feyduhbgn5BrzF5vLpayVGzMCQuRGhAW
--
http://www.jim.com
Sep 26 '05 #20

P: n/a
"Alan J. Flavell"
This may be a difference between marginal notes, and footnotes in the
strict sense of the term. Some books have both. Some books even have
three categories - marginal notes, notes at the foot of each page, and
supplementary notes at the back (not including the literature
references! Four?).

At least, with a decent web browser, the user has the option to open
additional resources in a separate window or tab, at their discretion
and convenience.


I was proposing to convert footnotes into marginal notes.

Several people seem to be suggesting that I make them into
supplementary notes at the back, and provide a link that the user can
open.

--
http://www.jim.com
Sep 26 '05 #21

P: n/a
On 26 Sep 2005 09:10:56 -0700, "James Pickering" <jp**@cox.net> wrote:
This page illustrates the way I do it .....

http://jp29.org/adc1938.htm

..... I do not worry about footnote (or gloss) text size when I write
for the Web.


Here is another example page:

http://jp29.org/blackhawk.htm


This seems a straightforward reproduction of the standard
printed matter approach - page with footnotes, rather
than an adaptation to a new medium.

--
http://www.jim.com
Sep 26 '05 #22

P: n/a
James A. Donald wrote:
--
James A. Donald wrote: This is a long document, so has to be translated to a
tree with the leaves of the tree in a doubly linked
list, hence not easily downloadable or printable.

I am coming to the view that the document should be
divided into natural units, each a fair bit longer than
a single screenful of html, with footnotes etc on the
bottom of these natural units in slightly smaller print,
as if they were pages and footnotes in the original
(though they will each correspond to roughly two or
three pages of original printed text on average) with
clickable links that move you to the footnote, or back
from the footnote to the text. Since the original is a
classic, it is worth staying as faithful to the original
as is reasonable in a new and different medium.

This however means that many of these natural units will
have several footnotes, which is bad, while the original
exercised great care to ration footnotes to one per
page. Perhaps this is more acceptable when footnote
backlinks are enabled.


We deal with this matter all the time, categorising such supplementary
and qualifying material as footnotes, endnotes and commentaries
(explanatory)

Whether the work is for print or screen, conceptually it is paged,
sectionised and chaptered.

If the reader of a printed work is directed to supplementary
information, he can rapidly cast his eye to the bottom of the page, or
bookmarked Section, Chapter and/or Work Endnote pages, holding his place
with his finger if necessary.

Web pages have a very different character.

Not only are they of indeterminate length depending on the Reader's
equipment but there seems no way to provide a foot with notes and
commentaries that can be positioned on the screen so that it not only
relates to the passage being read, but does not display superfluous
material.

If the notes or commentaries are placed as footers in a web page this
involves scrolling or linking to and back to the applicable note. Such
schema tends to be confusing and distracting to the Reader. It is less
easy for the reader to mark his place once there is movement of the body
of the text/table/graph

Broadly our practise is:

Place notes and commentaries into a database. (their collection,
management and updating being a major considerations also.)

Provide Section and Chapter Endnote web pages that are print friendly.

Enable the Reader, as he wishes, to activate a superscripted link
selecting the detail of the note or commentary and displaying it below
the passage; Notes and Commentaries can be differentiated by font and
background colors. (A major advantage that web pages have over printed
pages are that they are expandable. There is not the same constraint on
the length of the commentary.)

Provide on each web page a link to applicable Section and Chapter
Endnote web pages. All Notes and Commentaries are displayed in one or
other of the Endnote Pages. (Notes and Commentaries may not be unique to
a Section or Chapter Endnote page)

Louise
Sep 27 '05 #23

P: n/a
"James A. Donald" wrote:

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?


I am not really consistent in how I do this. Usually, I use
footnotes at the end of a section within a page; but other times, I
use endnotes at the bottom of the page.

Sometimes, I have a superscript as a link to the note (see the
table in my
<URL:http://www.rossde.com/PGP/pgp_keyserv.html#pubserv>); but
sometimes, I merely put the link on a key word or phrase (see first
line under "Solutions" in my
<URL:http://www.rossde.com/editorials/edtl_2ndamend.html>). This
latter is also used extensively for the Bible at
<URL:http://bible.ort.org/books/pentd2.asp>. With hyper-linking,
numbered footnotes or endnotes are not really necessary.

I use the following class to reduce the font size:
.ftnote { font-size: 85% }
Usually, this is on a paragraph: <p class=ftnote>. However, if I
have several notes, I use it on a division: <div class=ftnote> . .
.. </div> with paragraphs within it. Anyone having trouble reading
the small text usually knows how to make it larger.

I would strongly recommend placing the notes on a separate page.
This leads to launching a new window for those who don't used
tabbed browsing. Even launching a new tab unexpectedly can be
annoying. For pages that have very extensive notes, the user can
always choose to launch a new window or tab.

The most important thing to remember about footnotes and endnotes
is that the main text should be readable and understandable without
them. They merely add to the main text, often by providing
references to other texts. If they indeed refer to other texts
that are also Web pages, you might instead make the links to those
pages and omit the intervening notes.

--

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

I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.
Sep 27 '05 #24

P: n/a
James A. Donald wrote:
On Mon, 26 Sep 2005 04:59:48 GMT, mbstevens
Besides, the web itself is largely interlinked notes that
reference each other. What's important over here is just a
footnote to someone over there. Relativity of relevance rules.
You're denying visitors the ability to easily bookmark just the
footnote. You can use real footnotes, but it seems quaint and
outdated.

So you are arguing that when a book is adapted to this medium,
footnotes should become links. And if the user wants to see a link in
context, he (not I) should pop it up.

The user's preferences of how her browser should work has a lot
to do with it.

I'm a tab guy. I may have several tabs of the same page I'm
reading across the top of my browser (and, I often work from the
Fluxbox window manager which tabs all kinds of otherwise diverse
content together).

Others like popups. They set their browser to open new content
in a new window, and just close the window when they're finished
with it. This is the default behavior in, e.g., the newest
Gnome desktop (to the chagrin of many).

Still others prefer to just replace the content in the present
window with the new content, and just use their back-arrow to
return.

But on the web, I think that the thing that works most flexibly
is to err on the side of lots of .html pages. This does not
limit the grouping of content. But it does allow all kinds of
visitors to have their lap dance sitting in their favorite
chair. A single page well linked internally will do, too. But
if it is a large page then the visitor may have to wait a long
while for an item at page bottom to load. This occasionally
irritates me about the w3c's website, although I can appreciate
their interest in having a single huge document file for ease of
upkeep. I'll take lots of pages, thank you very much.
Sep 27 '05 #25

P: n/a
> On 26 Sep 2005 09:10:56 -0700, "James Pickering" <jp**@cox.net> wrote:
Here is another example page:

http://jp29.org/blackhawk.htm


One data point, FWIW:

I found this page rather irritating -- there are little bracketed
numbers apparently intended to be footnotes, but when I click on them
nothing happens.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you
Sep 27 '05 #26

P: n/a
Stan Brown wrote:
On 26 Sep 2005 09:10:56 -0700, "James Pickering" <jp**@cox.net> wrote:
Here is another example page:

http://jp29.org/blackhawk.htm


One data point, FWIW:

I found this page rather irritating -- there are little bracketed
numbers apparently intended to be footnotes, but when I click on them
nothing happens.


Oops, wrong page loaded -- I have now loaded the one I intended:

http://jp29.org/blackhawk.htm

Thanks for the feedback.

James Pickering

Sep 27 '05 #27

P: n/a
JRS: In article <8f****************@newsread2.news.pas.earthlink.n et>,
dated Mon, 26 Sep 2005 04:59:48, seen in news:comp.infosystems.www.autho
ring.html, mbstevens <NO***********@xmbstevensx.com> posted :

Footnotes can mostly be avoided on the web by giving each its
own little .html file, linked to by the main exposition. No
need to clutter the page. Let the _reader_ decide whether it
will come up as a replacement page, a new tab, or a popup.


If the OP wishes to be considerate of those without a permanent Net
link, who may want to save pages for reading later, he would do well to
avoid links to separate documents for footnotes.

ISTM that footnotes, in <small> or using CSS, could well go at the end
of the present logical section; either a paragraph or the next size up.
Alternatively, in side-boxes.

End-of-chapter-grade notes might well go at end-of-page.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Sep 27 '05 #28

P: n/a
boclair
Broadly our practise is:

Place notes and commentaries into a database. (their collection,
management and updating being a major considerations also.)

Provide Section and Chapter Endnote web pages that are print friendly.

Enable the Reader, as he wishes, to activate a superscripted link
selecting the detail of the note or commentary and displaying it below
the passage; Notes and Commentaries can be differentiated by font and
background colors. (A major advantage that web pages have over printed
pages are that they are expandable. There is not the same constraint on
the length of the commentary.)

Provide on each web page a link to applicable Section and Chapter
Endnote web pages. All Notes and Commentaries are displayed in one or
other of the Endnote Pages. (Notes and Commentaries may not be unique to
a Section or Chapter Endnote page)


Unfortunately, you write in a dialect with which I am not familiar,
and your POV is unstable, sliding between the client side page seen by
the end reader, and the constructs such as database entries and
categories seen by the author. (End reader does not grasp the
difference between a note and a commentary)

If I follow you, you say that the footnotes should appear to the user
at the end of section, or in some similarly appropriate place so that
the document makes sense when printed, but when viewed on screen, the
reader should access footnotes by clicking on the link.

--
http://www.jim.com
Sep 27 '05 #29

P: n/a

James A. Donald wrote:
In a book, a footnote is presented at the bottom of the page, in a
slightly smaller type.


One thing I've appreciated lately is the way isohunt presents its info,
as hidden window-within-a-window that slides or folds open and shut in
place. It works well for me as a metaphor for uncovering detail and
practically as a way to avoid having to juggle multiple simultaneous
windows, to avoid obscuring the main material with a popup window, and
to access detail without jumping. Google mail does something similar
with its conversations, which I also like, expanding them in place. Of
course it may not work at all for notes and it may impose too many
restrictions on the user end, but I've liked that sort of thing where
I've seen it. (Google groups and mail quote folding is another example,
more useful with the "top posting" style common in email since it hides
context.)

Sep 27 '05 #30

P: n/a
--
On 27 Sep 2005 12:08:43 -0700, co*************@gmail.com
wrote:
One thing I've appreciated lately is the way isohunt
presents its info, as hidden window-within-a-window
that slides or folds open and shut in place. It works
well for me as a metaphor for uncovering detail and
practically as a way to avoid having to juggle
multiple simultaneous windows, to avoid obscuring the
main material with a popup window, and to access
detail without jumping. Google mail does something
similar with its conversations, which I also like,
expanding them in place.


That can be done with client side javascript, but it is
not what people ordinarily expect. People expect
documents to quietly sit there doing nothing. When
faced with a dynamic document, they like it, but it
takes them a little while to get used to it.

--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
idwFFOoIdWBeRvct/kuckoZj3Varp2fCP9hzNstB
4zzGvkTidenBOle1a91rvtQEe5Tp7fiZNkrG+SRcU
--
http://www.jim.com
Sep 27 '05 #31

P: n/a
James A. Donald wrote:
boclair
Broadly our practise is:

Place notes and commentaries into a database. (their collection,
management and updating being a major considerations also.)

Provide Section and Chapter Endnote web pages that are print friendly.

Enable the Reader, as he wishes, to activate a superscripted link
selecting the detail of the note or commentary and displaying it below
the passage; Notes and Commentaries can be differentiated by font and
background colors. (A major advantage that web pages have over printed
pages are that they are expandable. There is not the same constraint on
the length of the commentary.)

Provide on each web page a link to applicable Section and Chapter
Endnote web pages. All Notes and Commentaries are displayed in one or
other of the Endnote Pages. (Notes and Commentaries may not be unique to
a Section or Chapter Endnote page)

Unfortunately, you write in a dialect with which I am not familiar,
and your POV is unstable, sliding between the client side page seen by
the end reader, and the constructs such as database entries and
categories seen by the author. (End reader does not grasp the
difference between a note and a commentary)

If I follow you, you say that the footnotes should appear to the user
at the end of section, or in some similarly appropriate place so that
the document makes sense when printed, but when viewed on screen, the
reader should access footnotes by clicking on the link.


Please don't think I am advising you or anybody. I was only outlining
our practice.

The difference between a note (we don't actually use the footnote
terminology; they go under the name, cites) and a commentary is simply;
a note cites something; a commentary is an authors explanatory passage
or aside. The category is apparent in the content.

The reader gets a normal marked up web page made up on the server. All
that happens is that having selected a note he is served an rewritten
page with the note detail displayed in a logical place.

We have found that it is necessary to openly display all cites and
commentaries somewhere other than the content web page. It is not
adequate to only display them on demand and hid them if not demanded.
They are fully listed and detailed in Section and Chapter Endnote web
pages that can be reached from links on each of the content web pages.

We have also found that it is useful to make the Endnote pages printer
friendly. For some material the reader may well need
to have open as he reads the cited references be it on tabbed windows,
other machines or hard copy.

Lastly, serious printed material and web material cannot be mixed in our
experience. Little more than the content is common. If it is produced
for the screen it is for the screen and, apart from limited
circumstances, not for the printer; and vice versa. Perhaps CSS will do
something better in the future for the printer media but it is very
basic at the moment. (and just fitting-to-size is no where near the end
of the need)

Louise

Sep 28 '05 #32

P: n/a
Stan Brown wrote:
Why is <small> not deprecated, I wonder?


<big>, <small>, <b> and <i> just aren't, for no apparent reason. I can see
an argument for keeping <small> (to counter-balance <strong>), but the
rest should have been deprecated.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Sep 28 '05 #33

P: n/a
JRS: In article <2j************@ophelia.g5n.co.uk>, dated Wed, 28 Sep
2005 08:33:22, seen in news:comp.infosystems.www.authoring.html, Toby
Inkster <us**********@tobyinkster.co.uk> posted :
Stan Brown wrote:
Why is <small> not deprecated, I wonder?


<big>, <small>, <b> and <i> just aren't, for no apparent reason. I can see
an argument for keeping <small> (to counter-balance <strong>), but the
rest should have been deprecated.


The counterbalance to <strong> should be <weak>, and the implementation
to make the characters either a colour intermediate between ordinary
text and background, or using thinner lines; <small> & <big>
counterbalance.

In some fields, there is an established convention, dating from before
computers, for the use of italic and bold in print-on-paper.

Authors in those fields should be able to specify bold and italic - it
is part of the meaning, not just decoration. HTML was introduced for
technical work; although use is now predominantly commercial / amateur,
the technical capability should be preserved.

A really good browser would by default display <b> and <i> as truly bold
and italic, with <em> and <strong> defaulting to be perceptibly
different; and the representations should be user-configurable, not
necessarily by CSS.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Sep 28 '05 #34

P: n/a
Dr John Stockton <jr*@merlyn.demon.co.uk> wrote:
The counterbalance to <strong> should be <weak>, and the implementation
to make the characters either a colour intermediate between ordinary
text and background, or using thinner lines;
Maybe. And definitely with a simple browser function to turn the
presentation to normal text and back. There's no point in keeping the text
barely readable once the user has decided to read it. The _point_ in using
small font size, or grey text, or something like that is to make the text
look less important by making it look kess readable.
A really good browser would by default display <b> and <i> as truly
bold and italic, with <em> and <strong> defaulting to be perceptibly
different;


I tend to agree. And the good browser, when working in nonvisual mode or
otherwise incapable of bolding or italicizing, would say "bold" and "end
bolding", "italics" and "end italics", since it could not possibly guess
what meaning, if any, the typographic features carry.

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

Sep 29 '05 #35

P: n/a
On Wed, 28 Sep 2005 08:33:22 +0100, Toby Inkster
<us**********@tobyinkster.co.uk> wrote:
Stan Brown wrote:
Why is <small> not deprecated, I wonder?


<big>, <small>, <b> and <i> just aren't, for no apparent reason. I can see
an argument for keeping <small> (to counter-balance <strong>), but the
rest should have been deprecated.


No. There is, for example, a convention that scientific names in
biological texts are written in italics. The correct markup for this is
<I>. It would be wrong to use <EM> because it is not a form of emphasis
and browsers are not required to emphasise text by using italics.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/
Sep 29 '05 #36

P: n/a
On Thu, 29 Sep 2005, Stephen Poley wrote:
No. There is, for example, a convention that scientific names in
biological texts are written in italics.
Yes...
The correct markup for this is <I>.
Given HTML as we currently have it, the correct markup for this is
presumably <i class="something">, to distinguish it from other
typographic conventions where <i> would be the correct markup.

I might have said <i class="species">, but then someone is sure to
leap up and say that class names have NO definitive value, and could
just as well be class="N42" for all that HTML cares. Which is as true
as it's unhelpful, I think.
It would be wrong to use <EM> because it is not a form of emphasis


Fully agreed.

However, if we go along with the *philosophy* of HTML, but not limited
by its current definition, then we'd presumably need a <species>
markup, to make this unambiguous. And <stanza> for verse, and so on.

I think one of the hopes of XML was that XHTML-like markups would
evolve for different topic fields, and browsers (thanks to
stylesheets) would get suggestions on how to render them. I don't see
a great deal of movement in that area, out in the field yet, despite
the enthusiastic use of XML internally in a lot of machine-to-machine
communications.

best regards
Sep 29 '05 #37

P: n/a
JRS: In article <2j************@ophelia.g5n.co.uk>, dated Wed, 28 Sep
2005 08:33:22, seen in news:comp.infosystems.www.authoring.html, Toby
Inkster <us**********@tobyinkster.co.uk> posted :
Stan Brown wrote:
Why is <small> not deprecated, I wonder?


<big>, <small>, <b> and <i> just aren't, for no apparent reason. I can see
an argument for keeping <small> (to counter-balance <strong>), but the
rest should have been deprecated.


I've now seen another reason for using <i> (which would apply to <b> and
<big>, <small> too) --- in quoted material, in which it is appropriate
to reproduce the original form without wondering whether in using
italics the originator really meant <strong> or <em> or whatever.

Since the material is specified by the Acts of 1751, the originator is
not available for consultation.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Oct 1 '05 #38

P: n/a
Stephen Poley wrote:
There is, for example, a convention that scientific names in biological
texts are written in italics.
True.
The correct markup for this is <I>.


Some might argue that.

I would argue that current versions of HTML contain *no* semantically
correct element for marking up species names. As such, I would continue
that <I> and <SPAN CLASS="species"> (with appropriate CSS) are equally
correct substitutes. The former has better backwards-compatibility; the
latter will be more useful for automated processing; one can get the best
of both worlds with <I CLASS="species">.

See also: my recent message to the www-html mailing list:

Date: Mon, 29 Aug 2005 07:16:14 +0000
Subject: Re: XHTML2: Proposal for total separation of semantics from
structure
Message-Id: <1125229466.2500.29.camel[at]ophelia.g5n.co.uk>

http://www.w3.org/mid/11************...elia.g5n.co.uk
--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Oct 6 '05 #39

P: n/a
Dr John Stockton wrote:
I've now seen another reason for using <i> (which would apply to <b> and
<big>, <small> too) --- in quoted material, in which it is appropriate
to reproduce the original form without wondering whether in using
italics the originator really meant <strong> or <em> or whatever.


So if I'm quoting some material which was originally in pink,

<FONT COLOR=PINK>...</FONT>

is OK?

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Oct 6 '05 #40

P: n/a
On Thu, 06 Oct 2005 11:53:22 +0100, Toby Inkster
<us**********@tobyinkster.co.uk> wrote:
I would argue that current versions of HTML contain *no* semantically
correct element for marking up species names.


Nor should it. That would be far too application-specific (look at
DocBook for an example of this run riot).

However <i> and <b> do have sufficient semantic meaning in their own
right to be maintained. There are plenty of instances where <i> or <b>
have as much implied meaning in particular application contexts as
<blockquote> or even <p>.

--
Cats have nine lives, which is why they rarely post to Usenet.
Oct 20 '05 #41

P: n/a
On Sat, 1 Oct 2005 16:57:04 +0100, Dr John Stockton
<jr*@merlyn.demon.co.uk> wrote:
I've now seen another reason for using <i> (which would apply to <b> and
<big>, <small> too) --- in quoted material,


So why not use <q> or <blockquote> ?
Oct 20 '05 #42

P: n/a
Andy Dingley <di*****@codesmiths.com> wrote:
On Thu, 06 Oct 2005 11:53:22 +0100, Toby Inkster
<us**********@tobyinkster.co.uk> wrote:
I would argue that current versions of HTML contain *no* semantically
correct element for marking up species names.
Nor should it. That would be far too application-specific


Things that appear frequently in newspapers (at least on science pages)
aren't really application-specific.
However <i> and <b> do have sufficient semantic meaning in their own
right to be maintained.
Their semantics is "italics" and "bold", respectively. Nothing more,
nothing less. We don't know from the markup whether it is essential or not,
i.e. whether a browser that cannot (or simply won't) use italics should
render "<i>foo</i>" as something like "italics; foo; end of italics"
or as "foo".
There are plenty of instances where <i> or <b>
have as much implied meaning in particular application contexts as
<blockquote> or even <p>.


Anything can have implied meaning, so that's no excuse for using <i> or
<b>.

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

Oct 20 '05 #43

P: n/a
JRS: In article <p2********************************@4ax.com>, dated
Thu, 20 Oct 2005 12:33:30, seen in news:comp.infosystems.www.authoring.h
tml, Andy Dingley <di*****@codesmiths.com> posted :
On Sat, 1 Oct 2005 16:57:04 +0100, Dr John Stockton
<jr*@merlyn.demon.co.uk> wrote:
I've now seen another reason for using <i> (which would apply to <b> and
<big>, <small> too) --- in quoted material,


So why not use <q> or <blockquote> ?


You failed to quote, or to consider the full implications of,
Since the material is specified by the Acts of 1751, the originator is
not available for consultation.


and to consider the implications of "in quoted material", particularly
the use of "in" rather than "around". In the text, only date-related
words are in italics.

The Calendar Acts of ~1751 specify that certain material should go into
the Book of Common Prayer, and it is the BCP which I was quoting.

<blockquote> is utterly inappropriate for words in the middle of a
sentence, and <q> was not known to any reference that I had to hand, or
to my IE4; a book I'm now reading does have it, but its effect (quote-
marks) is inappropriate and the book says that it does not work in IE6.

Presumably such as <span style="font-style:italic">Sunday</span>, or
with a Class, would do; but it seems bloated.

See <URL:http://www.merlyn.demon.co.uk/estrdate.htm#31>, or the front of
a BCP, page headed TABLES AND RULES.

If parts of the original material are printed in italics, then using <i>
is suitable when quoting it.

--
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>.
Oct 20 '05 #44

P: n/a
On Thu, 20 Oct 2005 22:07:57 +0100, Dr John Stockton
<jr*@merlyn.demon.co.uk> wrote:
<blockquote> is utterly inappropriate for words in the middle of a
sentence,
Agreed. That's why it's called a "block" quote
and <q> was not known to any reference that I had to hand


Then you need better references
http://www.w3.org/TR/html4/struct/text.html#edef-Q
Oct 20 '05 #45

P: n/a
On Thu, 20 Oct 2005 16:40:32 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:
Things that appear frequently in newspapers (at least on science pages)
aren't really application-specific.


If that's the criterion, then we'd also need to extend HTML markup for
sports, politics and breast size.
However <i> and <b> do have sufficient semantic meaning in their own
right to be maintained.


Their semantics is "italics" and "bold", respectively. Nothing more,
nothing less.


And that in itself is sufficient. That's my point exactly - "italics"
and "bold" have an accepted semantic value of themselves. We don't need
to go as far as to explain it (that gets too context dependent) but we
should honour it and preserve the annotation as such.

Oct 21 '05 #46

P: n/a
On Fri, 21 Oct 2005, Andy Dingley wrote:
And that in itself is sufficient. That's my point exactly -
"italics" and "bold" have an accepted semantic value of themselves.
We don't need to go as far as to explain it (that gets too context
dependent) but we should honour it and preserve the annotation as
such.


That may depend on whether one is authoring some content for which one
takes responsibility (and thus is personally aware of the reason for
the typographical choice), or - along the lines which JRS was
evidently dealing with - one is trying to render into an HTML format
some existing typography which was produced by someone else, whom one
can no longer question about their intentions.

OK: in some cases the reason for the choice of typography may be
obvious, and an appropriate HTML markup (where one exists) can be
used, e.g <cite> or <em> or <var> or whatever instead of mere <i>.

(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.)
Oct 21 '05 #47

P: n/a
Andy Dingley <di*****@codesmiths.com> wrote:
On Thu, 20 Oct 2005 16:40:32 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:
Things that appear frequently in newspapers (at least on science pages)
aren't really application-specific.
If that's the criterion, then we'd also need to extend HTML markup for
sports, politics and breast size.


Of course we should, if text about them contains specific repeating
constructs that have a particular meaning that is potentially useful in
automated processing of data. It would be very nice if, for example,
political texts would adequately use markup elements like <bullshit>.
However, people who write such texts aren't probably interested in making
the structure of their texts expressed in markup. Scientists and
popularizers of science might, and since they use some markup for species
names already if they write correctly, what's wrong with the idea of using
_meaningful_ markup?
Their semantics is "italics" and "bold", respectively. Nothing more,
nothing less.


And that in itself is sufficient.


For the purposes of simplistic rendering. Nothing else.
That's my point exactly - "italics"
and "bold" have an accepted semantic value of themselves.
No, they don't. If they had, you would have written them down, instead of
just claiming existence.
We don't need
to go as far as to explain it (that gets too context dependent) but we
should honour it and preserve the annotation as such.


"Context dependent" is just a way of expressing ignorance here. They could
mean anything (or nothing). The idea of semantic markup is to express
meanings, not to think about the potential existence of some varying
meaning.

In particular, if semantics is guessed, as people and software often do -
browsers that cannot display italics may use some method they can use to
express _emphasis_, based on the blind assumption that italics means
emphasis - the results are simply wrong for scientific names. Writing them
in italics does not mean emphasis of any kind.

People often search for information using scientific names, especially if
they are interested in images, so that the language of documents does not
matter. The reason is that it is common to mention species by their
scientific name, no matter what your language is. This would be even more
effective, if scientific names were marked up and search engines supported
them, so that you could search for, say, occurrences of the word "Pan" (the
genus name of chimpanzees) in scientific names, as opposite to finding
88 million pages containing the word "pan" in general.

Maybe it's far too late for semantic markup for things like scientific
names. But don't say the need doesn't exist.

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

Oct 21 '05 #48

P: n/a
On Fri, 21 Oct 2005, Andy Dingley wrote:
If that's the criterion, then we'd also need to extend HTML markup for
sports, politics and breast size.


We already have <BIG>, no? Even <BIG><BIG> is possible. ;-)

--
Netscape 3.04 does everything I need, and it's utterly reliable.
Why should I switch? Peter T. Daniels in <news:sci.lang>

Oct 21 '05 #49

P: n/a
JRS: In article <sb********************************@4ax.com>, dated
Fri, 21 Oct 2005 00:35:05, seen in news:comp.infosystems.www.authoring.h
tml, Andy Dingley <di*****@codesmiths.com> posted :
On Thu, 20 Oct 2005 22:07:57 +0100, Dr John Stockton
<jr*@merlyn.demon.co.uk> wrote:
<blockquote> is utterly inappropriate for words in the middle of a
sentence,


Agreed. That's why it's called a "block" quote
and <q> was not known to any reference that I had to hand


Then you need better references
http://www.w3.org/TR/html4/struct/text.html#edef-Q


I don't use anything that my browser does not understand; and using
something (believed to be) not known to IE6 would be even more
unreasonable.

--
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>.
Oct 21 '05 #50

55 Replies

This discussion thread is closed

Replies have been disabled for this discussion.