Critique of homepage - as per request.
Tina Marie Holmboe
The last two days have seen a couple of very interesting letters reaching
my *personal* mailbox. In the last one, I was challenged. I quote:
"Yes, please. I'd kindly ask you to go to c.i.w.a.h. and publish a
critique of your own home page. With the markup flaws we've just
discovered (improper use of ALT, use of CITE for a block level
element, link markup). I believe all your readers will really enjoy
this. You may even not credit me, I don't mind."
- Dmitry Kirsanov (d...@symbol.ru)
Of course I'll credit you, for seeing that I should use BLOCKQUOTE
instead of CITE, that my ALT-texts are not to your liking, and that the
© entity doesn't appear as a copyright symbol when viewed with Lynx
by a Russian. I'll also credit you for the rest. But firstly, I would
like to perform such a critique of my homepage.
Url-in-question: http://www.elfi.adbkons.se/%7Etina/
'Bobby': load time at 14.400 = 12.95 seconds. Total size 24Kb. 4
warnings, all for disability access. Background images can make the text hard
to read; and tables are not always rendered correctly.
'KGV' : 2 errors due to use of ", one unclosed <P>
'WebTech' : 1 error: unclosed <P>.
Using Lynx, the page appears readable, even though the quote in the middle
seem to become abit heaped together, and it is rather hard to figure out.
This is probably due to the use of a table for layout-purposes.
As is usual, and no doubt prompting Mr. Kirsanov to claim he was right,
I am not going to touch the actual design of the page. I will, however,
touch upon this point:
'I would like you to finally realize that professionalism is not
about checking a page against a specification. It's about making
pages that are perfect for the target audience. As one designer
has put it, "it took me one day to learn HTML and the whole life
to learn design."'
- Dmitry Kirsanov (d...@symbol.ru)
It is obvious that the entire point of 'purism' in relation to HTML
markup has not sunk in. The reason why a HTML page should conform to a
given standard is that you cannot, *CANNOT*, predict the equipment or
circumstances in which a reader may access your page.
To claim that it is possible is still folly. 'Purism' in HTML is a
pragmatic view of the world. We, as HTML authors, don't know how our pages
will be read, viewed, listened to, or printed. The only way to ensure against
failure is therefore to mark up a document as honest as possible. That is
'purism' - or "How to ensure that the information gets trough".
The designer that learned HTML in one day is producing pages that look
accordingly.
And Mr. Kirsanov ? No, I won't 'calm down'. I'll go on being annoying and
irritating. Further, I am not going along with any 'deal'.
'Either you publish a bitter complaint about this case of HTML
abuse by W3C, or you stop trying to criticize *my* pages in
any public media. Deal?'
- Dmitry Kirsanov (d...@symbol.ru)
Final note. Since Mr. Kirsanov managed to not only attempt the above,
but also challenged me to write - in ciwah - a critique of my own homepage,
I claim the 'fair use' clause, as well as his own comment about 'giving
credit' in order to defend my quoting of his letter.
Think of that what you will.
--
Tina Marie Holmboe / http://www.ifi.uio.no/%7Etina/ /
/ ti...@elfi.adbkons.se/%7Etina/ /
'When correctly viewed, Everything is lewd.
(I could tell you things about Peter Pan,
And the Wizard of Oz, there's a dirty old man!)' - Tom Lehrer
Alan J. Flavell
On 6 Feb 1997, Tina Marie Holmboe wrote:
(quoting a report that the)
> © entity doesn't appear as a copyright symbol when viewed with Lynx
> by a Russian.
This is a technical fault in the reader's setup. HTML standards require
that numbered entities be interpreted according to the ISO-8859-1
character set. If a browser/platform fails to do that, it's not the
HTML author's fault. If your informant has evidence of a fault in Lynx,
he should report it: as far as I understand it, the Lynx folks take a
pride in proper interpretation of the HTML standards.
Tao
I just took a look at your web page, Tina, and the best thing I can say
about it is that it is simple and efficient. It has all the charm of a
typewritten letter on blue stationary. Obviously, you have spared no
effort to utilize the full potential of the Web.
While it is technically fine, you really should run your text through a
spell checker.
On your "About the Author" page alone, I spotted the following spelling
errors:
comerce
althought (twice)
litterature
sofar
thats (twice)
caligraphy
parttime (twice).
Your photo loads very quickly, but I would strongly suggest you choose
another pose - perhaps you might even consider smiling? Your current
photo bears an uncanny resemblance to "Fraiser's" ex-wife, Lilith. Then
again after seeing the photo of your boyfriend, Jorgen, I can understand
why you're not smiling. (O.J. Simpson looks happier in his mug shot then
this guy does in that photo.)
Tina Marie Holmboe
[Thu, 06 Feb 1997 14:04:29] [Alan J. Flavell]
> This is a technical fault in the reader's setup. HTML standards require
> that numbered entities be interpreted according to the ISO-8859-1
> character set. If a browser/platform fails to do that, it's not the
> HTML author's fault. If your informant has evidence of a fault in Lynx,
> he should report it: as far as I understand it, the Lynx folks take a
> pride in proper interpretation of the HTML standards.
Oh, but Alan, I am *so* sorry - but you are wrong. See, here is the
*correct* answer, directly from the source:
"Fortunately, NONE of them does. Otherwise our life would be too
hard, since 99% of Russian-language pages do NOT specify their
charset in any formal way. You may dislike it if you wish but
that's so. No browser I know of forces any particular charset;
they just use whatever font I tell them to use. If you're after
strict standard conformance, you may be right; but if you're
after usability, you'd better avoid anything but 7 bit ASCII.
And *YOU* should be aware of this."
- Dmitry Kirsanov (d...@symbol.ru)
So sorry. Not. I *LOVE* my mailfilter !!!!
--
Tina Marie Holmboe
Unless explicitly stated otherwise, the / ti...@htmlhelp.com /
opinions expressed are mine, and should / http://www.htmlhelp.com/%7Etina/ /
in no way be associated with the WDG. / The Web Design Group /
Dmitry Kirsanov
Dearest Tina,
I am really pleased to see that you have responded positively to,
how you called it, my "challenge." Overall, your self-critique is
satisfactory (and, I believe, instructive to the readers of this
group). However, there are points I'd like to comment on, and in
some points your account needs just a little bit of expansion and
clarification.
> "Yes, please. I'd kindly ask you to go to c.i.w.a.h. and publish a
> critique of your own home page. With the markup flaws we've just
> discovered (improper use of ALT, use of CITE for a block level
> element, link markup). I believe all your readers will really enjoy
> this. You may even not credit me, I don't mind."
In view of the recent discussion of proper use of <BLOCKQUOTE>, it
is very interesting to see an example of an appropriately formatted
quotation, even though it's in the ASCII media.
> Of course I'll credit you, for seeing that I should use BLOCKQUOTE
> instead of CITE,
CITE was used for a quoted poem stanza between two paragraphs. No
doubt this requires a block level element, which CITE has never
been.
> that my ALT-texts are not to your liking,
In Lynx, the first line on your page reads:
"Tina Marie Holmboe This page is..."
Is this nice to *your* liking?
> and that the
> © entity doesn't appear as a copyright symbol when viewed with Lynx
> by a Russian.
Unfortunately, it doesn't. You're right when saying that "ALL
browsers should use ISO-8859-1 unless directed otherwise." But in
Russia, the overwhelming majority of web users have configured their
browsers for a cyrillic code page by default and *never* change it
back to ISO-8859-1, for it is not a one-click operation in most
browsers and many less experienced users just don't know how to do
it. They're lucky that at least Russian-language pages show up ok,
and they're accustomed to condone that the things like the copyright
or the second letter in the first name of one of the CSS creators
are presented as cyrillic letters to them. I suspect that a similar
situation can be observed with many other languages with non-latin
alphabets. So it's a good occasion to ask those who call themselves
"purists," what do you care for more? Is it strict standards
conformance or is it accessibility of your pages to the widest
possible audience? Isn't it reasonable to recommend avoiding
anything but 7 bit ASCII on English-language pages that intend to be
internationally accessible?
Getting back to your page, Tina, there's one more fault that we,
too, have agreed upon -- it's a link that starts with "and it is..."
which makes it silly looking when extracted from the context.
And please note that the above is the result of my investigation
into not much than literally the first screen of your home page. I
didn't even "press space for next page" to discover more.
> Using Lynx, the page appears readable,
BTW, it is widely claimed that pages that abuse HTML appear "broken"
in Lynx. Can anybody please provide a definition of what a
"Lynx-broken" page is? I use Lynx routinely when I browse for
textual information and I can say that, depending on your mood, you
may call "broken" either all and every page or none at all. Of
course it is possible to distinguish between some vague "levels of
brokenness" but only if you are especially interested in the
subject.
Naturally, most pages I visit with Lynx use some sort of "abused"
HTML. Still, it's an *extremely* rare occasion that I can't access
a page's information via Lynx. All but a few web pages in this
world are perfectly viewable with Lynx provided that you browse for
information and you're not obsessed with "proper markup" or "HTML
abuse."
> It is obvious that the entire point of 'purism' in relation to HTML
> markup has not sunk in. The reason why a HTML page should conform to a
> given standard is that you cannot, *CANNOT*, predict the equipment or
> circumstances in which a reader may access your page.
>
> To claim that it is possible is still folly.
Strictly speaking, you cannot, *CANNOT* predict that tomorrow you
will not, say, die in a car accident. So how could you
realistically plan for the future without preparing your testament
first? It's not very "pragmatic," you know, as "the information may
not get through" to reach the day after tomorrow.
But the comment I'd really want to make regarding the "honest
markup" issue is a bit different. Let me lay it out as a three part
essay.
===============================================================
(1) *With the HTML we have now, honest structural markup is next to
impossible.* SGML creators were smart guys. They realized that one
cannot grasp the entire world of text structures used around. So
what they created was not a markup tool, but a tool to create a
different markup tool for each, *limited enough*, case. When HTML
was incubated, its media indeed looked rather limited. But it's not
the case *now*. Nearly any conceivable type of document can -- and
*is* -- published on the Web. A few dozens logical tags in HTML
are simply laughable when one considers the *logical*, not even
visual, diversity of today's web content. Right away I can name
quite a number of structural units that have no direct support in
HTML:
Sidebars; set out headings; inline headings, like the ones in this
essay; small print at bottom, as in ads; highlights in text;
marginal notes, footnotes and endnotes; compendiums; running
heads; bilateral signatures, as in agreements; abstracts;
dedications; epigraphs; etc, etc.
Each of these is a genuinely *structural* unit with some associated
traditions of visual rendering. And each of these is impossible to
code using existing HTML content model. You can of course model
them using some other HTML tags, but frankly, I cannot see why
structural misuse of elements is any better than their misuse for
the sake of their visual side effects. Note that I've analyzed only
quite common types of documents; in other cases, the inventory of
structural units that need to be marked up may be much wider -- and
wilder, if I'm allowed to say so.
(2) *SGML itself is no rescue, either.* One may conclude that
distributing a customized DTD along with a document could help in
this situation. Indeed, in this way you can provide any number of
new structural tags for your document. But helas, this would be of
little help for *programs* that interpret your document in various
media. SGML allows to specify the syntax of a tag and its content
model (i.e. which other tags it can contain), but it has no means to
communicate "suggested rendering" or even the "essence" of the new
element. This information, if present, is always in --comments--
and is essentially human-readable. Say, if you define a
<DEDICATION> tag, you cannot hint a user agent on how to render it
(print right-justified in italics, or read aloud in a solemn voice)
unless the user agent *already* knows this element and how to
interpret it.
Summing up (1) and (2) leads me to the almost inevitable conclusion,
namely that proper structural markup is:
a) strictly impossible for many, if not the majority, of today's
web documents, if HTML only is used;
b) *is* possible using SGML, but in this case loses much of its
practical usability as it *cannot* influence presentation of
new/customized elements.
(3) *The back side of the CSS medal.* So what about CSS, you may
ask? At first glance, it looks like it can solve all the problems
stated above. Indeed, CSS is *intended* to influence presentation
and as such, coupled with SGML, is capable of building a markup tool
that's perfect in both structural and presentation aspects. It can
even help if we're restricted to HTML, not SGML, provided that we
all consent to viewing, say, <P CLASS=Dedication> as something
structurally equivalent to <DEDICATION> that we miss so badly. So
what may be wrong with this?
One apparent danger is that, with the advent of CSS, structural
markup may appear *no more necessary* to many people. As the
control of presentation is passed to CSS, reasons to mind the
suggested usage of many HTML tags will start vanishing. It is not
unlikely that with time, only <DIV> and <SPAN> tags will survive,
and the logical structure of the document, if any, will be expressed
by the more or less logical tree of CLASSes and IDs. Abuse, you
say? Maybe. Of course this will hurt the document's readability on
devices without CSS, but I'm afraid that with time, references to
such devices will become less and less persuasive. Please consider
that for many professional designers unearthing the "structure" of
their pages is an *extra work* with a dubious reward. They just
don't think about their creations in such terms. And if a designer
is suddenly struck by the idea of rendering on a speech device, s/he
is more likely to adjust voice parameters with the appropriate CSS
tools (if these are available) than to rely on the rendering
associated with a structural HTML tag.
And finally and most importantly, let's remember that CSS is still
not in wide use, and that SGML hardly ever will be. Which leaves us
with the conclusions of (1) above...
===============================================================
Let's get back to Tina's message.
> The designer that learned HTML in one day is producing pages that look
> accordingly.
A rather inconsiderate remark, given that you most probably don't
know the name of the designer in question.
> I'll go on being annoying and
> irritating.
Really? I haven't noticed you being too annoying. At least towards
me :)
> Further, I am not going along with any 'deal'.
>
> 'Either you publish a bitter complaint about this case of HTML
> abuse by W3C, or you stop trying to criticize *my* pages in
> any public media. Deal?'
This quotation needs an explanation. What I was alluding to was the
fact that W3C, a standard-setting body of the Web, has settled a
precedent of "abusing" HTML. Visit http://www.w3.org/pub/WWW/ to
see borderless tables used for layout purposes which, by W3C's own
words, "typically causes problems when rendering to speech or to
text only user agents." It just struck me as unfair that Ms Holmboe
was so eager to criticize my pages while being indifferent to the
similar case of HTML abuse by W3C.
-- dk
===========================================================
dmitry kirsanov </> http://www.symbol.ru/dk
Tina Marie Holmboe
[Fri, 07 Feb 1997 04:47:09] [Tao]
> Your photo loads very quickly, but I would strongly suggest you choose
> another pose - perhaps you might even consider smiling? Your current
> photo bears an uncanny resemblance to "Fraiser's" ex-wife, Lilith. Then
> again after seeing the photo of your boyfriend, Jorgen, I can understand
> why you're not smiling. (O.J. Simpson looks happier in his mug shot then
> this guy does in that photo.)
Perhaps I should take this as irony, or sarcasm. But I won't. I am wondering
how to respond... perhaps with a comment or two about you and your intelligence
and ability to understand. But I won't.
I'll pop you in my killfile ASAP, asshole, both for newsgroups and for
mail. As for my pages, I was tempted, for just a second, to remove them - but
I'm not going to give you that pleasure. They'll stay, spelling errors and all,
*JUST* the way they are now.
Now go away, 'Tao', and do something unpleasant to yourself.
Alan J. Flavell
On 7 Feb 1997, Tina Marie Holmboe wrote:
> [Thu, 06 Feb 1997 14:04:29] [Alan J. Flavell]
>
> > This is a technical fault in the reader's setup.
> Oh, but Alan, I am *so* sorry - but you are wrong. See, here is the
> *correct* answer, directly from the source:
But the answer that you quoted is addressing quite a different
problem, not the one that you originally described.
The character string © is a string of 7-bit ASCII characters
(ampersand, hash, one, six, nine, semicolon) irrespective of whether
it is represented in ISO-8859-1 or in koi8-r.
In HTML it means precisely "the copyright symbol", irrespective of
whether the document is transmitted in iso-8859-1 or in koi8-r.
Take Lynx in an environment where the terminal is set for koi8-r
and Lynx has been correctly adjusted for terminal charset of koi8-r.
Then Lynx receives the string © (or ©), and responds by
sending to the terminal the 8-bit character (decimal)191 = (hex)BF,
which is the koi8-r code for the copyright sign.
So, both in theory and in practice, this works as designed. This has
nothing at all to do with the transmission encoding of 8-bit characters
in the document: they could be in koi8-r or anything else, it would
not change the meaning of &-entities in the document.
As I said before, if Dmitry's browser fails to do this, it isn't set
up correctly. It has nothing to do with whether the transmitted
document is in ISO-8859-1 or in koi8-r: the document that we are
talking about is in fact transmitted in 7-bit US-ASCII, which is the
same for either of the two 8-bit codes under discussion.
For further details I suggest that you refer to the koi8-r table at
http://www.nagual.ru/~ache/koi8-r.gif
and the description starting at
http://www.nagual.ru/~ache/main.html
Note that Lynx is the _ONLY_ browser reviewed there that passes all
of the applicable tests.
Don't confuse the transmission encoding with the display character-set,
they are two completely different issues (Lynx is one of the few
browsers that understand how to handle this correctly. DOSLynx
on the other hand can't even get this right for ISO-8859-1, so let's
leave DOSLynx out of the discussion entirely.)
> "Fortunately, NONE of them does. Otherwise our life would be too
> hard, since 99% of Russian-language pages do NOT specify their
> charset in any formal way.
That's true, but it isn't relevant to this discussion. I repeat,
the character strings © and © are strings of US-ASCII 7-bit
characters, which are represented by precisely same bit patterns
in iso-8859-1 and in koi8-r. What they _mean_ is the copyright
symbol. Which, in the koi8-r code, is at code position 191 decimal,
as you can see on the koi8-r chart referenced above.
> but if you're
> after usability, you'd better avoid anything but 7 bit ASCII.
> And *YOU* should be aware of this."
I disagree. Tina's page is in this respect fully compliant with HTML2.0
_and_ should be displayed correctly _even_ on a browser that (contrary
to standards, but for the practical reason mentioned by Dmitry) assumes
koi8-r for its transmission code (i.e assumes text/html;charset=koi8-r
when no such HTTP header is present).
What Tina is doing is fully correct by HTML standards, and a reader has
no right to complain to the author if it fails to display correctly due
to a shortcoming in the reader's browsing situation. Considering your
usual support for standards-compliance, it's a pity that you have spread
this kind of confusion.
As I say, Lynx can and does work correctly in this respect. There is
a problem (the one described by Dmitry), but _that_ problem does not
cause the effect that you are describing.
Alan J. Flavell
On Fri, 7 Feb 1997, Dmitry Kirsanov wrote:
> > and that the
> > © entity doesn't appear as a copyright symbol when viewed with Lynx
> > by a Russian.
>
> Unfortunately, it doesn't. You're right when saying that "ALL
> browsers should use ISO-8859-1 unless directed otherwise." But in
> Russia, the overwhelming majority of web users have configured their
> browsers for a cyrillic code page by default and *never* change it
> back to ISO-8859-1,
Dmitry, the correct setting for Lynx (I'm using version 2.6) in
the situation that you describe is as follows.
- Your terminal emulation should be koi8-r, I assume this is true
already.
- Lynx (O)ption - display (C)haracter set = koi8-r
- - raw 8bit m(O)de = ON
This displays 8-bit koi8-r documents correctly (even if they don't
announce their content-type correctly, as you say) and at the same time
displays HTML entities correctly.
When you need to read an 8-bit ISO-8859-1 document (i.e one that
complies with the official HTML standards, instead of the de facto
Russian standard) you can turn raw 8-bit mode off with the keycommand
"@".
This certainly works. See the URL I mentioned in my other posting:
http://www.nagual.ru/~ache/main.html
for further information.
Jukka Korpela
ti...@elfi.adbkons.se (Tina Marie Holmboe) writes:
> - - But firstly, I would
> like to perform such a critique of my homepage.
I usually enjoy reading Tina's articles, and this was especially
enjoyable. But I will add some critique (well aware of the fact
that this may make some people criticize _my_ homepage in a manner
I may not like :-).
> Url-in-question: http://www.elfi.adbkons.se/%7Etina/
My first impression that Tina tries to be artistic instead of
being informative. The entire page is a mess. Too many fonts.
Confusing collection of unrelated pieces of text. I can imagine
that Tina likes Anne McCaffrey, and this conveys some message to me,
but suppose I hadn't heard of Anne... And after all, when visiting
Tina's page I'm interested in her, not so much in her interests.
> Using Lynx, the page appears readable, even though the quote in the middle
> seem to become abit heaped together, and it is rather hard to figure out.
> This is probably due to the use of a table for layout-purposes.
It's nice to be nice to Lynx. (By the way, lynxes are not housecats.
Your image associated with Lynx is misleading.) Mainly because it's
being nice to some people.
But the very idea of using a table for layout is a rather strange
action when taken by an HTML purist. Perhaps you are purist just
syntactically? (I can understand your use of CITE since I was on the
wrong track, too; the HTML specifications are in many respects rather
vague when describing the semantics of markup elements; see
http://www.hut.fi/~jkorpela/HTML3.2/5.15.html)
Maybe I'm the only parallelly challenged person in the world but I really
like to read text sequentially, not in parallel. I may occasionally like
to see _comparable_ texts in formatted as a table, to really _compare_ them
(cf. http://www.hut.fi/~jkorpela/HTML3.2/4.9.html#tablepar), and I can
live with the Gutenbergian multicolumn style, but putting things side by
side just for fun is not fun to me.
I know perfectly well that _my_ home page (together with the more detailed
pages linked to it) is far from ideal. I started by copying the page of
a colleague and editing it. I've added things gradually. Occasionally
I have even updated something. But the point is that as one starts
creating documents with other than personal contents, one begins to regard
the personal home page as something rather unimportant. It's there mainly
for those people who see an article or Web document or mail message
by me and wish to check who the *** the writer is.
What should I add? Que s'excuse, s'accuse.
Yucca, http://www.hut.fi/~jkorpela/
Tina Marie Holmboe
[Fri, 07 Feb 1997 17:02:19] [Jukka Korpela]
> I usually enjoy reading Tina's articles, and this was especially
> enjoyable. But I will add some critique (well aware of the fact
> that this may make some people criticize _my_ homepage in a manner
> I may not like :-).
Well, thankyou for your critique. I am afraid I don't see that it was
constructive, since it regarded itself with the 'art' in my page, and not
with the technical side, the acessability, load time, etc.
But thankyou anyway.
> My first impression that Tina tries to be artistic instead of
> being informative. The entire page is a mess. Too many fonts.
Now, actually, I tried to be cute. I really must apologize if my stylesheet
strikes you as having too many fonts. I cannot recall using more than two
of them, but I will certainly go back and have a look.
> Confusing collection of unrelated pieces of text. I can imagine
> that Tina likes Anne McCaffrey, and this conveys some message to me,
> but suppose I hadn't heard of Anne... And after all, when visiting
> Tina's page I'm interested in her, not so much in her interests.
The poem isn't there to convey my interest in Anne McCaffrey. It is there
to convey something about me. That, however, is again one of those points
which really cannot be 'jugded' or 'critiques', as it is a matter of
personal taste and perception.
> It's nice to be nice to Lynx. (By the way, lynxes are not housecats.
> Your image associated with Lynx is misleading.) Mainly because it's
I'll be sure to let the people at
http://www.ee.umanitoba.ca/~djc/personal/lynxfriend.html, and in
particular Brandi Weed know this about the feline.
> But the very idea of using a table for layout is a rather strange
> action when taken by an HTML purist. Perhaps you are purist just
Is it ? With fear of alienating you, given your nice critique of my page,
it does seem as you need to re-evaluate what 'purism' in this situation
is. For a purist to use a table for layout-purposes isn't against any
'purity code' - quite the contrary.
> syntactically? (I can understand your use of CITE since I was on the
> wrong track, too; the HTML specifications are in many respects rather
> vague when describing the semantics of markup elements; see
> http://www.hut.fi/~jkorpela/HTML3.2/5.15.html)
I suggest a visit to your local English-Finnish dictionary, and look up
the definition of 'cite' - had the quote from Mrs. McCaffrey been meant as
a *quote*, you are right. As it is, the use of CITE is quite correct, if
abit obscure.
And I don't really think CITE is very good for book titles.
> the personal home page as something rather unimportant. It's there mainly
> for those people who see an article or Web document or mail message
> by me and wish to check who the *** the writer is.
Exactly. You've summarized my pages very well. Thankyou, again, for your
extensive critique of my page.
Dmitry Kirsanov
Alan J. Flavell <fla...@mail.cern.ch> wrote:
> Then Lynx receives the string © (or ©), and responds by
> sending to the terminal the 8-bit character (decimal)191 = (hex)BF,
> which is the koi8-r code for the copyright sign.
You're absolutely right here, but still a lot of questions remain.
First, the Lynx I use (v. 2.3.7) does not translate code 169 into
191. And it doesn't have koi8-r as a (C)haracter set option. It
doesn't even have "raw 8bit m(O)de" option. I agree that this fact
is not very relevant to the discussion, but still it reveals
something. I can't upgrade Lynx as I'm not system administrator on
our site, and system administrators aren't usually too eager to
upgrade their Lynxes -- they have a lot of other things to do.
Second, let's consider, say, Netscape instead of Lynx. It does have
koi8-r as one of its encoding options, but still it doesn't recode
*anything* when switched to it. It just displays the text in a koi8
font provided you have supplied one. That's why many truetype koi8
fonts to be used with browsers put copyright char on 169, not 191,
although this contradicts to koi8 specification.
And third, let's consider that the case of the copyright is actually
quite special. It requires mapping from one code position to
another because two conditions are satisfied: (1) the character
glyph in question is present in both charsets; and (2) it occupies
there different positions. Actually I can't remember any other
character to satisfy these requirements. In other cases, either the
character is on the same code in both charsets (in which case no
mapping is needed) or it is completely missing in one of them (in
which case no mapping is possible). E.g. you cannot set any
reasonable mapping for latin letters with diacritics which *will* be
displayed as cyrillic letters when browser is configured for koi8-r
or nearly any other cyrillic encoding.
To sum it up:
1) The cases where browsers should remap codes when configured for
a local charset are not common and, consequently, it is not
realistic to expect that all browser manufacturers will support
this feature;
2) For the majority of HTML entities there's no reasonable mapping
at all and they *will* turn to garbage when viewed on the
default cyrillic browser configuration. Changing the charset, I
repeat, is difficult for many unexperienced users.
> What Tina is doing is fully correct by HTML standards, and a reader has
> no right to complain to the author if it fails to display correctly due
> to a shortcoming in the reader's browsing situation.
3) Okay, I don't complain. Nothing of the above was meant to
assume that standards were broken on the author's end (and I've
repeated this already). I only tried to explain that strict
adherence to standards is *difficult* for users and is *not*
properly supported by browser manufacturers, and I assume that
this is the case where HTML authors could come to help. At
least, I can't see why a pure English text could not restrict
itself to 7 bit ASCII.
Alan J. Flavell
On Sat, 8 Feb 1997, Dmitry Kirsanov wrote:
> Alan J. Flavell <fla...@mail.cern.ch> wrote:
>
> > Then Lynx receives the string © (or ©), and responds by
> > sending to the terminal the 8-bit character (decimal)191 = (hex)BF,
> > which is the koi8-r code for the copyright sign.
>
> You're absolutely right here, but still a lot of questions remain.
>
> First, the Lynx I use (v. 2.3.7)
You didn't mention a version before. That version is really obsolete!
Version 2.5 became official (instead of 2.4) quite some time ago; 2.6
has been current until now, and 2.7 is just being released.
I very strongly recommend you to upgrade to at least 2.6, or take 2.7
when it is officially released in a few days. When I say "Lynx" below,
I assume a reasonably recent version.
> does not translate code 169 into
> 191. And it doesn't have koi8-r as a (C)haracter set option. It
> doesn't even have "raw 8bit m(O)de" option. I agree that this fact
> is not very relevant to the discussion, but still it reveals
> something. I can't upgrade Lynx as I'm not system administrator on
> our site, and system administrators aren't usually too eager to
> upgrade their Lynxes -- they have a lot of other things to do.
I don't understand your situation, but as a user I have no problem
to build my own copy of Lynx. You would them be in a position to
demonstrate to your sysadmins that it only takes a few minutes, and
you could point them to the koi8-r page (I think he also offers a
Russian version) so that they understand the problem. This isn't a
matter of keeping up to date with every little change in Lynx, but
of upgrading from an obsolete version that does not support the things
that you, and their other users, need.
> Second, let's consider, say, Netscape instead of Lynx. It does have
> koi8-r as one of its encoding options, but still it doesn't recode
> *anything* when switched to it. It just displays the text in a koi8
> font provided you have supplied one.
Netscape is broken. We were discussing a browser that supports the
published standards.
> That's why many truetype koi8
> fonts to be used with browsers put copyright char on 169, not 191,
> although this contradicts to koi8 specification.
Again I refer you to the URL I mentioned before. There is a right and a
wrong way of doing this. Breaking your font in order to help a broken
browser is a bad idea, and of course has many consequences. I recommend
that Netscape users browse Latin-1 documents with Western encoding
manually selected, if necessary. But we were discussing Lynx.
> And third, let's consider that the case of the copyright is actually
> quite special. It requires mapping from one code position to
> another because two conditions are satisfied: (1) the character
> glyph in question is present in both charsets; and (2) it occupies
> there different positions. Actually I can't remember any other
> character to satisfy these requirements. In other cases, either the
> character is on the same code in both charsets (in which case no
> mapping is needed) or it is completely missing in one of them (in
> which case no mapping is possible).
In theory that depends on your terminal emulation. If it supports
ISO-2022 encodings, it would work (as for Japanese etc.) but this is not
supported, as far as I know, for Cyrillic. At any rate Lynx does not
offer that method for koi8-r - it offers 7-bit approximations. If your
terminal emulation is koi8-r then I think we have to assume that it does
not support ISO-2022 encodings anyway.
> E.g. you cannot set any
> reasonable mapping for latin letters with diacritics which *will* be
> displayed as cyrillic letters when browser is configured for koi8-r
> or nearly any other cyrillic encoding.
A graphcal browser simply needs to use glyphs from another, compatible,
font. If the makers of graphical browsers haven't done this yet, they
have work to do. The _meaning_ of an author's document does not change
simply because the _reader_ had a different setup.
Lynx converts Latin-1 characters into "7-bit approximations" e.g "(R)"
or "YEN" when you have told it that your terminal character code is
koi8-r.
I'm sorry, but you have proved the point that I originally made:
- Lynx (current versions) complies with the koi8-r standard, and will
display the copyright glyph in response to the numerical entity 169
- If it doesn't, then the fault lies with the reader's setup and not
with the author.
> 1) The cases where browsers should remap codes when configured for
> a local charset are not common and, consequently, it is not
> realistic to expect that all browser manufacturers will support
> this feature;
I expect browser makers to comply with the published standards.
Complain to them until they do.
> > What Tina is doing is fully correct by HTML standards, and a reader has
> > no right to complain to the author if it fails to display correctly due
> > to a shortcoming in the reader's browsing situation.
>
> 3) Okay, I don't complain. Nothing of the above was meant to
> assume that standards were broken on the author's end (and I've
> repeated this already). I only tried to explain that strict
> adherence to standards is *difficult* for users
Yes in general, but not with current versions of Lynx
> and is *not*
> properly supported by browser manufacturers,
True, there are some popular browsers that do not comply with
published open standards.
So, get a current version of Lynx ;-)
best wishes
Lester S. Garrett ciwah
On 7 Feb 1997 22:11:58 GMT ti...@htmlhelp.com (Tina Marie Holmboe)
wrote in comp.infosystems.www.authoring.html Re. Re: Critique of
homepage - as per request.:
. . .
> > But the very idea of using a table for layout is a rather strange
> > action when taken by an HTML purist. Perhaps you are purist just
> Is it ? With fear of alienating you, given your nice critique of my page,
> it does seem as you need to re-evaluate what 'purism' in this situation
> is. For a purist to use a table for layout-purposes isn't against any
> 'purity code' - quite the contrary.
First they create their gratuitous strawman, "the HTML purist". Then
they wallow about in darkness and confusion when they discover that we
don't conform to their artificial and phoney construct. Oh my. I
really do think we need to reintroduce the teaching of logical
thinking in the elementary schools. (At that level it should at least
preclude a symbolic logic approach.)
-={lsg}=-
Jukka Korpela
ti...@htmlhelp.com (Tina Marie Holmboe) writes:
> - - I really must apologize if my stylesheet
> strikes you as having too many fonts. I cannot recall using more than two
> of them, but I will certainly go back and have a look.
I wasn't referring to your explicit use of fonts. I referred to what I see.
Using various logical markup elements may also cause different fonts to be
used, and using embedded images with text in them usually makes me see
different fonts. The lesson is that even without using a single FONT
element or other physical markup or any style sheets one can produce
pages which, when displayed on a typical browser, contain too many fonts.
> The poem isn't there to convey my interest in Anne McCaffrey. It is there
> to convey something about me. That, however, is again one of those points
> which really cannot be 'jugded' or 'critiques', as it is a matter of
> personal taste and perception.
This sounds strikingly similar to how people motivate their strange-
looking pages with little information contents in general. Well, it seems
that you _intentionally_ want to be understood poetically, by "personal
taste". (I can imagine putting a poem onto some of my Web pages. A poem
of my own, to be exact. I would't put a poem onto my main home page, though.)
A Finnish communications researcher, prof. emeritus Osmo A. Wiio,
has formulated a "law" which says that all communication fails, except
by accident. I have tried to teach people take this seriously, with the
practical suggestion that we can at best increase the probability of
such accidents. My corollary to Wiio´s law is that people also fail to
understand correctly how other people see what they try to communicate;
that is, feedback fails, too (except by accident). So you may think that
some people really learn something about from poems you quote;
I am pretty sure you would call their impressions false if you were
able to see what they are.
> - - For a purist to use a table for layout-purposes isn't against any
> 'purity code' - quite the contrary.
I see. Well, there are at least two classes of purists then. My purism
means that we should use HTML in the way it is defined, both syntactically
and semantically. Not that I like all the definitions. But using an element,
intended for presenting a structural feature of a document, for a quite
different purpose than the indended one, sounds misuse to me. In a sense,
it is worse than, say, using Netscape-specific tags; the latter can easily
be detected by a syntax analyzer (verifier, checker, whatever you call it).
> > (I can understand your use of CITE since I was on the
> > wrong track, too; the HTML specifications are in many respects rather
> > vague when describing the semantics of markup elements; see
> > http://www.hut.fi/~jkorpela/HTML3.2/5.15.html)
>
> I suggest a visit to your local English-Finnish dictionary, and look up
> the definition of 'cite' - had the quote from Mrs. McCaffrey been meant as
> a *quote*, you are right. As it is, the use of CITE is quite correct, if
> abit obscure.
In fact I studied a few dictionaries, and they tend to explain "cite"
and "quote" roughly synonymous. Several descriptions of HTML, in different
languages, seemed to describe things so, too. But after some discussions,
including consultation of a teacher of English at our university (an
Englishwoman), I am convinced that the intended use of CITE does _not_
cover actual excerpts from external sources, only references to such
sources by their titles.
> And I don't really think CITE is very good for book titles.
Well, perhaps, but it definitely is one intended use, maybe the most
important intended use, for CITE, from the very dawn of the Web.
--
Yucca, http://www.hut.fi/~jkorpela/
Tina Marie Holmboe
[Fri, 07 Feb 1997 09:58:44] [Dmitry Kirsanov]
> I am really pleased to see that you have responded positively to,
> how you called it, my "challenge." Overall, your self-critique is
> satisfactory (and, I believe, instructive to the readers of this
'Satisfactory' ? It would be prudent of you to cut down on the rather
arrogant attitude. Someone might get the wrong idea.
> CITE was used for a quoted poem stanza between two paragraphs. No
> doubt this requires a block level element, which CITE has never
Sadly, the CITE in question was used to, and I quote, "...to qoute by
way of example...'. Perfectly suitable. In *your* opinion it should have been
done with a block level element.
> In Lynx, the first line on your page reads:
>
> "Tina Marie Holmboe This page is..."
>
> Is this nice to *your* liking?
In Lynx, the first line on my page reads:
Tina Marie Holmboe
which is the ALT text to the image I've used on top. The next element on
the page is a TABLE, which starts a new paragraph. A new paragraph should
be proceeded by a newline - but older versions of Lynx does not support
tables. This is what causes the effect that you see.
> Unfortunately, it doesn't. You're right when saying that "ALL
> browsers should use ISO-8859-1 unless directed otherwise." But in
> Russia, the overwhelming majority of web users have configured their
> browsers for a cyrillic code page by default and *never* change it
See Alan's replies to you.
> Getting back to your page, Tina, there's one more fault that we,
> too, have agreed upon -- it's a link that starts with "and it is..."
> which makes it silly looking when extracted from the context.
'We' ? What you refer to is no fault, and was not agreed upon by me as
being a fault. It is a stylistic issues. You don't like, which is your right.
As a matter of fact, when seen *in* context, the link is not very silly
at all:
This page is validated as HTML 3.2 (Wilbur) and it is Lynx Friendly
But it is still a stylistic issue.
> "Lynx-broken" page is? I use Lynx routinely when I browse for
Of course. Have a look at http://www.symbol.ru/dk/ or
http://www.killersites.com/, both of which appear broken in Lynx, due to
missing or ignored elements of HTML.
> not in wide use, and that SGML hardly ever will be. Which leaves us
Suggested reading: AltaVista, search for 'SGML', and after reading abit
up on that, explain to us what '...hardly ever will be...' means.
> This quotation needs an explanation. What I was alluding to was the
> fact that W3C, a standard-setting body of the Web, has settled a
> precedent of "abusing" HTML. Visit http://www.w3.org/pub/WWW/ to
> see borderless tables used for layout purposes which, by W3C's own
> words, "typically causes problems when rendering to speech or to
> text only user agents." It just struck me as unfair that Ms Holmboe
> was so eager to criticize my pages while being indifferent to the
> similar case of HTML abuse by W3C.
When the W3C comes to ciwah or me personally and asks for a critique of
their pages, I will most certainly do so.
Until such a time, I have no intentions of commenting upon W3C's use of
any element.
Tina Marie Holmboe
[Sat, 08 Feb 1997 16:43:39] [Jukka Korpela]
> I wasn't referring to your explicit use of fonts. I referred to what I see.
> Using various logical markup elements may also cause different fonts to be
> used, and using embedded images with text in them usually makes me see
> different fonts. The lesson is that even without using a single FONT
> element or other physical markup or any style sheets one can produce
> pages which, when displayed on a typical browser, contain too many fonts.
So, your critique is that using structural markup will, in some browsers,
lead to the display having too many fonts... ie. that using HTML as it was
intended (structural markup) *might* lead to a display that the user doesn't
find pleasant ?
Should I, then, change the way I use HTML on my pages, since the end user
might not enjoy the possibly strange display of various fonts that his UA
perhaps uses for the same elements of HTML ?
> has formulated a "law" which says that all communication fails, except
> by accident. I have tried to teach people take this seriously, with the
> practical suggestion that we can at best increase the probability of
> such accidents. My corollary to Wiio´s law is that people also fail to
> understand correctly how other people see what they try to communicate;
> that is, feedback fails, too (except by accident). So you may think that
> some people really learn something about from poems you quote;
> I am pretty sure you would call their impressions false if you were
> able to see what they are.
Feel free to be pretty sure about most things. I communicate - I put up
a poem that means alot to me on my homepage. It has a message, about me, to
convey. It does that using structurally sound HTML, and so cannot be attacked
on that issue. But there are always more than one party to communication; and
whether what *I* intend to communicate is what *you* perceive it to be...
That must be something for *you* to ponder, and not something that I need
to change.
> I see. Well, there are at least two classes of purists then. My purism
> means that we should use HTML in the way it is defined, both syntactically
> and semantically. Not that I like all the definitions. But using an element,
> intended for presenting a structural feature of a document, for a quite
> different purpose than the indended one, sounds misuse to me. In a sense,
> it is worse than, say, using Netscape-specific tags; the latter can easily
> be detected by a syntax analyzer (verifier, checker, whatever you call it).
There are many classes of purists, I'd imagine. I tend to belong to the
one that states "Use what you *know* will work, not what you *think* will
work. "
And use it honestly.
> including consultation of a teacher of English at our university (an
> Englishwoman), I am convinced that the intended use of CITE does _not_
> cover actual excerpts from external sources, only references to such
> sources by their titles.
When the 'intended' use of an element is vague, I would say that going
to the definition of the word itself is a Good Thing. One definition of the
word 'cite' is, and I quote:
"2) vt, to quote by way of example"
Alan J. Flavell
(further notes on my earlier posting. Yes, I know that following up
one's own postings is considered bad style...
I've left this on c.i.w.a.html because of its relevance to HTML
authoring. Questions about Lynx should really go on the
c.i.w.browsers.misc group)
On Sat, 8 Feb 1997, Alan J. Flavell wrote:
> Netscape is broken.
I've just noticed the splendid animated gif on this page:
http://www.nagual.ru/~ache/xnets.html
Unfortunately you won't get the full effect if your default background
is white, as mine is. He's specified a background image but omitted
to specify the other body color attributes (a mistake that's frequently
commented on in this group). It's worth a look, anyhow.
> > That's why many truetype koi8
> > fonts to be used with browsers put copyright char on 169, not 191,
> > although this contradicts to koi8 specification.
Again I refer you to the URL I mentioned before, which by the way
is based on koi8-r (there exist other variants of koi8 code, but the
recommended one for use on the 'net is koi8-r).
> There is a right and a
> wrong way of doing this. Breaking your font in order to help a broken
> browser is a bad idea, and of course has many consequences.
There is in fact more discussion about how to use Netscape, at the
above-cited pages. If you are going to install a broken font for use
with netscape then please give it a different name, and configure it
explicitly in Netscape, so that it doesn't break other applications that
are programmed correctly.
> > And third, let's consider that the case of the copyright is actually
> > quite special. It requires mapping from one code position to
> > another because two conditions are satisfied: (1) the character
> > glyph in question is present in both charsets; and (2) it occupies
> > there different positions. Actually I can't remember any other
> > character to satisfy these requirements.
You can see them in the KOI8-R part of LYCharSets.c in the source
code for Lynx (I'm looking at version 2.7). There's the degree sign,
the mid-dot, the superscript-2, etc. If you don't like their choice you
can always reconfigure this part of the source code!
As I said before, in this mode Lynx renders characters that aren't
available in koi8-r by means of "7-bit approximations". I don't
see what more they could do, in the circumstances.
good luck. If I happen to have access to a system that's comaptible
with yours, maybe I could send you (Dmitry) an executable binary. Just
a thought. (I'm _not_ offering this as a public service. There are
already some sites that have Lynx executable binaries for a selection of
platforms. Start from the memorable http://lynx.browser.org/ )
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <5dhvrp$7tr$3...@euas20.eua.ericsson.se>,
ti...@htmlhelp.com (Tina Marie Holmboe) wrote:
> When the 'intended' use of an element is vague, I would say that going
> to the definition of the word itself is a Good Thing. One definition of the
> word 'cite' is, and I quote:
>
> "2) vt, to quote by way of example"
Tina, I hate to do this (yeah right) but RFC 1866 says:
5.7.1.1. Citation: CITE
The <CITE> element is used to indicate the title of a book or
other citation. It is typically rendered as italics. For example:
He just couldn't get enough of <cite>The Grapes of Wrath</cite>.
The HTML 3.2 reference at our site used to give your interpretation,
until the amount of flames from Alan rose to unacceptable levels. :-)
- --
E-mail: gala...@htmlhelp.com .................... PGP Key: 512/63B0E665
Maintainer of WDG's HTML reference: <http://www.htmlhelp.com/reference/>
-----END PGP SIGNED MESSAGE-----
Karl-Johan Noren
In <bWN/y4uYOF...@htmlhelp.com>,
gala...@htmlhelp.com (Arnoud "Galactus" Engelfriet) wrote:
> ti...@htmlhelp.com (Tina Marie Holmboe) wrote:
> > When the 'intended' use of an element is vague, I would say that going
> > to the definition of the word itself is a Good Thing. One definition of the
> > word 'cite' is, and I quote:
> >
> > "2) vt, to quote by way of example"
>
> Tina, I hate to do this (yeah right) but RFC 1866 says:
>
> 5.7.1.1. Citation: CITE
>
> The <CITE> element is used to indicate the title of a book or
> other citation. It is typically rendered as italics. For example:
^^^^^^^^^^^^^^
Webster Definition for "citation"
ci.ta.tion \si--'ta--sh*n\ n 1: an official summons to appear (as
before a court) 2a: an act of quoting; esp : the citing of a
previously settled case at law 2b: EXCERPT, QUOTE 3: MENTION : as 3a:
a formal statement of the achievements of a person receiving an
academic honor 3b: specific reference in a military dispatch to
meritorious performance of duty
> He just couldn't get enough of <cite>The Grapes of Wrath</cite>.
>
> The HTML 3.2 reference at our site used to give your interpretation,
> until the amount of flames from Alan rose to unacceptable levels. :-)
Personally, I'd say that this one is one of the worst
mistakes in HTML 2.0. First the definition of what the
element means is ambigious, second it lacked the more second
half of the concept, the quote.
--
Karl-Johan Norén (Noren with acute e) -- k-j-...@dsv.su.se
http://www.dsv.su.se/~k-j-nore/
- To believe people are as stupid as one believes is
stupider than one can believe
Tina Marie Holmboe
[Sat, 08 Feb 1997 21:35:59] [Arnoud "Galactus" Engelfriet]
> Tina, I hate to do this (yeah right) but RFC 1866 says:
Yeah, right :)
> 5.7.1.1. Citation: CITE
>
> The <CITE> element is used to indicate the title of a book or
> other citation. It is typically rendered as italics. For example:
>
> He just couldn't get enough of <cite>The Grapes of Wrath</cite>.
And 3.2 says:
"CITE used for citations or references to other sources."
if one, as the original poster wanted us to accept, that is a 'vague'
definition, I claim that the only correct thing to do is look up the meaning
of the word - which includes the definition I quoted.
"...indicated the title of a book or other citation... " and
"...used for citations or references to other sources... "
A 'citation' is also defined as:
"b) n, EXCERPT, QUOTE"
and no matter how hard I dig, I don't think I can find anything even close
to this as a foundation for using CITE for a book title. Then again, it
can also - by the same logic - be used for an EXCERPT or QUOTE - and we are
back where we started.
Either CITE is for a 'citation', and then also allowed for a quote, or
what is it for ? HTML 3.0 used CREDIT to name book titles and authors. About
CITE, it says: "...specifies a citation... " - which, still, can be defined
as a quote...
> The HTML 3.2 reference at our site used to give your interpretation,
> until the amount of flames from Alan rose to unacceptable levels. :-)
Here, have a firehose >:) And a pillow, of course.
Jeanne A. E. DeVoto
In article <5dhubk$7tr$2...@euas20.eua.ericsson.se>, ti...@htmlhelp.com wrote:
>[Fri, 07 Feb 1997 09:58:44] [Dmitry Kirsanov]
> Tina Marie Holmboe
> which is the ALT text to the image I've used on top. The next element on
>the page is a TABLE, which starts a new paragraph. A new paragraph should
>be proceeded by a newline - but older versions of Lynx does not support
>tables. This is what causes the effect that you see.
Well, yes. If people use the browser and version you prefer, they will see
the effect you intended. Is this your idea of good page design? Pages that
only work when the visitor is using one of the specific browsers you had in
mind when coding?
Creating tables that degrade into a hash when viewed with a table-impaired
browser is a novice mistake, and your index page has two instances of it.
Pointing it out is a perfectly reasonable criticism and not adequately met
by the assertion that the page looks fine in browsers that support tables,
unless your aim is to create a page to be viewed only with such browsers.
>> Getting back to your page, Tina, there's one more fault that we,
>> too, have agreed upon -- it's a link that starts with "and it is..."
>> which makes it silly looking when extracted from the context.
>[...] As a matter of fact, when seen *in* context, the link is not very
>silly at all:
> This page is validated as HTML 3.2 (Wilbur) and it is Lynx Friendly
The page looks like that when it's viewed in Lynx. If alt text display were
a Lynx-only proprietary feature, then, this would be a fine and adequate
response.
However, Lynx is not the only browser that displays alt texts; there are
browsers that don't present them in the linear fashion Lynx does - they
display them one at a time based on mouse focus - and even if there
weren't, more to the point is the fact that there's nothing in the
definition of the alt attribute that requires it to be presented on all
images at once, and linearly laid out. A visitor who sees only the alt text
you have for the kitten graphic will see "and it is Lynx Friendly" [sic].
This message cannot but be confusing, hopelessly so to a person who doesn't
know Lynx is a browser. And unless that visitor is using Lynx, you cannot
count on their seeing the other half of the sentence at the same time.
Splitting the halves of a sentence between alt texts is a neat hack for
Lynx; unfortunately, like many such hacks, it does not travel gracefully to
the general case of browsers.
> But it is still a stylistic issue.
It's a design issue. Issues such as these are not mere matters of taste,
and dismissing them as "stylistic" does not make them so. Matters of taste
apply to the content, not to the presentation. (If someone were, for
example, to criticize your choice of poem on the grounds that he didn't
like it, you would be justified in ignoring this as not relevant to your
page's design and purpose. Thus also with the idiot who complained that you
weren't smiling enough in your photo for his satisfaction.) But the
problems that have been pointed out to you in this thread are not, for the
most part, with the content; they're with your use of HTML.
--
Tools, not rules.
Tina Marie Holmboe
[Sun, 09 Feb 1997 23:38:29] [Jeanne A. E. DeVoto]
> Well, yes. If people use the browser and version you prefer, they will see
> the effect you intended. Is this your idea of good page design? Pages that
> only work when the visitor is using one of the specific browsers you had in
> mind when coding?
From the top, then.
The TITLE I set to 'Homepage of Tina Marie Holmboe', since the page itself
does not have a specific theme. The word 'homepage' is rather empty, of
course, but frankly I don't know of any better.
In the BODY I've included a JPG which is supposed to look like an ocean. This
it will not do for everyone. I have set the background color, however, to be
white, with black text, to avoid any 'do not load images' conflicts. The link
colors are similarly set, and do provide good contrast on even an 8bit
laptop display.
After this follows a 'name icon', a really rather pointless little thing, a
gif I generated off one of those online banner-production sites. It spouts
HEIGHT-, WIDTH- and ALT-attributes, and should be reasonably secure in any
browser. It is packed in a DIV, which means no newlines should be rendered,
by browsers that render, either before or after.
The TABLE that follows I've used for layout-purposes, in order to put one
image one each 'side' of the page. It has a 100% WIDTH, so as to do that.
According to the specs, a <TABLE> is 'typically' rendered with a newline
before and after, as it acts as a 'paragraph'. Sadly earlier versions of Lynx
doesn't reckognise the TABLE element at all, and therefore doesn't render
it that way. All 3.2 compliant versions of Lynx do, however. This I concede.
I can fix that by putting in an extra <BR> in the appropriate place.
The ALT-texts are in place on both the 'Valid 3.2' icon, and on the 'Lynx
friendly' ones. It *is* a stylistic issue whether or not those texts are good,
or not. They should, preferably, be understandable out of context, and I do
firmly believe that they are - althought abit strange.
Following this is a paragraph, centered, that describes briefly that these
are indeed only my personal pages, and nothing else. After that another
paragraph, with <SMALL>, to point out that even though I am Norwegian the
pages are in English. Utterly pointless, I admit.
Now for the poem. It is placed into a table - so that the two verses can be
read - on browsers that support this - side by side. The reason why I have
that poem there is irrelevant. In browsers that do not support tables, the
verses of the poems are lined up beneath eachother, which they do in Lynx.
After the poem there is a HR. It is centered, and stretches for 30% of the
screen width. Thereafter follows a table, again used for layout-purposes,
which lines up the 6 links that I have on my homepage. When viewed with a
non-table-supporting browser, ie. a 2.0 one, it will degrade to something
approximating the following:
HTML and Such Stuff<br>
Updated: 24th of January, 1997, at 12:28<br>
About the Author<br>
Updated: 17th of January, 1997, at 15:15<br>
The HTML FEP<br>
Updated: 17th of January, 1997, at 15:15<br>
Chicken Galore<br>
Updated: 13th of October, 1996, at 21:35<br>
Projects<br>
Updated: 24th of January, 1997, at 15:51<br>
My Favourite MIDI's<br>
Updated: 24th of January, 1997, at 17:30<br>
I have left the <BR>'s in, to emphasize my point.
Finally there is a pretty little 'band', which has a '----' ALT-text,
which will again degrade nicely. On the bottom, there is a 'menu bar', entirely
in text, wrapped in a paragraph. This degrades nicely.
At the bottom is the WDG logo, with ALT, WIDTH and HEIGH, and again it will
appear properly in a 2.0 browser.
> Creating tables that degrade into a hash when viewed with a table-impaired
> browser is a novice mistake, and your index page has two instances of it.
Please explain the word 'hash' ? It would also be enlightening if a
description of how the tables *do* degrade in a 2.0 browser could be
presented.
> Pointing it out is a perfectly reasonable criticism and not adequately met
> by the assertion that the page looks fine in browsers that support tables,
> unless your aim is to create a page to be viewed only with such browsers.
As I have demonstrated above, I do think I can claim that I have indeed
thought out what *will* happen to that page when viewed with browsers that
support the standard, 2.0. I admit, again, that there are things that I can
fix.
> Splitting the halves of a sentence between alt texts is a neat hack for
> Lynx; unfortunately, like many such hacks, it does not travel gracefully to
> the general case of browsers.
This, again, *is* a stylistic issue. The ALT-texts, IMHO, convey the message
they are intended to convey, albeit in a 'strange' - to you - manner. Are they
*usable* ? If yes, then the matter of whether they are *likeable* not
interesting.
> weren't smiling enough in your photo for his satisfaction.) But the
> problems that have been pointed out to you in this thread are not, for the
> most part, with the content; they're with your use of HTML.
Well, I have now conceeded to the fact that I could use cleaner HTML around
the tables, and I will of course do so. As for the ALT-texts, I fear it will
take a whole lot more, and heavier, arguments in order for me to change my
view on them.
Andreas Prilop
In article <Pine.HPP.3.95a.97020...@hpplus09.cern.ch>,
"Alan J. Flavell" <fla...@mail.cern.ch> wrote:
>is based on koi8-r (there exist other variants of koi8 code, but the
>recommended one for use on the 'net is koi8-r).
No!!
"KOI8-R" is a *defective* *Russian* character set. It does not contain
any non-Russian Cyrillic letters. It is a typical Russian (or should
I say Soviet?) attitude to ignore everything non-Russian.
The complete MIME Cyrillic character set is ISO-IR-111.
<http://www.fingertipsoft.com/ref/cyrillic/isoir111.html>
<http://ds.internic.net/rfc/rfc1700.txt>
<ftp://dkuug.dk/i18n/charmaps/ECMA-CYRILLIC>
<ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets>
Use ISO-IR-111 and support also Ukrainian etc.!
Andreas
Mikhail A. Sokolov
In comp.infosystems.www.authoring.html Andreas Prilop <ap...@macb033.rrzn.uni-hannover.de.KILL.SPAM.DEAD> wrote:
# In article <Pine.HPP.3.95a.97020...@hpplus09.cern.ch>,
# "Alan J. Flavell" <fla...@mail.cern.ch> wrote:
# >is based on koi8-r (there exist other variants of koi8 code, but the
# >recommended one for use on the 'net is koi8-r).
# "KOI8-R" is a *defective* *Russian* character set. It does not contain
# any non-Russian Cyrillic letters. It is a typical Russian (or should
# I say Soviet?) attitude to ignore everything non-Russian.
Crap. Forgive my emotions, see P.S. below.
# The complete MIME Cyrillic character set is ISO-IR-111.
# Use ISO-IR-111 and support also Ukrainian etc.!
Totally incorrect. See RFC1489, http://www.nagual.ru/~ache/koi8.html.
This is standard Russian charecter set. Use koi8-u for ukrainian texts.
# Andreas
-mishania
P.S. Sometimes it's woth knowing what are you talking about.
Andreas Prilop
In article <5dnhvc$guq$1...@news.demos.su>,
Mikhail A. Sokolov <mish...@sinbin.demos.su> wrote:
># "KOI8-R" is a *defective* *Russian* character set. It does not contain
># any non-Russian Cyrillic letters. It is a typical Russian (or should
># I say Soviet?) attitude to ignore everything non-Russian.
># The complete MIME Cyrillic character set is ISO-IR-111.
># Use ISO-IR-111 and support also Ukrainian etc.!
>
>Totally incorrect. See RFC1489, http://www.nagual.ru/~ache/koi8.html.
>This is standard Russian charecter set. Use koi8-u for ukrainian texts.
Compare with the Latin-1 alphabet:
It would be silly to have different character sets for French, German,
Spanish, etc. Why should we have several different charsets for Russian,
Belarussian, Ukrainian, etc.??
If you closely inspect
<http://www.fingertipsoft.com/ref/cyrillic/isoir111.html>,
you'll find that the code positions of *all* Russian letters in KOI-8
and ISO-IR-111 are *identical*. Therefore, it makes no *practical*
difference for the Russian language. On the other hand, KOI8-R is filled
with completely useless, obsolete "box-drawing characters".
ISO-IR-111 has been adopted for use with MIME in RFC 1700.
Andreas
Mikhail A. Sokolov
In comp.infosystems.www.authoring.html Andreas Prilop <ap...@macb033.rrzn.uni-hannover.de.KILL.SPAM.DEAD> wrote:
# Mikhail A. Sokolov <mish...@sinbin.demos.su> wrote:
# Compare with the Latin-1 alphabet:
# It would be silly to have different character sets for French, German,
# Spanish, etc. Why should we have several different charsets for Russian,
# Belarussian, Ukrainian, etc.??
koi8-r for Russian, koi8-u for Ukrainian, something for Belorussian, never
wrote in Belorussian.
# If you closely inspect
# <http://www.fingertipsoft.com/ref/cyrillic/isoir111.html>,
# you'll find that the code positions of *all* Russian letters in KOI-8
# and ISO-IR-111 are *identical*. Therefore, it makes no *practical*
# difference for the Russian language.
It does. A) ISO? What's that? An american standard? Great. KOI8-r is a standard
for Russian language even in Soviet Union, maximum I can recall is 1982.
Example is Russian PDP11's, - DVK{I,II,Mera}, Elektronika-60 etc.
B) What OS's/clients/whatever support ISO-IR-111?
Can be continued.
# On the other hand, KOI8-R is filled with completely useless,
# obsolete "box-drawing characters". ISO-IR-111 has been adopted for
# use with MIME in RFC 1700.
Not that this fight belongs to this group, but what's "obsolete...."?
KOI8 doesn't draw 'box-drawing...', but they are in the RFC ;P
See, Miscrosoft pushes it's clients/OS's users into cp-1251 coitus, so what?
It isn't the standard. There's GOST for ALT, I don't remember it, there's
KOI8-R. That's all. Of course, anyone can issue new encoding table, but
who said everyone should start following it? Nonsence.
# Andreas
You can contact ac...@nagual.ru, the author of the RFC1489, though I doubt if
he will be interested in the debates.
-mishania
Jeanne A. E. DeVoto
In article <5dlvph$sfo$1...@euas20.eua.ericsson.se>, ti...@htmlhelp.com wrote:
> The TABLE that follows I've used for layout-purposes, in order to put one
>image one each 'side' of the page. It has a 100% WIDTH, so as to do that.
>According to the specs, a <TABLE> is 'typically' rendered with a newline
>before and after, as it acts as a 'paragraph'. Sadly earlier versions of Lynx
>doesn't reckognise the TABLE element at all, and therefore doesn't render
>it that way. All 3.2 compliant versions of Lynx do, however. This I concede.
>I can fix that by putting in an extra <BR> in the appropriate place.
Yes, this one is fortunately simple to fix.
> Now for the poem. It is placed into a table - so that the two verses can be
>read - on browsers that support this - side by side. The reason why I have
>that poem there is irrelevant. In browsers that do not support tables, the
>verses of the poems are lined up beneath eachother, which they do in Lynx.
The last time I took a look at the page, the copyright and attribution
appeared in the middle of the poem when viewed in a table-impaired browser,
instead of at the end or otherwise separated. This was confusing, because
when viewed that way it's not clear whether you have put up two similar
poems - the first credited to Anne McCaffrey, the second uncredited and
perhaps your own creation - or whether it's all one poem with the
attribution stuck into the middle for some mysterious reason, or whether
perhaps it is "modern" verse. ;-) This was the second table problem I was
referring to.
This one is harder to fix. One possibility would be to put the two stanzas
into two cells of a table row, then use colSpan to put the attribution
centered beneath the two stanzas. Admittedly, this is not exactly the same
as your preferred rendering, but it would ensure the attribution comes last
in table-impaired browsers.
Now that I look again, there is also a problem where the first line of the
poem is stuck onto the last line of the previous paragraph. The browser is
ignoring the table tags, of course, and it has somehow decided to append
text outside a block-level element to the previous paragraph. I can't find
anything in the HTML 2.0 spec saying how text outside block elements should
be handled, so I'm not sure whether this is legal behavior, but at least
one elderly browser (MacWeb 1.0A32) out there apparently does do this.
> Thereafter follows a table, again used for layout-purposes,
>which lines up the 6 links that I have on my homepage. When viewed with a
>non-table-supporting browser, ie. a 2.0 one, it will degrade to something
>approximating the following:
This table does degrade nicely and look good.
>> Creating tables that degrade into a hash when viewed with a table-impaired
>> browser is a novice mistake, and your index page has two instances of it.
>
>Please explain the word 'hash' ? It would also be enlightening if a
>description of how the tables *do* degrade in a 2.0 browser could be
>presented.
Sorry: "hash" is idiom for "all mixed together". (Hash is a hot dish made
of a mixture of foods chopped up and cooked together. Usually leftover
corned beef and potatoes. Yum ;-).) See above for the description you ask
for.
>> Splitting the halves of a sentence between alt texts is a neat hack for
>> Lynx; unfortunately, like many such hacks, it does not travel gracefully to
>> the general case of browsers.
>
> This, again, *is* a stylistic issue. The ALT-texts, IMHO, convey the message
>they are intended to convey, albeit in a 'strange' - to you - manner. Are they
>*usable* ? If yes, then the matter of whether they are *likeable* not
>interesting.
I think they're unusable when viewed in a browser that doesn't display all
alt texts at once, and linearly. Here is my argument:
Suppose a visitor uses a browser that pops up alt texts when he uses the
mouse to point to an "image" icon. He sees this: "and it is Lynx Friendly."
He cannot see the first half of the sentence, since it's in another image's
alt attribute, and he may not have read that alt text yet. If he knows Lynx
is a browser, he may be able to figure out that "it" probably refers to the
web page; if he doesn't, he can have no way of understanding the message
conveyed by the alt text.
This is not as bad as it might be, since in this case neither image nor alt
convey information that's necessary to use the page. But I would not call
this usable alt text for the general case of browsers, although it's fine
in Lynx.
In fact, when I look at it in Netscape, because of the length of the alt
texts and the fact that Netscape restricts these texts to the width and
height of the image, I cannot read the "Validated" alt text but can read
the "Lynx-friendly" alt text. The way Netscape handles alt text is evil, of
course, but still, here is another case where the visitor might see one alt
text but not the other.
Unless the viewer has first read the "Validated" alt text (or is familiar
with Lynx and can guess what is meant), this alt text is difficult or
impossible to understand, because the context is missing. If the alt text
read something like "and the page is Lynx-friendly, too!" it would still be
a sentence fragment, which is a little strange out of context, but it would
convey the necessary information.
--
Tools, not rules.
Tina Marie Holmboe
[Mon, 10 Feb 1997 18:03:09] [Mikhail A. Sokolov]
> It does. A) ISO? What's that? An american standard? Great. KOI8-r is a standard
*DO* share with us what the acronym 'ISO' expands to. 'USA' ?
Tina Marie Holmboe
[Mon, 10 Feb 1997 12:43:09] [Jeanne A. E. DeVoto]
> instead of at the end or otherwise separated. This was confusing, because
> when viewed that way it's not clear whether you have put up two similar
> poems - the first credited to Anne McCaffrey, the second uncredited and
> perhaps your own creation - or whether it's all one poem with the
> attribution stuck into the middle for some mysterious reason, or whether
> perhaps it is "modern" verse. ;-) This was the second table problem I was
Hum, I do see your point, althought I am not sure I quite agree that it
is all that confusing. I'll take that on into consideration, however. Whether
I'd like, as you suggest, to use a more complex table - that I am not entirely
certain of. Perhaps a rethinking is due - after all, I've had this homepage
for all of 2 months. That is a *long* time... >:)
> Now that I look again, there is also a problem where the first line of the
> poem is stuck onto the last line of the previous paragraph. The browser is
> ignoring the table tags, of course, and it has somehow decided to append
> text outside a block-level element to the previous paragraph. I can't find
> anything in the HTML 2.0 spec saying how text outside block elements should
> be handled, so I'm not sure whether this is legal behavior, but at least
> one elderly browser (MacWeb 1.0A32) out there apparently does do this.
From what I see in the 2.0 specs, the </P> of the last paragraph is
'typically' be rendered with 'a line or half a line' before and after. Atleast
to me that suggests a blank line between it and whatever came next - whether
or not the browser actually understood what came next.
Hmm... it does smell 'error' of that one. Then again, as the specs also
state, the '...exact indentation, leading space, etc. of a paragraph is not
specified ...'
> Sorry: "hash" is idiom for "all mixed together". (Hash is a hot dish made
> of a mixture of foods chopped up and cooked together. Usually leftover
> corned beef and potatoes. Yum ;-).) See above for the description you ask
> for.
*grins* I think I didn't explain that question - I know what *hash* is,
after all, 'm a Perl Programmer ( No, Randal, I am *not* going to start that
debate again >:) - I meant more: "What'ya mean they look like *HASH* ??" - and
you've explained that...
> I think they're unusable when viewed in a browser that doesn't display all
> alt texts at once, and linearly. Here is my argument:
Read, and clipped out. Good argument; will consider.
And Jeanne - *this* is good and constructive critique you are giving. I
still cannot see that my Russian 'friend' did anything of the sort....
Alan J. Flavell
On 10 Feb 1997, Tina Marie Holmboe wrote:
> *DO* share with us what the acronym 'ISO' expands to. 'USA' ?
Well, the only ISO representatives I know happen to be French speakers.
Ann
Tina Marie Holmboe <ti...@htmlhelp.com> wrote
:
: *DO* share with us what the acronym 'ISO' expands to. 'USA' ?
: --
: Tina Marie Holmboe
"In 1947, the International Organization for Standardization (ISO)
was founded to promote the development of international standards
and related activities in order to facilitate the exchange of goods
and services on a worldwide basis. ISO is composed of national
representatives from over 91 countries, and is located in Geneva,
Switzerland. ISO's standardization effort extends to all fields
except those of electrical and electronic engineering, which is
the responsibility of the International Electrotechnical Commission
(IEC). The results of ISO's standardization effort are published
as international standards or guides.
The American National Standards Institute (ANSI) is the
United States' representative (U.S. member body) to ISO and
provides United States impute to ISO's standardization effort."
Alan J. Flavell
You sent me what I thought to be an email copy of a posting, but that
posting hasn't shown up yet, so I'm following up to a different
article of yours on the thread...
On Mon, 10 Feb 1997, Andreas Prilop wrote:
[...]
First, let me apologise for the inappropriate wording when I said
"koi8-r is recommended". It isn't my place at all to make
recommendations about which character set should be used by Cyrillic
authors - I neither use nor study this topic. I was aware, from a
discussion much earlier, that there are strongly held opinions amongst
the participants.
Please take this only as an assesment of the technical situation as seen
by an outsider. I do not wish to interfere with opinions.
If I have understood that facts right, then roughly speaking:
- koi8-r is a code used primarily by Russians
- non-Russians are opposed to it because it omits letters used
in non Russian Cyrillic languages. They use ISO-IRV-111 for
preference, another variant of the koi8 group of codes.
I already gave a reference for koi8-r:
http://www.nagual.ru/~ache/main.html
For ISO-IRV-111 you suggested the resources mentioned at
http://www.ukraine.org/press.html
It's a fact that Lynx correctly supports koi8-r, as best it can in its
terminal-oriented situation; and that Netscape and MS IE attempt to
support it too, although their support is defective in various ways (NS
misinterpret both the named and numbered entities, and only render 8-bit
characters correctly; MS IE renders the named entities correctly, but
misinterprets the numbered entities, and its rendering of the boxing
etc. characters is a bit of a kludge). SGML defines what "correctly"
means in this context, and it's explained also in the i18n area at W3C).
The browsers do not advertise support for iso-irv-111, although
there are some details, pointed out at that Ukraine Press site, on how
to persuade them to do so.
(I was using NS N 3.01, and MS IE 3.01 with "pan european" kit applied.
And Lynx 2.6, also 2.7 pre-release, for my tests).
Andrew Dacey
Alan J. Flavell (fla...@mail.cern.ch) wrote:
: You sent me what I thought to be an email copy of a posting, but that
: posting hasn't shown up yet, so I'm following up to a different
: article of yours on the thread...
: On Mon, 10 Feb 1997, Andreas Prilop wrote:
: [...]
: First, let me apologise for the inappropriate wording when I said
: "koi8-r is recommended". It isn't my place at all to make
: recommendations about which character set should be used by Cyrillic
: authors - I neither use nor study this topic. I was aware, from a
: discussion much earlier, that there are strongly held opinions amongst
: the participants.
: Please take this only as an assesment of the technical situation as seen
: by an outsider. I do not wish to interfere with opinions.
: If I have understood that facts right, then roughly speaking:
: - koi8-r is a code used primarily by Russians
: - non-Russians are opposed to it because it omits letters used
: in non Russian Cyrillic languages. They use ISO-IRV-111 for
: preference, another variant of the koi8 group of codes.
Why does everyone seem to think that KOI8-r does not support non-Cyrillic
languages? KOI8 contains both latin and cyrillic characters. The only
omission I have noticed is that you lack accented characters (the ascii
codes are being used for other characters instead). Being a Russian major
I have had need to use KOI8 when reading Russian web pages and have had
no problems with it (I have had some slight problems with specific pieces
of software but that's a different matter).
: It's a fact that Lynx correctly supports koi8-r, as best it can in its
: terminal-oriented situation; and that Netscape and MS IE attempt to
: support it too, although their support is defective in various ways (NS
: misinterpret both the named and numbered entities, and only render 8-bit
: characters correctly; MS IE renders the named entities correctly, but
: misinterprets the numbered entities, and its rendering of the boxing
: etc. characters is a bit of a kludge). SGML defines what "correctly"
: means in this context, and it's explained also in the i18n area at W3C).
I have suceeded in using KOI8 in the following programs (all via the mac):
-Lynx 2.42
-Lynx 2.6 (both versions of lynx work excellently if you are using a KOI
font)
-Netscape 3.01 (Let's you specify what font's to use for different doc
encodings so I have had no problems).
On the mac I have the advantage that I can switch the font on the fly in
my terminal emulator (not sure about any other platform) so then I can
switch directly to KOI8. In another program I can't do this but I have
had no problems with just using KOI8 for the entire session.
Warren Steel
> definition, I claim that the only correct thing to do is look up the meaning
> of the word - which includes the definition I quoted.
There are other ways, Tina--see below.
Jukka Korpela wrote:
> To look up the meaning of a word isn't such an easy thing, you know.
> Dictionaries provide rough descriptions. It is not uncommon to get lost
> if you take them too definitely. As I mentioned, I made the same mistake
> when interpreting what CITE was intended for. What really matters is what
> the words "cite" and "citation" are _actually_ used in the English language
> in general and in the language of the HTML specifications in particular.
> The HTML specifications have certainly been vague as regards to CITE, since
> people have interpreted them in two rather different ways and are often
> convinced they have the right interpretation.
> > - - HTML 3.0 used CREDIT to name book titles and authors. About
> > CITE, it says: "...specifies a citation... " - which, still, can be defined
> > as a quote...
> I'm not so familiar with HTML 3.0, but I have been told that it had a
> special text-level element Q "for short quotation". So obviously this
> was intended to be something different from CITE (for "citation").
> As regards to CREDIT, it was an element allowed within BLOCKQUOTE and
> "used to name the source of a block quotation or figure".
True, Jukka. This is one piece of evidence that CITE is to
be used for something other than a short quotation from another
work, shorter than BLOCKQUOTE. Even stronger, and more
authoritative, is the description and example in RFC 1866,
which I'll quote, even though I've done it here before:
" The CITE element is used to indicate the title of a book
or other citation. It is typically rendered as italics.
For example:
He just couldn't get enough of <cite>The Grapes of Wrath</cite>. "
Nothing vague about that, eh?
This is RFC 1866, HTML 2.0. HTML 3.0 continued this
usage, and added the Q element for bried quotations (the
rendering could thus follow national conventions). I have
seen no evidence that W3C intended to change the purpose of
CITE in the least, and can find no discussion to that effect.
In 3.2 the Q tag was dropped for lack of support, so that brief
quotes are best marked by whatever ISO-Latin-1 glyphs best
approximate the appropriate national style (single or double
quotes, or French guillemots, but not "curly" inverted commas
or the German baseline begin-quote).
I never saw Tina's note to which Jukka replied, but I'm
surprised if she's questioning this usage. The WDG site
formerly stated that CITE could be used for a brief quotation,
but altered their description when convincing evidence was
presented to the contrary. It now defines CITE as marking
"the title of a cited work," and adds the following notes:
" *Do not use CITE for anything but titles of cited works...
*There is no element in HTML 3.2 to mark up short cited
phrases... "
Jukka recently corrected a similar error in his "HTML 3.2
by examples" reference. I commend both of these sites for
correcting their earlier errors,and for helping to clarify
the usage of this element.
--
Warren Steel mu...@olemiss.edu
Department of Music University of Mississippi
URL: http://www.mcsr.olemiss.edu/~mudws/
Tina Marie Holmboe
[Tue, 11 Feb 1997 13:51:19] [Jukka Korpela]
> To look up the meaning of a word isn't such an easy thing, you know.
Agreed - partially. The original critic ( not me, btw ) claimed that CITE
was not really defined in a good manner, and that I used it wrongly.
According to what the word 'cite' means, I think I still am - however: it
*does* go against what the RFC and specs say. That is unfortunate.
> when interpreting what CITE was intended for. What really matters is what
> the words "cite" and "citation" are _actually_ used in the English language
> in general and in the language of the HTML specifications in particular.
No! There I cannot agree - when it comes to a language, what matters is the
accepted *definitions* of the word. The 'classic' example is the phrase:
"I'm gay!" - which, to me, indicates that the person who spoke it must be
very happy. *THAT* is what the word *means*, but the common use is something
else entirely, and so widespread that one can no longer use the original.
Whatever they thought of when they introduced CITE - I don't know. I don't
agree that it should be used for book titles, but I *have* changed my homepage
so that I do - regards to Jeanne for constructive critique. I don't agree
with the use, now, but I will stick to the RFC.
Personally I feel we should use words for what they are *meant*; not some
(arbitrary) definition of them.
> I'm not so familiar with HTML 3.0, but I have been told that it had a
> special text-level element Q "for short quotation". So obviously this
This is correct, 3.0 does contain such an element.
> As regards to CREDIT, it was an element allowed within BLOCKQUOTE and
> "used to name the source of a block quotation or figure".
Mm... I still think it sounds better with 'CITE used for citations or
references to other sources' in general. In other words; I think CITE can
be used for citations, as citations are defined.
--
Alan J. Flavell
On 11 Feb 1997, Andrew Dacey wrote:
> Alan J. Flavell (fla...@mail.cern.ch) wrote:
>
> : - non-Russians are opposed to it because it omits letters used
> : in non Russian Cyrillic languages. They use ISO-IRV-111 for
> : preference, another variant of the koi8 group of codes.
> Why does everyone seem to think that KOI8-r does not support non-Cyrillic
> languages?
I don't know. Do they? I never heard anyone suggest it. What has it
got to do with what I wrote?
> KOI8 contains both latin and cyrillic characters.
Sure.
> The only
> omission I have noticed is that you lack accented characters
Technically, you don't, because à still means a-grave, even
in a document of Content-type: text/html;charset=koi8-r. But few
browsers understand that yet (Lynx an honourable exception). Try
the i18n department at W3C for enlightenment, don't take it from me,
this is only usenet, where you can read the most ridiculous assertions.
(the ascii
> codes are being used for other characters instead).
No they aren't. Do you know what ASCII is? It's a 7-bit code that's
fully populated already, and has no room for anything extra. That's why
koi8-r needs 8 bits, using the upper half for the Cyrillic letters. I
defer to your ability as a Russian major, but where character codes are
concerned, I believe I know what I'm talking about already.
> : It's a fact that Lynx correctly supports koi8-r, as best it can in its
> : terminal-oriented situation;
> -Lynx 2.42
> -Lynx 2.6 (both versions of lynx work excellently if you are using a KOI
> font)
Of course they do. The limitations that I referred to have nothing to
do with the Cyrillic repertoire, they are confined to the ISO Latin-1
repertoire (i.e the named and numbered entities, unicode positions 160
to 255 inclusive) because they don't exist in the koi8-r font and have
to be approximated.
> -Netscape 3.01 (Let's you specify what font's to use for different doc
> encodings so I have had no problems).
Let's font's what?
Tell us how © comes out on Netscape, for example. It comes
out correctly on Lynx. And ² and · and ... but, then
they have to start approximating. Which is better than nothing, and
in the circumstances it's clear they have little choice. Unless
you can find a terminal emulation that supports ISO-2022-like
mechanisms.
Lizsue
Tina Marie Holmboe wrote:
>
> [Tue, 11 Feb 1997 13:51:19] [Jukka Korpela]
> Whatever they thought of when they introduced CITE - I don't know.
I don't
> agree that it should be used for book titles, but I *have* changed my
homepage
> so that I do - regards to Jeanne for constructive critique. I don't
agree
> with the use, now, but I will stick to the RFC.
>
> Personally I feel we should use words for what they are *meant*;
not some
> (arbitrary) definition of them.
>
> > I'm not so familiar with HTML 3.0, but I have been told that it had
a
> > special text-level element Q "for short quotation". So obviously
this
>
> This is correct, 3.0 does contain such an element.
>
> > As regards to CREDIT, it was an element allowed within BLOCKQUOTE
and
> > "used to name the source of a block quotation or figure".
>
> Mm... I still think it sounds better with 'CITE used for citations
or
> references to other sources' in general. In other words; I think CITE
can
> be used for citations, as citations are defined.
How about a compromise? If a citation can be an excerpt from
a book's main text, footnote text, preface text, etc., why not
from its title text?
Warren Steel
Tina Marie Holmboe wrote:
> Why the surprise ? A slight disagreement, as I do believe that the phrase
> '...for citations...' in the 3.2 spec includes the use of CITE for small
> quotations.
You may infer that, but the definition and the example in
RFC 1866 contravene that inference (as does the existence of
Q in the expired draft), in the absence of any evidence for
an intentional change in HTML 3.2.
You have, and others have had, occasional problems with the
connotations of the word "cite" which may seem like a synonym for
"quote." In scholarly discourse, however, one of the most
frequent uses of the word is in the phrase "cite your source"
for a given fact/assertion/etc. This usually means "identify
your source," not "quote from it." This is what the CITE
element is designed to do.
> > " *Do not use CITE for anything but titles of cited works...
> > *There is no element in HTML 3.2 to mark up short cited
> > phrases... "
> This is strange - the 3.2 spec specifically mentions 'citations' as a use
> for CITE; and so *only* 'titles of cited works' must be very restrictive.
> But that is a debate for another forum.
I think that those notes may be a bit restrictive. The
"citation" could conceivably include the author and publication
data as well as the title, but the rendering of the CITE element,
both in recommendation and in practice, as italic text, coincides
with that of book titles in modern style guides, and makes the
CITE element more useful for the title alone, as explicitly
stated in RFC 1866.
As for "there is no element in HTML 3.2 to mark up short
cited phrases," it might be useful to suggest that, in the
absense of a Q element such as in HTML 3.0, an author can
only mark such passages with nationally-appropriate
punctuation, inasmuch as this is possible using ISO-Latin-1.
Tina Marie Holmboe
[Tue, 11 Feb 1997 21:44:49] [Warren Steel]
> There are other ways, Tina--see below.
There is always More Than One Way >:)
> I never saw Tina's note to which Jukka replied, but I'm
> surprised if she's questioning this usage. The WDG site
Why the surprise ? A slight disagreement, as I do believe that the phrase
'...for citations...' in the 3.2 spec includes the use of CITE for small
quotations.
> " *Do not use CITE for anything but titles of cited works...
> *There is no element in HTML 3.2 to mark up short cited
> phrases... "
This is strange - the 3.2 spec specifically mentions 'citations' as a use
for CITE; and so *only* 'titles of cited works' must be very restrictive.
But that is a debate for another forum.
--
Tina Marie Holmboe
Toby Speight
-----BEGIN PGP SIGNED MESSAGE-----
Alan> Alan J Flavell <URL:mailto:fla...@mail.cern.ch>
>>>>> In
>>>>> <URL:news:Pine.HPP.3.95a.97021...@hpplus01.cern.ch>,
>>>>> Alan wrote:
Alan> On 10 Feb 1997, Tina Marie Holmboe wrote:
>> *DO* share with us what the acronym 'ISO' expands to. 'USA' ?
Alan> Well, the only ISO representatives I know happen to be French
Alan> speakers.
Perhaps Tina meant "North America", rather than "USA" ;-)
(As a British person in England, I know the feeling)
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQB1AwUBMwHIK+dsuUurvcRtAQFf+wMAgO0DH01IhYmj0GIg5KEYSMQuzS6sKupA
LBlnChqt4OQpy4C5vlIVyD8QdYbMeYibrUKQfCRZ0MMcJa+u67qstuKTDZa2NBTJ
GakZPe1hhk3abvLzQlrUAxXyTOSk6A+H
=iBst
-----END PGP SIGNATURE-----
Andreas Prilop
In article <5dqlrq$5...@News.Dal.Ca>,
da...@ug.cs.dal.ca (Andrew Dacey) wrote:
>Why does everyone seem to think that KOI8-r does not support non-Cyrillic
>languages? KOI8 contains both latin and cyrillic characters.
I'm not speaking of "non-Cyrillic" but of "non-Russian" languages:
Belarussian, Bulgarian, Macedonian, Serbian, Ukrainian.
>Being a Russian major
>I have had need to use KOI8 when reading Russian web pages and have had
>no problems with it (I have had some slight problems with specific pieces
>of software but that's a different matter).
I do not dispute this. The question is what do to with chars 160 to 191:
Fill with obsolete "box-drawing characters" or with non-Russian letters?
Please compare
<http://www.fingertipsoft.com/ref/cyrillic/isoir111.html>
with
<http://www.fingertipsoft.com/ref/cyrillic/koi8-r.html>
<http://www.fingertipsoft.com/ref/cyrillic/charsets.html>
What is more useful on the Web? Please note that *all* Russian letters
have identical code positions.
Andreas
Tina Marie Holmboe
[Wed, 12 Feb 1997 01:08:49] [Lizsue]
> How about a compromise? If a citation can be an excerpt from
> a book's main text, footnote text, preface text, etc., why not
> from its title text?
Sounds like a better idea to me ... anyone else wanting to comment ?
Tina Marie Holmboe
[posted and CC'ed]
[Wed, 12 Feb 1997 01:29:49] [Warren Steel]
> You may infer that, but the definition and the example in
> RFC 1866 contravene that inference (as does the existence of
> Q in the expired draft), in the absence of any evidence for
> an intentional change in HTML 3.2.
As long as 3.2 specifically mention 'citation' and 'reference', I don't
think we can simply overlook those.
> You have, and others have had, occasional problems with the
> connotations of the word "cite" which may seem like a synonym for
> "quote." In scholarly discourse, however, one of the most
> frequent uses of the word is in the phrase "cite your source"
> for a given fact/assertion/etc. This usually means "identify
> your source," not "quote from it." This is what the CITE
> element is designed to do.
I am not sure I agree... yes, that is the way it is interpreted, but the
3.2 specs still refer directly to 'citation' as a possible use. If we for a
second avoid bringing meaning with use from 2.0, and looking at the definition
of the word 'citation':
2) a) n, an act of quoting; esp: the citing of a previously
settled case at law
b) n, EXCERPT, QUOTE
From this I would claim that the CITE element in fact also is very useful
for actual quoting, but not for *large* amounts - perhaps exactly as it is
defined, for a case at law. This, I would presume, includes more than just the
title of the same case.
The way you describe it's intended use, as 'cite your source', is of
course consistent with this as well, but restricting it *only* to a title
is, IMHO, too strict.
When digging abit further, 'EXCERPT' is defined
ex.cerpt (n)
('ek-.s*rpt, 'eg-.z*rpt)
n, a passage selected or copied: EXTRACT
and again I'd say that using CITE as cite is used; ie. for a citation, or
an excerpt, is quite acceptable. There may only be subtle differences, but
nevertheless. (IMHO, of course)
And, FYI, I don't think I have a problem with the word 'cite', but I do
have a problem with the interpretation that it should only be used for
the title of a quoted work...
Warren Steel
I said
> > You may infer that, but the definition and the example in
> > RFC 1866 contravene that inference (as does the existence of
> > Q in the expired draft), in the absence of any evidence for
> > an intentional change in HTML 3.2.
Tina Marie Holmboe wrote:
> As long as 3.2 specifically mention 'citation' and 'reference', I don't
> think we can simply overlook those.
These terms obviously have multiple meanings. RFC 1866
is explicit, and removes all ambiguity. Unless you can show
*any* evidence of an intentional change in the meaning of the
CITE element, either in HTML 3.0 or 3.2. After all,
"citation" can also mean a summons to appear before the
magistrate. By this I mean that RFC 1866 specifies precisely
which of the definitions of "cite" and "citation" is relevant
to hypertext markup.
> > You have, and others have had, occasional problems with the
> > connotations of the word "cite" which may seem like a synonym for
> > "quote." In scholarly discourse, however, one of the most
> > frequent uses of the word is in the phrase "cite your source"
> > for a given fact/assertion/etc. This usually means "identify
> > your source," not "quote from it." This is what the CITE
> > element is designed to do.
> I am not sure I agree... yes, that is the way it is interpreted, but the
> 3.2 specs still refer directly to 'citation' as a possible use. If we for a
> second avoid bringing meaning with use from 2.0, and looking at the definition
> of the word 'citation': [quotes dictionary]
Why would you want to "avoid bringing meaning with use from
2.0," when that's the authoritative basis upon which the newer (and
less carefully worded, both here and elsewhere) recommendations
are based? The word "citation" also means a reference to an
authority in support of one's position.
The definition of CITE in the expired draft was no
more specific than that in 3.2, saying only that "The <CITE>
element specifies a citation." Was the CITE element in
HTML 3.0 designed for brief *quotations* from outside
sources? No, the Q element was used for this purpose.
Are you with me so far?
OK, why was Q omitted from HTML 3.2? I suggest (1)
because it was not widely implemented by "market leaders"
among browser vendors, and (2) because the same vendors
failed to implement the international "quotations marks"
conventions and LANG attributes which would have
determined how Q was rendered in various languages.
Can you accept this also?
OK, does the meaning of CITE change between HTML 3.0
and HTML 3.2? If CITE identical in 3.0 and 3.2, then
it can't be used as a brief quote, since HTML 3.0 had
both CITE and Q.
Again, can you "cite" any authority for supposing
that there was an intentional change in the meaning of
the CITE element, as opposed to careless wording? How
then, should be use the CITE element (which all sources
agree should be rendered in italics if possible)?
CITE: indicates titles of works cited
BLOCKQUOTE: indicates substantial (i.e.
block-level "quotations" from another work
How, then, should brief, text-level quotations be
indicated? Why, with quotation marks! In the
absence of the Q element, and its implied
internationalisation, we must fall back on the
ISO8859-1 character set. An indexer can still
locate block quotations by searching for the
BLOCKQUOTE tag; it can locate titles of books
or other works cited by searching for CITE; and
it can locate brief quoations by searching for
quotation marks.
I've already acknowledged that CITE could
conceivably embrace the author's name, publication
data, and page number, as well as the title. But
these would be stretching the clear intent of
RFC 1866, which also clarifies the meaning of
CITE in both Wilbur and the expired draft.
I see no more reason to use CITE for a quotation
than for a summons or a traffic ticket.
Jukka Korpela
Warren Steel <mu...@olemiss.edu> writes:
> How, then, should brief, text-level quotations be
> indicated? Why, with quotation marks!
Or with some other method compatible with the conventions of the
language which you use. One common method is to use italics;
in HTML, the I element. Certainly it is physical markup. But
<I>Vae victi!</I> is not less structured (from HTML viewpoint)
than "Vae victi!". I'd rather say it is more structured.
After all, the purpose of putting a quotation into quotes is to
indicate something about the text, namely that it is a reproduction
of a text taken from an external source. I want to indicate that this
text is not from me, I am just quoting it. If this goal can be achieved
equally well or better using some other method than quotation marks,
one can dispense with quotation marks.
In fact, it would be rather easy to introduce a Q element (as a text level
element for quotations) if it were taken in this sense: as an element
to be presented in a manner suitable for quotations irrespective of the
language used, such as in italics or in some specific color. Style sheets
would then provide mechanisms for affecting the representation.
Yucca, the author of "Learning HTML 3.2 by Examples",
http://www.hut.fi/~jkorpela/HTML3.2/
Warren Steel
I wrote: [in the absense of the Q element...]
> How, then, should brief, text-level quotations be
> indicated? Why, with quotation marks!
Jukka Korpela wrote:
> Or with some other method compatible with the conventions of the
> language which you use. One common method is to use italics;
> in HTML, the I element. Certainly it is physical markup. But
> <I>Vae victi!</I> is not less structured (from HTML viewpoint)
> than "Vae victi!". I'd rather say it is more structured.
Yes, there's some sense to that, if you're consistent.
I certainly use the I element for foreign words or phrases,
in place of I CLASS=foreign, and I for names in biological
taxonomy, I CLASS=taxon. Since I use CITE for book titles
(or opera or play titles), and DFN for defining instance of
terms, it's a simple mattter to search or index these items
by their function, and distinguish them from garden-variety
emphasis EM. An Aside: Opera 2.11 now renders DFN as
italics, as recommended in the HTML specs. I have seen
no other browser that users anything other than normal body
text for this element.
In fictional dialog, most American
books use double quotes " while many British books use single
quotes instead ' Some modern novels (Joyce et al.) use a long
dash. In other contexts, italics might fit the style.
> In fact, it would be rather easy to introduce a Q element (as a text level
> element for quotations) if it were taken in this sense: as an element
> to be presented in a manner suitable for quotations irrespective of the
> language used, such as in italics or in some specific color. Style sheets
> would then provide mechanisms for affecting the representation.
Style sheets, and/or the LANG attribute. Indeed, the Q
element is once again proposed in Cougar, as a text-level
element for brief quotations, now that both STYLE and LANG
are available to specify the rendering.
--
Warren Steel mu...@olemiss.edu
Department of Music University of Mississippi
Alan J. Flavell
Postings seem to be arriving here after random delays. I've addressed
this by following up to one of the followups, but I just wanted to
be sure to clear up the misunderstanding that I incautiously created...
On Mon, 10 Feb 1997, Andreas Prilop wrote:
> In article <Pine.HPP.3.95a.97020...@hpplus09.cern.ch>,
> "Alan J. Flavell" <fla...@mail.cern.ch> wrote:
>
> >is based on koi8-r (there exist other variants of koi8 code, but the
> >recommended one for use on the 'net is koi8-r).
>
> No!!
I'm sorry, It wasn't my intention to suggest that _I_ was recommending
koi8-r. I don't study Cyrillic, I only study character codes. I gather
that koi8-r is widely used in Russia, but you have pointed out its
limitations in respect of non-Russian Cyrillic languages.
My apologies again for any wrong impression caused.
Liam Quinn
On 13 Feb 1997 12:42:04 +0200, Jukka Korpela <jkor...@alpha.hut.fi>
wrote:
>In fact, it would be rather easy to introduce a Q element (as a text level
>element for quotations) if it were taken in this sense: as an element
>to be presented in a manner suitable for quotations irrespective of the
>language used, such as in italics or in some specific color.
With so many browsers not supporting Q (defined in the expired HTML
3.0 draft and resurrected in Cougar), I don't think it'd be that easy
to phase it in. If one uses <Q>The medium is the message</Q>, almost
all browsers will fail to render it as a quotation. Unfortunately, Q
isn't very backwards-compatible.
Liam Quinn
=============== http://www.htmlhelp.com/%7Eliam/ ===============
Web Design Group Enhanced Designs, Web Site Development
http://www.htmlhelp.com/ http://enhanced-designs.com/
Christopher Gray
In article <Pine.HPP.3.95a.97021...@hpplus01.cern.ch> "Alan J. Flavell" <fla...@mail.cern.ch> writes:
On 10 Feb 1997, Tina Marie Holmboe wrote:
> *DO* share with us what the acronym 'ISO' expands to. 'USA' ?
Well, the only ISO representatives I know happen to be French speakers.
Nonetheless, ISO standards are not just published in French: the other
two official languages are English and, um, Russian.
--
________________________________________________________________________
Chris Gray Chris...@bcs.org.uk Compuserve: 100065,2102
http://columbia.digiweb.com/kiffer/chris_gray/
________________________________________________________________________
Ardua molimur: sed nulla nisi ardua virtus
John Russell
Warren Steel <mu...@olemiss.edu> wrote:
> OK, why was Q omitted from HTML 3.2? I suggest (1)
>because it was not widely implemented by "market leaders"
>among browser vendors, and (2) because the same vendors
>failed to implement the international "quotations marks"
>conventions and LANG attributes which would have
>determined how Q was rendered in various languages.
>Can you accept this also?
Having used a markup language (IBM's BookMaster) with a quotation tag
for several years, MHO is that it's more trouble than it's worth. A
common action that a processor might take is to move punctuation
inside or outside the quotation marks. This makes it risky to use in
technical writing, where often the punctuation is significant and
should not be moved.
Having 3 different ways to indicate quotations (", ", and <q>)
tends to be confusing for writers. <q> gets used for any situation
where one would typically use quotation marks, not necessarily for
true <q>quotations</q>. :-)
John
--
John Russell
joh...@interlog.com, http://www.interlog.com/~john13/
Jukka Korpela
joh...@interlog.com (John Russell) writes:
> Having used a markup language (IBM's BookMaster) with a quotation tag
> for several years, MHO is that it's more trouble than it's worth. A
> common action that a processor might take is to move punctuation
> inside or outside the quotation marks.
This indeed is a problem. Different languages have different conventions
in this respect, and it seems to me that even within the English language
there are different practices. I can understand that Web browser vendors
have not been enthusiastic about multinationalization (called
"internationalization" in Webbish), i.e. requirements on supporting
various features different languages. (There are a few thousand languages
in the world. Although we are only talking about Web-related issues
like directionality and punctuation conventions, this is really
a complicated issue.)
What I proposed was essentially that the Q element be defined so that
it affects the presentation of its contents only, the typical rendering
being in italics (but e.g. changing font or background color instead of
or in addition to font style change would be feasible). This would make
it independent of the difficult LANG issue.
> Having 3 different ways to indicate quotations (", ", and <q>)
> tends to be confusing for writers. <q> gets used for any situation
> where one would typically use quotation marks, not necessarily for
> true <q>quotations</q>. :-)
In fact, " and " are not essentially different ways to indicate
quotations. They are, by HTML definition, equivalent; there is difference
in the HTML file only, not in the representation.
On the other hand, there are _lots_ of different ways to indicate
quotations when quotation marks are used. To mention a few actually
used in different languages:
"Non multa, sed multum."
"Non multa, sed multum".
'Non multa, sed multum.'
«Non multa, sed multum.»
plus several others which cannot be presented in ISO Latin 1.
Still one more reason to avoid quotation marks for quotations: quotes
are often used to denote that a word or expression is used in a special
meaning or context, often ironically, as in
His "helpful" advice - -
Confusions may arise if people take such quotes as indicating quotation
or quotation marks as indicating e.g. irony. So it is better to reserve
quotes for such special use and indicate quotations by other means such
as font change (the details being browser dependent and style sheet
controllable).
Yucca, http://www.hut.fi/~jkorpela/
glenn mcdonald
Jukka Korpela <jkor...@alpha.hut.fi> wrote in article
<oipvxxn...@alpha.hut.fi>...
> it is better to reserve quotes for such special use and indicate
> quotations by other means such as font change
Well, several Western cultures, at least, have gotten along fine using
quotation marks to denote quotations for quite a while now.
Jukka Korpela
"glenn mcdonald" <gmcd...@instinctive.com> writes:
> Well, several Western cultures, at least, have gotten along fine using
> quotation marks to denote quotations for quite a while now.
Admittedly. And the basis of the Western civilization was created
VSING VPPERCASE ONLY and without even making distinction between u and v.
And without any kind of quotation marks, to be exact.
Now, honestly with all respect to our cultural ancestry, I'd like to
suggest that we could use some more suitable techniques for presenting
written information.
There is a difference, you know, between use and abuse (of fonts).
Abusus non tollit usum.
--
Yucca, http://www.hut.fi/~jkorpela/