Javascript Library

R

Rozzy

What does that mean? MS extensions aside, you can't magically set the
type attribute on creation.





See the previous post.





What is tricky about doing it right? In a nutshell, set the name
property first. Of course, the name property won't populate the
elements collection of the parent form (assuming there is one),
without a workaround (see the previous post.)





Then you either can't read or are just trying to string out this
ridiculous "argument."





It is semantics. See the previous post. And who said you should use
the outerHTML property to construct the replacement markup? You don't
need to read it, just loop through the specified attributes (assuming
you have a competent getAttribute wrapper) and build the string
yourself.

Don't worry David, I got your back! I'll put these jerks in their
place

Yo guys, I don't care if it works in 99% of all browsers, I don't care
how much time or money I waste, at least I won't have to debug them
when all the browsers suddenly decide to drop their backwards-
capability and 99% of all sites crash, except mine and David's! Whose
gonna get all the hits then?? And I don't care if 90% of developers,
including "experts" like John Resig and huge corporations like Google
and IBM (who are they anyway?) use them, they're all wrong, me and
David got this javascript thing down, we get it, we know it. I mean
just because you practically invented the language doesn't mean you
know it. James Naismith wasn't a good basketball player was he?
 
P

Peter Michaux

Don't worry David, I got your back! I'll put these jerks in their
place

Yo guys, I don't care if it works in 99% of all browsers, I don't care
how much time or money I waste, at least I won't have to debug them
when all the browsers suddenly decide to drop their backwards-
capability and 99% of all sites crash, except mine and David's! Whose
gonna get all the hits then?? And I don't care if 90% of developers,
including "experts" like John Resig and huge corporations like Google
and IBM (who are they anyway?) use them, they're all wrong, me and
David got this javascript thing down, we get it, we know it. I mean
just because you practically invented the language doesn't mean you
know it. James Naismith wasn't a good basketball player was he?

Some people strive for excellence and constantly improvement. Others
are happy with mediocrity because it is good enough for everyone else.

Peter
 
R

Rozzy

Some people strive for excellence and constantly improvement. Others
are happy with mediocrity because it is good enough for everyone else.

Peter

Holy shit are you defending him, I didn't realize assholes came in
two, I guess it gives me another one to rape. If you listen real
careful I think you can still hear David screaming in the background,
I didn't realize that was his first time recieving, oops, sorry, fell
better :)
 
D

David Mark

Don't worry David, I got your back! I'll put these jerks in their
place

Put who where? From the looks of it, most people posting to and
reading this thread agree with me.
Yo guys, I don't care if it works in 99% of all browsers, I don't care

What works in 99% of all browsers?
how much time or money I waste, at least I won't have to debug them
when all the browsers suddenly decide to drop their backwards-
capability and 99% of all sites crash, except mine and David's! Whose

Oh I get it now. You are an idiot. And from the "JavaScript Forum"
no less. I recommend you go back.
gonna get all the hits then?? And I don't care if 90% of developers,
including "experts" like John Resig and huge corporations like Google
and IBM (who are they anyway?) use them, they're all wrong, me and

Google and John Resig are JavaScript experts?! Really?
David got this javascript thing down, we get it, we know it. I mean
just because you practically invented the language doesn't mean you

Who practically invented the language? John Resig? You are out of
your tiny little mind.
 
D

David Mark

Peter Michaux said the following on 12/4/2007 3:16 PM:



I think you failed to catch the sarcasm and irony in it.

It would be hard to miss the sarcasm. The irony is that most of the
jQuery muppets think that their library works with "99% of all
browsers" and that it must be good because, after all, Google uses it.
(!)

Speaking of irony, a trip to the jQuery developer group reveals that
some of the issues raised here were debated (ad nauseum) and finally
pushed through. Others were ignored or shouted down with ludicrous
comments like "if it ain't broke, don't fix it." IIRC, that was in
response to the text node event target issue, which was described as a
"Safari bug" (it is neither.) Few over there seem to grasp that their
code will break constantly as browsers fix bugs and introduce new
ones. Why anybody would use code written by such people is beyond
me. Why they would bother trying to defend it here is an even greater
mystery.

BTW, where is the latest HikkScript test page? I was working on
something recently that used Ajax and innerHTML to update elements
periodically and it needed to have inline script execute (which seemed
like a silly idea to me.) I didn't have time to wade through the
hundreds of recent posts on the subject, so I recreated what I
remembered as the best strategy. I'd like to compare it to the
definitive version that has been tested on all of the weird Mac
browsers, etc.
 
D

David Mark

David Mark said the following on 12/5/2007 4:19 AM:



True. The irony I was referring to was that rozzy didn't have a f**king
clue what they were talking about.

No question there.
Personally, I think it is beyond silly. The entire problem comes about -
mostly - from sites simply making XHR calls to retrieve documents and
inserting them in a container element via innerHTML and then proclaiming
"We have an AJAX site". If the site is designed to be "AJAX friendly"
then the issue doesn't exist.

I am with you there. This odd strategy leads to people storing state
information in the location hash and then monitoring the location with
setInterval, etc. All in the name of having an "Ajax site." Seems to
me that page navigation is best accomplished without Ajax.
Was the first step in the strategy to determine if the scripts got
executed via innerHTML?
Yes.


The test page that shows what browsers support what methods?

<URL:http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>

Last function I posted to attempt to deal with script execution?

Some issues that I know of with it:

1) Doesn't deal with document.write at all.

Right. And as you have noted, if people are trying to download pages
with Ajax that contain document.write calls, then they should clearly
re-examine their design.
2) Should be conditional functions so that it isn't
doing all of the feature detection every time you
call the function.

That I did.
3) Will fail miserably in IE5.2 and early versions of iCab.

Define miserably. Script errors?
4) Probably some other places it will fail. Either silently
or not so silently.

I imagine so.
5) Just a note that there was the suggestion of simply
appending to the HEAD element and then removing it instantly

That's what I did.
in a thread. Good idea, I just never changed it to do it, mostly
so that I could make a "dump" of a div element to see what
was actually in place at the moment.

As for a "library", there isn't one really. The last code I posted can
definitely be improved on though.

var isIE = false;
/*@cc_on @*/
/*@if (@_jscript_version >= 4)
var isIE = true;
@end @*/
function loadHTMLFragment(elemId, HTMLFragment)
{
if (document &&
document.getElementById &&
document.getElementById(elemId) &&
document.createElement &&
document.appendChild &&
document.getElementsByTagName)
{
var el = document.getElementById(elemId);
if(isIE)
{
HTMLFragment = "&nbsp;" + HTMLFragment;
//The &nbsp; is a hack to cause IE to process the
//script elements if the first node in the
//HTMLFragment is a script element.
}

I tested for a script element at the head of the fragment and added
the &nbsp;, regardless of the browser.
el.innerHTML = HTMLFragment;
var d =el.getElementsByTagName('script');
var t = d.length;
for (var x=0;x<t;x++)
{
var newScript = document.createElement('script');
newScript.type = "text/javascript";
if(d[x].src)
{
newScript.src = d[x].src;
}

I skipped this case.
else
{
if(isIE)
{
newScript.text = d[x].text;
}

This is where mine differs. I create an array of functions to try,
based on testing the text and canHaveChildren properties of a created
script element, then try them in turn. The first one that works is
the one used in the innerHTML wrapper. I try the text property first,
which may or may not be good idea. Does that property throw errors in
any agents that support createTextNode? If so, I will have to change
the testing order.
else
{
var s = document.createTextNode(d[x].text);
newScript.appendChild(s);
}
}
el.appendChild(newScript);
}
for (var y=0;y<t;y++)
{
el.removeChild(el.getElementsByTagName("script")[0]);
}
}

}

Thanks for posting. If you want the one-off version, let me know.
 
R

Rozzy

David Mark said the following on 12/5/2007 4:19 AM:
True. The irony I was referring to was that rozzy didn't have a f**king
clue what they were talking about.

No question there.


Personally, I think it is beyond silly. The entire problem comes about -
mostly - from sites simply making XHR calls to retrieve documents and
inserting them in a container element via innerHTML and then proclaiming
"We have an AJAX site". If the site is designed to be "AJAX friendly"
then the issue doesn't exist.

I am with you there. This odd strategy leads to people storing state
information in the location hash and then monitoring the location with
setInterval, etc. All in the name of having an "Ajax site." Seems to
me that page navigation is best accomplished without Ajax.


Was the first step in the strategy to determine if the scripts got
executed via innerHTML?
Yes.
The test page that shows what browsers support what methods?

Last function I posted to attempt to deal with script execution?
Some issues that I know of with it:
1) Doesn't deal with document.write at all.

Right. And as you have noted, if people are trying to download pages
with Ajax that contain document.write calls, then they should clearly
re-examine their design.
2) Should be conditional functions so that it isn't
doing all of the feature detection every time you
call the function.

That I did.
3) Will fail miserably in IE5.2 and early versions of iCab.

Define miserably. Script errors?
4) Probably some other places it will fail. Either silently
or not so silently.

I imagine so.
5) Just a note that there was the suggestion of simply
appending to the HEAD element and then removing it instantly

That's what I did.


in a thread. Good idea, I just never changed it to do it, mostly
so that I could make a "dump" of a div element to see what
was actually in place at the moment.
As for a "library", there isn't one really. The last code I posted can
definitely be improved on though.
var isIE = false;
/*@cc_on @*/
/*@if (@_jscript_version >= 4)
var isIE = true;
@end @*/
function loadHTMLFragment(elemId, HTMLFragment)
{
if (document &&
document.getElementById &&
document.getElementById(elemId) &&
document.createElement &&
document.appendChild &&
document.getElementsByTagName)
{
var el = document.getElementById(elemId);
if(isIE)
{
HTMLFragment = "&nbsp;" + HTMLFragment;
//The &nbsp; is a hack to cause IE to process the
//script elements if the first node in the
//HTMLFragment is a script element.
}

I tested for a script element at the head of the fragment and added
the &nbsp;, regardless of the browser.
el.innerHTML = HTMLFragment;
var d =el.getElementsByTagName('script');
var t = d.length;
for (var x=0;x<t;x++)
{
var newScript = document.createElement('script');
newScript.type = "text/javascript";
if(d[x].src)
{
newScript.src = d[x].src;
}

I skipped this case.
else
{
if(isIE)
{
newScript.text = d[x].text;
}

This is where mine differs. I create an array of functions to try,
based on testing the text and canHaveChildren properties of a created
script element, then try them in turn. The first one that works is
the one used in the innerHTML wrapper. I try the text property first,
which may or may not be good idea. Does that property throw errors in
any agents that support createTextNode? If so, I will have to change
the testing order.


else
{
var s = document.createTextNode(d[x].text);
newScript.appendChild(s);
}
}
el.appendChild(newScript);
}
for (var y=0;y<t;y++)
{
el.removeChild(el.getElementsByTagName("script")[0]);
}
}

Thanks for posting. If you want the one-off version, let me know.

Guys its hard to take you seriously with dicks still in your mouth, I
mean it feels like the special olympics... I want to tell you your
wrong, but I'm pretty much obligated to let you win.

btw, Randy Webb, nice job backing down from your response, "it was a
general comment", and then coming back later with your attempted
insult you fucking pussy.
 
D

David Mark

[snip]
btw, Randy Webb, nice job backing down from your response, "it was a
general comment", and then coming back later with your attempted

Idiot. Peter said that and I doubt he meant it as a vote of
confidence for your nonsensical ramblings.
 
R

Rozzy

[snip]


btw, Randy Webb, nice job backing down from your response, "it was a
general comment", and then coming back later with your attempted

Idiot. Peter said that and I doubt he meant it as a vote of
confidence for your nonsensical ramblings.

Who the **** cares, Don't you get it David I'm just like you in every
way, every shot at me is a shot at you. Don't you see that.
 
D

David Mark

btw, Randy Webb, nice job backing down from your response, "it was a
general comment", and then coming back later with your attempted
Idiot. Peter said that and I doubt he meant it as a vote of
confidence for your nonsensical ramblings.

Who the **** cares, Don't you get it David I'm just like you in every

Apparently you care. How else do you explain the profanity-laced
reply? Tourette's Syndrome?

And I'm sure you are just like me, except that you have considerable
trouble reading and writing English and know virtually nothing about
JavaScript (as evidenced by your recent posts here and in the
JavaScript Forum.)
 
B

beegee

What would be your recommendation? I see some possibilities:

1. Use a freely-available library that isn't perfect, but has lots of
examples, speeds up development, and doesn't appear to break in any
cases
2. Write everything from scratch, which might be lower quality than
the libraries and take too long
3. Hire a competent developer to write everything from scratch, which
again might take too long and may not be an option financially
4. Make a post to comp.lang.javascript asking which library to use and
be told that they all suck, and awesome library code exists but you
can't have it.
5. ???

In a real case like this, how would you recommend that people proceed?

Matt Kruse

I have looked at all the libraries that have been mentioned here plus
mootools and scriptaculous. I use YUI now because a.) I know exactly
what it will give me (trees, menus, dialogs, and a pretty nice AJAX
wrapper and most importantly, it will not obfuscate the javascript
language) b.) people on this group haven't totally dissed it.

I am unable to see what the other libraries will give me. Could you
list (for me and the OP) what specific benefits jQuery, for example
will give me. I'm not angling here. If there is a great benefit I am
missing then I will switch over and damn the obfuscation and
"terrible" code.

Bob
 
R

Rozzy

I have looked at all the libraries that have been mentioned here plus
mootools and scriptaculous. I use YUI now because a.) I know exactly
what it will give me (trees, menus, dialogs, and a pretty nice AJAX
wrapper and most importantly, it will not obfuscate the javascript
language) b.) people on this group haven't totally dissed it.

I am unable to see what the other libraries will give me. Could you
list (for me and the OP) what specific benefits jQuery, for example
will give me. I'm not angling here. If there is a great benefit I am
missing then I will switch over and damn the obfuscation and
"terrible" code.

Bob

Your right, I don't know anything about Javascript, I don't even know
what it is? I just pretend like someone who knows everything about
Javascript, but really doesn't. Wait a minute, that kinda of sounds
like you, I told you we were the same
 
D

David Mark

David Mark said the following on 12/5/2007 7:17 AM:



Very true as I don't believe that there is any way to compensate for a
document.write without writing your own parser.

It would certainly be a waste of time.
I don't think it would error out, it would never make it pasts the
feature testing. Although I don't even know that it would make it that
far in an AJAX application. "Fails silently without fallback" would be a
better description. If the innerHTML assignment was made first, before
any script insertion code, then it would insert the HTML, process the
scripts, and move on.

The test for innerHTML script execution is as simple as:

innerHTMLFailed = true;
window.onload=insertScript;

function insertScript(){
document.getElementById('scriptDiv').innerHTML='<script
type="text/javascript">innerHTMLFailed = false;<\/script>'

}

Aren't you missing the &nbsp; at the start of the string?
And then in the function you could have this:

if(innerHTMLFailed){
//code here

}

This is similar to what I did, but I don't test with a straight
innerHTML assignment as I use a wrapper for setting or appending HTML
that smooths out some of the issues with innerHTML. The wrapper uses
insertAdjacentHTML in a dummy DIV and then adds the nodes to the
target element. It seems it has identical issues with inline script,
including the need for the &nbsp; hack in IE.
With a conditional function, you could test for innerHTML script
execution and if it succeeded, you would simply insert the HTML and be
finished. In fact, I have changed my local version to insert the HTML
before the feature testing that is related to the script insertion.
I imagine so.
That's what I did.

I think the main reason I used a scriptDiv element was for testing more
than anything else. I could dump the innerHTML of scriptDiv to make sure
the script block got inserted if it didn't execute.

I tested for a script element at the head of the fragment and added
the &nbsp;, regardless of the browser.

That is a better way to go with it since it would only get added when it
was needed.
el.innerHTML = HTMLFragment;
var d =el.getElementsByTagName('script');
var t = d.length;
for (var x=0;x<t;x++)
{
var newScript = document.createElement('script');
newScript.type = "text/javascript";
if(d[x].src)
{
newScript.src = d[x].src;
}
I skipped this case.

That was added in the last version I posted as an afterthought.
else
{
if(isIE)
{
newScript.text = d[x].text;
}
This is where mine differs. I create an array of functions to try,
based on testing the text and canHaveChildren properties of a created
script element, then try them in turn. The first one that works is
the one used in the innerHTML wrapper. I try the text property first,
which may or may not be good idea. Does that property throw errors in
any agents that support createTextNode? If so, I will have to change
the testing order.

iCab, Safari2/Mac and some other fringe browsers error if you try to set
the .text property of a script element but using createTextNode works in
those two browsers. The main reason I used the isIE is because IE is the
only browser I am aware of that doesn't support createTextNode and the
idea was to use createTextNode and only use .text for IE.

I switched the order of testing to try createTextNode first.
Sure. Maybe the two together we can get something that is better than
either of them alone.

You won't be able to run this as it makes numerous references to
wrappers and an object defined in another script. The feature testing
logic looks like this:

methods = [];
s = createElement('script');
if (s) {
add = function(method, t) {
head.appendChild(s);
method(s, t);
head.removeChild(s);
};
if (doc.createTextNode && s.canHaveChildren ||
typeof(s.canHaveChildren) == 'undefined') {
push(methods, function(s, t) {
s.appendChild(doc.createTextNode(t));
});
}
if (typeof(s.text) == 'string') {
push(methods, function(s, t) {
s.text = t;
});
}
l = methods.length;
while (!api._testscriptinsertion && l--) {
add(methods[l], 'this.api._testscriptinsertion = true;');
}
if (api._testscriptinsertion) {
setElementScript = api.setElementScript = function(el, t) {
s = el;
while (s.firstChild) { s.removeChild(s.firstChild); }
add(methods[l], t);
}
addElementScript = api.addElementScript = function(s, t) {
s = el;
add(methods[l], t);
}
addScript = api.addScript = function(t) {
s = createElement('script');
add(methods[l], t);
s = null;
};
}
delete api._testscriptinsertion;
s = null;
}

So it doesn't actually do the innerHTML test first as it defines
general purpose script insertion/addition methods that can be used
without innerHTML.

After this it augments the HTML manipulation methods if they exist:

findAndAddScripts = function(el) {
var l, scripts = elementElementsByTagName(el, 'script');
l = scripts.length;
while (l--) {
if (scripts[l].text) { addScript(scripts[l].text); }
}
}

if (addElementHTML) {
addElementHTML(head, '<script type="text/
javascript">this.api._testaddhtmlscript = true;</script>');
if (!api._testaddhtmlscript) {
api.addElementHTML = function(el, html) {
addElementHTML(el, html);
findAndAddScripts(el);
};
}
}

There are two more clauses like this that have to run after the body
is parsed as they create and append a DIV to test the wrappers that
set inner/outerHTML. Worked for me, at least in the modern browsers I
use to test Ajax apps. Now that I switched the initial testing order,
it should work for iCab and those other odd Mac browsers that I don't
have here.
 
D

David Mark

Your right, I don't know anything about Javascript, I don't even know

Your (sic) right, as evidenced by this thread:

http://groups.google.com/group/Java...7af26aa611d/f5395dcf68e5d57a#f5395dcf68e5d57a

what it is? I just pretend like someone who knows everything about

Yep.

http://groups.google.com/group/Java...2ab75695d97/5bd62731ea83bb61#5bd62731ea83bb61

Salient quote:

"...except a textnode is not a valid element and
therefore cannot be referenced as the firstChild."

-Rozzy
Javascript, but really doesn't. Wait a minute, that kinda of sounds
like you, I told you we were the same

Never me.
 
D

David Mark

I have looked at all the libraries that have been mentioned here plus
mootools and scriptaculous. I use YUI now because a.) I know exactly
what it will give me (trees, menus, dialogs, and a pretty nice AJAX
wrapper and most importantly, it will not obfuscate the javascript
language) b.) people on this group haven't totally dissed it.

Parts of it have been panned recently. Their tree widget is bloated
and uses nested tables IIRC. And certainly there are decent stand-
alone menu and "dialog" (assuming you mean centered elements with
backdrops) scripts out there that don't require half of the YUI
framework to function. By coincidence, I posted examples of both here
recently. They are both available from the Google Code repository
(search the group for my name + Google and you should find the links.)
I am unable to see what the other libraries will give me. Could you

A massive headache every time one of the handful of browsers they
claim to support comes out with an update.
list (for me and the OP) what specific benefits jQuery, for example

jQuery is less than worthless, even with the recent patches that
addressed a few of the concerns pointed out in this thread. It is a
major liability and will remain one as its developers are mostly
buffoons. Avoid it at all costs.
will give me. I'm not angling here. If there is a great benefit I am
missing then I will switch over and damn the obfuscation and
"terrible" code.

What sort of strategy is that? Terrible code leads to terrible
Websites. There's no benefit in that. Not to mention that the
greatest perceived benefit of jQuery is its CSS selector queries,
which are largely useless and lead to ridiculous code that constantly
creates and discards objects, fails to test if queried elements
actually exist and generally shields the author from ever learning
anything about competent browser scripting. It's fool's gold.
 
R

Rozzy

Your (sic) right, as evidenced by this thread:

http://groups.google.com/group/JavaScript-Information/browse_thread/t...


Yep.

http://groups.google.com/group/JavaScript-Information/browse_thread/t...

Salient quote:

"...except a textnode is not a valid element and
therefore cannot be referenced as the firstChild."

-Rozzy


Never me.

This is too funny. For someone who thinks there so smart, you really
are stupid. Don't you get it, your my fucking puppet, I say one stupid
thing, and you waste your time going through my history and reading my
posts in an attempt to insult or embarrass me. Good Luck. By doing so
your letting me win, this is the only reason I posted to this thread.
Your every assholes dream.

I look forward to your reply because this is nothing but entertaining
to me.
 
R

Rozzy

Rozzy said:
[...]
Don't worry David, I got your back! I'll put these jerks in their
place [...]

Please do not feed the troll.

Yeah you got it, but the problem is that he can't sit back and say
nothing knowing hes been whipped since the beginning. Somebody got the
best of him and its eating him up inside. I scouted you well.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,745
Messages
2,569,485
Members
44,909
Latest member
DestinyKetoScam

Latest Threads

Top