Singleton desing patter approach without function expressions...

[Matt Kruse]

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.

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.

 

[Richard Cornford]

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.

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.

 

[Thomas 'PointedEars' Lahn]

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.

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.

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]

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*

 

[VK]

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]

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.

 

[VK]

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]

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]

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 (e-mail address removed)
HTML and CSS specifications are available from http://www.w3.org/
Lobby your company to join W3C, see http://www.w3.org/Consortium

 

[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]

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]

ROTFLOLBTCASTC. YMMD.

Sorry?

 

[VK]

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]

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]

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) ...

Thank you for this discover. I am indeed not.

Well, you are. See below.

You missed that.

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]

you are most definitely a troll

Even Pope or Rome if it makes you sleep better.

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]

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.

 

[Thomas 'PointedEars' Lahn]

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?!

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

So the sample should be adjusted to:

if ((window)&&(window.ActiveXObject)&&(document.compatMode))

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

 

[Richard Cornford]

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.compatMode))

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.