From: David Mark on
On Dec 25, 6:19 pm, Thomas 'PointedEars' Lahn <PointedE...(a)>
> 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
> alt.scriptkiddie.misc.

The type of tag serialized in the string (e.g. TD vs. SCRIPT). Are
you proposing to refer to these as *elements*? I think not as we are
talking about just one (ending) tag (not both).
From: Dr J R Stockton on
In comp.lang.javascript message <7895e8b5-1f6f-4a3c-9e09-11d5379a3973(a)n1>, Thu, 24 Dec 2009 16:08:38, David Mark
<dmark.cinsoft(a)> posted:
>On Dec 23, 3:33�pm, Dr J R Stockton <reply0...(a)>
>> In comp.lang.javascript message <hgp1oo$ve...(a)news.eternal-
>>>, Mon, 21 Dec 2009 15:52:55, Garrett Smith
>> <dhtmlkitc...(a)> posted:

>> > * inconsistent return types
>> >Methods should return one type; returning null instead of an Object
>> >may be a fair consideration.
>> Where successful operation of a routine cannot return anything
>> resembling false, ISTM reasonable and useful to return something
>> resembling false if the routine has failed to do what was wanted.
>That's an over-generalization. Functions that return nothing result
>in the undefined value. That shouldn't mean they failed. It really
>depends on the function, but there is no general reason to return a
>"truthy" value.

"A implies B" does not imply "not A implies not B", although the
converse seems to be taught in American schools.

If the "main results" of a function are obtained other than through the
returned value of the function, then one can still return false if it
fails, but one should then return true if it succeeds.

But clearly I had in mind a function which returns its main results.

>> >Strategies:
>> > * Modifying built-in or Host object in ways that are either error
>> >prone or confusing (LOD).
>> Include : using without explanation jargon or any other than well-known
>> acronyms & abbreviations
>typeof x == 'unknown'; // ActiveX (is that okay?)
>(x); // Boom

A pointless remark.

>> >Strings:
>> > * use of concatenation to repeatedly (repeatedly create and
>> >discard temporary strings)
>> >Instead use String.prototype.concat(a, b, c) or htmlBuf.push(a, b, c);
>> Remember that the chief use of JavaScript by the untended FAQ readership
>> is to produce smallish pieces of code without much looping, running in a
>> Web browser as a result of a user action.
>" a result of a user action" is the operative phrase. Such
>results _need_ to be as fast as possible. If you've ever typed into
>an "autocomplete" widget, you know what I'm talking about.

Utter nonsense. If the calculation and display take less than about 100
ms from user initiation, there is no benefit in speeding them up.

FF 3.0.15, XPsp3, P43GHz,
<URL:> :
100,000 sequential concatenations of a 9-character string, by Turtle,
takes under 0.06 seconds. That, for a member of the intended FAQ
readership, is rarely of any importance.

>> There is no point at all in
>> telling a general FAQ reader that the less machine-efficient methods are
>> wrong, if they work perfectly well and the code will complete within 100
>> ms.
>Huh? Repetitive string concatenation is a performance killer
>(particularly in IE).

Perhaps you should test that assertion. Possibly you are an aged
person, raised on JavaScript in early browsers running on 486/33 CPUs or
similar, when code ran a hundred or more times slower than it does
today. Nevertheless, the real point which you show no signs of having
grasped is that, for most of the work of those who the FAQ is intended
to help the difference between the various methods will be at most a few
milliseconds, which DOES NOT MATTER.

If a string is short enough to be displayed of an ordinary Web page of
reasonable size, then any method of joining its natural parts will be
fast enough.

>> Writing the fastest code in a nice intellectual exercise for consenting
>> participants, but it should not be imposed overall.
>I don't see what that has to do with excessive concatenation.

Your problem.

>> Include - don't repeat code where it can reasonably be avoided.
>> temporary variables, or functions or methods, for this.

>Temporary variables? And it's not exactly clear what "this" is. :)

Your problem. It is repeating code where it can reasonably be avoided.

Examples :

Don't repeat getElementById on the same element unnecessarily; save the
reference in a temporary variable, for readability.

Don't multiply repeat, with different variables, such as M D h m s,
if (M<10) M = "0" + M
but use a function such as
function LZ(n) { return (n!=null&&n<10&&n>=0?"0":"") + n }
or function LZ(n) { return (n<10?"0":"") + n }

(c) John Stockton, nr London, UK. ? Turnpike v6.05 MIME.
Web <URL:> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
From: Garrett Smith on
Eric Bednarz wrote:
> Garrett Smith <dhtmlkitchen(a)> writes:
>> * Use valid html.
> If that really was a valid requirement for web authoring, it wouldn't be
> joined by deep confusion about very basic and simple issues in almost
> all cases.
>> * Use standards mode, with DOCTYPE first (no comment, xml prolog).
> Well, that didn't take long. The document type declaration *is part of
> the prolog*, in both XML and SGML productions.
Maybe so, but for HTML, no comments and no prolog will trigger quirks
mode in IE. They should both be avoided for this reason.
comp.lang.javascript FAQ:
From: Garrett Smith on
Garrett Smith wrote:
> Eric Bednarz wrote:
>> Garrett Smith <dhtmlkitchen(a)> writes:


>> Well, that didn't take long. The document type declaration *is part of
>> the prolog*, in both XML and SGML productions.
> Maybe so, but for HTML, no comments and no prolog will trigger quirks
> mode in IE. They should both be avoided for this reason.
"comments and/or prolog will trigger quirks mode in IE."
comp.lang.javascript FAQ:
From: Asen Bozhilov on
Dmitry A. Soshnikov wrote:

> If you still wanna to write this as a rule, please mentioned, that
> it's not the rule, but *just your own suggestion and own meaning*,
> meanwhile other people can choose different (good) way augmenting
> object and write in OOP-style such as `string.capitalize()' instead of
> long ugly `Ext.util.Format.capitalize(string)'. Especially in own
> project.

You are absolutely right, but augmentation Object.prototype can be
harmful and confused. If implementations use native object produced
via `new Object()` as a VO and internal [[Prototype]] refer
Object.prototype, any augmentation of `object' referred from
Object.prototype can be harmful and confused. See below:

Object.prototype.x = 10;
var x = null;

Expected value of `x` is `null`, but if VO is implement as a native
object value of `x` will be 10. Because:

| 10.1.4 Scope Chain and Identifier Resolution
| 1. Get the next object in the scope chain.
| If there isn't one, go to step 5.

In that case next object is VO/AO associated with EC created from
anonymous function.

| 2. Call the [[HasProperty]] method of Result(1),
| passing the Identifier as the property.

[[HasProperty]] lookup in prototype chain and will be return `true` in
that case.

| 3. If Result(2) is true, return a value of type Reference
| whose base object is Result(1) and whose property name
| is the Identifier.

{base : VO, propertyName : x};

So in my case *expected* value is primitive number value 10.

See and next example in Firefox 3.5:

Object.prototype.x = 10;
window.alert(x); //10 expected ReferenceError

window.alert(this instanceof Object); //false
window.alert(this.__proto__ === Object.prototype); //false

How it is implement Global Object in Firefox 3.5? We can see Global
Object does not refer from internal [[Prototype]] object referred from
Object.prototype. And we can see that `object' doesn't inherit in
explicit way from Object.prototype. The question is, how it is
implement that object?