I've not had a clear definition in my mind of "citation," and so have
avoided it. For example, if I suggest that the reputation of the New
York Times has suffered, is that a citation?
I suppose it really is and I should shift to <cite> and give up the
use oif a custom CSS tag such as a "title" class. However, that also
brings up a question. What is the proper format for a citation? I've
seen it underlined (Chicago, I guess), italicized, or left
unadorned. Is there a prefered format for HTML, or some consensus over
a global standard?
--
Haines Brown br****@hartford-hwp.com kb****@arrl.net www.hartford-hwp.com 59 5148
"Haines Brown" <br****@teufel.hartford-hwp.com> wrote in message
news:87************@teufel.hartford-hwp.com... I've not had a clear definition in my mind of "citation," and
so have avoided it. For example, if I suggest that the reputation of
the New York Times has suffered, is that a citation?
I suppose it really is and I should shift to <cite> and give up
the use oif a custom CSS tag such as a "title" class. However, that
also brings up a question. What is the proper format for a citation?
I've seen it underlined (Chicago, I guess), italicized, or left unadorned. Is there a prefered format for HTML, or some
consensus over a global standard?
Here's my take on it, not saying it's the gospel or anything.
Use <q> for very short quotes. <p>I thought he said
<q>trouser</q> but he actually said <q>browser</q>.</p> All
browsers I've seen express this as "quote" except IE which does
nothing.
Use <cite> for longer quotes within one block element, or for
special names which should be italicized (like magazines, ships,
etc.). All browsers I've seen italicize <cite>, even IE. BTW, I
was taught in school that italics are the print version of
underlining on a typewriter, and if you can do italics it's
preferred. Also, I wouldn't do much underlining in HTML as that
makes it look like a link.
Use <blockquote> when there is a complete block element or more
quoted. Browsers will deepen the margins for this.
"Neal" <ne**@spamrcn.com> wrote in message
news:3f**********************@news.rcn.com... "Haines Brown" <br****@teufel.hartford-hwp.com> wrote in message news:87************@teufel.hartford-hwp.com... I've not had a clear definition in my mind of "citation," and so have avoided it. For example, if I suggest that the reputation of the New York Times has suffered, is that a citation?
[snip] Here's my take on it, not saying it's the gospel or anything.
Use <q> for very short quotes. <p>I thought he said <q>trouser</q> but he actually said <q>browser</q>.</p> All browsers I've seen express this as "quote" except IE which does nothing.
Use <cite> for longer quotes within one block element, or for special names which should be italicized (like magazines, ships, etc.).
Citation is not the same thing as quotation. It's the identification of the
source of a quotation or of information. As the W3C explains, a <cite> tag
"contains a citation or a reference to other sources." The examples they
give are:
As <CITE>Harry S. Truman</CITE> said,
<Q lang="en-us">The buck stops here.</Q>
More information can be found in <CITE>[ISO-0000]</CITE>.
I personally don't see any point to it. For one thing, when using the kind
of browser that *does* emulate print in the way it presents a document (that
is, your garden variety graphical browser), I don't expect to see effects
that aren't traditionally called for. If I read in a book or in an
advertisement,
As Harry S. Truman said, "The buck stops here."
I would be startled if "Harry S. Truman" were italicized, because there's no
reason for it.
As you point out, book and magazine titles and the like *are* conventionally
italicized, but they are so even when they're not being cited (as in, "I saw
a copy of <?>The Observer</?> lying on his desk"), so it doesn't really
make sense, semantically speaking, to use the <cite> tag with them. You
might as well just use <em> or, if you want to leave yourself the
flexibility to change how titles appear beyond italicization, <span
class="title">
Haines Brown <br****@teufel.hartford-hwp.com> wrote: I suppose it really is and I should shift to <cite> and give up the use oif a custom CSS tag such as a "title" class. However, that also brings up a question. What is the proper format for a citation? I've seen it underlined (Chicago, I guess), italicized, or left unadorned. Is there a prefered format for HTML, or some consensus over a global standard?
MLA style: <p><q>Yes, I did it</q> <cite>(Smith 98)</cite>.</p>
APA style: <p><q>Yes, I did it<q> <cite>(Smith, 2003, p. 98)</cite>.</p>
Chicago style: <p><q>Yes, I did it</q><cite><sup><a
href="#footnote">1</a></sup></cite>.</p>
Since <cite> is inline, it makes sense to use it for inline quotes. Note
that the text of the quote is within the <q> tag.
You aren't supposed to include the quote marks in the <q> tags, but since IE
doesn't insert them like it's supposed to, you can add them yourself and
then disable the automatic quotes with style sheets.
--
Michael Wilcox
mjwilco at yahoo dot com
Essential Tools for the Web Developer - http://mikewilcox.t35.com
"Harlan Messinger" <h.*********@comcast.net> writes: "Neal" <ne**@spamrcn.com> wrote in message
Citation is not the same thing as quotation. It's the identification of the source of a quotation or of information. As the W3C explains, a <cite> tag "contains a citation or a reference to other sources." The examples they give are:
As <CITE>Harry S. Truman</CITE> said, <Q lang="en-us">The buck stops here.</Q>
More information can be found in <CITE>[ISO-0000]</CITE>.
Yes, I don't see any relation between citation and quotation. I'm
surprised that association has come up in this thread. The two seem
entirely different things. On the other hand, I have no idea why the
WC3 examples put the <cite> around the author of a quotation. That's a
real surprise to me. It seems far removed from the usual meaning of
the word "citation," and certainly would confuse anyone used to normal
typographic practice.
...I don't expect to see effects that aren't traditionally called for.
Exactly, the examples would seem to imply a reference to a book named
"Harry S. Truman."
As you point out, book and magazine titles and the like *are* conventionally italicized, but they are so even when they're not being cited (as in, "I saw a copy of <?>The Observer</?> lying on his desk"), so it doesn't really make sense, semantically speaking, to use the <cite> tag with them. You might as well just use <em> or, if you want to leave yourself the flexibility to change how titles appear beyond italicization, <span class="title">
Yes, this is the point of my question. Because there are situations in
which a work is mentioned, but not as a citation, I cooked up a
class="title" which put the content in italics, but I was criticized
for doing that and told to use <cite>. So I came to feel insecure
about it. Also, the names of articles being cited don't normally get
italicized, but simply put into quotes. and so one would not use
<cite> even though you are citing a work. Typographic convention would
do this with a citation, for example: Haines Brown,
<q>Postalgeschichte Sudchinas.</q> To italicize the name of the work
would imply it was a book.
But let me expand on this question. What about Web pages. Would, for
example, a reference to the web page, World History Archives, but put
in quotes or italicized?
--
Haines Brown br****@hartford-hwp.com kb****@arrl.net www.hartford-hwp.com
Haines Brown wrote: the names of articles being cited don't normally get italicized, but simply put into quotes. and so one would not use <cite> even though you are citing a work.
<P>In <cite class="article">An Aggressive Conservative vs. a "Liberal
to be Determined"</cite>, I read that "a systematic review of 'Hannity
& Colmes' does reveal a show listing to the right in virtually every
respect...."
cite.article {font-style: normal;}
--
Brian
follow the directions in my address to email me
"Brian" <us*****@julietremblay.com.invalid-remove-this-part>
wrote in message news:VpmKb.753338$Tr4.2093067@attbi_s03... Haines Brown wrote: the names of articles being cited don't normally get
italicized, but simply put into quotes. and so one would not use <cite>
even though you are citing a work. <P>In <cite class="article">An Aggressive Conservative vs. a
"Liberal to be Determined"</cite>, I read that "a systematic review of
'Hannity & Colmes' does reveal a show listing to the right in virtually
every respect...."
cite.article {font-style: normal;}
Well, I was the one confused about the purpose of <cite> so
apologies. This example served only to support my misconception: http://www.htmldog.com/reference/htmltags/cite/ . Upon reviewing
the recommendation, I think I have it now.
However, the above markup will show italics when there is no CSS
loaded. I know it's a situation where there's no good
alternative, but seems to me the W3C has neglected this when it
comes to tags.
If we want a content-driven meaningful markup shouldn't there be
separate tags for a quoted citation, such as an article or a
chapter or a TV episode, and an italicized citation, such as a
book or movie? While we're at it, a pair of tags dedicated to
other titles which are properly italicized, like ships and such -
as they are not citations, we're stuck. If there were tags for
each of these, browsers could render them appropriately AND we'd
have meaningful markup.
Seems to me proper font and such, in this type of situation, is a
matter of meaning and not presentation. There's a meaningful
difference between:
<p>I saw Harvey last night.</p>
and:
<p>I saw <title>Harvey</title> last night.</p>
Just one example of how, in the attempt to move all "decoration"
to stylesheets, the traditions of meaningful text presentation
have to be abandoned for those whose browsers can't access CSS.
Brian <us*****@julietremblay.com.invalid-remove-this-part> writes: Haines Brown wrote: the names of articles being cited don't normally get italicized, but simply put into quotes. and so one would not use <cite> even though you are citing a work.
<P>In <cite class="article">An Aggressive Conservative vs. a "Liberal to be Determined"</cite>, I read that "a systematic review of 'Hannity & Colmes' does reveal a show listing to the right in virtually every respect...."
cite.article {font-style: normal;}
Aha! Of course! But in this example, I'd probably also want to have
the class put quotation marks around the article title. This presents
an interesting challenge! Here's its parameters:
An article class that
1. puts a double quotation mark at beginning and end of the enclosed
string,
2. and does it through the use of <q> so any nested quotations (as in
the example above), also tagged <q>, acquire the proper quotation
symbols.
So, the above example would then appear as:
In "An Aggressive Conservative vs. a 'liberal to be...
(except, of course, with typographic quotes). I bet there's a solution
to this, but it's not coming to me off hand.
--
Haines Brown br****@hartford-hwp.com kb****@arrl.net www.hartford-hwp.com
"Haines Brown" <br****@teufel.hartford-hwp.com> wrote in message
news:87************@teufel.hartford-hwp.com... "Harlan Messinger" <h.*********@comcast.net> writes:
"Neal" <ne**@spamrcn.com> wrote in message
Citation is not the same thing as quotation. It's the identification of the source of a quotation or of information. As the W3C explains, a <cite> tag "contains a citation or a reference to other sources." The examples they give are:
As <CITE>Harry S. Truman</CITE> said, <Q lang="en-us">The buck stops here.</Q>
More information can be found in <CITE>[ISO-0000]</CITE>.
Yes, I don't see any relation between citation and quotation. I'm surprised that association has come up in this thread. The two seem entirely different things. On the other hand, I have no idea why the WC3 examples put the <cite> around the author of a quotation. That's a real surprise to me. It seems far removed from the usual meaning of the word "citation," and certainly would confuse anyone used to normal typographic practice.
That's *is* the meaning of "citation"--the identification of the source of
some information or of a quotation. It's just that as far as typography is
concerned, citation isn't of interest, since there isn't any typographical
convention applicable to it as such.
1. "The end of the world is coming next week," reported the Reverend Sam
Doomsday.
2. "The end of the world is coming next week," reported *The New York
Times*.
3. The *New York Times* is published daily.
1 and 2 include citations. 2 and 3 include the title of a newspaper. 2 and 3
get italics. The only way I can see using the <cite> tag at all is to deem
it to be an incorrectly named tag that's meant to denote a typographically
significant title:
1. "The end of the world is coming next week," reported the Reverend Sam
Doomsday.
2. "The end of the world is coming next week," reported <cite>The New
York Times</cite>.
3. The <cite>New York Times</cite> is published daily.
1 and 2 include citations; 2 and 3 use <cite>. I'd rather have the tag
renamed. In the meantime, I prefer your solution, using a "title" class,
better.
"Neal" <ne**@spamrcn.com> writes: "Brian" <us*****@julietremblay.com.invalid-remove-this-part> wrote in message news:VpmKb.753338$Tr4.2093067@attbi_s03...
Well, I was the one confused about the purpose of <cite> so apologies. This example served only to support my misconception: http://www.htmldog.com/reference/htmltags/cite/ .
I'll say! The example there is:
<p>And he said <cite>banana</cite>.</p>
This makes no sense to me at all, for it appears a simple quotation.
If we want a content-driven meaningful markup shouldn't there be separate tags for a quoted citation, such as an article or a chapter or a TV episode, and an italicized citation, such as a book or movie?
The previous message in this dialog seems to have it: use of an
appropriate class, such as class="article".
While we're at it, a pair of tags dedicated to other titles which are properly italicized, like ships and such - as they are not citations, we're stuck. If there were tags for each of these, browsers could render them appropriately AND we'd have meaningful markup.
Excuse my ignorance, but are ships names, such as USS Irex SS-482,
italicized? If so, that would not be a citation, and so I guess one
has to cook up a custom class, such as <spam class="title">.... Does
this satisfy your preceived need?
Seems to me proper font and such, in this type of situation, is a matter of meaning and not presentation. There's a meaningful difference between:
<p>I saw Harvey last night.</p>
and:
<p>I saw <title>Harvey</title> last night.</p>
Just one example of how, in the attempt to move all "decoration" to stylesheets, the traditions of meaningful text presentation have to be abandoned for those whose browsers can't access CSS.
Not sure I quite follow you here. Not to strain the point, but there
seem three possibilities:
1. I placed the volume <span class="title">Harvey</span> on the table
2. I spoke with Harvey last night and also his wife.
3. I saw <cite>Harvey</cite> at the Majestic theater last night.
Granted, non-CSS browswers won't see the distinctions, but I'm not
sure there is any way around this.
--
Haines Brown br****@hartford-hwp.com kb****@arrl.net www.hartford-hwp.com
Neal wrote: However, the above markup will show italics when there is no CSS loaded. I know it's a situation where there's no good alternative, but seems to me the W3C has neglected this when it comes to tags.
The HTML spec doesn't really say anything about presentation, does it?
There are proposed styles for visual browsers, but that's separate
from the markup language.
If we want a content-driven meaningful markup shouldn't there be separate tags for a quoted citation, such as an article or a chapter or a TV episode, and an italicized citation, such as a book or movie?
With all due respect, it seems you're thinking about this the wrong
way. HTML says nothing about presentation. <CITE> does not say "put in
italics," any more than <BLOCKQUOTE> says "indent this." They describe
the contents of the element.
Your point is better made by saying that HTML should have an element
to cite a book, and a different one to cite an article. But then why
not have a third to cite a magazine. A fourth to cite a play. If HTML
had a tag for every conceivable need, it would become very unwieldy.
While we're at it, a pair of tags dedicated to other titles which are properly italicized, like ships and such - as they are not citations, we're stuck.
But Lynx users would be stuck either way, since it cannot render italics.
Seems to me proper font and such, in this type of situation, is a matter of meaning and not presentation.
I think you're trying to make a distinction between presentation for
decoration -- e.g., making paragraph text green instead of black --
and presentation used to convey information -- e.g., italicizing the
title of book. I see where you're going, but I don't think it's quite
appropriate for HTML.
HTML is not about presentation, it is about meaning. Putting something
in italics is a presentation that is associated with meaning and has a
history in typesetting. But HTML is supposed to attach meaning and let
the ua determine how to express that meaning.
Just one example of how, in the attempt to move all "decoration" to stylesheets,
To take it out of HTML, which is how it was at its origins, no? AFAIK,
presentation was *added* to html at 3.2. CSS is in part an attempt to
take it back out.
the traditions of meaningful text presentation have to be abandoned for those whose browsers can't access CSS.
....and cannot do what you want in any case. What meaning does italics
have in braille? An aural browser?
--
Brian
follow the directions in my address to email me
"Brian" <us*****@julietremblay.com.invalid-remove-this-part>
wrote in message news:ASzKb.764546$Fm2.731352@attbi_s04... I think you're trying to make a distinction between
presentation for decoration -- e.g., making paragraph text green instead of
black -- and presentation used to convey information -- e.g.,
italicizing the title of book. I see where you're going, but I don't think
it's quite appropriate for HTML.
As things are leaning toward XML, it seems logical to go in that
direction.
HTML is not about presentation, it is about meaning. Putting
something in italics is a presentation that is associated with meaning
and has a history in typesetting. But HTML is supposed to attach meaning
and let the ua determine how to express that meaning.
I guess a good place to have started would have been to at least
have enough tags to allow visual browsers to do that within
traditional style. (As if IE would have gotten it right
anyway...) And I understand that different languages have
different conventions, too - I'm sure book titles aren't
italicized in, say, Russian. But it seems to me that the
compromise arrived at by the W3C results in it not working for
anyone, and I suppose that's fair - though a strange sort of
fair.
"Haines Brown" <br****@teufel.hartford-hwp.com> wrote in message
news:87************@teufel.hartford-hwp.com... I'll say! The example there is:
<p>And he said <cite>banana</cite>.</p>
This makes no sense to me at all, for it appears a simple
quotation.
Agreed. This is otherwise a very good resource.
Haines Brown wrote: An article class that 1. puts a double quotation mark at beginning and end of the enclosed string,
Punctuation should be in the content of the document.
2. and does it through the use of <q> so any nested quotations (as in the example above), also tagged <q>, acquire the proper quotation symbols.
I'd avoid the <q> element. It was a mistake to require that a ua add
the punctuation, since that broke backward compatibility. Using <q>
without adding quotation marks -- as the spec requires -- leaves
MSIE/Win users (currently a majority of users) with no clue that the
enclosed text is a quotation.
So, the above example would then appear as:
In "An Aggressive Conservative vs. a 'liberal to be...
(except, of course, with typographic quotes).
I should have included the correct punctuation in my proposal. Here's
an update:
<P>In <cite class="article">"An Aggressive Conservative vs. a 'Liberal
to be Determined'</cite>," I read that "a systematic review of
'Hannity & Colmes' does reveal a show listing to the right in
virtually every respect...."</P>
cite.article {font-style: normal}
--
Brian
follow the directions in my address to email me
"Brian" <us*****@julietremblay.com.invalid-remove-this-part> wrote in
message news:VpmKb.753338$Tr4.2093067@attbi_s03... Haines Brown wrote: the names of articles being cited don't normally get italicized, but simply put into quotes. and so one would not use <cite> even though you are citing a work.
<P>In <cite class="article">An Aggressive Conservative vs. a "Liberal to be Determined"</cite>, I read that "a systematic review of 'Hannity & Colmes' does reveal a show listing to the right in virtually every respect...."
cite.article {font-style: normal;}
That makes some sense: Use <cite> for all citations, and assign them all to
classes. But, on the other hand, to me the significant feature of a title,
from a document structure perspective, is that it is a title, not that it is
cited, and it should be presented in the same manner whether it is part of a
citation or not. So I think the whole <cite> thing is just ill-conceived.
"Harlan Messinger" <h.*********@comcast.net> wrote in message
news:bt************@ID-114100.news.uni-berlin.de... That's *is* the meaning of "citation"--the identification of
the source of some information or of a quotation. It's just that as far as
typography is concerned, citation isn't of interest, since there isn't any
typographical convention applicable to it as such.
I think it's most commonly seen when courts refer to, say,
<cite>Roe vs. Wade</cite>.
"Brian" <us*****@julietremblay.com.invalid-remove-this-part> wrote in
message news:ASzKb.764546$Fm2.731352@attbi_s04... HTML is not about presentation, [...]
It is entirely possible to transmit information over the web as
"text/plain". If the purpose of "text/html" isn't to add tags *with the
expectation that they will be used by user agents, to the extent possible,
to assist in the presentation*, then either (1) there is some other
practical purpose to it, or (2) there isn't.
If there is, what is it? The pat answer, to provide information about
document structure, is circular, because it only leads back to the question,
"What is the value in providing information about document structure if it's
not going to be used in some manner in producing the presentation?"
If there isn't, why bother with tags? Why does anybody bother with tags,
other than because tags are expected to have some impact on the way the
resource will be presented to the user? The answer is that there wouldn't be
any reason.
"HTML is not about presentation" is a hyperbolic misstatement of the valid
precept that HTML is not about presentational *details*.
[...] it is about meaning.
If they are not translated into presentational cues, <cite> and <q> and
<blockquote> and <em> have no meaning at all to the user, and the HTML
stream then has no more meaning than a plain text stream with the same
content. The "meaning" conveyed by HTML tags is commensurate with their use
presentationally by the user agent.
Putting something in italics is a presentation that is associated with meaning and has a history in typesetting. But HTML is supposed to attach meaning and let the ua determine how to express that meaning.
Just one example of how, in the attempt to move all "decoration" to stylesheets,
To take it out of HTML, which is how it was at its origins, no? AFAIK, presentation was *added* to html at 3.2. CSS is in part an attempt to take it back out.
the traditions of meaningful text presentation have to be abandoned for those whose browsers can't access CSS.
...and cannot do what you want in any case. What meaning does italics have in braille? An aural browser?
None. If I were writing *only* for those platforms, <em> would have *no*
meaning, and I would never, ever bother with using it. I only use it solely
because the information it provides *is* used presentationally by many of
the user agents through which it is rendered, and therein lies its
meaning--at least, meaning that is of any value.
Harlan Messinger wrote: Brian wrote
HTML is not about presentation, [...] If the purpose of "text/html" isn't to add tags *with the expectation that they will be used by user agents, to the extent possible,
That is the purpose of html. <em> is for emphasis, not italics. It is
up the ua to determine how to present it.
"HTML is not about presentation" is a hyperbolic misstatement of
No. HTML is not about presentation, it is about meaning. UAs are
about presentation. ...and cannot do what you want in any case. What meaning does italics have in braille? An aural browser?
None. If I were writing *only* for those platforms, <em> would have *no* meaning, and I would never, ever bother with using it.
Really? I expect <em> to having meaning in any presentation. For
example, I'd expect an aural ua to change the voice inflection for
content inside <em>.
--
Brian
follow the directions in my address to email me
"Brian" <us*****@julietremblay.com.invalid-remove-this-part> wrote in
message news:baBKb.764978$Fm2.732066@attbi_s04... Harlan Messinger wrote: Brian wrote
HTML is not about presentation, [...] If the purpose of "text/html" isn't to add tags *with the expectation that they will be used by user agents, to the extent possible,
That is the purpose of html. <em> is for emphasis, not italics. It is up the ua to determine how to present it.
"HTML is not about presentation" is a hyperbolic misstatement of
No. HTML is not about presentation, it is about meaning. UAs are about presentation.
Repeating a fallacy and ignoring my explanation of why it is wrong doesn't
establish your assertion any more firmly. How do you suppose the UA,
whatever its internal rules may be, would know how to arrange a presentation
without the markup to apply the rules to? And that's the *only* reason for
the markup to exist. It's absurd to insist that code whose sole purpose is
to give the user agent the cues it needs to arrange the presentation isn't
"presentational". It's like saying, "Take two aspirins" isn't a medical
instruction; it's only my compliance with that instruction that's medical. ...and cannot do what you want in any case. What meaning does italics have in braille? An aural browser?
None. If I were writing *only* for those platforms, <em> would have *no* meaning, and I would never, ever bother with using it.
Really? I expect <em> to having meaning in any presentation. For example, I'd expect an aural ua to change the voice inflection for content inside <em>.
I was responding to Neal's implication that it *wouldn't* have any meaning
in such a user-agent. Your response is based on the opposite premise, so
it's inapplicable to my remark to him. I'll let you and Neal fight it out.
"Neal" <ne**@spamrcn.com> wrote in message
news:3f**********************@news.rcn.com... "Harlan Messinger" <h.*********@comcast.net> wrote in message news:bt************@ID-114100.news.uni-berlin.de... That's *is* the meaning of "citation"--the identification of the source of some information or of a quotation. It's just that as far as typography is concerned, citation isn't of interest, since there isn't any typographical convention applicable to it as such.
I think it's most commonly seen when courts refer to, say, <cite>Roe vs. Wade</cite>.
I don't know where you get the "most" from, but that certainly is another
kind of citation.
Harlan Messinger wrote: Brian wrote
Harlan Messinger wrote:
Brian wrote
HTML is not about presentation
If the purpose of "text/html" isn't to add tags *with the expectation that they will be used by user agents, to the extent possible, That is the purpose of html. <em> is for emphasis, not italics. It is up the ua to determine how to present it.
"HTML is not about presentation" is a hyperbolic misstatement
No. HTML is not about presentation, it is about meaning. UAs are about presentation.
Repeating a fallacy
It's not a fallacy, and I did not repeat it. But since you missed the
point, I will repeat it here: in principle, the html model leaves
presentation to the ua.
and ignoring my explanation of why it is wrong doesn't establish your assertion any more firmly.
I could say the same thing to you.
How do you suppose the UA, whatever its internal rules may be, would know how to arrange a presentation without the markup to apply the rules to?
How does this contradict my statement? The ua presents e.g. <em>
markup as italicized. Or as bold. Or spoken more forcefully. etc. What meaning does italics have in braille? an aural browser?
None. If I were writing *only* for those platforms, <em> would have *no* meaning, and I would never, ever bother with using it.
Really? I expect <em> to having meaning in any presentation. For example, I'd expect an aural ua to change the voice inflection for content inside <em>.
I was responding to Neal's implication that it *wouldn't* have any meaning in such a user-agent. Your response is based on the opposite premise, so it's inapplicable to my remark to him. I'll let you and Neal fight it out.
I have no idea what you're on about. You were responding to me in this
exchange, which is composed only of things you and I wrote.
--
Brian
follow the directions in my address to email me
On Tue, 6 Jan 2004, Harlan Messinger wrote: Repeating a fallacy and ignoring my explanation of why it is wrong doesn't establish your assertion any more firmly.
Quite right. It's no fallacy that the majority of misguided web page
authors think HTML is some kind of low-grade DTP, without any regard
to underlying structure.
However, it's an admissible leap of faith to claim that because these
supporters of Sturgeon's Law are all doing it, therefore it must have
been the intention of HTML all along.
The HTML specifications do occasionally mention typical presentations
used by the then-current browsers for representing logical markups;
one might suppose that the folks who wrote that were crediting their
readers with a greater power of abstract thought than has been
justified by experience, and that they should have tried harder to
distance themselves from the implication that these mentioned visual
presentations were the One True Result of such logical markups.
How do you suppose the UA, whatever its internal rules may be, would know how to arrange a presentation without the markup to apply the rules to?
What? A stressed voice, oblique font, or underlined text, are all
valid representations of emphasis, and each of those presentations
(and no doubt others which don't come to mind right now) appear in
actual browser presentations of emphasis.
And, to take another example, a valid presentation of Hn elements
would be an Overview menu. Some browsers already offer this; others
can do it with client-side scripts, bookmarklets etc.
And that's the *only* reason for the markup to exist.
Wrong. For one thing, not all client agents are browsers.
It's absurd to insist that code whose sole purpose is to give the user agent the cues it needs to arrange the presentation isn't "presentational". It's like saying, "Take two aspirins" isn't a medical instruction; it's only my compliance with that instruction that's medical.
At the Germans say, "not everything that hobbles is an analogy".
"Brian" <us*****@julietremblay.com.invalid-remove-this-part> wrote in
message news:ldCKb.765578$Fm2.732461@attbi_s04... Harlan Messinger wrote: Brian wrote
Harlan Messinger wrote:
Brian wrote
> HTML is not about presentation
If the purpose of "text/html" isn't to add tags *with the expectation that they will be used by user agents, to the extent possible,
That is the purpose of html. <em> is for emphasis, not italics. It is up the ua to determine how to present it.
"HTML is not about presentation" is a hyperbolic misstatement
No. HTML is not about presentation, it is about meaning. UAs are about presentation. Repeating a fallacy
It's not a fallacy, and I did not repeat it. But since you missed the point, I will repeat it here: in principle, the html model leaves presentation to the ua.
My doctor leaves it to me to actually take the pills. He doesn't force them
down my throat. Are his instructions not "medical instructions"? and ignoring my explanation of why it is wrong doesn't establish your assertion any more firmly. I could say the same thing to you.
Not really, since I responded to your arguments. You said, for example,
<CITE> does not say "put in italics," any more than <BLOCKQUOTE> says "indent this."
*Agreeing* with you on this point, I noted that these are presentation
*details*, which HTML should not be used to convey, and then I distinguished
the correct observation that HTML ought not to be used to convey
presentational details from the incorrect observation that "HTML is not
about presentation", which doesn't mean the same thing, and which your
examples don't contradict. How do you suppose the UA, whatever its internal rules may be, would know how to arrange a presentation without the markup to apply the rules to?
How does this contradict my statement? The ua presents e.g. <em> markup as italicized. Or as bold. Or spoken more forcefully. etc.
> What meaning does italics have in braille? an aural browser?
None. If I were writing *only* for those platforms, <em> would have *no* meaning, and I would never, ever bother with using it.
Really? I expect <em> to having meaning in any presentation. For example, I'd expect an aural ua to change the voice inflection for content inside <em>.
I was responding to Neal's implication that it *wouldn't* have any meaning in such a user-agent. Your response is based on the opposite premise, so it's inapplicable to my remark to him. I'll let you and Neal fight it out.
I have no idea what you're on about. You were responding to me in this exchange, which is composed only of things you and I wrote.
My mistake--I was misreading my thread tree. It was *you* who questioned
what meaning italics have in a browser. And I, unfortunately, interpreted
that as questioning what meaning *emphasis* has in a browser, and proceeded
from there, at which point you appeared to contradict yourself but didn't.
So let me back up: I don't know why you wrote "What meaning does italics
have in an aural browser?" We were talking about HTML, and I assume we meant
HTML as used in the recommended way--which means we're not using <i> tags.
So that was already a given for me, and I don't see why you brought the HTML
tag that directly calls for italics--<i>--into this. But as long as you did:
Does the fact that a UA may not follow through on this tag make it a
non-presentational tag? If I choose not to take the pills, does my doctor's
advice become non-medical? Even if he's aware that I might ignore him?
Funny thing, though: I had thought for quite a while that <i> was
deprecated, but now I see that it's not. Interesting, and confusing.
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message
news:Pi******************************@ppepc56.ph.g la.ac.uk... On Tue, 6 Jan 2004, Harlan Messinger wrote:
Repeating a fallacy and ignoring my explanation of why it is wrong doesn't establish your assertion any more firmly. Quite right. It's no fallacy that the majority of misguided web page authors think HTML is some kind of low-grade DTP, without any regard to underlying structure.
However, it's an admissible leap of faith to claim that because these supporters of Sturgeon's Law are all doing it, therefore it must have been the intention of HTML all along.
"HTML is not for presentation" is not the complement of "HTML is used to
establish every last presentational details for a document". I disagree with
the latter state of affairs, but it does not follow that I agree with the
former contention. That is the point I am trying to make. The HTML specifications do occasionally mention typical presentations used by the then-current browsers for representing logical markups; one might suppose that the folks who wrote that were crediting their readers with a greater power of abstract thought than has been justified by experience, and that they should have tried harder to distance themselves from the implication that these mentioned visual presentations were the One True Result of such logical markups.
How do you suppose the UA, whatever its internal rules may be, would know how to arrange a presentation without the markup to apply the rules to? What? A stressed voice, oblique font, or underlined text, are all valid representations of emphasis, and each of those presentations (and no doubt others which don't come to mind right now) appear in actual browser presentations of emphasis.
Yes. This means that, properly used, HTML doesn't convey the details of the
presentation. Again, this is not the same as "HTML is not about
presentation". If I talk with my architect about building a house, and I
tell him about my lifestyle and my possessions and my activities and my
finances, but believe it's best to leave it to him to suggest floor plans
and materials, does that mean we're not having an architectural discussion?
If it isn't, then why am I bothering to give the architect all these
details? I'll just say, "Here's money, build a house," and let him figure
out what I want. And, to take another example, a valid presentation of Hn elements would be an Overview menu. Some browsers already offer this; others can do it with client-side scripts, bookmarklets etc.
And that's the *only* reason for the markup to exist. Wrong. For one thing, not all client agents are browsers.
I don't happen to know what your, or the official, definition of "browser"
is that would make it only a subset of the class of user agents. Can you
give me a reference? I also don't know what difference it really makes in
the discussion, but I suppose it's worth knowing. It's absurd to insist that code whose sole purpose is to give the user agent the cues it needs to arrange the presentation isn't "presentational". It's like saying, "Take two aspirins" isn't a medical instruction; it's only my compliance with that instruction that's medical.
At the Germans say, "not everything that hobbles is an analogy".
But your reasons for rejecting analogies are anything but apparent.
The funny thing is, I've agreed with you on pretty much all the specifics
about what HTML is or isn't or should or shouldn't be used for, so as far as
I can tell the only thing left about "HTML is not about presentation" that
has a hold on you and Brian is some kind of semantic dogma.
Harlan Messinger wrote:
[snip] If there is, what is it? The pat answer, to provide information about document structure, is circular, because it only leads back to the question, "What is the value in providing information about document structure if it's not going to be used in some manner in producing the presentation?"
The "pat answer" is that the markup provides information about the various
parts of a document, which can then be used in *multiple* ways. One of
those uses is to aid in presentation, sure. Others include search engine
analysers, meta-information, mechanisms to discover alternative interfaces
to a website, and so on.
"HTML is not about presentation" is a hyperbolic misstatement of the valid precept that HTML is not about presentational *details*.
What is the difference between "presentation" and "presentational details"? [...] it is about meaning.
If they are not translated into presentational cues, <cite> and <q> and <blockquote> and <em> have no meaning at all to the user,
So? End-users aren't the only things that read documents.
[snip] ...and cannot do what you want in any case. What meaning does italics have in braille? An aural browser?
None. If I were writing *only* for those platforms, <em> would have *no* meaning, and I would never, ever bother with using it.
Are you saying that there is no way of emphasising something aurally?
I only use it solely because the information it provides *is* used presentationally by many of the user agents through which it is rendered, and therein lies its meaning--at least, meaning that is of any value.
Its meaning is defined in the HTML specifications. It's a user-agent's job
to apply that meaning how it sees fit - a search engine might note the
extra emphasis and rank a document higher for those particular keywords, or
a browser might render the text in italics or a different colour to
communicate that meaning to the end-user.
The presentation is only the mechanism to communicate the meaning from
user-agent to end-user. It's not an artifact of the markup language per
se. I disagree with the notion that because some popular browsers agree on
a default presentation for some element types that HTML is suddenly
"presentational".
--
Jim Dabell
"Jim Dabell" <ji********@jimdabell.com> wrote in message
news:JL********************@giganews.com... Harlan Messinger wrote: [snip] If there is, what is it? The pat answer, to provide information about document structure, is circular, because it only leads back to the question, "What is the value in providing information about document structure if it's not going to be used in some manner in producing the presentation?" The "pat answer" is that the markup provides information about the various parts of a document, which can then be used in *multiple* ways. One of those uses is to aid in presentation, sure. Others include search engine analysers, meta-information, mechanisms to discover alternative interfaces to a website, and so on.
Some of the tags are used for those purposes as well, and obviously <meta>
tags are used predominately for these purposes. But others, such as <em> or
<blockquote>, are of little or no use for any of these purposes. And some of
these purposes are secondary. Before I worry about whether information I'm
providing can be found by others, I worry about whether they're going to be
able to use it once they find it, and presentation is an aspect of that.
"HTML is not about presentation" is a hyperbolic misstatement of the
valid precept that HTML is not about presentational *details*. What is the difference between "presentation" and "presentational
details"?
The details.
[...] it is about meaning. If they are not translated into presentational cues, <cite> and <q> and <blockquote> and <em> have no meaning at all to the user,
So? End-users aren't the only things that read documents.
In the end, they're the only readers that I'm concerned with. I don't much
care whether a search engine has noted in some database all the nice <em>
and <li> tags I've used. I care whether they benefit the end-user, and they
will only do that when they are used for presentational purposes.
[snip] ...and cannot do what you want in any case. What meaning does italics have in braille? An aural browser? None. If I were writing *only* for those platforms, <em> would have *no* meaning, and I would never, ever bother with using it.
Are you saying that there is no way of emphasising something aurally?
There was a misunderstanding here...no point in repeating the explanation
that I gave elsewhere. I only use it solely because the information it provides *is* used presentationally by many of the user agents through which it is
rendered, and therein lies its meaning--at least, meaning that is of any value. Its meaning is defined in the HTML specifications. It's a user-agent's
job to apply that meaning how it sees fit - a search engine might note the extra emphasis and rank a document higher for those particular keywords,
or a browser might render the text in italics or a different colour to communicate that meaning to the end-user.
Do you use <em> and <li> and <blockquote> to entertain the search engine or
to facilitate communication with the end user.
And--can HTML only be one thing? If you use it for one thing, is it a
technical violation to say it's also used for something else? How does
pointing non-presentational aspects of some HTML mean that no HTML has
presentational aspects. The presentation is only the mechanism to communicate the meaning from user-agent to end-user. It's not an artifact of the markup language per se. I disagree with the notion that because some popular browsers agree
on a default presentation for some element types that HTML is suddenly "presentational".
The agreement or the default-ness have nothing to do with my contention, so
that particular disagreement of yours is not with me.
"Brian" <us*****@julietremblay.com.invalid-remove-this-part>
wrote in message news:baBKb.764978$Fm2.732066@attbi_s04... <em> is for emphasis, not italics. It is up the ua to determine how to present it.
A conforming UA will generally present it in italics or as
stressed speech. http://www.w3.org/TR/REC-html40/stru...t.html#edef-EM
Is it possible <strong> and <em> were invented to be
intentionally analogous to boldface and italics? Perhaps a more
'P.C.' version than <b> and <i>...
Neal wrote: Brian wrote:
<em> is for emphasis, not italics. It is up the ua to determine how to present it. A conforming UA will generally present it in italics or as stressed speech.
*Generally*, but no always. Lynx is a conforming UA. Lynx cannot do
italics. Thus, <em>foo</em> is not rendered in italics in Lynx. http://www.w3.org/TR/REC-html40/stru...t.html#edef-EM
Here's the relevant bit that you paraphrased:
"Generally, visual user agents present EM text in italics and STRONG
text in bold font."
But if you keep reading, you'll find, in the *very next sentence*:
"Speech synthesizer user agents may change the synthesis parameters,
such as volume, pitch and rate accordingly."
<em> does not mean italics. It means emphasized text.
--
Brian
follow the directions in my address to email me
Harlan Messinger wrote: I don't much care whether a search engine has noted in some database all the nice <em> and <li> tags I've used.
Do you care whether a search engine notes <title> or <h1>?
I care whether they benefit the end-user, and they will only do that when they are used for presentational purposes.
If <title>, <h1>, <h2> etc. help search engines categorize the
billions of pages on the www, then that *does* help the end-user.
Do you use <em> and <li> and <blockquote> to entertain the search engine or to facilitate communication with the end user.
They are not mutually exclusive. Unless, of course, you try to make
HTML into a presentational markup language.
--
Brian
follow the directions in my address to email me
"Brian" <us*****@julietremblay.com.invalid-remove-this-part>
wrote in message news:XuGKb.77854$xX.547074@attbi_s02... Neal wrote: A conforming UA will generally present it in italics or as
stressed speech. *Generally*, but no always. Lynx is a conforming UA. Lynx
cannot do italics. Thus, <em>foo</em> is not rendered in italics in Lynx.
Yes, that is true. Lynx does nothing at all with <em> to my
knowledge. (I've not succeeded in getting it to work, every
download I've found requires some 'assembly,' with which I have
zero skill...) The text browser emulator in Opera, which I'm told
is similar, makes no change to <em> and <strong> elements. I'll
assume Lynx behaves the same.
So in fact, you cannot make italic text in such a browser. No way
no how. While the reasons why differ, <em> is to Lynx as <q> is
to IE - an ignored bit of markup when it comes time to render.
But - if Lynx *did* do italics, wouldn't it make sense for it to
do so in this case? http://www.w3.org/TR/REC-html40/stru...t.html#edef-EM
Here's the relevant bit that you paraphrased: "Generally, visual user agents present EM text in italics and
STRONG text in bold font."
But if you keep reading, you'll find, in the *very next
sentence*: "Speech synthesizer user agents may change the synthesis
parameters, such as volume, pitch and rate accordingly."
My statement should have had the words "visual browsers" in it.
That was an omission, I intended to include that.
What I'm suggesting is this - italics/underlining (analogous in
meaning in text, historically) and boldface are standard
paper-printing styles. Italics has long been used to emphasize,
as well as do other things. Printed italics and spoken emphasis
have been analogous for quite some time. (While italics might not
be emphasized when spoken in every case, when transcribing speech
one would generally use italics for emphasized words if it is
available.)
It seems to me - and if anyone can point me to contrasting facts,
I'd welcome it - that while what you say is true:
<em> does not mean italics. It means emphasized text.
.... it is also true that italics has long meant emphasized text.
It's also true that of all the visual UA's I've ever heard of
that make any distinction at all with regards to <em> and
<strong>, all use italics and boldface respectively. And as I
mentioned, even the W3C suggests that that would be the general
way to express those elements visually, if you're going to do it
at all.
So <em> really has one of three end effects on one's content. 1)
It renders it visually as italics.2) It has no effect at all. 3)
It creates audible emphasis on the element's contents, which as
I've said is analogous to italics.
What you're not saying, but appears to be the crux of your
argument, is that there is no connection between emphasized words
and italicized words. Yet there clearly is.
That's why I argue that presentation is not so easily divorced
from meaning. While the attempt is noble, it fails to account for
the fact that humans *do* associate the two in some cases.
Colors, font sizes and faces, and other presentation have at best
vague implications of expression of content. But the
emphasis/italics connection cannot be so easily brushed aside.
Let me put it this way - if you are quoting inline, do you use
the <q> markup? If so, you will not have quotes around the quote
in IE. If you add quotes but do not use the tag, you are not
marking it for meaning. If you use both, many poor viewers will
see extra quotes. If that bothers you in the slightest, you *are*
concerned with the presentation caused by the <q> markup.
Now, are quotes meaning or presentation? In their absence, you
cannot easily discern a quote.
Is italics (or boldface) meaning or presentation? In their
absence, you cannot discern emphasis at all.
My point is simply that italics are as meaningful as quotes, and
while their absence is not quite as disruptive to the reader, it
is still absent. If all browsers and speech readers did not
render <em>, I charge that nobody would bother using it - similar
to the state of affairs with the noticeable absence of <q> in
source codes, when only one admittedly widespread browser does
not support it.
"Harlan Messinger" <h.*********@comcast.net> wrote in message
news:bt************@ID-114100.news.uni-berlin.de... I don't know where you get the "most" from, but that certainly
is another kind of citation.
But I rarely see citations presented in italics except with this
tag. Maybe I look in the wrong places.
Haines Brown wrote: I've not had a clear definition in my mind of "citation," and so have avoided it. For example, if I suggest that the reputation of the New York Times has suffered, is that a citation?
While on the subject, the docs list the blockquote cite attribute as a
URI ("The value of this attribute is a URI that designates a source
document or message.") What would you make of citing offline sources in
the 'cite' attribute? (eg. name of a book and page num, or 'Shak.
Romeo&Juliet I.II.30-43') (Yes, after visibly citing in the body itself).
Neal wrote: The text browser emulator in Opera, which I'm told is similar, makes no change to <em> and <strong> elements. I'll assume Lynx behaves the same.
Incorrect assumption. Lynx by default identifies <em> and <strong>
elements with color. You should assume other text browsers behave the same.
--
To email a reply, remove (dash)un(dash). Mail sent to the un
address is considered spam and automatically deleted.
Neal wrote: Lynx does nothing at all with <em> to my knowledge.
<quoting source="Alan Flavell">
OH YES IT DOES
</quoting>
:-D
Lynx 2.8.3 rel 1 running on Win2k displays <em> as purple text
(instead of black for normal text). (I think I may have configured it
to do this some time ago, but I can't find any place to do so at the
moment.)
Lynx 2.8.4 rel 1 running on Linux displays <em> text underlined.
The text browser emulator in Opera, which I'm told is similar, makes no change to <em> and <strong> elements.
I just tried text browser mode in O7.23/Win2k. It appears to have lots
of problems. For one thing, visited links have lines running through
them instead of under them. (Is it supposed to do that?) In any case,
it doesn't appear to be a very good Lynx emulator, but then it doesn't
promise to be a Lynx emulator.
Try this instead: http://www.delorie.com/web/lynxview.html
However, note that this emulator uses italics for <em>, which is
likely impossible for the real Lynx in any setting.
So in fact, you cannot make italic text in such a browser. No way no how.
AFAIK, that is correct. But it *can* render <em> in a useful way.
What I'm suggesting is this - italics/underlining (analogous in meaning in text, historically) and boldface are standard paper-printing styles.
The web is not paper. It's worth dwelling on that point for a moment.
The point of the html is to allow multiple renderings of the same
document, each one appropriate to its medium. The same document can be
presented on a computer screen, spoken by an aural browser, or printed
on paper. In each case, the content will be presented in a useful
manner, assuming a reasonably conforming ua is used. <em> does not mean italics. It means emphasized text.
... it is also true that italics has long meant emphasized text.
But italics means other things, too. A book title should be rendered
in italics in a print, but that title should not be emphasized when
spoken. Some style guides recommend putting foreign words or phrases
in italics, but such phrases need not necessarily be emphasized. (You
hinted at this in your response.)
So <em> really has one of three end effects on one's content. 1) It renders it visually as italics.2) It has no effect at all. 3) It creates audible emphasis on the element's contents, which as I've said is analogous to italics.
4) it renders it with underline
5) it renders it in a different color
6) ...
What you're not saying, but appears to be the crux of your argument, is that there is no connection between emphasized words and italicized words.
No. I'm saying that authoring HTML is about assigning meaning to text.
Interpreting HTML is about choosing an appropriate rendering of the
meaning. If this newsgroup were devoted to creating browsers, then I'd
argue that <em> content should be italicized where possible. But this
is an html authoring group. You, as author, do not have final say in
how <em> is rendered, and should not get overly concerned about it.
Mark up the text for meaning, and let the ua do its job.
--
Brian
follow the directions in my address to email me
Neal wrote: if you are quoting inline, do you use the <q> markup?
No. I used to, until I was dissuaded from using <q> in a thread here.
<q> is fraught with problems, for reasons that you already know.
If so, you will not have quotes around the quote in IE. If you add quotes but do not use the tag, you are not marking it for meaning. If you use both, many poor viewers will see extra quotes. If that bothers you in the slightest, you *are* concerned with the presentation caused by the <q> markup.
Exactly the problem.
Now, are quotes meaning or presentation? In their absence, you cannot easily discern a quote.
Don't use <q>; put quotation marks in the document content.
I charge that nobody would bother using it - similar to the state of affairs with the noticeable absence of <q> in source codes, when only one admittedly widespread browser does not support it.
<q> is rarely used in part because of the requirement that uas render
quotation marks -- it should have been forbidden instead.
--
Brian
follow the directions in my address to email me
"Brian" <us*****@julietremblay.com.invalid-remove-this-part>
wrote in message news:A5JKb.761682$Tr4.2170461@attbi_s03... Lynx 2.8.3 rel 1 running on Win2k displays <em> as purple text (instead of black for normal text). (I think I may have
configured it to do this some time ago, but I can't find any place to do so
at the moment.)
Lynx 2.8.4 rel 1 running on Linux displays <em> text
underlined.
Gee, you could have told me *before* my rant! :)
Still, Lynx is the sole anomaly, and out of necessity, as it does
not generate italic text. Color isn't the wisest method to convey
meaning, and underlining is typically reserved for marking links.
If the Lynx viewer (and thanks very much for the link) is
accurate, Lynx shows emphasized text and links identically
(except perhaps color). For many of the users who require a text
browser, coloration is tantamount to no presentation at all
applied to <em>, and underlining a rather confusing and IMO
ill-advised presentation.
I just tried text browser mode in O7.23/Win2k. It appears to
have lots of problems. For one thing, visited links have lines running
through them instead of under them. (Is it supposed to do that?)
That's how my Opera works as well. What I'm suggesting is this - italics/underlining (analogous
in meaning in text, historically) and boldface are standard paper-printing styles.
The web is not paper. It's worth dwelling on that point for a
moment.
You are correct. But we cannot so easily wipe away hundreds of
years of precedent to printed text with one swoop. It might not
be paper, but we are still reading - and we as humans are
conditioned to getting cues from the presentation of text which
clarify meaning. What the proponents of total unequivical
separation of presentation from content -- whether that
presentation concretely aids in expressing the content, is purely
decorative, or is somewhere in between -- are asking is, "Ok,
you've been doing this for hundreds of years, and it's worked gre
at for the tech you've had, but now we have this new tech, so
everything changes now." People just don't change that quickly.
It's an unreasonable expectation to assume that the common man
will simply nod and say, "Gee, these computer people must be
right."
Hundreds of years of precedent in reading type, and a millenia
plus before of reading in general, and suddenly the world must
accept change.
My overriding point is that presentation has always intersected
content. They can be as successfully separated as your head from
your body. While they are distinct, they are married to each
other. Raw content without presentation is less meaningful, and
if our goal is to express meaning with HTML, we must consider the
effect of presentation in order to most clearly express what we
have to say.
Just because we want high school graduates to be able to read
Chaucer and solve a quadratic equation doesn't mean we teach
Chaucer and algebra in kindergarten. But we begin by teaching
numbers, letters and words. Likewise, though a visionary can see
that the end result of the internet's efect on mankind is a whole
new way of thinking about presenting information, we're not there
yet. We're still in maybe 3rd or 4th grade.
The point of the html is to allow multiple renderings of the
same document, each one appropriate to its medium. The same document
can be presented on a computer screen, spoken by an aural browser, or
printed on paper. In each case, the content will be presented in a
useful manner, assuming a reasonably conforming ua is used.
So if I print out a well-formed valid HTML document, it will
follow print conventions? Doesn't seem to happen. Sounds more to
me like every UA for itself. "Useful" isn't enough for me. I'd
like to know the recipient of the content is getting my message
whatever the medium - paper, screen or sound. To me, that
involves considering not only meaning but expression. Like the
already-time-worn mantra that tone is difficult to discern in an
email or Usenet post. The reason is that the opportunities to
present the content appropriately are absent.
If I ran the W3C, I'd want UA's of forseeable classifications to
adhere as closely as possible to traditional modes of
presentation. I would not recommend that complying UA's render
<em> with italics, I would require it. I would not reccomend that
aural browsers change the pitch and volume of <strong> markedly,
I'd require it. The only exceptions would be when a particular
technology to cause it to happen is unavailable or impossible in
a particular UA.
We might as well leave out speech readers from the discussion, as
we both agree that they are unique in many ways. We both agree
that they should ideally be expected to emulate human expressive
reading. I think you agree that it's appropriate to mark up text
toward the end that a speech reader will more acurately mimic the
patterns of human speech.
Yet you discard the notion that text UA's should be expected to
emulate human expressive writing. You say it is inappropriate to
mark up text toward the end that a text UA will more acurately
mimic the patterns of human writing.
Unless I have you wrong. Please correct me if I do - believe it
or not, I'd like you to convince me.
"Brian" <us*****@julietremblay.com.invalid-remove-this-part>
wrote in message news:%bJKb.79056$xX.559306@attbi_s02... <q> is rarely used in part because of the requirement that uas
render quotation marks -- it should have been forbidden instead.
Actually, it would seem <q> is unused because the most prevalent
browser fails to render <q> according to the recommendation, thus
making it express no meaning in the most prevalent browser.
Unless you have further background on this you'd like to share?
I still argue that if IE (or, in a different world, whatever
other browser had the market share) didn't render <em> as
italics, it would be the same. Just as the usefulness of <q> is
ruined by its lack of presentation, <em> would be a lost vestage
of HTML 2.0 if it were not rendered. Especially since we have <i>
to force italics, as we have " to force a quotation presentation.
"Firas D." <fd************@firasd.org> wrote in message
news:bt************@ID-214165.news.uni-berlin.de... While on the subject, the docs list the blockquote cite
attribute as a URI ("The value of this attribute is a URI that designates a
source document or message.") What would you make of citing offline
sources in the 'cite' attribute? (eg. name of a book and page num, or
'Shak. Romeo&Juliet I.II.30-43') (Yes, after visibly citing in the
body itself).
According to the spec, the cite attribute for <blockquote> and
<q> are not required. http://www.w3.org/TR/html401/struct/text.html#h-9.2.2
On Tue, 6 Jan 2004 09:32:52 -0500, "Harlan Messinger"
<h.*********@comcast.net> wrote: 1. "The end of the world is coming next week," reported the Reverend Sam Doomsday.
2. "The end of the world is coming next week," reported <cite>The New York Times</cite>.
3. The <cite>New York Times</cite> is published daily.
1 and 2 include citations; 2 and 3 use <cite>. I'd rather have the tag renamed. In the meantime, I prefer your solution, using a "title" class, better.
I believe (admittedly without any hard evidence to hand) that the <cite>
element was originally intended to be used for cited documents/articles,
so that a UA could extract them as a list of references. That being the
case I would only consider using it in case 2 above. In fact I don't
think it's even worth having there, but might be in:
4. A prediction of the end of the world was given in <cite>The New York
Times, 14 December 1999, page 97</cite>.
Anyone know of any such UA, BTW?
--
Stephen Poley http://www.xs4all.nl/~sbpoley/webmatters/
"Stephen Poley" <sb******************@xs4all.nl> wrote in message
news:vf********************************@4ax.com... I believe (admittedly without any hard evidence to hand) that
the <cite> element was originally intended to be used for cited
documents/articles, so that a UA could extract them as a list of references.
From the 2.0 memo at http://ftp.ics.uci.edu/pub/ietf/html/rfc1866.txt :
.. . .
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>.
.. . .
From 3.2: "CITE used for citations or references to other
sources"
4.0/4.1 has a very similar wording plus these two examples;
As <CITE>Harry S. Truman</CITE> said,
<Q lang="en-us">The buck stops here.</Q>
More information can be found in <CITE>[ISO-0000]</CITE>.
If <cite> was originally intended as you suggest, they have a
weird way of showing that through their examples...
"Neal" <ne**@spamrcn.com> wrote in message
news:3f**********************@news.rcn.com... "Firas D." <fd************@firasd.org> wrote in message news:bt************@ID-214165.news.uni-berlin.de... While on the subject, the docs list the blockquote cite attribute as a URI ("The value of this attribute is a URI that designates a source document or message.") What would you make of citing offline sources in the 'cite' attribute? (eg. name of a book and page num, or 'Shak. Romeo&Juliet I.II.30-43') (Yes, after visibly citing in the body itself).
According to the spec, the cite attribute for <blockquote> and <q> are not required.
http://www.w3.org/TR/html401/struct/text.html#h-9.2.2
Sorry, misread your question.
The value for cite for both of these elements is a URI "for
source document or msg" - if it is an offline source, you'd link
to a bibliography, perhaps, where the full information is listed.
On Tue, 6 Jan 2004 18:45:42 -0500, "Neal" <ne**@spamrcn.com> wrote: What you're not saying, but appears to be the crux of your argument, is that there is no connection between emphasized words and italicized words. Yet there clearly is.
That's why I argue that presentation is not so easily divorced from meaning. While the attempt is noble, it fails to account for the fact that humans *do* associate the two in some cases. Colors, font sizes and faces, and other presentation have at best vague implications of expression of content. But the emphasis/italics connection cannot be so easily brushed aside.
Do you have a pen, Neal? How do you indicate emphasised text when you
are using it? I'll lay long odds it's not with italic text, and probably
not often with bolding either.
I've certainly spent more years indicating emphasis with either capital
letters or underlining than I have with italics - that applies to pen,
typewriter and the early word-processors.
How about Usenet posts? Did you use italics for emphasis in your post?
You did not - you used asterisks, and expected everyone to understand
that. You could have used capitals, and that would also have been
understood.
The fact is that most people are used to emphasis being represented in a
variety of different ways, according to context. The concept of emphasis
is clearly separate from any specific presentation.
--
Stephen Poley http://www.xs4all.nl/~sbpoley/webmatters/
On Wed, 7 Jan 2004 03:04:25 -0500, "Neal" <ne**@spamrcn.com> wrote: 4.0/4.1 has a very similar wording plus these two examples;
As <CITE>Harry S. Truman</CITE> said, <Q lang="en-us">The buck stops here.</Q>
More information can be found in <CITE>[ISO-0000]</CITE>.
If <cite> was originally intended as you suggest, they have a weird way of showing that through their examples...
The ISO-0000 example is near enough what I am suggesting. I can only
agree with you about the others. The Harry S. Truman example makes no
sense to me.
--
Stephen Poley http://www.xs4all.nl/~sbpoley/webmatters/
Neal wrote: Brian wrote:
Lynx 2.8.3 rel 1 running on Win2k displays <em> as purple text (instead of black for normal text). Color isn't the wisest method to convey meaning, and underlining is typically reserved for marking links.
Not in Lynx.
Lynx 2.8.3 rel 1 (Win2k)
<em> is purple
<a:link> is blue
<a:focus> is brown
Lynx 2.8.4 rel 1 (Linux)
<em> is underlined
<a:link> is bold
<a:focus> is reverse
For many of the users who require a text browser, coloration is tantamount to no presentation at all applied to <em>, and underlining a rather confusing and IMO ill-advised presentation.
No offense intended, but given how little you know about how Lynx
actually works, perhaps you should concede this part of your argument.
What the proponents of total unequivical separation of presentation from content
My arguments are not based on idealism. On the contrary, they are
based on the reality of the www.
Hundreds of years of precedent in reading type, and a millenia plus before of reading in general,
Have you actually read any of those documents? Did medieval
manuscripts contain italics? I must say I've never seen them in the
12th-14th century manuscripts of medieval French I've looked at.
Raw content without presentation is less meaningful,
Straw man. I never suggested that markup should have no distinct
presentation in a browser.
if our goal is to express meaning with HTML, we must consider the effect of presentation in order to most clearly express what we have to say.
I assume that e.g. <h1> will be interpreted in some useful way in a
conforming ua. Conventional typography says a headline should be
significantly larger than the body text, often in a different font.
And if I were laying out a newspaper, that's how I'd do it. On the
web, however, I don't know the properties of the display medium. I
don't know whether different fonts are available or larger text is
possible. I don't even know if letters will be printed at all. The point of the html is to allow multiple renderings of the same document, each one appropriate to its medium.
So if I print out a well-formed valid HTML document, it will follow print conventions? Doesn't seem to happen.
Isn't your complain better directed toward whoever wrote the ua?
Sounds more to me like every UA for itself. "Useful" isn't enough for me.
Then the www isn't for you, because it's all you can realistically expect.
If I ran the W3C, I'd want UA's of forseeable classifications to adhere as closely as possible to traditional modes of presentation. I would not recommend that complying UA's render <em> with italics, I would require it.
In other words, you'd solve the problem at the receiving end, with the
browser, and not at the authoring end. At the author's end, <em> means
emphasis, not italics. At the other end, the ua receives not <italics>
but <emphasis>. It then translates <emphasis>, as italics if that is
possible and appropriate, or in some other way if not.
Unless I have you wrong. Please correct me if I do - believe it or not, I'd like you to convince me.
I cannot convince you of anything. You are free to recognize the www
for what it is, or try to reformulate it into what you want it to be.
--
Best,
Brian
follow the directions in my address to email me
"Brian" <us*****@julietremblay.com.invalid-remove-this-part> wrote in
message news:fBGKb.760576$Tr4.2159835@attbi_s03... Harlan Messinger wrote: I don't much care whether a search engine has noted in some database all the nice <em> and <li> tags I've used. Do you care whether a search engine notes <title> or <h1>?
Yes. (I'm not sure what you're going to do with that response! At most, this
causes me to back away from *my* absolute statement that "HTML is about
presentation" and refine it, maybe as far as "much of HTML is largely about
presentation", which is still at odds with "HTML is not about
presentation".) I care whether they benefit the end-user, and they will only do that when they are used for presentational purposes. If <title>, <h1>, <h2> etc. help search engines categorize the billions of pages on the www, then that *does* help the end-user.
Granted. Do you use <em> and <li> and <blockquote> to entertain the search engine or to facilitate communication with the end user. They are not mutually exclusive.
My question was rhetorical. I will be astonished if tell me that you use
these tags to entertain the search engine, or even with the expectation that
the search engine will be entertained.
Unless, of course, you try to make HTML into a presentational markup language.
"Neal" <ne**@spamrcn.com> wrote in message
news:3f**********************@news.rcn.com... "Harlan Messinger" <h.*********@comcast.net> wrote in message news:bt************@ID-114100.news.uni-berlin.de... I don't know where you get the "most" from, but that certainly is another kind of citation.
But I rarely see citations presented in italics except with this tag. Maybe I look in the wrong places.
OK, I see what you mean.
Neal wrote: it would seem <q> is unused because the most prevalent browser fails to render <q> according to the recommendation, thus making it express no meaning in the most prevalent browser.
That is likely true.
I still argue that if IE (or, in a different world, whatever other browser had the market share) didn't render <em> as italics, it would be the same.
IE does render <em> as italics. And *still* many authors use <i>
instead of <em> when they want to emphasize something. If you're going
to mimic what most of the world does, writing code as a presentational
markup language intended only for MSIE/Win, then throw out <em> and
<strong>. Don't bother with <h?>, either; heading elements are not
necessary to display large fonts. (Ab)use tables for layout. Don't
include a dtd. Forget about mime types. Etc.
Just as the usefulness of <q> is ruined by its lack of presentation, <em> would be a lost vestage of HTML 2.0 if it were not rendered. Especially since we have <i> to force italics, as we have " to force a quotation presentation.
<i> most certainly does not force italics. Have you not been reading
this thread very carefully? How do suppose <i> "force[s] italics" in
Lynx, which is incapable of that font variant?
As for quotation marks, " is not an html tag. It does not force
anything except its own display.
--
Brian
follow the directions in my address to email me
On Tue, 6 Jan 2004 18:45:42 -0500,
"Neal" <ne**@spamrcn.com> wrote: Lynx does nothing at all with <em> to my knowledge.
Here, Lynx (on Linux) will colour emphasised text, if allowed to colour
the output (something that actually annoys me, because I can't get it to
save my settings not to do that).
--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.
This message was sent without a virus, please delete some files yourself.
On Wed, 7 Jan 2004, Brian wrote: Hundreds of years of precedent in reading type, and a millenia plus before of reading in general,
Have you actually read any of those documents? Did medieval manuscripts contain italics? I must say I've never seen them in the 12th-14th century manuscripts of medieval French I've looked at.
Old manuscripts also had a tendency to present a new paragraph by
writing a pilcrow sign and continuing in-line (presumably because of
the considerable cost of the recording media in those days ;-)
"Neal" <ne**@spamrcn.com> wrote: As <CITE>Harry S. Truman</CITE> said, <Q lang="en-us">The buck stops here.</Q>
- - If <cite> was originally intended as you suggest, they have a weird way of showing that through their examples..
Even the odd-looking use of <cite> in the example is not _that_ far
from the idea of generating a list of references. After all, it _is_
about citing a person, and having an entry like
"Harry S. Truman"
in a list of references could make some sense. Scientic reports may
cite a person by name and add "(personal communication)".
On the other hand, I have seen no references to the idea of generating
a list of references from <cite> elements before this. It's not a bad
idea, but I think somewhat more informative markup would be needed for
the purpose. Note that <cite> is commonly used for titles of books (for
example) even when the books aren't really cited, as in
"I was reading <cite>Bored of the Rings</cite>, when the phone rang and
....".
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Bruce W...1 |
last post by:
For include files I see both the file extensions .php and .inc used.
Which one is proper? Does it matter? What's the diff?
Thanks for your help.
|
by: T. Kaufmann |
last post by:
Hi there,
I have some lines of code in a Tkinter programm - I want to list every single
file of a zip-archive in a Text widget:
fp = os.popen("%s %s" % ('unzip -vl ', 'anyarchiv.zip', 'r')...
|
by: m.ramana |
last post by:
Given a string it should convert it to a proper text.
Example: if you passed a string 'Cat in the hat', I want 'Cat In The
Hat'
Curious about few things, Does sql have Instr OR Split(like VB)...
|
by: Kevin |
last post by:
I am currently importing data into Access 2002 from 3 Sybase ASA 7.0
databases over a network. At this time I am using a ODBC System DSN
connection using the proper ASA 7 driver. I would like to...
|
by: RC |
last post by:
I have an Access 2002 database with many tables and forms (but just to
keep things simple, let's say the DB has one Table "Table1" and one
Form "Form1").
I have managed to cobble together so much...
|
by: bj |
last post by:
hello
is there any chance to get proper char width for
class derived from user control - im working over
text editing control, so i need proper width of every
character for currently selected...
|
by: yogarajan |
last post by:
hi all
i need proper alignment
my treeview looks like
<checkbox>Fruits(parent)-134
<checkbox>Mango(child)-45
<checkbox>Orange(child)-45
...
|
by: jagdeep gupta |
last post by:
The image is not shown proper at some pc but shows proper at some other pcs.
<%@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage.master.cs" Inherits="MasterPage" %>
<!DOCTYPE...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
by: PapaRatzi |
last post by:
Hello,
I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Defcon1945 |
last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
|
by: Shællîpôpï 09 |
last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
| |