Javascript standards...

[Ian]

Hi there,

Can anybody tell me where I can find a standards documents like you have in
c#.

I am trying to write javascript and would like to know what standards are
i.e.

Where to put the javascript function i.e. in Head , Body or Below?

WHen to use pascal casing i.e. variables etc..

Any help would be really appreciated

Thanks

Ian

 

[Lasse Reichstein Nielsen]

Can anybody tell me where I can find a standards documents like you have in
c#.
ECMAScript:
<URL:http://www.mozilla.org/js/language/E262-3.pdf>

DOM:
<URL:http://www.w3.org/TR/DOM-Level-2-Core/>
<URL:http://www.w3.org/TR/DOM-Level-2-HTML/>

I am trying to write javascript and would like to know what standards are
i.e.

Where to put the javascript function i.e. in Head , Body or Below?

HTML:
<URL:http://www.w3.org/TR/html4/>
(Script elements can be placed in most places inside either the head
or body elements, and nowhere else).

WHen to use pascal casing i.e. variables etc..

ECMAScript is case sensitive, but there are no restrictions on the
cases used. Traditions seems to suggests Java-like casing;

normal variables and functions: camelCase
constructor functions: CapitalizedCamelCase
magic constants: ALL_CAPITALS_AND_UNDERSCORES

Example:
---
var MAGIC_CONSTANT = 42;
function Foo(x) {
this.x = x;
}
var foo = new Foo(MAGIC_CONSTANT);
alert(foo.x);
---

The FAQ for this group is a good start for the practical application
of all these standards and specifications:
<URL:http://jibbering.com/faq/>
Likewise are the browser manufacturers' documentation:

<URL:http://devedge.netscape.com/library/manuals/2000/javascript/1.5/reference/>
<URL:http://www.mozilla.org/docs/dom/domref/>
<URL:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/js56jsoriJScript.asp>
<URL:http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/dhtml_node_entry.asp>

Douglas Crockford has an overview of the language here:
<URL:http://www.crockford.com/javascript/survey.html>

Good luck.
/L

 

[Ivan Marsh]

Hi there,

Can anybody tell me where I can find a standards documents like you have
in c#.

That's a funny question considering Micro$oft "embraced and enhanced"
javascript which is why there is more than one "standard".

 

[Ian]

Cheers, great stuff!

Just what I needed... thanks

Ian

 

[DU]

Hi there,

Can anybody tell me where I can find a standards documents like you have in
c#.

I am trying to write javascript and would like to know what standards are
i.e.

Where to put the javascript function i.e. in Head , Body or Below?

WHen to use pascal casing i.e. variables etc..

Any help would be really appreciated

Thanks

Ian

Get yourself Mozilla (say, Mozilla 1.6)

http://www.mozilla.org/
http://www.mozilla.org/start/1.6/

then go to

http://devedge.netscape.com/toolbox/sidebars/

and add in the sidebar these tabs:

# JavaScript 1.5 Guide
# JavaScript 1.5 Reference
DOM 2 References
CSS2.1
HTML 4.01

and you're ready to script. You'll be able to use the best Javascript
debugger there is (Venkman) and use Mozilla's DOM inspector: these are
very powerful tools.

DU

 

[DU]

ECMAScript:
<URL:http://www.mozilla.org/js/language/E262-3.pdf>

DOM:
<URL:http://www.w3.org/TR/DOM-Level-2-Core/>
<URL:http://www.w3.org/TR/DOM-Level-2-HTML/>
<URL:http://www.w3.org/TR/DOM-Level-2-Events/>
(there are a few more)




HTML:
<URL:http://www.w3.org/TR/html4/>
(Script elements can be placed in most places inside either the head
or body elements, and nowhere else).




ECMAScript is case sensitive, but there are no restrictions on the
cases used. Traditions seems to suggests Java-like casing;

normal variables and functions: camelCase
constructor functions: CapitalizedCamelCase
magic constants: ALL_CAPITALS_AND_UNDERSCORES

I think chosing meaningful, self-explanatory identifiers is much more
important than case. Also, prefixing to indicate the type of variable is
helpful when debugging. E.g.:

var strWindowName = "ProductDescription";
var intTableRowsCollection = document.getElementById("idTable").rows;
function ModifyTextNode(strIdNode, strNewText)

are much more useful, clear, explicit, helpful in the short and long run
than

prod = "Product"
rows = document.getElementById("table").rows;
function newtext(text, text2)

Example:

"You can create a read-only, named constant with the const keyword."
http://devedge.netscape.com/library/manuals/2000/javascript/1.5/guide/ident.html#1012982

DU

 

[Lasse Reichstein Nielsen]

I think chosing meaningful, self-explanatory identifiers is much more
important than case.

Definitly, but one does not preclude the other.

Also, prefixing to indicate the type of variable
is helpful when debugging. E.g.:

I'll never get used to that, though. Probably because I'm too used
to write in a language with declared types.

"You can create a read-only, named constant with the const keyword."
http://devedge.netscape.com/library/manuals/2000/javascript/1.5/guide/ident.html#1012982

Great for people using JavaScript 1.5, but who is that?

It's not part of ECMAScript v3, and probably only works in Gecko based
browsers (definitly doesn't work in IE 6 or Opera 7.5 - I'm not able
to check Safari or other KHTML-based browsers).

/L

 

[Lee]

DU said:

I think chosing meaningful, self-explanatory identifiers is much more
important than case. Also, prefixing to indicate the type of variable is
helpful when debugging. E.g.:

var strWindowName = "ProductDescription";
var intTableRowsCollection = document.getElementById("idTable").rows;
function ModifyTextNode(strIdNode, strNewText)

Taken to an extreme, prefixing can make it much more difficult to
read the code. I would suggest to use it when (a) the name doesn't
otherwise make it obvious, and (b) the variable is used more than a
few lines away from where it is assigned, and (c) the type matters.
It's usually more readable to incorporate clues into the name,
rather than use a prefix, anyway:

var windowName = "Product Description";
var today = new Date();
var todayString = today.getLocaleString();
var thisMonthName = monthName[today.getMonth()];
function modifyTextNode(nodeId, newText)

A variable that claims to be a "Name" or to be "Text" only needs to
have its type specified if it is NOT a string.

Similarly a variable named nodeId should be suitable for use as an
argument to getElementById(), unless a nodeId is obviously something
else in the context of the code.

 

[Grant Wagner]

That's a funny question considering Micro$oft "embraced and enhanced"
javascript which is why there is more than one "standard".

No, there is a single standard (<url:
http://www.ecma-international.org/publications/standards/Ecma-262.htm />). All
implementations of ECMAScript vary a little from the standard.

As for "embracing and extending", I recently discovered that the RegExp()
object as defined in the ECMAScript standards has no "compile()" method, yet
practically every implementation of JavaScript (including Opera and Mozilla,
which claim to be the most standards compliant browsers) support a "compile()"
method on objects created using "new RegExp()". So if Microsoft is being
blamed for "embracing and extending" JavaScript, I guess Mozilla and Opera are
guilty of this as well.

You also might be referring to the DOMs of the various browsers, which do
differ, and have since Netscape 4 introduced the proprietary <layer> tag and
it's associated entries in the DOM hierarchy (which came before Microsoft
added the document.all collection to IE 4). However, the discussion of
proprietary DOMs is irrelevant to the discussion of ECMAScript the language.

--
| Grant Wagner <[email protected]>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-developer/upgrade_2.html

 

[Ivan Marsh]

No, there is a single standard (<url:
http://www.ecma-international.org/publications/standards/Ecma-262.htm
/>). All implementations of ECMAScript vary a little from the standard.

Standard is in quotes in my post, indicating that what I was talking about
are not true standards but the standards being used.

Embrace and enhance is how MS screws up everything it gets it's hands on
(tcp/ip, javascript, java, etc...).

Javascript pre-dates the ECMA standard and Netscape/Mozilla are
responsible for the ECMA standard existing.

 

[Grant Wagner]

Standard is in quotes in my post, indicating that what I was talking about
are not true standards but the standards being used.

If it's not the true standard, then it's not a standard.

Embrace and enhance is how MS screws up everything it gets it's hands on
(tcp/ip, javascript, java, etc...).

Exactly how has Microsoft "screwed up" tcp/ip, javascript and java? Nevermind,
whatever you write will be a combination of mis-information and your bias
against Microsoft formed from years of reading slashdot.org.

As for ECMAScript, JScript (now JScript.NET) conforms to the ECMA-262 standard
as documented by <url:
http://msdn.microsoft.com/library/en-us/jscript7/html/jsgrpecmafeatures.asp
/>. If you as a developer are about to use some feature of JScript and are
concerned about compatibility with other browsers, you'd want to check that
feature against the list presented at <url:
http://msdn.microsoft.com/library/en-us/jscript7/html/jsgrpnonecmafeatures.asp
/>.

Javascript pre-dates the ECMA standard and Netscape/Mozilla are
responsible for the ECMA standard existing.

If this is the case, one would think that Mozilla's implementation of
ECMAScript would be 100% compliant, yet Javascript in Mozilla includes
RegExp.prototype.compile(), something which also pre-dates ECMAScript, but
something that is not in ECMA-262. Which brings me back to my original
statement: "All implementations of ECMAScript vary a little from the
standard."

--
| Grant Wagner <[email protected]>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-developer/upgrade_2.html

 

[Ivan Marsh]

If it's not the true standard, then it's not a standard.

Technology exists before the certified standards that describe it.

It may not be a certified standard by a standards board like ISO IEEE or
ECMA but if you create a technology and release documentation describing
how others can use it you've created a standard.

In cronological order:

Windows 3.1

Winsock

Netscape Browser

Javascript

Release of javascript language and Netscape DOM specification

Win 95 w/internet explorer with incompatible DOM and Javascript

Now there is more than one javascript specification to deal with.

Exactly how has Microsoft "screwed up" tcp/ip, javascript and java?
Nevermind, whatever you write will be a combination of mis-information
and your bias against Microsoft formed from years of reading
slashdot.org.

Ah... you're just going to call me a liar rather than realize you're
wrong?

MS uses Embrace and Enhance as a strategy to kill competitive technology.

MS's tcp/ip stack is not compliant with the RFC (though I doubt that has
anything to do with EandE).

Javascript was the same across all browsers until IE was released.

Java was a write once run anywhere language until MS wrote their version
of Java... or did you miss that whole thing between Sun and MS? or the DOJ
trials?

As for ECMAScript, JScript (now JScript.NET) conforms to the ECMA-262
standard as documented by <url:
http://msdn.microsoft.com/library/en-us/jscript7/html/jsgrpecmafeatures.asp
/>. If you as a developer are about to use some feature of JScript and
are concerned about compatibility with other browsers, you'd want to
check that feature against the list presented at <url:
http://msdn.microsoft.com/library/en-us/jscript7/html/jsgrpnonecmafeatures.asp
/>.


If this is the case, one would think that Mozilla's implementation of
ECMAScript would be 100% compliant, yet Javascript in Mozilla includes
RegExp.prototype.compile(), something which also pre-dates ECMAScript,
but something that is not in ECMA-262.

Which brings me back to my original statement: "All implementations of
ECMAScript vary a little from the standard."

I never suggested this statement was incorrect... it is however irrelivent
to the subject because Netscape/Mozilla's implimentation of the language
existed before the ECMA standard.

The history of JavaScript (unless you think O'Reily lies too):
http://www.oreillynet.com/pub/a/javascript/2001/04/06/js_history.html

An Excerpt:

"ECMAScript: an attempt at standardization

The introduction of IE3 and its unfortunate lack of support for the
document.images array led Netscape and Sun to standardize the language
with help from the European Computer Manufacturers Association (ECMA),
giving us yet another name for what had by now become a strange hybrid of
powerful and universally supported core functionality and often
incompatible object models: ECMAScript. Standardization was begun in
conjunction with ECMA in November 1996 and adopted in June 1997 by ECMA
and by ISO in April 1998.

In the meantime, as ECMAScript was being standardized (but unfortunately
neglecting everything but the core language), Netscape and Microsoft
introduced the 4.0 browser generation, each browser with its own
completely proprietary document object model, and "Dynamic HTML" became
the next morass into which JavaScript's good heart was dragged."

 

[Jim Ley]

Javascript was the same across all browsers until IE was released.

no it wasn't it was different between version 2 and 3 of Netscape, but
the single vendor "same" doesn't really matter much.

I never suggested this statement was incorrect... it is however irrelivent
to the subject because Netscape/Mozilla's implimentation of the language
existed before the ECMA standard.

Mozilla didn't even exist before the standard.

In the meantime, as ECMAScript was being standardized (but unfortunately
neglecting everything but the core language),

nope, quite right too, standardise what's relevant to the language not
the wider world.

Now I'll agree that DOM standardisation hasn't gone well and the lack
of any DOM activity at the W3 now is bad, it's not something we can
blame ECMA on.

Jim.

 

[Ivan Marsh]

Mozilla didn't even exist before the standard.

My above statement refers to the organization not the browser.

Look at the Netscape 1.0 browser... it reports as Mozilla.

 

[Grant Wagner]

Ah... you're just going to call me a liar rather than realize you're
wrong?

I'm not calling you a liar, I'm asking for clarification. The fact that you can't
provide any indicates you are simply parroting what others have told you.

MS uses Embrace and Enhance as a strategy to kill competitive technology.

So everything they do must be a variant of embrace and enhance (it's "embrace,
extend and extinguish" <url: http://zdnet.com.com/2100-11-512681.html?legacy=zdnn />
by the way), and is, if you just look hard enough and apply the concept to enough
coincidences. Because Microsoft is The Evil Empire!

MS's tcp/ip stack is not compliant with the RFC (though I doubt that has
anything to do with EandE).

"the RFC"? TCP/IP is a suite of protocols, which RFC(s) do you refer to precisely?
RFC 791 Internet Protocol? RFC 793 Transmission Control Protocol? RFC 768 User
Datagram Protocol? RFC 792 Internet Control Message Protocol? others? And in
_exactly_ what (damaging) ways does Microsoft's suite of protocol(s) vary from the
RFC(s)?

Besides, variation from "the RFC" isn't embrace and enhance[sic] to extinguish
TCP/IP unless it has a damaging affect on the way TCP/IP works on the Internet, or
Windows machines in particular. The fact that millions of Windows computers
world-wide interact on the Internet without bringing it or themselves to their knees
seems to point to the fact that whatever differences Microsoft has included are not
fatal to the operation of the Internet or their own interaction with it.

As I said, whatever you write will be a combination of mis-information (refering to
"the [TCP/IP] RFC") and your bias against Microsoft formed from years of reading
slashdot.org ("MS uses Embrace and Enhance as a strategy to kill competitive
technology" - which was said - and misquoted by you - by _one_ person 6 years ago).

Javascript was the same across all browsers until IE was released.

Since Java(Live)script only existed in Netscape browsers before IE supported
JScript, I guess that's a true enough statement. Once someone else released an
implementation of Javascript it could no longer be "the same" because it runs on
another user agent. Not including the document.images collection [below] was more a
question of the timing of the release of JScript in IE3, rather then any deliberate
act to do damage to Java(Live)script. I'm sure if Microsoft had had time, they would
have wanted to include all the functionality of the original Java(Live)script, since
at that point it became a feature race.

Java was a write once run anywhere language until MS wrote their version
of Java... or did you miss that whole thing between Sun and MS? or the DOJ
trials?

Java compiled with Sun's Java 1.1.x compilers runs on Microsoft's JVM, Java compiled
with J++ with Microsoft extensions enabled does not run on other Virtual Machines.
Avoid the extensions and the code runs elsewhere. Sun managed to convince the courts
that somehow developers compiling Java with extensions to make it run more
efficiently on their platform choice (or through ignorance) was damaging to them.

There are lots of features that are in ECMAScript now that weren't in the first
release of Javascript, there are some that are deprecated and some methods have
actually changed how they behave. None of these

I never suggested this statement was incorrect... it is however irrelivent
to the subject because Netscape/Mozilla's implimentation of the language
existed before the ECMA standard.

And that's my point. If the language that inspired the standard came _before_ the
standard, then why doesn't the standard conform to the language which inspired it?

The history of JavaScript (unless you think O'Reily lies too):
http://www.oreillynet.com/pub/a/javascript/2001/04/06/js_history.html

An Excerpt:

"ECMAScript: an attempt at standardization

The introduction of IE3 and its unfortunate lack of support for the
document.images array led Netscape and Sun to standardize the language
with help from the European Computer Manufacturers Association (ECMA),
giving us yet another name for what had by now become a strange hybrid of
powerful and universally supported core functionality and often
incompatible object models: ECMAScript. Standardization was begun in
conjunction with ECMA in November 1996 and adopted in June 1997 by ECMA
and by ISO in April 1998.

document.images is part of the DOM, _not_ the language. That entire paragraph talks
about the _object model_ (DOM) of the various browsers. Which is different from the
ECMAScript _language_. The document object of which the images[] collection is a
member isn't even part of ECMAScript, nor is the Image() object itself. The
inclusion or exclusion of these user agent DOM objects and collections does not
dictate the level of ECMAScript compliance in the user agent.

In the meantime, as ECMAScript was being standardized (but unfortunately
neglecting everything but the core language), Netscape and Microsoft
introduced the 4.0 browser generation, each browser with its own
completely proprietary document object model, and "Dynamic HTML" became
the next morass into which JavaScript's good heart was dragged."

"...ECMAScript was being standardized (but unfortunately neglecting everything but
the core language)..." wow, that's a goofy thing to say. ECMA-262 is the standard
for the _language_, it "neglected everything but the core language" because the only
thing it was a standard for was the core language. Duh.

If you want to complain about user agent DOM standardization, you are talking about
the W3C DOM standards (<url: http://www.w3.org/DOM/ />).


You seem to be arguing that JScript implementations aren't ECMAScript compliant when
what you seem to mean is that the user agent DOM isn't W3C compliant. Once you
figure out what the point you're trying to make is, get back to me.

 

[Ivan Marsh]

You seem to be arguing that JScript implementations aren't ECMAScript
compliant when what you seem to mean is that the user agent DOM isn't
W3C compliant. Once you figure out what the point you're trying to make
is, get back to me.

My point is exactly what my OP said:

Micro$oft "embraced and enhanced" javascript which is why there is more
than one "standard".

 

[Matt Kruse]

Micro$oft "embraced and enhanced" javascript which is why there is
more than one "standard".

Netscape "embraced and enhanced" java(live)script itself between early
versions of it's first browser.

Since there was no standard, and Microsoft had to write their own version of
java(live)script from scratch anyway, how could anyone expect it to be
exactly the same as Netscape's version? Why would it?

Just because Netscape was first, that makes their version the 'standard'
forever?

 

[Ivan Marsh]

Netscape "embraced and enhanced" java(live)script itself between early
versions of it's first browser.

Since there was no standard, and Microsoft had to write their own
version of java(live)script from scratch anyway, how could anyone expect
it to be exactly the same as Netscape's version? Why would it?

Just because Netscape was first, that makes their version the 'standard'
forever?

If you think the only thing that constitutes a standard is a standard
certified by a standards board than there is no way were going to agree on
any of this.

Netscape published their standard of JavaScript and made it available to
everyone.

....and if you think MS doesn't purposfully write incompatibilities into
their software to squash competition you just haven't been paying
attention over the last 10 years.