«

On Jun 27, 3:48*pm, Jorge <jo...@jorgechamorro.com> wrote:
> On Jun 27, 10:01*am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> > (...)
> > I do agree that this deserves mention in the FAQ. If Steve's book is
> > going to be included, it ought to mention that his application design
> > advice is considerably harmful.
>
> Mention that *you* consider it harmful.

Plus a link to the convoluted non-arguments(*) in your (OMG) long
post...

(*)
1.- WTHIT ?
javascript:alert(document.createElement
("script").canHaveHTML):undefined

2.- Wow:
"The file name changed it's not "menu.js", but now "menu-
degrading.js",
but notice how Steve gets that wrong a couple of times. That right
there
is evidence that the "degrading" part is unrelated to the original
code."

3.- That says nothing about the validity of the pattern:
"The inline code at the end of menu-degrading.js loops through
elements
in the document. It uses all global variables, including a global
loop
counter |i|."

4.- The same global context in which any program (read: <script>) is
run:
"The eval method is called in global context."

5.- idiocy++ ?:
"Looping through the DOM while the page loads is a strategy that
hurts
performance."

6.- Again ?
"AISB, eval is called in global context. Steve did not mention this,
and
the code is so naive that I doubt he is even aware of it"

7.- Of course, it's a <script>, remember ?
"but the code must exist in global context"

8.- Etc...
--
Jorge.

Jorge wrote:
> On Jun 27, 3:48 pm, Jorge <jo...@jorgechamorro.com> wrote:
>> On Jun 27, 10:01 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>
>>> (...)
>>> I do agree that this deserves mention in the FAQ. If Steve's book is
>>> going to be included, it ought to mention that his application design
>>> advice is considerably harmful.
>> Mention that *you* consider it harmful.

Any rational person reading that couldn't really disagree that what I
wrote was incorrect based on the fact that it was long. The review was
not nearly as long as the video itself

The video contains so much maladvice that a complete review would be
longer than the video itself.

The arguments were valid, clearly stated, and addressed one of the
video's topics in overview and specifics. Steve's advice on application
design and architecture is dangerous and should be eschewed.

>
> Plus a link to the convoluted non-arguments(*) in your (OMG) long
> post...

It was long, I should have trimmed it up a bit. But it was not nearly as
long as the video, right?

That video is potentially harmful. Someone might watch that and
actually believe it was useful.

>
> (*)
> 1.- WTHIT ?

I take it that means "what the hell is this". It is an MSIE property.
I should have mentioned that |canHaveHTML| is an MSIE property[5].

(BTW - the MSDN doc came up #1 in google rank for "canHaveHTML".)

> javascript:alert(document.createElement
> ("script").canHaveHTML):undefined
>


> 2.- Wow:
> "The file name changed it's not "menu.js", but now "menu-
> degrading.js",
> but notice how Steve gets that wrong a couple of times. That right
> there
> is evidence that the "degrading" part is unrelated to the original
> code."
>

The confusion it causes should not be surprising; rather, it is
indicative that the technique is confusing.

> 3.- That says nothing about the validity of the pattern:
> "The inline code at the end of menu-degrading.js loops through
> elements
> in the document. It uses all global variables, including a global
> loop
> counter |i|."
>

Steve says the technique is "safer". It is less safe because of the use
of eval. That point should have been clear. It is also unsafe because,
AISB, it is based on the expectation that all browsers violate HTML 4.01
to make it work.

Garrett
[5]http://msdn.microsoft.com/en-us/library/ms533547(VS.85).aspx
--
comp.lang.javascript FAQ: http://jibbering.com/faq/

Garrett Smith wrote:
> Jorge wrote:
> (...)
>> 1.- WTHIT ?
>
> I take it that means "what the hell is this". It is an MSIE property.
> I should have mentioned that |canHaveHTML| is an MSIE property[5].
> (...)
> AISB, it is based on the expectation that all browsers violate HTML 4.01
> to make it work.
> (...)

True, <script>s can (and should) not contain *markup* and nobody is
asking for it. In the absence of (inner) markup, .innerHTML becomes ===
..innerText === .textContent === .text. If it makes you feel any better
use the latter. Although -I can only guess- they must have chosen
..innerHTML for a reason.

see:
http://jorgechamorro.com/cljs/070/

--
Jorge.

On Jun 27, 7:23*pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> (...)
> Steve says the technique is "safer". It is less safe because of the use
> of eval. That point should have been clear.(...)

BTW, could you explain to me why/how is it any unsafer eval
(script.text) than a <script> tag ?

TIA,
--
Jorge.

Jorge wrote:
> Garrett Smith wrote:
>> Jorge wrote:
>> (...)
>>> 1.- WTHIT ?
>>
>> I take it that means "what the hell is this". It is an MSIE property.
>> I should have mentioned that |canHaveHTML| is an MSIE property[5].
>> (...)
>> AISB, it is based on the expectation that all browsers violate HTML
>> 4.01 to make it work.
>> (...)
>
> True, <script>s can (and should) not contain *markup* and nobody is
> asking for it. In the absence of (inner) markup, .innerHTML becomes ===
> .innerText === .textContent === .text. If it makes you feel any better
> use the latter. Although -I can only guess- they must have chosen
> .innerHTML for a reason.
>

Script content is CDATA[1]. That means it must *not* contain markup.
While that is true, it is not the incompliance that I mention.

What I am talking about is the HTML 4.01 requires the browser to ignore
the element's contents when the script has a URI. See HTML 4.01, 18.2.1
The SCRIPT element:

| If the src attribute is not set, user agents must interpret the
| contents of the element as the script. If the src has a URI value,
| user agents must ignore the element's contents and retrieve the script
| via the URI.

"*must* *ignore*"

And 6.14 Script data:

| User agents must not evaluate script data as HTML markup but instead
| must pass it on as data to a script engine.

And section 6.2 SGML basic types:
| ...
| Although the STYLE and SCRIPT elements use CDATA for their data model,
| for these elements, CDATA must be handled differently by user agents.
| Markup and entities must be treated as raw text and passed to the
| application as is.

Now, in a browser that does not support the script element, it should,
(or must, in other specifications) attempt to process the element's
content.

HTML 4.01, B.1 Notes on invalid documents:
| # If a user agent encounters an element it does not recognize, it
| should try to render the element's content.

XHTML 1, 3.2. User Agent Conformance:
| # If a user agent encounters an element it does not recognize, it must
| process the element's content.

The choice of judgment to use |script.innerHTML| is based on the
expectation that the script will have an innerHTML property containing
the script data as text, that gets passed as-is to eval. That
expectation is, according to Steve Souders, based upon what "all
browsers" do.

Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/

Jorge wrote:
> On Jun 27, 7:23 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> (...)
>> Steve says the technique is "safer". It is less safe because of the use
>> of eval. That point should have been clear.(...)
>
> BTW, could you explain to me why/how is it any unsafer eval
> (script.text) than a <script> tag ?
>

The eval function uses the calling context's [[Scope]], Variable object,
and |this| value.

When eval is called, and the code inside eval is parsed, assignment to
identifiers inside that eval'd code resolve to the calling context's
variable object when it is invoked.

Using a SCRIPT tag, that behavior does not happen.

Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/

On Jun 28, 7:20*am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> Jorge wrote:
> > On Jun 27, 7:23 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >> (...)
> >> Steve says the technique is "safer". It is less safe because of the use
> >> of eval. That point should have been clear.(...)
>
> > BTW, could you explain to me why/how is it any unsafer eval
> > (script.text) than a <script> tag ?
>
> The eval function uses the calling context's [[Scope]], Variable object,
> and |this| value.
>
> When eval is called, and the code inside eval is parsed, assignment to
> identifiers inside that eval'd code resolve to the calling context's
> variable object when it is invoked.
>
> Using a SCRIPT tag, that behavior does not happen.

Thanks, but AFAICS, an eval('code') at the top level is ===
<script>'code'</script> :

- 'this' === window,
- [[scope]] === global context, and
- no Variable 'object'.

--
Jorge.

On Jun 28, 9:23*am, kangax <kan...@gmail.com> wrote:
> Garrett Smith wrote:
> > Jorge wrote:
> >> On Jun 27, 7:23 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >>> (...)
> >>> Steve says the technique is "safer". It is less safe because of the use
> >>> of eval. That point should have been clear.(...)
>
> >> BTW, could you explain to me why/how is it any unsafer eval
> >> (script.text) than a <script> tag ?
>
> > The eval function uses the calling context's [[Scope]], Variable object,
> > and |this| value.
>
> > When eval is called, and the code inside eval is parsed, assignment to
> > identifiers inside that eval'd code resolve to the calling context's
> > variable object when it is invoked.
>
> I know that ES3 allows for implementations to throw EvalError with
> indirect eval calls, but don't browsers instead evaluate in a global scope?
>
> (this happens in at least FF 3 and Safari 4)
>
> var x = 'outer';
> (function(){
> * *var x = 'inner';
> * *return this.eval('x');
>
> })();

var x = 'outer';
(function f () {
var x = 'inner';
alert(window.eval('x'));
})();

--> outer

var x = 'outer';
(function f () {
var x = 'inner';
alert(eval('x'));
})();

--> inner

--
Jorge.

On Jun 28, 3:23*am, kangax <kan...@gmail.com> wrote:
> Garrett Smith wrote:
> > Jorge wrote:
> >> On Jun 27, 7:23 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >>> (...)
> >>> Steve says the technique is "safer". It is less safe because of the use
> >>> of eval. That point should have been clear.(...)
>
> >> BTW, could you explain to me why/how is it any unsafer eval
> >> (script.text) than a <script> tag ?
>
> > The eval function uses the calling context's [[Scope]], Variable object,
> > and |this| value.
>
> > When eval is called, and the code inside eval is parsed, assignment to
> > identifiers inside that eval'd code resolve to the calling context's
> > variable object when it is invoked.
>
> I know that ES3 allows for implementations to throw EvalError with
> indirect eval calls, but don't browsers instead evaluate in a global scope?

Some might if the Global Object is used. Don't count on it though
(better strategy is to count on an exception.)

>
> (this happens in at least FF 3 and Safari 4)

I wouldn't infer anything from that.

>
> var x = 'outer';

AIUI, this would be more future-proof with regard to the next version
of ES:

var GLOBAL = this;

> (function(){
> * *var x = 'inner';
> * *return this.eval('x');

return GLOBAL.eval('x');

>
> })();
>

But best to avoid it entirely.

On Jun 28, 3:37*am, Jorge <jo...@jorgechamorro.com> wrote:
> On Jun 28, 7:20*am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
>
>
> > Jorge wrote:
> > > On Jun 27, 7:23 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> > >> (...)
> > >> Steve says the technique is "safer". It is less safe because of the use
> > >> of eval. That point should have been clear.(...)
>
> > > BTW, could you explain to me why/how is it any unsafer eval
> > > (script.text) than a <script> tag ?
>
> > The eval function uses the calling context's [[Scope]], Variable object,
> > and |this| value.
>
> > When eval is called, and the code inside eval is parsed, assignment to
> > identifiers inside that eval'd code resolve to the calling context's
> > variable object when it is invoked.
>
> > Using a SCRIPT tag, that behavior does not happen.
>
> Thanks, but AFAICS, an eval('code') at the top level is ===
> <script>'code'</script> :
>
> - 'this' === window,

Bad assumption, but irrelevant here.

> - [[scope]] === global context, and

Not exactly.

And are you planning to run this XHR/eval combo in the global
context? I would expect it to reside in a function.

> - no Variable 'object'.

See above.