The Document Object Model (DOM) is a interface-based model for ` Document `
objects. The DOM allows scripts to dynamically access and update a
document's content, style, and event handlers.
The DOM is _not_ part of the ECMAScript programming language.
Official DOM standards are defined by the World Wide Web Consortium.
Scriptable browsers also have proprietary DOM features (
http://msdn.microsoft.com/en-us/library/ms533050(VS.85).aspx
https://developer.mozilla.org/en/DOM_Client_Object_Cross-Reference
),
such as ` document.writeln() `.
Also see the section on
http://jibbering.com/faq/#domRef
http://jibbering.com/faq/#onlineResources
http://www.w3.org/DOM/faq.html
https://developer.mozilla.org/en/Gecko_DOM_Reference/Introduction#What_is_the_DOM.3F
The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/
--
The sendings of these daily posts are proficiently hosted
by http://www.pair.com.
Above : "The" should be "A".
>
>Official DOM standards are defined by the World Wide Web Consortium.
Since this is a JavaScript FAQ and not a BrowserScript FAQ, that
sentence, which might readily be taken to mean DOM standards for all
purposes, is inappropriate. Remember : JavaScript needs a DOM, and is
not a Web-only language.
DOM standards for browsers are defined by the World Wide Web Consortium.
/or/ The World Wide Web Consortium defines DOM standards for browsers.
>Scriptable browsers also have proprietary DOM features (
> ...
>),
>such as ` document.writeln() `.
True; but something "always" available in browsers does not make a good
sole example. Quote, or quote also, a proprietary DOM feature available
on at least one, but not all, of the major current browsers ; or don't
say that.
Does JavaScript always run with a DOCUMENT OM? ISTM that it needs an
OM, but that if JavaScript were used to control a machine (not just a
computer), its chief OM would be application-dependent with relatively
little D about it.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
The w3c Document Object Model (DOM) is not part of ECMAScript.
The entry does not convey the concept that "The w3c DOM" is not one
specification. It is many specifications (Core, Events, HTML, Style).
>> Official DOM standards are defined by the World Wide Web Consortium.
>
> Since this is a JavaScript FAQ and not a BrowserScript FAQ, that
> sentence, which might readily be taken to mean DOM standards for all
> purposes, is inappropriate. Remember : JavaScript needs a DOM, and is
> not a Web-only language.
>
DOM stands for "Document Object Model"; In some environments "Document"
would be meaningless (Flash).
It is important to disambiguate between a hazy "w3c DOM" (many specs)
and the general idea of an browser's scriptable object model, which
includes window, screen, and navigator. The term "BOM" (Browser Object
Model) does that, but is not a common term, so seems unsuitable for the FAQ.
Thus, I would like propose:
1) change "DOM" in the entry to "w3c DOM"
2) change the initial definition:
| The Document Object Model (DOM) is a interface-based model for
| Document objects.
to:
| The w3c Document Object Model (DOM) specifications define
| an interface-based model for XML and HTML Document objects
| and Events.
3) change the following:
| Scriptable browsers also have proprietary DOM features (MSDN, MDC),
| such as document.writeln().
to:
| Scriptable browsers have proprietary object models (MSDN, MDC), that
| include many other features (window, screen, document.execCommand).
> DOM standards for browsers are defined by the World Wide Web Consortium.
> /or/ The World Wide Web Consortium defines DOM standards for browsers.
>
>> Scriptable browsers also have proprietary DOM features (
>> ...
>> ),
>> such as ` document.writeln() `.
>
document.writeln is a DOM 2 standard; thus not proprietary. A
proprietary feature would be document.execCommand.
I propose changing document.writeln to document.execCommand.
[snip]
> Does JavaScript always run with a DOCUMENT OM? ISTM that it needs an
> OM, but that if JavaScript were used to control a machine (not just a
> computer), its chief OM would be application-dependent with relatively
> little D about it.
>
There are three Oms; each has unicode representative.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
[snip]
>>
> There are three Oms; each has unicode representative.
s/representative/representation.
(pun).
It is a pity that you can neither read nor write English reliably.
>The entry does not convey the concept that "The w3c DOM" is not one
>specification. It is many specifications (Core, Events, HTML, Style).
>
>>> Official DOM standards are defined by the World Wide Web Consortium.
>> Since this is a JavaScript FAQ and not a BrowserScript FAQ, that
>> sentence, which might readily be taken to mean DOM standards for all
>> purposes, is inappropriate. Remember : JavaScript needs a DOM, and is
>> not a Web-only language.
>>
>
>DOM stands for "Document Object Model"; In some environments "Document"
>would be meaningless (Flash).
Change to "... needs an OM".
>It is important to disambiguate between a hazy "w3c DOM" (many specs)
>and the general idea of an browser's scriptable object model, which
>includes window, screen, and navigator. The term "BOM" (Browser Object
>Model) does that, but is not a common term, so seems unsuitable for the
>FAQ.
>
>Thus, I would like propose:
>1) change "DOM" in the entry to "w3c DOM"
Then you will be changing
>The DOM is _not_ part of the ECMAScript programming language.
to
The w3c DOM is _not_ part of the ECMAScript programming language.
That is true, but weak; it suggests that one or more other DOMs may be
part of it. Better to say something like "The ECMAScript standard does
not define a DOM; an implementation of the language will need an
application-dependent OM. For Web browsers, that is the W3C DOM.".
W3C use "W3C, not "w3c". St Luke: Chapter 10, Verse 37, tail.
>2) change the initial definition:
>| The Document Object Model (DOM) is a interface-based model for
>| Document objects.
>
>to:
>| The w3c Document Object Model (DOM) specifications define
>| an interface-based model for XML and HTML Document objects
>| and Events.
>
>3) change the following:
>| Scriptable browsers also have proprietary DOM features (MSDN, MDC),
>| such as document.writeln().
>to:
>| Scriptable browsers have proprietary object models (MSDN, MDC), that
>| include many other features (window, screen, document.execCommand).
Every acronym in the FAQ needs to be explained, either at first use or
in a glossary. Remember that the target audience includes normal
people.
>
>> DOM standards for browsers are defined by the World Wide Web Consortium.
>> /or/ The World Wide Web Consortium defines DOM standards for browsers.
>>
>>> Scriptable browsers also have proprietary DOM features (
>>> ...
>>> ),
>>> such as ` document.writeln() `.
>>
>document.writeln is a DOM 2 standard; thus not proprietary. A
>proprietary feature would be document.execCommand.
>
>I propose changing document.writeln to document.execCommand.
Needs a reference to a definition. Google offers 43,700 choices. The
first seems suitable but may not be the best.
>
>[snip]
>
>> Does JavaScript always run with a DOCUMENT OM? ISTM that it needs an
>> OM, but that if JavaScript were used to control a machine (not just a
>> computer), its chief OM would be application-dependent with relatively
>> little D about it.
>>
>There are three Oms; each has unicode representative.
How do you know that there are three OMs? FAQ 2.3 effectively refers to
at least three (browser, file, nuke); ISTM that JavaScript for a wind
farm and for transport ticketing would require different OMs.
In any case, your response does not address the question - perhaps
"don't know" would have been better,
Do you have something worth reading? Snide remarks such as that are a
waste of everyone's time.
[snip]
> Change to "... needs an OM".
>
What is changed from? Better yet, what is the sentence you suggest. It
seems context was lost there.
>> It is important to disambiguate between a hazy "w3c DOM" (many specs)
>> and the general idea of an browser's scriptable object model, which
>> includes window, screen, and navigator. The term "BOM" (Browser Object
>> Model) does that, but is not a common term, so seems unsuitable for the
>> FAQ.
>>
>> Thus, I would like propose:
>> 1) change "DOM" in the entry to "w3c DOM"
>
> Then you will be changing
please finish this sentence; I don't understand what you mean.
>> The DOM is _not_ part of the ECMAScript programming language.
> to
> The w3c DOM is _not_ part of the ECMAScript programming language.
>
> That is true, but weak; it suggests that one or more other DOMs may be
> part of it. Better to say something like "The ECMAScript standard does
> not define a DOM; an implementation of the language will need an
> application-dependent OM. For Web browsers, that is the W3C DOM.".
>
I agree. What you have written is more comprehensive. It switches the
subject from "DOM" to "ECMAScript". As written, it seems more suited for
"What is ECMAScript?".
| As with any OM, the W3C DOM is _not_ part of the ECMAScript
| programming language.
[snip]
>> | Scriptable browsers have proprietary object models (MSDN, MDC), that
>> | include many other features (window, screen, document.execCommand).
>
> Every acronym in the FAQ needs to be explained, either at first use or
> in a glossary.
<abbr title="Microsoft Developer Network">MSDN</abbr>
Glossary, at /faq/glossary/, is a good idea for other terms. Along with
section for Functions and updated notes, which I started.
Remember that the target audience includes normal
> people.
>
>>> DOM standards for browsers are defined by the World Wide Web Consortium.
>>> /or/ The World Wide Web Consortium defines DOM standards for browsers.
>>>
>>>> Scriptable browsers also have proprietary DOM features (
>>>> ...
>>>> ),
>>>> such as ` document.writeln() `.
>> document.writeln is a DOM 2 standard; thus not proprietary. A
>> proprietary feature would be document.execCommand.
>>
>> I propose changing document.writeln to document.execCommand.
>
> Needs a reference to a definition. Google offers 43,700 choices. The
> first seems suitable but may not be the best.
>
Scriptable browsers also have proprietary DOM features, such as
document.execCommand (link:MSDN) or window.atob (link:MDC).
[snip]
>>>
>> There are three Oms; each has unicode representative.
>
> How do you know that there are three OMs?
You're right; I was mistaken. There are apparently *four* OMs[1]. Thanks
for pointing it out.
Reached a little far, so now having to explain my bad joke.
1) \u0F00
2) \u0950
etc.
I'll have to go over this again tomorrow, when I'm a little more clear
headed.
[1]http://en.wikipedia.org/wiki/Aum
<snip>
>>DOM stands for "Document Object Model"; In some environments "Document"
>>would be meaningless (Flash).
>
>Change to "... needs an OM".
<snip>
"needs" is too strong; it does not have to be an OM. The code needs some
way of interacting with its environment, but there need not be objects
nor a model. The MS Windows API, for instance, uses a collection of
global functions. JScript's FileSystem objects are objects, but do not
model the file store in the way that the HTML DOM models the structure
of the document.
John
--
John Harris
No : "needs" is correct (the essential point is that, lacking any form
of output, ECMAScript is useless on its own) - but you are saying that
the need may be fulfilled by something which is not actually an OM.
"... needs an external interface, such as an OM/DOM."
^^^^^^^^^^^^^^^^^^ not necessarily optimal wording.
It is worth pointing out that the FAQ maintainer, although resident in a
country where they think they use English [1], cannot be relied upon to
understand communications written in that language.
>>> Thus, I would like propose:
>>> 1) change "DOM" in the entry to "w3c DOM"
>> Then you will be changing
>
>please finish this sentence; I don't understand what you mean.
You make comprehension difficulties. You should have read up to the
full stop.
>>> The DOM is _not_ part of the ECMAScript programming language.
>> to
>> The w3c DOM is _not_ part of the ECMAScript programming language.
>> That is true, but weak; it suggests that one or more other DOMs may
>>be
>> part of it. Better to say something like "The ECMAScript standard does
>> not define a DOM; an implementation of the language will need an
>> application-dependent OM. For Web browsers, that is the W3C DOM.".
>>
>
>I agree. What you have written is more comprehensive. It switches the
>subject from "DOM" to "ECMAScript". As written, it seems more suited
>for "What is ECMAScript?".
No. The term DOM is commonly enough used in the newsgroup that it needs
an explanation in the FAQ, findable in the index.
>| As with any OM, the W3C DOM is _not_ part of the ECMAScript
>| programming language.
>
>[snip]
>
>>> | Scriptable browsers have proprietary object models (MSDN, MDC), that
>>> | include many other features (window, screen, document.execCommand).
>> Every acronym in the FAQ needs to be explained, either at first use
>>or
>> in a glossary.
>
> <abbr title="Microsoft Developer Network">MSDN</abbr>
Readers of the FAQ should not be expected to read its source code in
case something is marked with 'abbr', which it currently isn't.
Remember that the FAQ items are published in plaintext News, and need to
be equally usable there
>Glossary, at /faq/glossary/, is a good idea for other terms. Along with
>section for Functions and updated notes, which I started.
That can be of no use while the FAQ contains no link to it.
If an abbreviation/acronym which is not, with an appropriate meaning, in
a medium-sized printed dictionary of the English language (indeed, since
we have here many who are more fluent in their mother tongue than in
English, a m-s p English-to/from-Foreign dictionary), then, on its first
use in the main part of the FAQ, its expanded form needs also to be
given. The Subject of this thread shoes it being done.
A Glossary should generally be more than an acronym-expander.
>>> There are three Oms; each has unicode representative.
>> How do you know that there are three OMs?
>
>You're right; I was mistaken. There are apparently *four* OMs[1].
>Thanks for pointing it out.
Since you cannot know all applications using JavaScript, you cannot know
how many OMs there are; you can only know that there are at least some
number. If you mean only W3C OMs, then say so.
The link "FAQ Notes" on the third line of the FAQ is too inconspicuous.
It should be as big as the level 1 numbered links following. It does
not even look like a link, because the standard link appearance has
foolishly been overridden.
[1] e.g. over there, they have non-rectangular oblongs !
[snip]
>>>> | Scriptable browsers have proprietary object models (MSDN, MDC), that
>>>> | include many other features (window, screen, document.execCommand).
>>> Every acronym in the FAQ needs to be explained, either at first use
>>> or
>>> in a glossary.
>> <abbr title="Microsoft Developer Network">MSDN</abbr>
>
> Readers of the FAQ should not be expected to read its source code in
> case something is marked with 'abbr', which it currently isn't.
> Remember that the FAQ items are published in plaintext News, and need to
> be equally usable there
>
>
The <abbr> elements can be styled so that they have a dotted
border-bottom. That way, when user mouse over the term, the title is
displayed. Screen reader should read the title as well. It's a WCAG p3
guideline.
OK; but that is no help to those reading plaintext.
Standard convention for documents in general is to put both abbreviation
and full version at first use, with one in parentheses. That should be
adhered to, the existence of an alternative notwithstanding. The <abbr>
has the defects that while reading the document one has to fetch the
mouse for elucidation, and that when mousing around the document one
gets distracting titles appearing.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; WinXP.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
> FAQ server posted:
>> The Document Object Model (DOM) is a interface-based model for `
>> Document` objects. The DOM allows scripts to dynamically access and
>> update a document's content, style, and event handlers.
>>
>> The DOM is _not_ part of the ECMAScript programming language.
>
> Above : "The" should be "A".
No. "The DOM" refers to whatever DOM implementation it means in the
context of a task, not necessarily one of the W3C DOM.
>> Official DOM standards are defined by the World Wide Web Consortium.
>
> Since this is a JavaScript FAQ and not a BrowserScript FAQ, that
> sentence, which might readily be taken to mean DOM standards for all
> purposes, is inappropriate. Remember : JavaScript needs a DOM, and is
> not a Web-only language.
>
> DOM standards for browsers are defined by the World Wide Web Consortium.
> /or/ The World Wide Web Consortium defines DOM standards for browsers.
No, the W3C DOM specifies a language- and platform-independent API. Start
with looking into the DOM classes in PHP 5, usable client-side and server-
side, which implement these interfaces.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
> Dr J R Stockton wrote:
>> Garrett Smith posted:
>>> | Scriptable browsers have proprietary object models (MSDN, MDC), that
>>> | include many other features (window, screen, document.execCommand).
>>
>> Every acronym in the FAQ needs to be explained, either at first use or
>> in a glossary.
>
> <abbr title="Microsoft Developer Network">MSDN</abbr>
MSDN (MicroSoft Developer Network) is an acronym¹, not just any
abbreviation. Use the ACRONYM element here instead.
PointedEars
___________
¹ <http://en.wikipedia.org/wiki/Acronym>; see also the references there.
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
The abbr element represents an abbreviation or acronym in HTML 5:
http://dev.w3.org/html5/markup/abbr.html
HTML 5 is merely some wannabes' collective wet dream.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
It most assuredly is _not_ an acronym. We've been over this. If it
isn't intended to be pronounced as a word (e.g. radar, STENDEC), it's
not an acronym (it is simply an abbreviation). The question of whether
to use the (largely useless) ABBR element here is a toss-up. The
determining factor should be whether the intended audience will
recognize MSDN for what it is. For instance, we certainly wouldn't need
to bother with HTML or CSS.
Great reading on the subject:-
> Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>>> Dr J R Stockton wrote:
>>>> Garrett Smith posted:
>>>>> | Scriptable browsers have proprietary object models (MSDN, MDC),
>>>>> | that include many other features (window, screen,
>>>>> | document.execCommand).
>>>> Every acronym in the FAQ needs to be explained, either at first use or
>>>> in a glossary.
>>> <abbr title="Microsoft Developer Network">MSDN</abbr>
>>
>> MSDN (MicroSoft Developer Network) is an acronym¹, not just any
>> abbreviation. Use the ACRONYM element here instead.
>
> It most assuredly is _not_ an acronym.
I say it is.
> We've been over this.
And by contrast to you I have not been posting a reference to a Web site
of some half-wit who is not even a speaker of English as first language,
hardly an authority on the subject. Now you only need to notice that.
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)
But that doesn't make it so. :)
>
>> We've been over this.
>
> And by contrast to you I have not been posting a reference to a Web site
> of some half-wit who is not even a speaker of English as first language,
> hardly an authority on the subject. Now you only need to notice that.
>
Jukka is quite an authority on HTML IMO. Who cares if he speaks English
as a first language? I found that article insightful and had no problem
understanding his English. Do _you_ speak English as a first language?
And that is beside the point anyway. I meant we had been over the radar
thing, which has nothing to do with Jukka's site. ;)
How are you pronouncing this alleged acronym? Without any vowels it's
going to be difficult. An acronym is a word and is pronounced as a word,
not a sequence of letters. MSDN is pronounced M S D N with four
syllables and each letter is spoken individually. True acronyms aren't
spelled out letter by letter, they're spoken as words and often aren't
even capitalized anymore.
Examples: Laser, Radar, Sonar, Ram, Rom.
> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Garrett Smith wrote:
>>>>> Dr J R Stockton wrote:
>>>>>> Garrett Smith posted:
>>>>>>> | Scriptable browsers have proprietary object models (MSDN, MDC),
>>>>>>> | that include many other features (window, screen,
>>>>>>> | document.execCommand).
>>>>>> Every acronym in the FAQ needs to be explained, either at first use
>>>>>> or in a glossary.
>>>>> <abbr title="Microsoft Developer Network">MSDN</abbr>
>>>> MSDN (MicroSoft Developer Network) is an acronym¹, not just any
>>>> abbreviation. Use the ACRONYM element here instead.
>>> It most assuredly is _not_ an acronym.
>> I say it is.
>
> But that doesn't make it so. :)
True, I am relying here on the professional linguistic experience of
several other people speaking English as first language, and on obvious
etymologic and semantic relationships among Indo-European languages,
including my native one (German). Use the URL I posted and get yourself
informed (especially, consider the references there).
>>> We've been over this.
>>
>> And by contrast to you I have not been posting a reference to a Web site
>> of some half-wit who is not even a speaker of English as first language,
>> hardly an authority on the subject. Now you only need to notice that.
>
> Jukka is quite an authority on HTML IMO.
He has his moments, but that is irrelevant here.
> Who cares if he speaks English as a first language? [...]
A person who truly wants to know how the English terms "abbreviation" and
"acronym" can be reasonably defined and might be related to one another,
which would define in turn which one of the two HTML elements, ABBR or
ACRONYM, they should use to mark up certain words. (The HTML 5 WD aside.)
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
<snip>
>It most assuredly is _not_ an acronym. We've been over this. If it
>isn't intended to be pronounced as a word (e.g. radar, STENDEC), it's
>not an acronym (it is simply an abbreviation).
<snip>
According to the online Webster's Dictionary an acronym is something
that can be pronounced, maser, and also something that can't, SPQR. The
Wikipedia article agrees that these two meanings are in common use.
The defining point is that an acronym is built from initial letters,
whereas a mere abbreviation need not be.
John
--
John Harris
> David Mark wrote:
>> It most assuredly is _not_ an acronym. We've been over this. If it
>> isn't intended to be pronounced as a word (e.g. radar, STENDEC), it's
>> not an acronym (it is simply an abbreviation).
>
> According to the online Webster's Dictionary an acronym is something
> that can be pronounced, maser, and also something that can't, SPQR. The
> Wikipedia article agrees that these two meanings are in common use.
>
> The defining point is that an acronym is built from initial letters,
> whereas a mere abbreviation need not be.
Well put. More precisely, there appears to be agreement in all sources
that an acronym is a special form of abbreviation.
I presume it was this ambiguity that led the WHATWG to believe that the
ACRONYM element was unnecessary in the HTML 5 they are drafting, that ABBR
sufficed. However, I do not think it is because acronyms in the sense of
initialisms would often need to be interpreted and spoken differently than
mere abbreviations (like "eightch-tea-em-el" ["HTML"] vs. "et cetera"
["etc."]). Perhaps they argued that this difference would be
presentational and therefore should not be covered by a markup language,
that an aural stylesheet should take care of that instead, but consequently
they would have needed to abolish B and I in favor of SPAN with font-
weight/font-style as well, which they did not.
X-Post & F'up2 comp.infosystems.www.authoring.html
PointedEars
For the simple-=minded pedants : that applies to all of the acronyms in
the FAQ. There is at least one.
It does not of itself apply to non-acronyms; but it indicates an
argument which applies equally well to abbreviations and to jargon in
general.
The explanations need to be in ordinary displayed text; using some HTML
feature such as <abbr> which may or may not be displayed is permissible
but insufficient.
Moreover, since the FAQ is posted in parts to the newsgroup for comment,
the explanations need to be in a form which will naturally appear there
in a similar form.
Aside : Someone recently has remarked on the ugly and
distracting (to the literate) quote-marks which
appear in the news version, I think where the HTML
has <code> & </code>. It would be better to use
either underscore (which is not otherwise needed)
or a si8ngle space (making three in all).
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3 6.20 ; WinXP.
> [abbreviations and jargon in the FAQ]
> The explanations need to be in ordinary displayed text; using some HTML
> feature such as <abbr> which may or may not be displayed is permissible
> but insufficient.
Yes, an explaining `title' attribute, and a glossary link and entry would
be a good idea.
> Moreover, since the FAQ is posted in parts to the newsgroup for comment,
> the explanations need to be in a form which will naturally appear there
> in a similar form.
>
> Aside : Someone recently has remarked on the ugly and
> distracting (to the literate) quote-marks which
> appear in the news version, I think where the HTML
> has <code> & </code>.
That someone was me.
> It would be better to use
> either underscore (which is not otherwise needed)
The underscore is defined as a means to provide underlined formatting for
supporting user agents. If the source code would be displayed underlined,
it would be harder to read. Those user agents include Mozilla-based ones
(SeaMonkey, Thunderbird etc.), Outlook Express with plugin (perhaps Windows
Mail too?), KNode and presumably others, so that is not a good idea.
> or a si8ngle space (making three in all).
A lot better.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
No, not "title". The literate expect to see such things in-line in the
displayed text, either as "Eritrean Judo Association (EJA)" or as "EJA
(Eritrean Judo Association)" on first appearance. One should not be
forced to look elsewhere for abbreviations / acronyms.
That should be done also for things which look like abbreviations
acronyms but [now] are not : e.g. ECMA (ex- European Computer
Manufacturers Association, now Ecma International) _ or just _ ECMA (now
Ecma International).
>> Moreover, since the FAQ is posted in parts to the newsgroup for comment,
>> the explanations need to be in a form which will naturally appear there
>> in a similar form.
>>
>> Aside : Someone recently has remarked on the ugly and
>> distracting (to the literate) quote-marks which
>> appear in the news version, I think where the HTML
>> has <code> & </code>.
>
>That someone was me.
>
>> It would be better to use
>> either underscore (which is not otherwise needed)
>
>The underscore is defined as a means to provide underlined formatting for
>supporting user agents. If the source code would be displayed underlined,
>it would be harder to read.
I did not write "underline". Underscore is a character, ASCII 95, which
can be put in News wherever it is wanted. I did not suggest that it be
put in the HTML, rather that it be added, in place of the characters `
and ` , by the HTML-to-text conversion process. Bart?
Underscore works better than a space when it falls at the end of a line.
You are not very good at reading English, presumably because of undue
haste. Festina lente.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7)
Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
> Thomas 'PointedEars' Lahn posted:
>> Dr J R Stockton wrote:
>>> [abbreviations and jargon in the FAQ]
>>> The explanations need to be in ordinary displayed text; using some HTML
>>> feature such as <abbr> which may or may not be displayed is permissible
>>> but insufficient.
>> Yes, an explaining `title' attribute, and a glossary link and entry
>> would be a good idea.
>
> No, not "title".
Yes, `title'.
> The literate expect to see such things in-line in the
> displayed text, either as "Eritrean Judo Association (EJA)" or as "EJA
> (Eritrean Judo Association)" on first appearance. One should not be
> forced to look elsewhere for abbreviations / acronyms.
Your logic is flawed. One uses abbreviations in text in order _not_ to
disturb the flow of reading with complex explanations.
The `title' attribute of an (X)HTML element can and is specified to provide
immediate information as to the meaning of the element's content, both for
visual and non-visual readers: it can be used for tooltips, either
implicitly (many graphical browsers do that) or explicitly (as a CSS-
powered tooltip, scripted too where available); screenreaders would allow
reading the value of the `title' attribute to the user. Furthermore, the
glossary entry can provide more detailed information, and the link to the
glossary entry on the element provides immediate access to the former.
Combining those two approaches avoids using complicated terms in the
original text. This provides the most user-friendly presentation of
textual information and is most appropriate for the Web. There is even a
built-in cursor shape that signifies the affordance of such a link: `help'.
> That should be done also for things which look like abbreviations
> acronyms but [now] are not : e.g. ECMA (ex- European Computer
> Manufacturers Association, now Ecma International) _ or just _ ECMA (now
> Ecma International).
If the `title' attribute or a tooltip created using other means would not
suffice, the linked glossary entry would.
>>> It would be better to use
>>> either underscore (which is not otherwise needed)
>>
>> The underscore is defined as a means to provide underlined formatting
>> for supporting user agents. If the source code would be displayed
>> underlined, it would be harder to read.
>
> I did not write "underline".
Underlined text is the possible outcome of using corresponding underscore
characters.
> Underscore is a character, ASCII 95, which can be put in News wherever it
> is wanted.
Apparently you do not understand that certain characters are given special
meaning, not only semantically, but in actual text formatting, when used in
corresponding pairs: *bold* /italic/ _underline_ While some newsreaders
are more lenient not to consider those characters format delimiters when
they are set apart with whitespace, or followed or preceded by punctuation,
others are not.
> I did not suggest that it be put in the HTML,
I was/am well aware of that.
> rather that it be added, in place of the characters ` and ` , by the
> HTML-to-text conversion process.
Yes, and I pointed out that and why that would be not a good idea. Another
important counter-argument is ambiguity: _ is a valid identifier.
> Underscore works better than a space when it falls at the end of a line.
When source code would span several lines, or there would be other possible
ambiguities, it should be set apart differently (new paragraph,
indentation). Regardless, your argument is flawed as a trailing whitespace
character followed by underscore is likely to result in the underscore
character being word-wrapped to the next line, still leaving doubt as to
whether the underscore belonged to the source code or delimited it.
> You are not very good at reading English, presumably because of undue
> haste. Festina lente.
Pot, kettle, black.