From: Garrett Smith on
Asen Bozhilov wrote:
> Garrett Smith wrote:
>> RegularExpressions
>> Be simple, but do not match the wrong thing.
> I ever wondering about using RegExp for type checking.
> /^\s*\bfunction\b/.test("" + f);
RegExp.test converts the argument to a string, so could be written as:-


Type checking clutters the code up.

Type checking properties of Host object has been known to cause errors.
Safari 2 blows up when accessing a property off a NodeList.

The typeof operator can hide errors in IE, though, as discussed recently.
javascript: alert(typeof document.styleSheets[-1] );

typeof hides error.

There should be a list of things that blow up in IE.

> That will be check implementation depended string returned from
> f.toString(); for as function, and that checking can be falsish.

f.toString() would resolve a toString property on the function before
calling it.

A function's toString property could be an own property. Otherwise, it
would be found in Function.prototype. The implementation-dependent
representation is required to be a FunctionDeclaration. In practice,
most implementations violate that as:-


The results is a string that is not a FunctionDeclaration (looks like a
FunctionDeclaration). The specification should change and I have
proposed this change to the ECMAScript committee. My proposal was to
change where it says "FunctionDeclaration" to "Function Definition".
This would legalize existing implementations' returning a string
representing a FunctionExpression.

| Function.prototype.toString ( )
| An implementation-dependent representation of the
| function is returned. This representation has the
| syntax of a Function Definition. Note in particular
| that the use and placement of white space, line
| terminators, and semicolons within the representation
| string is implementation-dependent.

> e.g.
> var o = {
> toString : function()
> {
> return 'function function';
> }
> };
> window.alert(/^\s*\bfunction\b/.test("" + o)); //true

That is a different situation. Here we have an object that is not a
function, but has a toString that could result in a false positive.

new Object("Conjunction Junction, what's your function?");
comp.lang.javascript FAQ:
From: Asen Bozhilov on
Garrett Smith wrote:
> Asen Bozhilov wrote:
> > Garrett Smith wrote:

> > /^\s*\bfunction\b/.test("" + f);
> RegExp.test converts the argument to a string, so could be written as:-
> /^\s*\bfunction\b/.test(f);

Yes, but do you can to explain next lines in IE:

var xhr = new ActiveXObject('Microsoft.XMLHTTP');
try {
}catch(e) {
window.alert(e instanceof TypeError); //true
window.alert(('foo' + xhr).length); //3
window.alert(typeof ('foo' + xhr)); //string
window.alert(typeof (xhr + 'foo')); //undefined

| String
| Returns a string value (not a String object)
| computed by ToString(value).

ToString for Object call ToPrimitive with hint `string`. ToPrimitve
call internal [[DefaultValue]] method of that Object. [[DefaultValue]]
throw TypeError if Object properties `toString' and `valueOf' is not a

| 11.6.1 The Addition operator ( + )
| The production AdditiveExpression :
| AdditiveExpression + MultiplicativeExpression
| is evaluated as follows:
| 1. Evaluate AdditiveExpression.
| 2. Call GetValue(Result(1)).
| 3. Evaluate MultiplicativeExpression.
| 4. Call GetValue(Result(3)).
| 5. Call ToPrimitive(Result(2)).
| 6. Call ToPrimitive(Result(4)).

Lets modified my example to use native object instead of host object:

var o = {toString : null, valueOf : null};
try {
}catch(e) {
window.alert(e instanceof TypeError); //true
window.alert(('foo' + o).length); //3
window.alert(typeof ('foo' + o)); //string
window.alert(typeof (10 + o)); //number
window.alert(typeof (o + 'foo')); //object
window.alert(typeof (o + 10)); //object

window.alert(typeof (o + 'foo')); //object

Here i expected 'string' from 11.6.1 step 7.
| If Type(Result(5)) is String or Type(Result(6)) is String,
| go to step 12. (Note that this step differs from step 3 in
| the comparison algorithm for the relational operators,
| by using or instead of and.)

From what that i can see JScript use much complex algorithm in `The
Addition operator ( + )` and definitely they don't follow
documentation steps in `11.6.1 The Addition operator ( + )`. Can
anybody explain used algorithm of JScript?

From: Thomas 'PointedEars' Lahn on
Garrett Smith wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>>> Changed to:
>>> * Use of == where strict equality is required
>>> Where strict equality is required, the strict equality operator must be
>>> used.
>> That goes without saying.
> It is a true statement, but not obvious to all.

A spoon must be used where a spoon is required. How stupid does one have to
be not to recognize the inherent veracity of such statements?

Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)> (2004)
From: Thomas 'PointedEars' Lahn on
David Mark wrote:

> On Dec 22, 10:38 pm, RobG <rg...(a)> wrote:
>> On Dec 22, 9:52 am, Garrett Smith <dhtmlkitc...(a)> wrote:
>> > * Not escaping ETAGO.

For better understanding, the exact term "ETAGO delimiter" should be used.

>> > Replace: "</" + "script>"
>> > with: "<\/script>";
>> > Replace: "</td>";
>> > with: "<\/td>";
>> I don't understand the issue here, is it specifically with the TD end
>> tag? Or is it more generally with end tags in HTML sent as an XHR
>> response?
> No, it refers to markup in script (e.g. document.write calls).


> Nothing to do with the tag type.

The *what*? I thought this was comp.lang.javascript, not

Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)>
From: Thomas 'PointedEars' Lahn on
Garrett Smith wrote:

> RobG wrote:
>> I don't understand the issue here, is it specifically with the TD end
>> tag? Or is it more generally with end tags in HTML sent as an XHR
>> response?
> * Not escaping ETAGO, or using concatenation to escape ETAGO.
> Inline script must not contain the character sequence "</"

There really is no reason here to go at lengths citing hopelessly outdated


> When concatenating strings of HTML in an inline script, a backslash
> should appear before the solidus symbol in the sequence "</", resulting
> in "<\/", and not - "<" + "/" -.

Do not confuse the solidus character (U+2044) with that of the US-ASCII-
compatible forward slash (U+002F), though.

>> A suitable alternative may be to omit the closing TD tag altogether
>> (valid in HTML 4.01 and draft HTML 5).

Wrong. It is Valid in HTML 4.01 Transitional only. As for the "HTML 5"
reference: When will you ever learn? And it certainly would not apply to
the "XHTML variant" of "HTML 5", whatever that is supposed to become some

>>> CSS:
>>> * invalid css
>>> * classNames that do not have semantic meaning
>> While that comment is OK for class values used for CSS, it should be
>> noted that class names are not intended for CSS only.
> True. Non-semantic class or ID lacks meaning (HTML and CSS). The same
> applies to ID.
> Instead, class and id should be meaningful, so the code is easier to
> understand.


> Bad:
> .errorButton, #warningMessage
> Good:


var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16