Singleton desing patter approach without function expressions...

[Luke Matuszewski]

I am designing the library, which will hidden all its functions within
singleton object ... So for clients
they will use it like [functional_prefix].[function_name] eg.

system.getElementWithId('ruler');
At library side, i will use constructs like follows (at global scope)
eg.

function System() {

function _getElementWithId(id) {
/*
GENERIC CODE (using first DOM getElementById(id) and if not
successful
using document.all with some checks...)
*/
}

/*
MORE UTIL FUNCS
*/

this.getElementWithId = _getElementWithId;
/*
MORE ASSIGMENTS like
this.[util_method] = _[util_method];
*/

}

var system = new System();

System = null; /* since System constructor is desinged to produce
singletons, and it
should not be visible after singleton
instantiation... */

My question is simple, can i use construct like:

System = null;

, to redefine constructor System reference to null ? If not, then how i
should do it ?
Also remember that i can't use function expressions like

function(...) { }

I will appreciate somebody knowlegable to lighten my problem...

Best regards
Luke Matuszewski

[Matt Kruse]

Luke Matuszewski wrote:

I am designing the library, which will hidden all its functions within
singleton object ... So for clients
they will use it like [functional_prefix].[function_name] eg.
There is a better way to do what you're trying to do.
For example, this is simple:

var System = new Object();
System.getElementWithId = function() { }
System.otherFunction = function() { }
var system = new System();
System = null; /* since System constructor is desinged to produce
singletons, and it
should not be visible after singleton
instantiation... */

I don't believe that is a good example of the singleton pattern. Rather than
allowing multiple calls to a getInstance(), all of which return the same
instance, you're just destroying the constructor entirely. Why even bother?

Try this, for example:

var Singleton = (function() {
// This isn't "lazy" instantiation, but you could do that if you wanted
var instance = new Object();
instance.property = Math.random(1000);
return {'getInstance':function() { return instance; }}
})();

// The next line will generate a script error.
// You should not be able to directly instantiate an instance of the class
var object = new Singleton();

// The proper way to get the class instance
var x = Singleton.getInstance();
alert(x.property); // Alerts random number
var y = Singleton.getInstance();
alert(y.property); // Alerts same random number
alert(x==y); // True - same object

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Matt Kruse]

Luke Matuszewski wrote:

Also remember that i can't use function expressions like
function(...) { }

Oh, and what does that even mean?

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Luke Matuszewski]

Matt Kruse wrote:

Luke Matuszewski wrote:

Also remember that i can't use function expressions like
function(...) { }

Oh, and what does that even mean?

Function expressions is expressions that returns function reference
(EcmaScript 3rd ed.- 13) like:

....
System.someFunc = function() {
/* CODE */
}
....

Function expressions where not present in EcmaScript 2nd and 1st
ed.(only function declarations where present). If i will not use
function expressions, then i could write code that
will run in all browsers (maybe without result, but also without errors
in old browsers if they encounter function expressions).
Also it seems that function expressions, in the form of

var System.someFunc = function identifier(...) { /* syntax allowed
since JavaScript 1.2 and JScript 1.0 */
}

, or in the form of

var System.someFunc = function(...) { /* syntax allowed since
JavaScript 1.5(!) and JScript ?(do not remeber) */
}

My only apprehension is question: can i null'yfi the function
identifier like:

function System() {
/* code */
}

var system = new System();
System = null; /* THIS */

, so System() constructor will not be visible after THIS statement.
(also see that if i can, there is only one object system, so no memory
leaks will happen in IE revelant to many execution contexts...).

Anyway, thanks for such knowlegable examples ;-)
Best regards
Luke Matuszewski

[Luke Matuszewski]

Matt Kruse wrote:

http://www.JavascriptToolbox.com

PS your example in http://www.JavascriptToolbox.com of moving <iframe>
is not strictly valid agains used doctype. Your are using:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

, and <iframe> is only allowed in loose dtd (see
http://www.w3.org/TR/html4/index/elements.html). To correct it, you
will have to use <object> instead of <iframe>... Thats all according to
specs, but according to real world the <iframe> tag is supported wider
by existing (existed) user agenst than the <object> tag (so maybe to
support all user agents there should be user-agent version checking...
but thats always bad idea).
See
<URL:http://www.cs.tut.fi/~jkorpela/html/iframe.html>
<URL:http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.5>
<URL:http://www.w3.org/TR/2000/NOTE-WCAG10-HTML-TECHS-20000920/#alt-frames>
<URL:http://www.stack.nl/htmlhelp/faq/html/design.html#include-file>
<URL:http://www.webmasterworld.com/forum21/6539.htm>
<URL:http://www.webmasterworld.com/forum21/11590.htm>

To make a solution, on the page where you present moving <iframe>'s,
use:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

, as the table on <URL:http://hsivonen.iki.fi/doctype/> suggests (only
Konqueror 3.2 switches to quirk :( ). Also can also use strict doctype
inside iframe's, to maintain standards mode.

[VK]

Luke Matuszewski wrote:

var system = new System();
System = null; /* THIS */

IE (specially IE 5.x) chokes sometimes on nullifying function
references this way. Nothing to do with ECMA - just IE behavior. It is
more secure (and user friendly) to emulate the GetObject behavior thus
if an instance doesn't exists then create one; if an instance already
exists then return a reference to the existing instance.

function System() {
if (typeof System.instance == 'undefined') {
this.foo = ...
this.bar = ...
System.instance = this;
System.toString = function() {return 'function';}
}
else {
return System.instance;
}
}

// create instance:
var system = new System();

// this simply returns a reference to
// the existing instance:
var system2 = new System();

I also like to kill toString method for constructor (see above) to
prevent source code dump at runtime. Now alert(System) simply displays
"function". Not obligatory, but may be helpful.

Overall you have to remember that it is nothing like in say C++. In
compiled languages all these public/private/singleton/multiton :-)
indeed produce compiled binary code with some predefined behavior, and
to change that behavior one has either to crack the code or to steal
the source. In JavaScript anyone can open your .js file and make all
your private members public or transform your singleton into an
auto-multiplying object.
So your concern should be about *runtime* only in two aspects only:
1) occasional environment damage (say some vital property overriden by
mistake due say a name conflict)
2) script highjaking (so your script is forced to act in a
non-desirable way or expose non-desirable property) - once again *at
runtime*

[VK]

Luke Matuszewski wrote:

PS your example in http://www.JavascriptToolbox.com of moving <iframe>
is not strictly valid agains used doctype. Your are using:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Which is always a bad idea because strict.dtd is defective and never
was corrected since the original publication in 1999

It doesn't have <iframe> which alone makes it unusable in the modern
Web. Also it has some rude mistakes in form element definitions (like
missing "wrap" attribute for textarea).

Also it worth to point out that is someone is really crazy about
standard perfectness then HTML 4.01 should be connected with the
relevant DTD:
<http://www.w3.org/TR/html401/strict.dtd>

because <http://www.w3.org/TR/html4/strict.dtd> points to the previous
version (HTML 4.0)

It has no practical sense though because both
<http://www.w3.org/TR/html4/strict.dtd> and
<http://www.w3.org/TR/html401/strict.dtd> are exact copies of the very
same document (?!?!?)

Whoever is wondering what a hey they can try to reach someone Dave
Raggett <ds*@w3.org> who's claimed to be the author of both
masterpieces.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

Again the really correct version is:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html401/loose.dtd">

(with the same practical outcome - namely with a total absence of such)

[Matt Kruse]

Luke Matuszewski wrote:

Function expressions where not present in EcmaScript 2nd and 1st
ed.(only function declarations where present). If i will not use
function expressions, then i could write code that
will run in all browsers

If you can name a browser that is still in use that does not support
function expressions, you might have a point.
Writing code that still supports Netscape 2.0, for example, is a pointless
exercise.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Luke Matuszewski]

VK napisal(a):

Luke Matuszewski wrote:

PS your example in http://www.JavascriptToolbox.com of moving <iframe>
is not strictly valid agains used doctype. Your are using:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Which is always a bad idea because strict.dtd is defective and never
was corrected since the original publication in 1999

I must not agreed. For me standard that was accepted and largely
disscused at HTML ERB before formalization is good standard (also HTML
4.0 what certified in 1998 and HTML 4.01 is bugfixed version of that
HTML 4.0 standard defined in december of 1999).

It doesn't have <iframe> which alone makes it unusable in the modern
Web. You can always use XmlHttpObject (AJAX) to make <iframe> emulation
inside <div> (using responseText as innerHtml or even as
document.write(XmlHttpObjectInstance.responseText) .
Also it worth to point out that is someone is really crazy about
standard perfectness then HTML 4.01 should be connected with the
relevant DTD:
<http://www.w3.org/TR/html401/strict.dtd>

because <http://www.w3.org/TR/html4/strict.dtd> points to the previous
version (HTML 4.0)

It has no practical sense though because both
<http://www.w3.org/TR/html4/strict.dtd> and
<http://www.w3.org/TR/html401/strict.dtd> are exact copies of the very
same document (?!?!?)
Again i will not agree.
To answer why i suggested :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

, i will point you to <URL:http://hsivonen.iki.fi/doctype/> (and if you
don't like to read much i will explain that with above doctype user
agents presented on table will "switch" themself to standards mode
(which means that they will try to use standards defined by w3c.org
concerning CSS and HTML when they will render the web page)... so for
me i will use:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

or even:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd"> <!--Which allow me to use
<iframe> techniques-->

I know that you like IE (or are interested in IE), and so even on
microsoft site you can see my examples of doctype. See
<URL:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp>

Whoever is wondering what a hey they can try to reach someone Dave
Raggett <ds*@w3.org> who's claimed to be the author of both
masterpieces.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

Again the really correct version is:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html401/loose.dtd">

No. As you can see, even HTML 4.01 Recomendation specifies

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

or

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

See <URL:http://www.w3.org/TR/html401/struct/global.html#h-7.2> (which
is your HTML 4.01 Specification).

So first look inside specs before you will use words like 'no practical
sense' or 'defective'. I your words are true then organizations like:
MIT <URL:http://www.lcs.mit.edu/>,
INRIA <URL:http://www.inria.fr/>
Keio <URL:http://www.keio.ac.jp/>
and at last but not least W3C <URL:http://www.w3.org/>
, will have to be also with 'no practical sense' or 'defective'.

Best regards.
Luke M.

[Luke Matuszewski]

Matt Kruse napisal(a):

Luke Matuszewski wrote:

Function expressions where not present in EcmaScript 2nd and 1st
ed.(only function declarations where present). If i will not use
function expressions, then i could write code that
will run in all browsers

If you can name a browser that is still in use that does not support
function expressions, you might have a point.
Writing code that still supports Netscape 2.0, for example, is a pointless
exercise.

Agree. From my point of view, scripts that work down to Netscape 4.0x
(in a sense that they do not do harm, including memory leaks provided
by circular references between ActiveX objects and DOM objects in IE)
are well written. From this point (Netscape 4.0x) you can always use
function expression syntax below:

System.myFunc = function
identifierOnlyForReferencingInsideThisFunction() {

}

(the syntax: function(...) { } is only supported from JavaScript
1.5(Netscape 6.x), thus should be avoided if writting scripts that
should run on them too).

Again ***thanks*** for knowlegable examples from Matt Kruse and VK.

Best regards.
Luke M.

PS Matt you can update your http://www.AjaxToolbox.com to suppor
IceBrowser see <URL:http://www.jibbering.com/2002/4/httprequest.html>
(window.createRequest)

[Matt Kruse]

VK wrote:

Luke Matuszewski wrote:

PS your example in http://www.JavascriptToolbox.com of moving
<iframe> is not strictly valid agains used doctype. Your are using:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

Which is always a bad idea

Ridiculous.

Putting browsers into standards mode vs. quirks mode is definitely
recommended.
Just because the DTD doesn't allow iframes, for example, doesn't mean that
browsers won't allow them in the source and show them correctly. It just
means that it won't validate perfectly. Who cares. At least the browser is
in standards mode.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Jim Ley]

On Sun, 5 Feb 2006 08:59:33 -0600, "Matt Kruse"
<ne********@mattkruse.com> wrote:

VK wrote:

Luke Matuszewski wrote:

PS your example in http://www.JavascriptToolbox.com of moving
<iframe> is not strictly valid agains used doctype. Your are using:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

Which is always a bad idea

Ridiculous.

Putting browsers into standards mode vs. quirks mode is definitely
recommended.
Just because the DTD doesn't allow iframes, for example, doesn't mean that
browsers won't allow them in the source and show them correctly. It just
means that it won't validate perfectly. Who cares. At least the browser is
in standards mode.

Absolutely, if the UA's are going to play silly buggers with standards
and quirks mode, you've got to play along.

Jim.

[Luke Matuszewski]

Matt Kruse napisal(a):

Putting browsers into standards mode vs. quirks mode is definitely
recommended.
Just because the DTD doesn't allow iframes, for example, doesn't mean that
browsers won't allow them in the source and show them correctly. It just
means that it won't validate perfectly. Who cares. At least the browser is
in standards mode.

You can also use:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd"> <!-- you can use <iframe> !
;-) -->

(doctype with URL), and all browser (almost - the exception is
Konqueror 3.2 but i am almost sure that they will change this to
"almost standards mode" - which common for IE6, Mozilla (Gecko),
Safari... when used with Transitional).
See <URL:http://hsivonen.iki.fi/doctype/> and
<URL:http://gutfeldt.ch/matthias/articles/doctypeswitch/table.html>
(so Transitional with System URI is really standards or almost
standards mode).

Best regards
Luke Matuszewski

[Luke Matuszewski]

Luke Matuszewski napisal(a):

You can also use:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
^^^^ "http://www.w3.org/TR/html4/loose.dtd"> <!-- you can use <iframe> !
;-) --> sorry my fault, you actualy can use:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd"> <!-- ^^^^^ -->
(doctype with URL), and all browser (almost - the exception is
Konqueror 3.2 but i am almost sure that they will change this to
"almost standards mode" - which common for IE6, Mozilla (Gecko),
Safari... when used with Transitional).
See <URL:http://hsivonen.iki.fi/doctype/> and
<URL:http://gutfeldt.ch/matthias/articles/doctypeswitch/table.html>
(so Transitional with System URI is really standards or almost
standards mode).

Best regards
Luke Matuszewski

[VK]

Jim Ley wrote:

On Sun, 5 Feb 2006 08:59:33 -0600, "Matt Kruse"
<ne********@mattkruse.com> wrote:

VK wrote:

Luke Matuszewski wrote:
PS your example in http://www.JavascriptToolbox.com of moving
<iframe> is not strictly valid agains used doctype. Your are using:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Which is always a bad idea

Ridiculous.

Putting browsers into standards mode vs. quirks mode is definitely
recommended.
Just because the DTD doesn't allow iframes, for example, doesn't mean that
browsers won't allow them in the source and show them correctly. It just
means that it won't validate perfectly. Who cares. At least the browser is
in standards mode.

Absolutely, if the UA's are going to play silly buggers with standards
and quirks mode, you've got to play along.

Declare Strict mode knowing in advance that you're going to break it is
a pure hypocrisy. If you need a standard-compliant mode from IE (for
say uniformed element offset calculations) then use

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html401/loose.dtd">

P.S. In some higher education establishments I've seen even more
ridicilous approach: people were making iframe-less HTML with iframes
generated and inserted onload via JavaScript (document.createElement).
I've seen one prof who was debugging his iframe behavior while
periodically validating the page against the 4.01 Strict.
I see *he was happy* by seeing that both iframe is working properly and
4.01 Strict is validated. I'm not sure is it a new XX! century
psychosis or simply a childish behavior.
In any case it would be nice to see the majority of developers acting
normal and adult-like.

[Luke Matuszewski]

Furthermore "almost standards mode" is "standars mode" with addition to
this:
<quote>
"Almost standards" rendering mode is exactly the same as "standards"
mode in all details save one: the layout of images inside table cells
is handled as they are in Gecko's "quirks" mode, which is fairly
consistent with other browsers, such as Internet Explorer. This means
that sliced-images-in-tables layouts are less likely to fall apart in
Gecko-based browsers based on the rendering engine found in Mozilla
1.0.1 or later when in either "quirks" or "almost standards" mode. (See
the DevEdge article "Images, Tables, and Mysterious Gaps" for a
detailed explanation of how such layouts are treated in "standards"
mode.)
</quote>
<URL:http://developer.mozilla.org/en/docs/Gecko's_%22Almost_Standards%22_Mode>

BR
Luke Matuszewski

[VK]

Luke Matuszewski wrote:

, i will point you to <URL:http://hsivonen.iki.fi/doctype/> (and if you
don't like to read much i will explain that with above doctype user
agents presented on table will "switch" themself to standards mode
(which means that they will try to use standards defined by w3c.org
concerning CSS and HTML when they will render the web page)... so for
me i will use:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
You did not get my point. DTD declares used scheme in the first
segment, and DTD file containing the scheme in the second segment. The
second part is needed if say browser has no clue what HTML 4.01 is:-
then it can retrieve the scheme from the file to validate.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

is a *contradictory invalid* declaration because in the first segment
you declare HTML 4.01, but you propose as the validation scheme file
HTML 4.0 <http://www.w3.org/TR/html4/strict.dtd>

It doesn't have sense from any point of view. If you want HTML 4.01,
then please provide the relevant DTD file:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html401/strict.dtd">

(this file exists and waiting for you)
I know that you like IE (or are interested in IE)

My position is clearly expressed in
Message-ID: <11**********************@o13g2000cwo.googlegroups .com>

So no, I'm not Microsoft biased but at the same time "Microsoft must
die" is not my post auto-signature :-)

It is not related though to the question of matching the scheme
declaration to the scheme file.
For HTML 4.0 we're using one file
For HTML 4.01 we're using other file

The fact that this contradiction was not noticed for so many years (and
the relevant <http://www.w3.org/TR/html401/> folder stayed without use)
is just another proof of how "serious" all this DTD story is.

[Thomas 'PointedEars' Lahn]

Matt Kruse wrote:

VK wrote:

Luke Matuszewski wrote:

PS your example in http://www.JavascriptToolbox.com of moving
<iframe> is not strictly valid agains used doctype. Your are using:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"> Which is always a bad idea

Ridiculous.

Agreed.
Putting browsers into standards mode vs. quirks mode is definitely
recommended.
Non sequitur.
Just because the DTD doesn't allow iframes, for example, doesn't mean that
browsers won't allow them in the source and show them correctly. It just
means that it won't validate perfectly. Who cares.
Obviously you do not. Other people do because they care for _interoperable_
markup, that is, markup that has the potential to work everywhere and
anytime (for the foreseeable future), not markup that works only in a few
versions of a few user agents.
At least the browser is in standards mode.

Nonsense. Standards Compliance Mode does not require a Strict DTD. HTML
4.01 Transitional also triggers this mode and allows for the `iframe'
element. Furthermore, HTML 4.01 Strict provides the `object' element as
standards-compliant alternative to `iframe'.
PointedEars

[Luke Matuszewski]

VK napisal(a):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

is a *contradictory invalid* declaration because in the first segment
you declare HTML 4.01, but you propose as the validation scheme file
HTML 4.0 <http://www.w3.org/TR/html4/strict.dtd>

It doesn't have sense from any point of view. If you want HTML 4.01,
then please provide the relevant DTD file:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html401/strict.dtd">

(this file exists and waiting for you)

There is some true in your words i quoted above, but my concern is
not valid DTD syntax but valid behaviour of user agents which is stated
on following sites:
<URL:http://gutfeldt.ch/matthias/articles/doctypeswitch/table.html>
<URL:http://hsivonen.iki.fi/doctype/>
<URL:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp>
, and they ***all*** have followin DTD:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

, or

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

(both switch revelant UAs into almost or standads mode)

BR
Luke Matuszewski

[Luke Matuszewski]

VK napisal(a):

The fact that this contradiction was not noticed for so many years (and
the relevant <http://www.w3.org/TR/html401/> folder stayed without use)
is just another proof of how "serious" all this DTD story is.

See: <URL:http://www.w3.org/TR/html401/struct/global.html#h-7.2> of
HTML 4.01 specifiction also... you there have followin examples:
<quote>
HTML 4.01 specifies three DTDs, so authors must include one of the
following document type declarations in their documents. The DTDs vary
in the elements they support.

* The HTML 4.01 Strict DTD includes all elements and attributes
that have not been deprecated or do not appear in frameset documents.
For documents that use this DTD, use this document type declaration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

* The HTML 4.01 Transitional DTD includes everything in the strict
DTD plus deprecated elements and attributes (most of which concern
visual presentation). For documents that use this DTD, use this
document type declaration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

* The HTML 4.01 Frameset DTD includes everything in the
transitional DTD plus frames as well. For documents that use this DTD,
use this document type declaration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
</quote>

Interesting fact is that when reading more of it you have links to
revelant files:
<quote>
The URI in each document type declaration allows user agents to
download the DTD and any entity sets that are needed. The following
(relative) URIs refer to DTDs and entity sets for HTML 4:

* "strict.dtd" -- default strict DTD (points to:
http://www.w3.org/TR/html401/strict.dtd)
* "loose.dtd" -- loose DTD (points to:
http://www.w3.org/TR/html401/loose.dtd)
....
</quote>

BR
Luke Matuszewski

[Richard Cornford]

Luke Matuszewski wrote:

Matt Kruse wrote:

Luke Matuszewski wrote:

> Also remember that i can't use function expressions like
> function(...) { }
Oh, and what does that even mean?

Function expressions is expressions that returns function reference
(EcmaScript 3rd ed.- 13) like:

...
System.someFunc = function() {
/* CODE */
}
...

Function expressions where not present in EcmaScript 2nd
and 1st ed.(only function declarations where present).

I practice this is not an issue as anonymous function expressions were
implemented as an extension of ECMAScript in JavaScript 1.2 and JScript
3 (so Netscape 4 and IE 4 respectively). You won't find many older
environments still in use, and with assigning the result of an anonymous
function expression to a property of a function's prototype being the
most common method of specifying a custom object any browser not
implementing anonymous function expressions is not going to be of much
use executing Internet browser scripts.

<snip> var System.someFunc = function(...) { /* syntax allowed
since JavaScript 1.5(!) and JScript ?(do not remeber) */
}
Your version numbers are wrong. JavaScript 1.2 and JScript 3 would be
closer.
My only apprehension is question: can i null'yfi
the function identifier like:

function System() {
/* code */
}

var system = new System();
System = null; /* THIS */

, so System() constructor will not be visible after
THIS statement.
Assigning null to an Identifier will stop that Identifier from referring
to a function, and so being effectively used in a CallExpression.
However, given you want the function to only be callable once it would
be clearer to assign null to the function's Identifier from within the
function (as the last line). I.E.:-

function System() {
/* code */
System = null;
}

var system = new System();

(also see that if i can, there is only one object system,
so no memory leaks will happen in IE revelant to many
execution contexts...).

<snip>

IE's memory leak problem is caused by circular references that include
ActiveX/COM objects (which include IE's DOM nodes) not by closures.
Misidentifying the cause of the memory leaks will leave you avoiding
closures for no good reason and not seeing other circular reference
scenarios and so still having memory leaks.

It doesn't happen often but here I agree with Matt, your reasons for
excluding the function expression are not sound and there use seems
better suited to achieving your apparent goal.

Richard.

[Matt Kruse]

Thomas 'PointedEars' Lahn wrote:

Obviously you do not. Other people do because they care for
_interoperable_ markup, that is, markup that has the potential to
work everywhere and anytime (for the foreseeable future), not markup
that works only in a few versions of a few user agents.
Then you wouldn't use transitional, as the old deprecated markup may not be
supported in the future (unlikely, but possible).

Furthermore, I take your comments as almost humorous, considering the
example you set with your own site.

At least the browser is in standards mode.

Nonsense. Standards Compliance Mode does not require a Strict DTD.

However, to make sure your page isn't using any old markup it's good to have
a strict dtd and validate.
HTML
4.01 Transitional also triggers this mode and allows for the `iframe'
element. Furthermore, HTML 4.01 Strict provides the `object' element
as standards-compliant alternative to `iframe'.

I suppose a fine alternative would be to design in strict mode and validate
everything except the iframe tag. Then if the page has an iframe object,
change it to transitional.

Since the specific example given (my site) puts the doctype in using a
global include file, changing it for just a few pages that have iframes
makes no sense. Just because a document doesn't validate because of 1 tag
doesn't mean a browser isn't going to work correctly. In theory, everything
should validate. In practice, that's not always possible. And perfect
validation doesn't actually offer an value (unless you're working with xhtml
or something) except for the theoretical future case where a browser won't
display anything that doesn't validate - and that will never happen.

Validation is a tool. It is not a goal.

PS: The iframe pages like http://www.javascripttoolbox.com/lib/dragiframe/
show up as validating just fine in Firefox using the Html Validation 0.7.7
extension, which is what I use to validate my pages. I never even noticed
that iframes are not in the strict dtd, as I almost never use them. Checking
the same page using the W3C validator shows some discrepencies in the
results. I'll have to look into that, as I assumed the validator extension
would provide the same results as the W3C validator.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Thomas 'PointedEars' Lahn]

Matt Kruse wrote:

Thomas 'PointedEars' Lahn wrote:

Obviously you do not. Other people do because they care for
_interoperable_ markup, that is, markup that has the potential to
work everywhere and anytime (for the foreseeable future), not markup
that works only in a few versions of a few user agents.
Then you wouldn't use transitional, as the old deprecated markup may not
be supported in the future (unlikely, but possible).

Transitional document types are not going to be deprecated at all. It is
the features they declare that are deprecated in the overall language
concept which is why they are not included in the Strict DTDs; however, as
long as the Web in its current form (based on SGML-based markup languages)
exists, those document types must be supported.

In contrast, the development of user agents has a tendency to have them
become more standards compliant, not less. Therefore it is likely that a
(future) user agent for the Web in its current form will cease to support
elements that are not supported by the declared DOCTYPE of a markup
document and even error if they are encountered anyway. XHTML 1.0 as a
reformulation of HTML 4 in XML 1.0 is a sign of that; once XHTML becomes
the accepted standard document type on the Web (hopefully pushed with the
release of IE7 to support application/xhtml+xml and including an XML parser
to be triggered by XML document types, too), it will become more and more
important and eventually required for Web documents to be Valid.

Furthermore, and to be on topic again, it has been shown already that
scripts operating from within and on invalid markup are inherently
unreliable, which creates an even greater obligation, especially for
a script developers, to create Valid documents (unless they are not
responsible for the underlying markup; then that burden is shifted to
the people who are responsible for that, or to the people who want
their content to be reused).
Furthermore, I take your comments as almost humorous, considering the
example you set with your own site.
When running out of arguments, people tend to such ad hominem attacks.
AFAIK, my Web site (<URL:http://pointedears.de/>) consists of Valid markup
except of the index documents created automatically by the Web server and
the frameset documents (where I have to accomodate user agents that do not
adhere to the standards until I have a better solution).

In case you have any explicit hint as to whether something that looks
_finished_ is not Valid and/or does not work as it should (and a suggestion
to fix that), I am more than happy to read it _where that is appropriate_
and will make any attempt to make it better as soon as I can. Otherwise I
strongly suggest you stop such childish subtle attempts at discrediting
others; it is like you throwing stones in glass houses and will not do
anyone anything good.

At least the browser is in standards mode.

Nonsense. Standards Compliance Mode does not require a Strict DTD.

However, to make sure your page isn't using any old markup it's good to
have a strict dtd and validate.

True, but that is a different thing. Standards compliance is provided with
any recognized DTD and markup adhering to it; Standards Compliance Mode of
browsers does not require a Strict DTD to be triggered. You are wrong and
you do not admit it.

HTML 4.01 Transitional also triggers this mode and allows for the
`iframe' element. Furthermore, HTML 4.01 Strict provides the `object'
element as standards-compliant alternative to `iframe'.

I suppose a fine alternative would be to design in strict mode and
validate everything except the iframe tag. Then if the page has an
iframe object, change it to transitional.

ACK, and I would extend that to any deprecated language feature.
[...]
Validation is a tool. It is not a goal.
Valid documents are an important milestone towards interoperable content.
PS: The iframe pages like http://www.javascripttoolbox.com/lib/dragiframe/
show up as validating just fine in Firefox using the Html Validation 0.7.7
extension, which is what I use to validate my pages.
Obviously this extension is flawed. Try the Web Developer extension which
can use several online validators, or try HTML Tidy which recognizes at
least the DOCTYPE mismatch.
I never even noticed that iframes are not in the strict dtd, as I almost
never use them. Checking the same page using the W3C validator shows some
discrepencies in the results. I'll have to look into that, as I assumed
the validator extension would provide the same results as the W3C
validator.

Start with examining

<URL:http://www.w3.org/TR/html4/loose.dtd>
<URL:http://www.w3.org/TR/html4/strict.dtd>

and searching for "ELEMENT IFRAME" in each resource.
HTH

PointedEars

[Matt Kruse]

Thomas 'PointedEars' Lahn wrote:

PS: The iframe pages like
http://www.javascripttoolbox.com/lib/dragiframe/ show up as
validating just fine in Firefox using the Html Validation 0.7.7
extension, which is what I use to validate my pages.

Obviously this extension is flawed. Try the Web Developer extension
which can use several online validators, or try HTML Tidy which
recognizes at least the DOCTYPE mismatch.

The Html Validator extension is based off tidy.
*shrug*

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[VK]

Matt Kruse wrote:

The Html Validator extension is based off tidy.
*shrug*

You just need to look at the *date* of strict.dtd: 1999
This holy crap did not change for *6 years*

I will not paint the whole historical background of the year 1999
(doubt very much you need my help anyway), just few notes:

In the year 1999 the only browser supporting <iframe> is Internet
Explorer, so it is not an option for W3C to unclude it into standard.
All hopes are related with the <object>.

Year 2006: all more-or-less serious browsers support <iframe>.
<object> idea failed because it appeared to be an endless source of
security exploits.

Side note: some people suggested to use <object> instead of <iframe> to
display pages. Gentlemen, did you actually try it?

The only reasonnable action W3C could make right now is to add <iframe>
into the Strict schema. But they will never do it because it goes
against the fake image W3C builds up: "W3C cannot be wrong". Therefore
they never edit their mistakes, they just silently allow to disregard
them.

I'm sorry if I sound pathetic but DTD at the top of your page is a
*commitment*. It means that you act upon the declared standards even if
it's not convenient or even if forces you to change the whole solution.
If you don't want to go for such troubles then simply do not sign the
commitment.
I never use Strict or even Loose because the rent is too high and
overall it's not my bank :-)
IMHO standard-wise it is more correct and fair rather then declare some
standard schema and break it right away. IMHO

Firefox validator is *forcely* adjusted to the real world, because
Mozilla Foundation doesn't have the W3C's opportunity to spit on the
reality and live in an abstract Ivory Tower. I bet 100:1 for another
difference between W3C validator and Mozilla validator:

<textarea wrap="physical">Test</textarea>
<textarea wrap="hard">Test</textarea>

Try both samples (inside a page of course) in both validator.

[Matt Kruse]

VK wrote:

I'm sorry if I sound pathetic but DTD at the top of your page is a
*commitment*. It means that you act upon the declared standards even
if it's not convenient or even if forces you to change the whole
solution.
Says who? W3C Dogma?
I never use Strict or even Loose because the rent is too high and
overall it's not my bank :-)
Considering IE's box model "problem" (in quotes because its original box
model sizing logic is actually superior to the W3C model, IMO) it makes no
sense to design pages without putting IE into standards mode by using at one
of the standards-mode-triggering DTD's.
IMHO standard-wise it is more correct and fair rather then declare

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[VK]

Matt Kruse wrote:

Considering IE's box model "problem" (in quotes because its original box
model sizing logic is actually superior to the W3C model, IMO) it makes no
sense to design pages without putting IE into standards mode by using at one
of the standards-mode-triggering DTD's.

It is not a wise decision especially if you're making distiributable
libraries. On the real world run most of the time the page will either
don't have DTD declaration at all or it will have URL-less loose
declaration
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
which doesn't switch IE to the W3C mode.

It is much more secure to have two algorithms and check read-only
compatMode property for the needed one:

if (document.compatMode) { // this is IE
if (document.compatMode == 'BackCompat') {
// IE in its own mode
}
else {
// compatMode is set to 'CSS1Compat'
// IE will act upon W3C (or at least it will try :-)
}
}

[VK]

VK wrote:

It is much more secure to have two algorithms and check read-only
compatMode property for the needed one:

if (document.compatMode) { // this is IE
if (document.compatMode == 'BackCompat') {
// IE in its own mode
}
else {
// compatMode is set to 'CSS1Compat'
// IE will act upon W3C (or at least it will try :-)
}
}

And for debugging purposes you can always use Transitional schema with
URL indication which does switch IE to the W3C mode:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html401/loose.dtd">

(note the proper path for dtd file)

[Thomas 'PointedEars' Lahn]

Matt Kruse wrote:

Thomas 'PointedEars' Lahn wrote:

PS: The iframe pages like
http://www.javascripttoolbox.com/lib/dragiframe/ show up as
validating just fine in Firefox using the Html Validation 0.7.7
extension, which is what I use to validate my pages.

Obviously this extension is flawed. Try the Web Developer extension
which can use several online validators, or try HTML Tidy which
recognizes at least the DOCTYPE mismatch.

The Html Validator extension is based off tidy.
*shrug*

So they are using it wrong or the extension is based on a buggy version of
HTML Tidy.

----------------------------------------------------------------------------
$ cat iframe.html
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>HTML Tidy Test File: iframe</title>
</head>

<body>
<iframe src="/">
</iframe>
</body>
</html>

$ tidy -i --indent-attributes yes iframe.html
Info: Doctype given is "-//W3C//DTD HTML 4.01//EN"
Info: Document content looks like HTML 4.01 Transitional
No warnings or errors were found.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

<html>
<head>
<meta name="generator"
content=
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
<meta http-equiv="Content-Type"
content="text/html; charset=us-ascii">

<title>HTML Tidy Test File: iframe</title>
</head>

<body>
<iframe src="/"></iframe>
</body>
</html>

To learn more about HTML Tidy see http://tidy.sourceforge.net
Please send bug reports to ht*******@w3.org
HTML and CSS specifications are available from http://www.w3.org/
Lobby your company to join W3C, see http://www.w3.org/Consortium
----------------------------------------------------------------------------

PointedEars

[VK]

For hell of it I filed bug report with request to update HTML schema to
HTML 4.02 Strict:

<http://www.w3.org/Bugs/Public/show_bug.cgi?id=2812>

At least they cannot say that they did not know.

[Thomas 'PointedEars' Lahn]

VK wrote:

For hell of it I filed bug report with request to update HTML schema to
HTML 4.02 Strict:

<http://www.w3.org/Bugs/Public/show_bug.cgi?id=2812>

At least they cannot say that they did not know.

ROTFLOLBTCASTC. YMMD.
PointedEars

[VK]

Thomas 'PointedEars' Lahn wrote:

ROTFLOLBTCASTC. YMMD.

Sorry?

[VK]

Thomas 'PointedEars' Lahn wrote:

ROTFLOLBTCASTC. YMMD.

Rolling On The Floor Laughing Out Loud
Biting The Carpet
ASTC ?
You Made My Day

I guess... I thought it was ROT13... ASTC is still dark but the main
idea is clear. Still it's not a criptography group here.

And what so funny any way? All bugs have to be reported and asked to be
fixed, it's the normal procedure. The real fun is that for many years
so many *adult* people prefered to silently cheat on validator, like
little children on their parents. That's indeed LOL.

[Thomas 'PointedEars' Lahn]

VK wrote:

Thomas 'PointedEars' Lahn wrote:

ROTFLOLBTCASTC. YMMD.
Rolling On The Floor Laughing Out Loud
Biting The Carpet
ASTC ?

And Scaring The Cat.
You Made My Day

[...] And what so funny any way? [...]

Well, maybe you are not really a fool or a troll but only incapable of
understanding. I will give it a try. So JFYI: You have proposed one
unnecessary and one debatable extension for a future HTML document type.
And you did that in a bugtracking system for the W3C Validator software
instead of discussing it on the W3C HTML mailing list. I only wonder
/when/ this bug will be CLOSED as INVALID, not if.
F'up2 poster

PointedEars

[VK]

Thomas 'PointedEars' Lahn wrote:

Well, maybe you are not really a fool or a troll
Thank you for this discover. I am indeed not.
but only incapable of
understanding. I will give it a try. So JFYI: You have proposed one
unnecessary and one debatable extension for a future HTML document type.
And you did that in a bugtracking system for the W3C Validator software
instead of discussing it on the W3C HTML mailing list.

I am not a W3C contributor. I am one of customers of their products
(and the product of W3C is their documentation and DTD's)
If they had a section "Report a bug about DTD" I would post there right
away. As they did not, I filed the bug to the first section seemed
more-or-less appropriate. Olivier Thereaux forwarded me to the next
instance (appropriate mailing list) where the request is currently
located.

Now I guess (99% chance) this request will be rejected as it should. It
will fill the hearts of spectators with joy ("I told ye!") and they
will just keep secretly cheating on validator as they used to:
*including* Mosilla Foundation developers. And everyone will stay happy
*including* W3C.

[Thomas 'PointedEars' Lahn]

I had set Followup-To poster in order to clarify this privately, but since
you insist on discussing this in public (despite you replying the same via
private e-mail) ...

VK wrote:

Thomas 'PointedEars' Lahn wrote:

Well, maybe you are not really a fool or a troll
Thank you for this discover. I am indeed not.

Well, you are. See below.

but only incapable of understanding.
You missed that.
I will give it a try. So JFYI: You have proposed one
unnecessary and one debatable extension for a future HTML document type.
And you did that in a bugtracking system for the W3C Validator software
instead of discussing it on the W3C HTML mailing list.

I am not a W3C contributor.

No, you are just an incompetent troll wasting everyone's time, using
nonsensical arguments in a eventually futile attempt to show that you
are right after all.
I am one of customers of their products
(and the product of W3C is their documentation and DTD's)
Nonsense. You are no customer of W3C as you are no customer of ECMA, ISO,
IESG, IEEE aso. W3C is more or less an international standardization
organization, and in you are free and welcome to participate in its
decision-making process. Instead you foolishly decided to complain, and
as if that was not bad enough, to complain in a foolish manner, in the
wrong place.
If they had a section "Report a bug about DTD" I would post there right
away.
There can be no bug in the DTD other than a syntax error or a referenced
but undeclared element or entity. So far no such thing exists.
As they did not, I filed the bug to the first section seemed
more-or-less appropriate.
Hello? There is no bug in the W3C Validator regarding this as the
Validator validates against the DTD (which is not necessarily sufficient
to ensure validity of a markup document as the specification imposes
further restrictions, still it is so). Unless you discover false
positives regarding something that is declared in the DTD, there is
no bug the Validator whatsoever.
Olivier Thereaux forwarded me to the next instance (appropriate mailing
list) where the request is currently located.
Where you should have posted in the first place instead of wasting his time!
Now I guess (99% chance) this request will be rejected as it should.
It will fill the hearts of spectators with joy ("I told ye!") and they
will just keep secretly cheating on validator as they used to:
*including* Mosilla Foundation developers. And everyone will stay happy
*including* W3C.

If you only post to waste people's time and bandwidth, just to see your
prejudices confirmed by annoyed reactions provoked by your irresponsible
nonsensical behavior, you are most definitely a troll.
PointedEars

[VK]

Thomas 'PointedEars' Lahn wrote:

you are most definitely a troll
Even Pope or Rome if it makes you sleep better.

Olivier Thereaux forwarded me to the next instance (appropriate mailing
list) where the request is currently located.

Where you should have posted in the first place instead of wasting his time!

Taking into account that not a single dot in DTD has been changed since
1999 I wonder that HTML Group could be so terribly buzy with? Their
entire mailing archive for January of this year consists of
hundred-something messages.
blah-blah-blah...
...blah

Now real stuff:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN"
"http://www.w3.org/TR/html401/strict.dtd">
<html>
<head>
<title>Cheat List v1.0</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<style type="text/css">
body { background-color: #FFFFFF}
</style>

</head>

<body>

<iframe src="foo.html"></iframe>

</body>
</html>

1]
HTML Validator
The errors and warnings are generated by Tidy.
This program is originally developed by the Web Consortium W3C.

0 Errors / 0 Warnings

2]
<http://validator.w3.org>
This page is not Valid -//W3C//DTD HTML 4.01 Strict//EN!

You want to participate in this comedy - you are welcome. Just please
stop forcing others into it. OK?

[Richard Cornford]

VK wrote:

Matt Kruse wrote:

Considering IE's box model "problem" ...

<snip> It is much more secure to have two algorithms and check
read-only compatMode property for the needed one:

if (document.compatMode) { // this is IE
The - document.compatMode - property is implemented in Gecko browsers,
and Opera browsers (and probably others by now).
if (document.compatMode == 'BackCompat') {
// IE in its own mode
- And Gecko browsers when not in standards mode, and Opera 8+ when not
in standards mode.
}
else {
// compatMode is set to 'CSS1Compat'
- Or anything other than "BackCompat", including the 'QuirksMode' value
used in early Opera 7 browsers.
// IE will act upon W3C (or at least it will try :-)

- And Gecko browsers when in standards mode, and Opera 7+ when in
standards mode plus Opera 7 browsers in Quirks mode.
}
}

- And all browsers not implementing - document.compatMode - end up here.
Including IE 5 and 5.5, which are, after all, the browsers with which
'BackCompat' mode is compatible, and so logically can be handled with
the same code that handles IE 6 in that mode.

Yet another example of choosing to do something in the worst possible
way available.

Richard.

[VK]

Richard Cornford wrote:

VK wrote:

Matt Kruse wrote:

Considering IE's box model "problem" ...

<snip>

It is much more secure to have two algorithms and check
read-only compatMode property for the needed one:

if (document.compatMode) { // this is IE

The - document.compatMode - property is implemented in Gecko browsers,
and Opera browsers (and probably others by now).

if (document.compatMode == 'BackCompat') {
// IE in its own mode

- And Gecko browsers when not in standards mode, and Opera 8+ when not
in standards mode.

Could you elaborate on "Gecko standard" vs. "Gecko quirk" mode? :-)

Well, the "I'm IE" mimicrie becomes a real epidemie as I can tell. I'm
fine (technically and humanly) with forged userAgent strings:- overall
everyone wants to survive.
But forged properties and methods is something I would cut sensitive
parts of body off for. Either *implement* it or leave it undefined,
don't place a *placeholder*. Are they nuts?!

So the sample should be adjusted to:

if ((window)&&(window.ActiveXObject)&&(document.compa tMode))

It also suggested then to re-check all your features checks (not only
this one) on a monthly basis. - In case if Opera (was specially bad on
it so far) or Gecko add window.ActiveXObject property with value
"true".

[Thomas 'PointedEars' Lahn]

VK wrote:

Richard Cornford wrote:

VK wrote:

> Matt Kruse wrote:
>> Considering IE's box model "problem" ...
> It is much more secure to have two algorithms and check
> read-only compatMode property for the needed one:
>
> if (document.compatMode) { // this is IE
The - document.compatMode - property is implemented in Gecko browsers,
and Opera browsers (and probably others by now).

> if (document.compatMode == 'BackCompat') {
> // IE in its own mode

- And Gecko browsers when not in standards mode, and Opera 8+ when not
in standards mode.

Could you elaborate on "Gecko standard" vs. "Gecko quirk" mode? :-)

Visit the well-known <URL:http://www.quirksmode.org/>. (Google, which
you are posting with, would have helped.)
Well, the "I'm IE" mimicrie becomes a real epidemie as I can tell. I'm
fine (technically and humanly) with forged userAgent strings:- overall
everyone wants to survive.
But forged properties and methods is something I would cut sensitive
parts of body off for. Either *implement* it or leave it undefined,
don't place a *placeholder*. Are they nuts?!
What you are babbling about has no relevance to Richard's argument.
So the sample should be adjusted to:

if ((window)&&(window.ActiveXObject)&&(document.compa tMode))
This will be true in Gecko-based browsers with the ActiveX Plugin installed,
and the parantheses are unnecessary.
It also suggested then to re-check all your features checks (not only
this one) on a monthly basis. - In case if Opera (was specially bad on
it so far) or Gecko add window.ActiveXObject property with value
"true".

The Gecko DOM does not implement window.ActiveXObject, that is an extension
by the ActiveX Plugin, which is installed in Netscape for Windows by
default, to facilitate scripting of the Windows Media Player Plugin.
PointedEars

[VK]

Thomas 'PointedEars' Lahn wrote:

Visit the well-known <URL:http://www.quirksmode.org/>. (Google, which
you are posting with, would have helped.)
I know this site, thank you though.

I repeat my question:

what does
compatMode == "BackCompat"
and
compatMode == "CSS1Compat"

means in application to Gecko? Can I switch Firefox in "IE-compatible"
mode? Or it's just an attempt to mimic IE even if it can break
someone's old code?

I stay on the second one.
What you are babbling about has no relevance to Richard's argument.
In direct relevance as you can see now.
The Gecko DOM does not implement window.ActiveXObject, that is an extension
by the ActiveX Plugin, which is installed in Netscape for Windows by
default, to facilitate scripting of the Windows Media Player Plugin.

So we have either close this newsgroup as futile: because there is no
way to detect the presence and *workability* of some feature.

As it seems like not an option :-) then we have to find more or less
reliable way to check the platform and feature with possible small
percent of browsers we have to screw on.

[Richard Cornford]

VK wrote:

Thomas 'PointedEars' Lahn wrote: <snip>

The Gecko DOM does not implement window.ActiveXObject, that
is an extension by the ActiveX Plugin, which is installed
in Netscape for Windows by default, to facilitate scripting
of the Windows Media Player Plugin.

So we have either close this newsgroup as futile: because
there is no way to detect the presence and *workability*
of some feature.

The majority of the regular contributors to this group have been coping
with the way web browser object models are for half a decade or more.
You might throw up your hands in horror at discovering that there is
more to the practice than you can conceive of but that is not a surprise
to anyone else.
As it seems like not an option :-) then we have to find
more or less reliable way to check the platform and feature
with possible small percent of browsers we have to screw on.

Try to remember that your mental process has you choosing the worst
possible approach to any issue, and you are doing it again here. Don't
speak of "we" when you are describing your personal shortcomings.

Richard.

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

VK wrote:

> Matt Kruse wrote:
>> Considering IE's box model "problem" ... <snip>

> It is much more secure to have two algorithms and check
> read-only compatMode property for the needed one:
>
> if (document.compatMode) { // this is IE

The - document.compatMode - property is implemented in
Gecko browsers, and Opera browsers (and probably others
by now).

> if (document.compatMode == 'BackCompat') {
> // IE in its own mode

- And Gecko browsers when not in standards mode, and
Opera 8+ when not in standards mode.

Could you elaborate on "Gecko standard" vs. "Gecko quirk"
mode? :-)

What is up, cannot do your own research into a subject you are so keen
to give the impression you already understand?
Well, the "I'm IE" mimicrie becomes a real epidemie as I
can tell.
As Microsoft started this by imitating Netscape's browser nobody has
reasonable grounds for complaining when others imitate IE.
I'm fine (technically and humanly) with forged userAgent
strings:- overall everyone wants to survive.
But forged properties and methods is something I would cut
sensitive parts of body off for.
Who said they were forged? Opera and Gecko browsers operate in multiple
modes and use the - document.compatMode - property to announce which
mode they are in, just like IE 6 does. It is a non-standardised property
so there is no reason to be surprised when implementations differ in the
name they assign to their non-standard mode.
Either *implement* it or leave it undefined,
don't place a *placeholder*. Are they nuts?!
People have been coping with the nature of the - document.compatMode -
property for nearly half a decade now and successfully creating
cross-browser code along the way. If doing likewise exceeds your
capabilities that is not an issue for the browser manufacturers.
So the sample should be adjusted to:

if ((window)&&(window.ActiveXObject)&&(document.compa tMode))
That will give you a different set of chaotic outcomes. The trick with
feature detection is to understand what it is you need to know and why
you want to know it. The required test can then be deduced from an
analysis of that information. Though as you have no understanding of
logic and no talent for analysis that simple process will remain beyond
your abilities for the foreseeable future.
It also suggested then to re-check all your features checks
(not only this one) on a monthly basis. - In case if Opera
(was specially bad on it so far) or Gecko add
window.ActiveXObject property with value "true".

Don't be silly, your proposed 'feature test' made the mistake of
assuming that - window.ActiveXObject - was related to question that
needed answering. It probably has no relationship to that question so
your maintenance problem directly follows from the flawed logic in your
test and is not an inherent issue in browser scripting.

Bear in mind that there are already at least two desktop scriptable
dynamic visual web browsers that implement a global ActiveXObject
constructor and are not Windows IE 5+.

Richard.

[Thomas 'PointedEars' Lahn]

VK wrote:

Thomas 'PointedEars' Lahn wrote:

Visit the well-known <URL:http://www.quirksmode.org/>. (Google, which
you are posting with, would have helped.)
I know this site, thank you though.

I repeat my question:

what does
compatMode == "BackCompat"
and
compatMode == "CSS1Compat"

means in application to Gecko?

If the Gecko-based UA renders the document in Standards Compliance Mode, the
value of the `compatMode' property is "CSS1Compat". Otherwise, if it is
rendered in Quirks Mode, the value is "BackCompat".
Can I switch Firefox in "IE-compatible" mode?
Whatever that might be, no. DOCTYPE switching is triggered by the DOCTYPE
declaration or by omitting it.
Or it's just an attempt to mimic IE even if it can break someone's old
code?
Neither one. This property works the same in IE, only that Quirks Mode is
called Compatibility Mode there.
I stay on the second one.

Figures.

What you are babbling about has no relevance to Richard's argument.

In direct relevance as you can see now.

Richard argued that document.compatMode cannot be used to detect IE.
Your rant had no relevance to that. Again.

The Gecko DOM does not implement window.ActiveXObject, that is an
extension by the ActiveX Plugin, which is installed in Netscape for
Windows by default, to facilitate scripting of the Windows Media Player
Plugin.

So we have either close this newsgroup as futile: because there is
no way to detect the presence and *workability* of some feature.

Nonsense, there is.
PointedEars

[VK]

Thomas 'PointedEars' Lahn wrote:

If the Gecko-based UA renders the document in Standards Compliance Mode, the
value of the `compatMode' property is "CSS1Compat". Otherwise, if it is
rendered in Quirks Mode, the value is "BackCompat".
If IE says "BackCompat" it means that it uses Internet Explorer Box
Model which has a significant difference from W3C Box Model. It also
renders style declarations and some attributes differently (in IE's
way). The full list of differences one can find at
<http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp>

If it says "CSS1Compat" than it goes by W3C specs (at the best of its
abilities).

That was the main and only purpose to introduce this property, so
developers could make a runtime check.

If some browser later decides to introduce this property (with the same
values!) than I expect that it will indicate to the same differences as
spelled at
<http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp>

If not (and it is not) then it's a nasty useless crap that breaks my
pre-existing code.

Firefox declares "CSS1Compat" for any DTD as long as it's presented. So
the only use I see of it (Thomas' special :-) is:

if ('BackCompat' == document.compatMode) {
var url = 'http://validator.w3.org/check?uri=';
url+= escapeURIComponent(window.location.href);
alert('DTD is missing!');
window.location.href = url;
}

Don't see any serious usage for it neither for Gecko nor for Opera. Am
I so blind? Possibly.
This property works the same in IE, only that Quirks Mode is
called Compatibility Mode there.
Again, the full detailed explanation of how it works in IE explained
here:
<http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp>
I doubt very much that it works the same way anywhere else.
Richard argued that document.compatMode cannot be used to detect IE.
Your rant had no relevance to that. Again.

So let us think what would be the way to detect that it's IE and it's
in CompatMode, so we could for example calculate offsets properly. I
practically need it and now I'm really running out of fantasy what's
not covered yet by the mimicrie?

P.S. This thread is going to be the Queen of Off-Topics I'm affraid.

[Thomas 'PointedEars' Lahn]

VK wrote:

Thomas 'PointedEars' Lahn wrote:

If the Gecko-based UA renders the document in Standards Compliance Mode,
the
value of the `compatMode' property is "CSS1Compat". Otherwise, if it is
rendered in Quirks Mode, the value is "BackCompat".
If IE says "BackCompat" it means that it uses Internet Explorer Box
Model which has a significant difference from W3C Box Model.

OK, I know of no equivalent for that in Gecko-based UAs.
It also renders style declarations and some attributes differently [...]
That is the same in Quirks Mode in Gecko-based UAs. The reason is that in
both UAs another base stylesheet is used.
[...]
That was the main and only purpose to introduce this property, so
developers could make a runtime check.

If some browser later decides to introduce this property (with the same
values!) than I expect that it will indicate to the same differences as
spelled at
<http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp>
The result of these "CSS enhancements" are invalid and/or not interoperable
stylesheet which is what forces Web developers to hide parts of their CSS
from broken IE and still have them working as supposed in compliant user
agents.
If not (and it is not) then it's a nasty useless crap that breaks my
pre-existing code.
To put in bluntly, the problem here is that your code is crap, as in the
following:
Firefox declares "CSS1Compat" for any DTD as long as it's presented. So
the only use I see of it (Thomas' special :-) is:

if ('BackCompat' == document.compatMode) {
var url = 'http://validator.w3.org/check?uri=';
url+= escapeURIComponent(window.location.href);
alert('DTD is missing!');
window.location.href = url;
}
[...]

Richard argued that document.compatMode cannot be used to detect IE.
Your rant had no relevance to that. Again.

So let us think what would be the way to detect that it's IE [...]

There is exactly no need to detect that it is IE. The major flaw in your
logic is that you actually believe there is.
PointedEars

[Richard Cornford]

VK wrote:
<snip>

If not (and it is not) then it's a nasty useless crap that
breaks my pre-existing code.
You write code that is chaotic, brittle and maintenance-heavy and then
test it sufficiently ineffectively that you can maintain the illusion
that you know what you are doing. The results are going to fall apart at
the slightest provocation, that is inevitable. But Gecko browsers have
had the - document.compatMode - property from Mozilla 1.0, and Opera
since the release of version 7, so its existence should hardly come as a
surprise after all these years.

<snip>

Richard argued that document.compatMode cannot be used to
detect IE. Your rant had no relevance to that. Again.

So let us think what would be the way to detect that it's IE
and it's in CompatMode,

You should never need to do that. You should be identifying the question
that really needs to be answered, as the appropriate test will follow
from that.
so we could for example calculate offsets properly.
So the real question relates to the significance of the properties used
in calculating offsets.
I practically need it and now I'm really running out of
fantasy what's not covered yet by the mimicrie?
Well you could always ask a question on the group and see if any of the
people you have relentlessly disregarded and wasted the time of are now
willing to lift a finger to help you. (For all you may regard everyone
here as uninformed amateurs dabbling in browser scripting it is obvious
that most have worked out successful strategies for working with
offsets).
P.S. This thread is going to be the Queen of Off-Topics I'm
affraid.

The subject header of a thread is unrelated to what way or may not be
off topic for the group. We are still discussing scripting web browsers
with javascript, which is on topic.

Richard.

[VK]

Richard Cornford wrote:

You should never need to do that. You should be identifying the question
that really needs to be answered, as the appropriate test will follow
from that.

I need to have an expression evaluated to true

if (IE, IE only and nothing but IE) && (IE in CompatMode)

in order to implement the proper offset calculations. Any other
browsers do not change offset rules depending on mode so out of my
interest. Your suggestions?

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

You should never need to do that. You should be identifying the
question that really needs to be answered, as the appropriate test
will follow from that.

I need to have an expression evaluated to true

if (IE, IE only and nothing but IE) && (IE in CompatMode)

in order to implement the proper offset calculations. Any other
browsers do not change offset rules depending on mode so out of my
interest. Your suggestions?

Stop thinking in terms of browsers and identify the question you really
need to have answered. You want to know something about the meaning of
offset values so that is what the question you need answering relates
to.

Richard.

[VK]

Richard Cornford wrote:

Stop thinking in terms of browsers and identify the question you really
need to have answered. You want to know something about the meaning of
offset values so that is what the question you need answering relates
to.

Strange question. Nevertheless:

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp>

<quote>
Compliant Behavior

With Internet Explorer 6 or later, when you use the !DOCTYPE
declaration to switch on standards-compliant mode, the width and height
properties specify the distance between the left and right edges and
top and bottom edges of the bounding box, respectively. The border and
padding belts are not included.
Noncompliant Behavior

When the !DOCTYPE declaration does not switch on standards-compliant
mode, as with earlier versions of Internet Explorer, the width property
includes the object's content box, plus the values of the following
properties: border-left, border-right, padding-left, and padding-right.
Subtracting the sum of the values of these properties from the value of
the width property equals the width of the parent object's content box.
Likewise, subtracting the sum of the values of the border-top,
border-bottom, padding-top, and padding-bottom properties from the
value of the height property equals the height of the parent object's
content box.
</quote>

There is only one browser implementing IE's Box Model in quirk mode,
and overall only one known browser implementing a different box model
in quirk mode: this is IE.

So the minimum reqirement is:

Detect that this is IE
and
Detect that it's in quirk mode

Your solution?