Javascript Library

[Jeff North]

On Wed, 31 Oct 2007 22:34:36 -0000, in comp.lang.javascript John Resig
<[email protected]>

[snip]

|
| So besides .attr() needing a rewrite (I fully admit that) - I see
| absolutely no valid criticism of the library - and if anything, a
| gross misunderstanding of common cross browser issues and of how test
| driven development works.
|
| Let me know when you release your library, as I'd love to take a look
| and see what I've been missing.

John, I hope your not holding your breath for this event
-- -------------------------------------------------------------
(e-mail address removed) : Remove your pants to reply
-- -------------------------------------------------------------

 

[Jeff North]

[snip]

| > Let me know when you release your library, as I'd love to take a look
| > and see what I've been missing.
|
| I bet you would like to crib from me. And who said I was releasing a
| public general-purpose JavaScript library? Seems to me I said just
| recently that I would never do that (much to the chagrin of several
| people in this thread.) Apparently you don't read before you post.

LOL of course you wouldn't. You couldn't stand the criticism.
Why would anyone want to steal your code. If it is a superior product
than what is currently available people would start using your library
and forget about the others, right?
-- -------------------------------------------------------------
(e-mail address removed) : Remove your pants to reply
-- -------------------------------------------------------------

 

[David Mark]

[snip]

| > Let me know when you release your library, as I'd love to take a look
| > and see what I've been missing.
|
| I bet you would like to crib from me. And who said I was releasing a
| public general-purpose JavaScript library? Seems to me I said just
| recently that I would never do that (much to the chagrin of several
| people in this thread.) Apparently you don't read before you post.

LOL of course you wouldn't. You couldn't stand the criticism.

What does that mean? Just because I have no interest in peddling a
free library does not mean that I don't post code examples. I
absolutely welcome any (coherent) criticism.

Why would anyone want to steal your code. If it is a superior product

Why would anybody want to steal anything? So as to get it for free.
Somebody suggested I should sell JavaScript code without posting it.
That would be an interesting trick. As soon as you send it to the
wrong person to "try out", it is public domain.

than what is currently available people would start using your library
and forget about the others, right?

Some people would. The point is that I am not in the business of
giving away libraries for beer money donations. What I will do for
anybody who asks is perform a jQuery (or any library) abatement.
Though I prefer to build applications, I often find myself cleaning up
after clueless JavaScript/HTML/CSS "designers." Most of them use
Prototype or .NET. Occasionally Dojo pops up. jQuery, not so much.
Regardless, it isn't cheap labor, so in a way, I am grateful to the
John Resig's of the world.

 

[Matt Kruse]

Google as an example?! The worst JavaScript developers in history?
Same goes for Amazon.

I don't think you can dismiss the "big guys" so easily. These
companies are worth billions of dollars and they are doing it by using
a strategy that you say is terrible and will never work. Clearly, it
does work. When you can showcase the kind of success that these
companies have by using YOUR methodology, then maybe your criticisms
will have more weight.

And the
question remains: what sort of XML document runs script in IE?

XML can be returned by ajax calls and operated on.

Oddly enough, I don't have any trouble setting the type attribute for
input elements, dynamically created or not.

I'd be curious to see your code, as I've never gotten it to work in
IE. Always had to resort to creating a new input of the new type and
removing the old.

I bet you would. My test suite covers quite a few more agents than
yours.

Code you post your test suite, or give a url? If you have test cases
that break other libraries or functions, it would be great to make
them available. And you wouldn't even need to share your precious
code.

You read it backwards apparently. The point is that the problem may
exist in browsers that are NOT IE. Why make stupid assumptions? Here
is that portion of the code:
if ( jQuery.browser.msie ) {
for ( var i = 0; second; i++ )
if ( second.nodeType != 8 )
first.push(second);} else

for ( var i = 0; second; i++ )
first.push(second);
What's wrong with that picture?

Wow, I hadn't looked at that portion of the code yet. Things like that
certainly concern me.

The difference between you and me is that I don't give away code for
beer money donations.

You should. Free beer is fantastic.

I don't have to assume. I have dealt with all of the same problems
that you are stumbling over.

And solved them, presumably? And then locked those awesome solutions
up in the closet so no one else can benefit from them?

I think publicly-available code with some problems is more valuable
than robust, "perfect" code that is locked away. The public code will
be inspected, torn apart, improved, and re-thought on a regular basis.
It will evolve into the best solution. The code kept private will rot
and not benefit from public criticism and improvements. So, while your
code may be "better" than that in jQuery, it is of no use to anyone
but yourself, so I'm not sure why you keep mentioning it.

Does it indicate Mozilla? IE has spoofed Mozilla in its userAgent
string since the beginning. So is IE Mozilla?

jQuery correctly identifies IE as IE, not Mozilla.

GC is automatic. Do you understand that a memory leak is an exception
to GC? Your comment indicated that you thought the event might leak.
What do you base that suspicion on? Do you automatically remove every
listener every time the page unloads, just in case it might cause a
memory leak?

Memory leaks are a complex issue, especially in IE. I'm not sure if
you're aware of every possible leak scenario, but I know I'm not.
There are ridiculous leak scenarios that don't even involve closures
or circular references or events. Removing event listeners in this
case may not be required to avoid leaks, but it's perhaps a safe,
conservative practice.

if ( typeof a != "array" )
What (in any JavaScript implementation) will evaulate that to false?
What is an array in JavaScript?

I hope someone somewhere is blushing.

You are blind. Others certainly did. Even the jQuery fanboy Matt
Kruse agreed with enough of it to open up tickets on your site.

I didn't actually open tickets, I just started a discussion.

FYI, some of your criticisms are certainly valid, and I posted your
entire original post to the jQuery dev list. I also followed up with
my own post below that goes into detail on the attr() function. You
are welcome to critique my critiques. I already see a few places that
my suggestions could be improved.

=== Begin Copied Post From jQuery-Dev ===

I haven't had time yet to look into the code in detail, but I will do
so in the next few weeks.

I took a look at the 'attr' function today and here are my comments.
I'm not going to open a ticket for specific items, but I'd like to
hear some feedback. If these types of comments are helpful I will
continue looking at the code and making suggestions. If I am way off
base, then I'll just be quiet

I've copied the entire attr() function from the nightly build below
and added comments:

attr: function( elem, name, value ) {
var fix = jQuery.isXMLDoc( elem ) ?
{} :
jQuery.props;
// Safari mis-reports the default selected property of a hidden option
// Accessing the parent's selectedIndex property fixes it
if ( name == "selected" && jQuery.browser.safari )
elem.parentNode.selectedIndex;

Why even do the name and browser check? Surely no browser will choke
on simply accessing the selectedIndex property. Just do it blindly.

// Certain attributes only work when accessed via the old DOM 0 way
if ( fix[ name ] ) {
if ( value != undefined )
elem[ fix[ name ] ] = value;
return elem[ fix[ name ] ];
} else if ( jQuery.browser.msie && name == "style" )
return jQuery.attr( elem.style, "cssText", value );
else if ( value == undefined && jQuery.browser.msie && jQuery.nodeName( elem, "form" ) && (name == "action" || name == "method") )
return elem.getAttributeNode( name ).nodeValue;

If you're going to include this fix for 'action' and 'method' then why
not also for 'accept','enctype','name','target', etc?
And why restrict it only to IE? In fact, why even use getAttribute()?
Why not just use elem.getAttributeNode( name ).nodeValue for all node
values in all browsers?
(I've not researched that one, so there is a potential that fails in
some browsers)

You could also just do a general fix in the code below... (Marked #1)

// IE elem.getAttribute passes even for style
else if ( elem.tagName ) {
if ( value != undefined ) {
// We can't allow the type property to be changed (since it causes problems in IE)
if ( name == "type" && jQuery.nodeName( elem, "input" ) && elem.parentNode )
throw "type property can't be changed";

Do other browsers allow it? Why fail for all browsers, if only IE has
a problem?

elem.setAttribute( name, value );

Now, what if I am setting the 'action' attribute of a form that has an
input with name 'action'? It will safely get to this block in IE and
fail to set the attribute. You've handled this case for getting the
value, but not setting. Calling form.attr('action','val') in this case
will not set the action attribute in IE.

}
if ( jQuery.browser.msie && /href|src/.test( name ) && !jQuery.isXMLDoc( elem ) )
return elem.getAttribute( name, 2 );

What harm would there be in always passing a '2' to this call in all
browsers? Browsers other than IE would ignore it, and IE would always
use it to return the actual node value. Why not get rid of the browser
check and condition and just call it blindly?
In this specific case, I see that IE has a problem with passing '2' in
the case above where we are trying to get the 'action' attribute. But
the fix below avoids that. The general point is, why only limit things
like this to a browser-sniffed IE, when it wouldn't hurt to apply the
same fix for every browser?

return elem.getAttribute( name );

Here you could put in a general fix (#1) that would do away with the
special case handling above:

var v = elem.getAttribute(name);
return ((v && v.tagName)?
elem.getAttributeNode(name).nodeValue:elem.getAttribute(name,2));

This seems to cover all cases, doesn't it? If future cases are found
where certain attributes are 'masked' by returning elements, the case
will automatically be handled. And it's not limited to any specific
browser.
I haven't tested anything other than IE, but I would be interested to
hear if it causes any problems.

// elem is actually elem.style ... set the style

I don't understand why opacity, filter, etc are even considered
attributes.

} else {
// IE actually uses filters for opacity
if ( name == "opacity" && jQuery.browser.msie ) {

Will it ever even get here if it's not IE?

if ( value != undefined ) {
// IE has trouble with opacity if it does not have layout
// Force it by setting the zoom level
elem.zoom = 1;
// Set the alpha filter to set the opacity
elem.filter = (elem.filter || "").replace( /alpha\([^)]*\)/, "" ) +
(parseFloat( value ).toString() == "NaN" ? "" : "alpha(opacity=" + value * 100 + ")");
}
return elem.filter ?
(parseFloat( elem.filter.match(/opacity=([^)]*)/)[1] ) / 100).toString() :
"";
}
name = name.replace(/-([a-z])/ig, function(all, letter){
return letter.toUpperCase();
});
if ( value != undefined )
elem[ name ] = value;
return elem[ name ];
}
}

I hope these comments make sense!

Matt Kruse

 

[David Mark]

I don't think you can dismiss the "big guys" so easily. These

Why not? Their Websites throw lots of script errors, degrade poorly,
etc.

companies are worth billions of dollars and they are doing it by using

How much they are worth has no bearing to the discussion. Their
scripts are still incompetently written. Stock market analysts are in
no position to judge the quality of these sites. Those who are
invariably agree that they are junk. Your argument sounds like: "if
Google is incompetent and makes lots of money, then I should follow
their lead and I will make lots of money."

a strategy that you say is terrible and will never work. Clearly, it

Everything is relative. Perhaps they would make more money with
competent developers. Or perhaps hiring better developers would eat
into their TV advertising budget. There are too many variables to
make a correlation between Website quality and the bottom-line bean
counting of a massive multinational concern.

does work. When you can showcase the kind of success that these
companies have by using YOUR methodology, then maybe your criticisms

How do you know what I have "showcased." Do you have any idea what I
do or who I do it for?

will have more weight.

They have all the weight they need in relation to the current
discussion. On the contrary, babbling about Google lends no weight to
your "arguments" at all.

XML can be returned by ajax calls and operated on.

And you really think that the jQuery attr function is appropriate for
manipulating XML results? I can tell you that it is not. Certainly
not in IE. jQuery doesn't even work with XHTML unless it is served as
tag soup HTML.

I'd be curious to see your code, as I've never gotten it to work in
IE. Always had to resort to creating a new input of the new type and
removing the old.

I'm sure you would. Why would you ever need to change the type of an
extant input element? Nevertheless, if you poke around the Web with
your favorite search engine, you should be able to find the answer
quickly. First things first, you have to detect the broken IE get/
setAttribute implementation or you won't know when you need this
specific workaround. That is important as the method required to fix
it is proprietary to IE. Once you find the method I am referring to,
do not feature detect it and infer that attribute handling is broken
(and certainly do not infer anything from the userAgent string.) If
you understand what IE is doing wrong and look at the various
workarounds posted, you should be able to come up with the same answer
I did.

Code you post your test suite, or give a url? If you have test cases
that break other libraries or functions, it would be great to make

I don't know what that means. My test "suite" (a page actually) calls
functions in my code. It is worthless for testing other libraries.
And as for those, I think I gave you enough on the one you recommend
(and apparently use) from the code snippets I posted. Why do you need
to test what is obviously broken?

them available. And you wouldn't even need to share your precious
code.

You really don't help yourself do you?

You read it backwards apparently. The point is that the problem may
exist in browsers that are NOT IE. Why make stupid assumptions? Here
is that portion of the code:
if ( jQuery.browser.msie ) {
for ( var i = 0; second; i++ )
if ( second.nodeType != 8 )
first.push(second);} else

for ( var i = 0; second; i++ )
first.push(second);
What's wrong with that picture?

Wow, I hadn't looked at that portion of the code yet. Things like that
certainly concern me.

As well they should. No need to thank me.

You should. Free beer is fantastic.
Whatever.


And solved them, presumably? And then locked those awesome solutions
up in the closet so no one else can benefit from them?

That would seem a good presumption, otherwise I wouldn't know that the
code in jQuery is wrong. And I don't really care if you (or your
clients) benefit from my work. You might as well stop badgering me.
If you have a specific question, post it. Maybe I will take the time
to answer it and maybe I won't. It depends on the scope of the
question, how you ask it, if you can demonstrate that you have tried
to solve it yourself, etc.

I think publicly-available code with some problems is more valuable
than robust, "perfect" code that is locked away. The public code will
be inspected, torn apart, improved, and re-thought on a regular basis.

Inspected, torn apart and improved by whom? Tearing apart jQuery here
didn't seem to light fire under its author. On the contrary, his
argument seemed to be that because so many people us it, it must be
great.

It will evolve into the best solution. The code kept private will rot
and not benefit from public criticism and improvements. So, while your

I constantly post code here in hopes of getting criticism. And I
constantly make improvements. But why would you care? Oh, because
you want to bait me into making you a Beta tester or something. Good
luck. I don't need your help.

code may be "better" than that in jQuery, it is of no use to anyone
but yourself, so I'm not sure why you keep mentioning it.

I don't. You keep mentioning it.

jQuery correctly identifies IE as IE, not Mozilla.

jQuery doesn't identify anything as anything. It sets flags that are
not mutually exclusive. Have a look at the regex that sets the
"mozilla" flag.

Memory leaks are a complex issue, especially in IE. I'm not sure if
you're aware of every possible leak scenario, but I know I'm not.

Nobody but IE's developers could be aware of every leak scenario. And
they probably don't either. Interestingly enough, the specific leak
issue referred to had nothing to do with IE.

There are ridiculous leak scenarios that don't even involve closures

Yes there are. In IE and other browsers.

or circular references or events. Removing event listeners in this
case may not be required to avoid leaks, but it's perhaps a safe,
conservative practice.

So you would remove every event handler on every page unload?
Regardless, that is not what the line in question did.

I hope someone somewhere is blushing.

Especially since that is the second time I posted that snippet in this
thread. What followed was pure bluster and indicates that the author
didn't read what I posted at all.

I didn't actually open tickets, I just started a discussion.

Good for you. Seriously. I'm glad you found my comments helpful and
did something positive in response.

FYI, some of your criticisms are certainly valid, and I posted your
entire original post to the jQuery dev list. I also followed up with
Great.

my own post below that goes into detail on the attr() function. You
are welcome to critique my critiques. I already see a few places that
my suggestions could be improved.

I really don't have time right now. It would be a good idea not to
waste any more of my time with silly arguments and badgering.

read more »

I really hate Google. Never mind. I have had enough of this
discussion anyway.

 

[Matt Kruse]

Why not? Their Websites throw lots of script errors, degrade poorly,
etc.
How much they are worth has no bearing to the discussion. Their
scripts are still incompetently written. Stock market analysts are in
no position to judge the quality of these sites.

If you are looking purely from a technical javascript standpoint, I
understand.

But that's not what most people care about. The more important issue
is the big picture. Great javascript code is not the end goal for most
people - business decisions are. And if Google et al can build a
successful business using the strategy that you despise, by writing
code that you think is junk, then how can you blame others for doing
the same?

Obviously, using general-purpose libraries that are not up to your
standards on the public internet does not hold back these companies
from reaching their goals. If someone else comes in here asking about
which libraries to use to solve problems or to increase the
productivity of their team, they are probably thinking in the same
way. A perfect library that stands up to all criticisms would be
fantastic, but a well-documented, well-supported, well-tested library
that does most things right and can quickly reap rewards and help
reach the business goals is better than nothing.

When you consider all the factors that most people are dealing with,
using libraries like jQuery makes an awful lot of sense. If you ONLY
consider the pure coding quality of the underlying javascript, then
keeping your own set of "bullet-proof" libraries and reusable
functions might make the most sense. Most people, IMO, are interested
in the former. Many people in this group are interested in the latter.
Thus, the conflict.

I'm sure you would.

I would very much. Would you share it?

Why would you ever need to change the type of an
extant input element?

There are some situations where I've wanted to do it. It would be hard
to explain. But it's irrelevant.

Nevertheless, if you poke around the Web with
your favorite search engine, you should be able to find the answer
quickly.

I haven't been able to find a solution. Have you?

Good for you. Seriously. I'm glad you found my comments helpful and
did something positive in response.

My goal is to improve the tools that I and other developers use. I
have no emotional attachment to jQuery or any code. If real criticisms
and suggestions are raised, I want to address them. If they aren't
addressed by the jQuery team (I assume they will be), I'll consider
branching my own version of jQuery or something. I don't know.

Matt Kruse

 

[David Mark]

If you are looking purely from a technical javascript standpoint, I
understand.

But that's not what most people care about. The more important issue
is the big picture. Great javascript code is not the end goal for most
people - business decisions are. And if Google et al can build a
successful business using the strategy that you despise, by writing
code that you think is junk, then how can you blame others for doing
the same?

I don't blame anybody for anything. I just offer advice.

Obviously, using general-purpose libraries that are not up to your
standards on the public internet does not hold back these companies
from reaching their goals. If someone else comes in here asking about

If they were competent, perhaps they could set their goals higher. Or
maybe it wouldn't matter to the bottom line of a huge corporation.
What works for a huge corporation isn't necessarily going to translate
into success for Joe Webmaster.

which libraries to use to solve problems or to increase the
productivity of their team, they are probably thinking in the same
way. A perfect library that stands up to all criticisms would be
fantastic, but a well-documented, well-supported, well-tested library
that does most things right and can quickly reap rewards and help

Does what things right? I still contend that the library in question
is not exactly huge or all-encompassing. The time it takes to learn
it and deal with all of the issues from the 15% (or so) or users who
will not be able to use the resulting projects could be spent
learning. For instance, learning the difference between attributes
and DOM properties and how IE mixes up the two.

reach the business goals is better than nothing.

When you consider all the factors that most people are dealing with,
using libraries like jQuery makes an awful lot of sense. If you ONLY

Not for a public Website it doesn't. I thought Peter's comments
concerning expected rates of failure and the ramifications of those
failures was a good explanation of why it doesn't make sense at all
(unless the goal is abject failure.)

consider the pure coding quality of the underlying javascript, then
keeping your own set of "bullet-proof" libraries and reusable

Nothing is "bullet-proof." How you deal with the bullets that get
through is what is important. The author(s) of jQuery apparently deal
with them by shrugging.

functions might make the most sense. Most people, IMO, are interested
in the former. Many people in this group are interested in the latter.

I am very quickly losing interest in any sort of discussion regarding
jQuery, Prototype, Dojo, etc. Use whatever you want. It won't bother
me a bit. Just don't expect to encourage others to follow suit
without hearing dissenting opinions.

Thus, the conflict.


I would very much. Would you share it?

You would have been better off asking me that about twenty posts ago.

There are some situations where I've wanted to do it. It would be hard
to explain. But it's irrelevant.

Certainly. I don't need to do it. But I did need to create radio
buttons on the fly, so I ran into the problem. It isn't relegated to
nodes in the document, or even nodes with parents. The problem is
with IE's handling of the name attribute.

I haven't been able to find a solution. Have you?

I found a partial solution posted on some blog and had to spend some
time to perfect it for all cases. As I understand it, you are asking
about a specific case (changing types of elements in the document
tree) and I gave you several hints as to how to do that.
Unfortunately, you snipped them. Try googling for "IE setAttribute
type name outerHTML." But you still need to detect the problem before
you can implement the solution. Here is another hint:

Assuming el is an element object and has a getAttribute method, what
will this evaluate to in standards-based browsers?

el.getAttribute('style') && typeof(el.getAttribute('style')) ==
'object'

If it doesn't have a style attribute, it the first test will return
null and the second test is not evaluated. If it does have one, the
second test will return false. So in standards-based browsers, the
conjunction is always false.

Now consider current and past (broken) versions of IE which doesn't
know what attributes are (it thinks they are properties of the element
object.) Regardless of whether the element has a style attribute, it
has a style property which is an non-null object, so the first test
always passes. Obviously the second test is always evaluated for IE
and always true. Therefore, the conjunction is always true.

So there you have it. A boolean result that is guaranteed to tell you
when an implementation has broken attribute handling. Furthermore, it
does not harm future versions that will (hopefully) fix the problem.
Use that on an arbitrary element (I use the HTML element) during
feature detection and you only have to apply fixes for browsers that
are actually broken. The rest of them use get/setAttribute as normal.

And you should realize that this test does not directly indicate when
there will be a problem regarding the name and type attributes. That
is an inference (though a very good one) and you still need to detect
outerHTML support to work around those issues. You should also
realize at this point that this test does indicate specific problems
that can arise when confusing attributes and properties. For
instance, what do you suppose these will do in IE?

el.setAttribute('style', 'color:red');
el.setAttribute('onclick', 'alert("jQuery forgot to fix this");');
el.setAttribute('disabled', 'disabled'); // This too
el.setAttribute('checked', 'checked'); // And this

Now that you understand the problem, you can properly address it.
That's all the help I will give you on this. Perhaps if you had
posted the question first instead of running off at the mouth, I would
have helped you more.

My goal is to improve the tools that I and other developers use. I
Good.

have no emotional attachment to jQuery or any code. If real criticisms

You would seem in the minority among jQuery users.

and suggestions are raised, I want to address them. If they aren't
addressed by the jQuery team (I assume they will be), I'll consider
branching my own version of jQuery or something. I don't know.

Why expend effort to salvage an obvious derelict. Face it, you were
fooled into thinking you had a magic bullet, but it was really a time
bomb. The mad bombers who built it just shrugs off valid criticism.
The criticism will likely get more heated as more devices are
introduced with embedded browsers and they will likely continue to
chant "we don't care about anything but IE7, Opera 9, etc." Their
attitude does not indicate that they will switch gears to keep up with
the times and they are therefore doomed to end up an obscure footnote
in the history of browser scripting. Never mind the author's delusion
about remaining relevant for decades to come.

I haven't looked much at your toolkits, but why don't you concentrate
on building those up. It would make more sense to work with code you
are already familiar with. Attribute handling would seem a good
starting point.

 

[Matt Kruse]

Certainly. I don't need to do it. But I did need to create radio
buttons on the fly, so I ran into the problem. It isn't relegated to
nodes in the document, or even nodes with parents. The problem is
with IE's handling of the name attribute.

Most experienced developers have run into this problem at some point,
but this has nothing to do with changing the 'type' of an element.

I found a partial solution posted on some blog and had to spend some
time to perfect it for all cases. As I understand it, you are asking
about a specific case (changing types of elements in the document
tree) and I gave you several hints as to how to do that.
Unfortunately, you snipped them. Try googling for "IE setAttribute
type name outerHTML."

Either you are misunderstanding the problem or you have never actually
experienced and fixed it. I still cannot find a single solution for
changing the type of an input element in IE. And I'm a fairly good
googler.

I can replace the outerHTML of the element, obviously. But that just
creates a new element. It doesn't change the type of the existing
object. And it has problems of its own.

Here is another hint:

I'm not stupid - your "hints" are nothing insightful. and they don't
even begin to address the problem. It's not about bugs in setAttribute
in IE, it's about the fact that IE just doesn't want to let you change
an input's type.

Perhaps if you had
posted the question first instead of running off at the mouth, I would
have helped you more.

I'm not sure you _can_ actually be more helpful. You continue claiming
that you have all these solutions, yet you never post any of them.
Instead you give "hints" and say "search the web" and "if you had read
my posts before" etc. I'm still not convinced that you actually can
write the code that you claim to be able to. Not that I really care.

Why expend effort to salvage an obvious derelict. Face it, you were
fooled into thinking you had a magic bullet, but it was really a time
bomb.

Not at all. I like the API. I like the approach. I like the
compactness. I like the plugins. I like the community. I was aware of
some problems in the code before I decided to begin using it. I think
it has the best chance of quickly improving and becoming exactly what
I want. And it does a damn fine job for everything I'm using it for at
the moment.

I haven't looked much at your toolkits, but why don't you concentrate
on building those up.

I'd love to. Unfortunately with a wife and kids and dogs, etc, my free
time is almost nil! The days of working on my own projects for hours
at a time are long gone. Some of the code in those libs is old and
quite rusty. Some of it (like the table sorting) is newer and I
believe I solve some very tricky problems that others don't even
tackle (rowspan, colspan, etc). I always keep meaning to get back to
it...

But in a business development environment, I need to hand off tools to
other teams of developers and tell them what to use. I need javascript
tools that are documented in detail, supported with a user community,
preferrably with a printed book about them, and with a consistent and
logical API. Just having these things is such a huge improvement over
patching together various functions and utilities that the minor code
problems that exist don't really bother me much.

Matt Kruse

 

[David Mark]

Most experienced developers have run into this problem at some point,
but this has nothing to do with changing the 'type' of an element.

Actually it does. When you create an input element, it starts off as
a text element. You have to change its type to create a radio
button. If you don't do it exactly right, you will get a non-working
radio button. I assume as an "experienced developer" you have already
figured out how to do this, so I won't elaborate.

Either you are misunderstanding the problem or you have never actually
experienced and fixed it. I still cannot find a single solution for
changing the type of an input element in IE. And I'm a fairly good
googler.

You must be a lousy "Googler." The first hit that comes up has most
of the answers you seek.

I can replace the outerHTML of the element, obviously. But that just
creates a new element. It doesn't change the type of the existing

Semantics aside, it does exactly what you need. Assuming you actually
need to magically change the type of an existing element. Yes, it
invalidates any object references.

object. And it has problems of its own.

I am well aware of the problems. The blog solution I found was
incomplete. It took me hours of tinkering to get it right. In the
end, the fix for changing existing input elements led to the fix for
newly created radio buttons. All of it was either directly or
indirectly caused by IE's attribute woes. Not unsurprisingly, other
browsers, which treat attributes as attributes, do not share any of
these problems. That is why the feature detect I gave you is the
perfect branching indicator.

I'm not stupid - your "hints" are nothing insightful. and they don't
even begin to address the problem. It's not about bugs in setAttribute
in IE, it's about the fact that IE just doesn't want to let you change

It has everything to do with bugs in setAttribute in IE. What you
fail to understand is that those very bugs are what lead you to have
to set properties instead of attributes. Is that not clear at this
point?

an input's type.


I'm not sure you _can_ actually be more helpful. You continue claiming
that you have all these solutions, yet you never post any of them.

I all but gave you the solution in the last post. Not just to the
specific type/name problem, but to the entire IE get/setAttribute
issue. Whether you are playing dumb or actually are dumb is unclear
to me. Either way, I couldn't care less at this point.

 

[Peter Michaux]

I'd love to. Unfortunately with a wife and kids and dogs, etc, my free
time is almost nil! The days of working on my own projects for hours
at a time are long gone.

What about life priorities, man?! When you are lying on your death
bed, won't you have regrets? ;-)

But in a business development environment, I need to hand off tools to
other teams of developers and tell them what to use. I need javascript
tools that are documented in detail, supported with a user community,
preferrably with a printed book about them, and with a consistent and
logical API. Just having these things is such a huge improvement over
patching together various functions and utilities that the minor code
problems that exist don't really bother me much.

I agree with your sentiment here. It is very pragmatic for a business
environment. A English teacher of mine once said "A job worth doing is
worth doing poorly." This is sometimes true in business. The overall
profit of using a library like jQuery may be higher than starting from
scratch or cobbling bits and pieces together. The majority of
developers are punching the clock and things just won't ever be
released if a library like jQuery is not used.

However...

I think the utility of comp.lang.javascript would be sorely degraded
if it was ok to say "Well, that's good enough. I need to get some work
done." There are so many online communities where that is the case it
is good there is at least one where technical correctness is
paramount. I do think comp.lang.javascript's collective knowledge
should be better harnessed. Perhaps we should do something about
that.

Good to see you posting again, Matt.

Peter

 

[Evertjan.]

David Mark wrote on 01 nov 2007 in comp.lang.javascript:

Actually it does. When you create an input element, it starts off as
a text element. You have to change its type to create a radio
button. If you don't do it exactly right, you will get a non-working
radio button. I assume as an "experienced developer" you have already
figured out how to do this, so I won't elaborate.

"TYPE Attribute | type Property

Retrieves or initially sets the type of input control represented by the
object.

As of Microsoft Internet Explorer 5, the type property is read/write-once,
but only when an input element is created with the createElement method and
before it is added to the document."

<http://msdn2.microsoft.com/en-us/library/ms534700.aspx>

 

[David Mark]

David Mark wrote on 01 nov 2007 in comp.lang.javascript:


"TYPE Attribute | type Property

Retrieves or initially sets the type of input control represented by the
object.

As of Microsoft Internet Explorer 5, the type property is read/write-once,
but only when an input element is created with the createElement method and
before it is added to the document."

<http://msdn2.microsoft.com/en-us/library/ms534700.aspx>

That's Microsoft's general explanation of that attribute/property
(which they think are the same thing), but it doesn't touch on the
issues relating to the creation of radio buttons, which are related to
both the type and name attributes (and affect elements created with
createElement.) As is typical with them, the implementation doesn't
quite match the explanation.

 

[Richard Cornford]

Yawwwwnnnnn.... this is, quite possibly, the most inane
set of ramblings set up by someone who has obviously
never created a JavaScript library of any kind,

Sigh. Where's your ultra-documented, totally-awesome,
perfect-in-every- way JavaScript library? That's what I
thought - you don't have one, nor does one exist.

The same argument, over and over, is getting incredibly
old. Where's your ultra-popular library that is 100%
future proof?

"The same argument, over and over"?

So how does this work then? I cannot validly criticise dojo's authors
for demonstrating an ignorance of fundamental aspects of javascript
until after I have created something that resembles dojo (or at
least some form of "ultra-documented", "totally-awesome",
"perfect-in-every- way", "ultra-popular", "future proof" general
javascript library)? The implication being that this act is the only
pertinent qualification when judging javascript, and that my knowing
that by type-converting comparison the values undefined and null both
equal null and that no others do leaves me less qualified to judge
dojo than the people who wrote it in a way that demonstrated their
ignorance of that fact.

It doesn't really work as an argument. And if it were valid it would
raise many questions. The first would be why are there not (and never
have been) more of these things than there are? Over the years I
have knows a fair number of individuals who pretty much know
javascript and browser scripting inside out, and there must be
thousands who would never make the logical mistakes demonstrated in
dojo, so where are all of their general javascript libraries?

The next question would be; if creating these libraries is itself
the qualification why does the current set of half a dozen or so
contenders include so much code that can be validly criticised?
Shouldn't these things be demonstrating the sate of the art and
not falling down on questions of basic logic and employing
techniques which were recognised as inadequate nearly a decade ago?

So besides .attr() needing a rewrite (I fully admit that) -
I see absolutely no valid criticism of the library

And of course because the only pertinent criteria for valid
criticisms is someone having written general-purpose javascript
library, having done that yourself you then must be in the better
position to judge valid criticism, and so can be satisfied with
just dismissing whatever you don't see as valid out of hand.

- and if anything, a gross misunderstanding of common cross
browser issues

This from someone who uses user agent string browser sniffing
virtually to the exclusion of anything else? And someone who's
code only works with a couple of versions of only 4 web browsers.

and of how test driven development works.

Let me know when you release your library, as I'd love to take
a look and see what I've been missing.

So if David publishes (or continues to publish) scripts it does not
matter how cross-browser they may be, how reliable, how future proof,
how easily maintained they are, how artfully they employ javascript
or how impeccable their logic may be, so long as they are not a
library you are not interested.

Richard.

 

[Matt Kruse]

That's Microsoft's general explanation of that attribute/property
(which they think are the same thing), but it doesn't touch on the
issues relating to the creation of radio buttons

The only person who has ever said anything about the creation of radio
buttons is you.
Creating a new input element and setting its type is a completely
different issue.

I know of no solution to change the type of an existing input in IE.
Which was the point all along. If you have the solution you claim to
have, please do us all a favor, stop the "hinting" and just post an
example.

Matt Kruse

 

[Matt Kruse]

Actually it does. When you create an input element, it starts off as
a text element.

Only if you don't create it as one to begin with.

You have to change its type to create a radio
button.

Which you can do only once.

If you don't do it exactly right, you will get a non-working
radio button.

It's not as tricky as you make it sound.

You must be a lousy "Googler." The first hit that comes up has most
of the answers you seek.
Negative.

Semantics aside, it does exactly what you need.

It's not semantics. It creates a new object, rather than modifying an
existing one. Further, the outerHTML of an element in IE is not a fair
representation of how it was constructed in the source.

Matt Kruse

 

[VK]

Heh! You're quite right, and I think many people who have peeked
under the layer of carpets that is the Dojo library, and run away
shuddering would agree with you!

There are good libraries, bad libraries, awful libraries and God knows
what else libraries. As a side note: a superior quality of a product
is not a decisive argument for its possible popularity. It is only
partially technical problem - in a total it is a complex technical-
administrative-human factor domain with the technical part very rarely
holding the blocking stock package

The real problem of JavaScript is not in the absence of good
libraries. Its real problem is in lack of package mechanics - that
prevents from having real, 3rd party software independent, Java-like
frameworks. As a result one is oftenly having a huge library loaded
just for a few used methods, another huge library for other several
methods/properties etc. There is no easy way just to include any
libraries one likes - but to have the resulted .js only with what
really needed and used from each library.

JavaScript is matured and it went the regular way of any maturing
language: from repetitive code snippets to small libraries; from small
libraries to big "solution size" libraries; now it is on the stage
when one needs libraries to manage libraries - so frameworks. Yes,
everything can be re-done from scratch to exactly fit a particular
solution: but no one will pay for extra hours, so it's an option for
private works at one's leisure time. With the maturity JavaScript also
got the regular pay back of of this stage: a heavily overweighted,
junky inside coding style of big commercial solutions. "There is never
time to polish anything: this lib for this, that lib for that, patch
here, add there, and new processors' speed will compensate any sick
ugly ineffective algorithm."

Some people like Richard Cornford just do not accept that the baby is
grown so trying to put old cloth on it

From the practical point of view we don't need so much a Yet-Another-

But-Now-Really-Correct library. What is really needed is a framework
software that would compensate current package limitations of
JavaScript. So the user could link as many libraries as she wants but
the runtime-generated .js for the page would include from each library
only what is used and also what is required for used parts. That also
mean that we need an RFC to describe each library so all dependencies
could be properly read and traced by any RFC-aware software.

In My Humble but strong Opinion.

 

[David Mark]

The only person who has ever said anything about the creation of radio
buttons is you.

And you would do well to re-read what I said about it and how it
relates to the issue of setting the type property of input elements in
IE.

Creating a new input element and setting its type is a completely
different issue.

I know of no solution to change the type of an existing input in IE.

Define an "existing input." Does that mean an input that has a parent
node? Or one that has had its type property set? Either case causes
attempts to set the type property to throw an exception. It would
seem that IE assumes a default type as soon as the node is added to a
document (or document fragment.) And as I told you previously, you
can indeed change an input element from one type to another,
regardless of its circumstance.

Which was the point all along. If you have the solution you claim to

You have no point. You are just repeating the same non-argument about
outerHTML creating a new element. Of course it creates a new element
and you have to deal with that fact in your code. Assuming you
account for this properly, the user of your (very strange) application
will see the input change types, just as it does in standards-based
browsers and will experience no ill after-effects. Whether a node was
orphaned (or destroyed) and replaced by another in the process is
irrelevant.

If you are going to argue semantics, you will have to avoid vagueries
like "existing input." Furthermore, if you really wanted such a
solution for this, you would just use what I already gave you. It
would seem you just want to argue with me.

 

[Matt Kruse]

You have no point. You are just repeating the same non-argument about
outerHTML creating a new element. Of course it creates a new element
and you have to deal with that fact in your code.

Any references to the original object will be lost.
Which means you haven't changed the type of an input, you've just
created a new one to replace it.
That's one way to accomplish a goal, but it's not an answer to
modifying an existing input.

It would seem you just want to argue with me.

What are you, my wife?

Matt Kruse

 

[David Mark]

Only if you don't create it as one to begin with.

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

Which you can do only once.

See the previous post.

It's not as tricky as you make it sound.

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

Negative.

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

It's not semantics. It creates a new object, rather than modifying an
existing one. Further, the outerHTML of an element in IE is not a fair
representation of how it was constructed in the source.

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.

 

[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 was good a basketball was he?