My Library _passes_ TaskSpeed in IE < 7

[S.T.]

You know that if I was your manager and I brought my shiny new mobile
device to you to help me get our company's web site to display on it
properly and you told me that you don't care the site doesn't display
properly on mobile devices your next task would be to update your resume.

Thank goodness I'm a part-owner (though not majority) and not all that
easy to get rid of. I'm not discussing a client here -- I might not be
so cavalier about my decision to write off mobile for the time being
were it for a client who's business I did not know inside out. Hell,
were it for a client I could milk more billable hours to ensure mobile
bliss, regardless of mobile's actual value to that business.

Look, I could put up a mobile-friendly version of the site in a matter
of days. At present there is little to no value. You don't have to
believe me, but at least believe I'm working off more data than my gut
instinct and simply maintain I'm interpreting the data wrong.

Fact is my resources are better served elsewhere, though admittedly
participating in endless loop arguments on cljs might suggest otherwise.

Still attacking the messenger and not checking whether the message that
is carried is valid or not.

I'd say "attacking" is overstating my demeanor just a bit, while David
being labeled something so innocent as "messenger" is a bit generous.

David can't envision a scenario where using one of the major libraries
makes sense whereas I'm quite certain there are scenarios where it makes
sense and others where it isn't so wise. We appear to be equally baffled
by the other's conclusion. There doesn't seem to be much common ground
to discuss further.

 

[S.T.]

You think that caring about mobile devices is equivalent to defrauding
your clients???

The fact is for many business' mobile, at present, is about as useful as
a flash-intro page. You know it and I know it. You sell pizzas? OK,
mobile might have some value. You sell chemical analysis of dirt soil
samples for the oil industry? Mobile has absolutely no value whatsoever.

In the future? Perhaps, as who knows for certain. But a client should at
least be told your doing extra work and/or constraining design choices
based on your speculative assessment of the web's future. "Sure, the
layout is pretty lackluster BUT it scales perfectly for 320px browsers
for all that mobile traffic headed your way!!! One site to cover it
all!!" That's not an example of fraud, it's an example of exaggerating
your expertise and, likely, incompetence.

Fact is, I couldn't hire you simply because you don't care about a
growing sector of the market.

Among the list of reasons you couldn't hire me, this one ranks pretty low.

Ok, if your prefer, "you appear to continue to fail to address the valid
objective criticisms that have been raised".

While David may have made some valid points and illustrated some errors
in the past 2.5 years (really? 30 months of yelling about this?)
preaching from his code-perfect pulpit, it's a rare soul that would use
the term "objective" when describing that effort.

Yes of course, its David's fault that he publicises faults he finds in
GP libraries.

I don't think anyone minds David pointing out flaws. Many find the
analysis useful. Rather, it's the inevitable tantrum added to each
criticism where he derides every developer for not dropping everything
that instant to fix what he's found (or, most often, starting from
scratch) and mocking each user for not immediately abandoning all use of
a library until it meets his threshhold for perfection.

I guess if you can offload the responsibility for things not working
(eg. lack of support for mobile devices, or XHTML support) then you're
lucky.

I don't know where XHTML came into the conversation. I don't know if the
libraries support it or not as, again, I don't care (I'd have to serve
it up as text/html anyhow). The only possible merit to XHTML is for
machines to more easily read the document -- not too concerned if my
client-side scripting works for a spider.

I doubt anyone wants a discussion per se. I want an argument where one
side presents a premise drawn on various facts (which David has done)
and the other side counters the premise with facts of their own (which
no one appears to have done). Not talking about whether calling David a
"messenger" is generous.

No one is claiming the libraries are flawless. I don't know what you
(and presumably David) read that suggests otherwise.

 

[David Mark]

The fact is for many business' mobile, at present, is about as useful as
a flash-intro page.

That's nonsensical hyperbole.

You know it and I know it.

That's an assertion you aren't qualified to make.

You sell pizzas? OK,
mobile might have some value. You sell chemical analysis of dirt soil
samples for the oil industry? Mobile has absolutely no value whatsoever.

That's crazy. Virtually everyone carries a mobile browser these days
(and the ones who may be unable to afford such are likely using older
browsers and dial-up at home, which IIRC you don't care about either).

In the future? Perhaps, as who knows for certain.

Mobile browsers are important right now (and have been for years).

But a client should at
least be told your doing extra work and/or constraining design choices
based on your speculative assessment of the web's future.

What extra work? That's the fallacy in this (and similar) arguments.
Doing it right takes no longer than doing it wrong (and doing it wrong
leads to making two sites down the road when one would have done).

"Sure, the
layout is pretty lackluster BUT it scales perfectly for 320px browsers
for all that mobile traffic headed your way!!! One site to cover it
all!!"

You don't get it at all. Did you look at that example I showed you.
Did you consider it lackluster because it only had two columns? How
many columns do you think are wise? And BTW, it adjusts to one column
in most older mobile devices.

Here it is again:-

http://www.hartkelaw.net/

Other than it is waiting for a real logo and some real content, what do
you find "lackluster" about that?

Also, if you use fluid layouts, they will scale, regardless of the
number of columns (and more than two is too many anyway).

That's not an example of fraud, it's an example of exaggerating
your expertise and, likely, incompetence.
Huh?


Among the list of reasons you couldn't hire me, this one ranks pretty low.

Any time I hear a Web developer telling me they "don't care" about this
browser or that sector, I figure that means they just let those break,
which is completely incompetent. It's not hard to write documents that
work, even in environments that you don't care about. Make no mistake
that your end-users don't know (or care) what you care about. All they
know is whether your sites work. If your scripts blow up during
initialization, there's a good chance that your sites will not work,
perhaps wasting the end-users time (e.g. they fill out a form, hit
submit and nothing happens).

While David may have made some valid points and illustrated some errors
in the past 2.5 years (really? 30 months of yelling about this?)
preaching from his code-perfect pulpit, it's a rare soul that would use
the term "objective" when describing that effort.

I never said anything about "perfect code" (mine or otherwise). That's
something that they beetle-browed incompetents toss around, but they
made it up out of thin air.

As for valid points, what are the last five letters in jQuery? What do
queries do? They _read_ (or attempt to read) documents. And what did
they foul up the worst on? There you go. No amount of Matt Kruse (or
the like) dismissing every test case as an attribute (or scenario) they
don't care about is going to change that.

Then there is the ridiculous height/width code, which makes another
important task near impossible. Not just problematic, but virtually
impossible in a cross-browser fashion. That's two and if you have read
my reviews, you know there are boatloads more. Granted, they have fixed
some of them, but where are the thanks for pointing them out? All I
hear is that they don't like my "yelling".

I don't think anyone minds David pointing out flaws.

Resig - for one - sure seems to.

Many find the
analysis useful.

Yes, those are called competent developers. Eventually they convince
the incompetents. It's like dropping a boulder into a large pond. The
waves eventually break on all shores.

Rather, it's the inevitable tantrum added to each
criticism where he derides every developer for not dropping everything
that instant to fix what he's found (or, most often, starting from
scratch) and mocking each user for not immediately abandoning all use of
a library until it meets his threshhold for perfection.

That's your own interpretation. I've done nothing but try to help the
typical jQuery abuser. I've never blamed the ignorant, but those who
attempt to deceive them.

"Publicise" <> http://google.com/search?q=davidmark+site:ajaxian.com
Huh?


I don't know where XHTML came into the conversation.

Somebody else expressed surprise that jQuery doesn't support XHTML (same
as Resig did when I pointed it out to him years ago). XHTML served as
(and error-corrected to) HTML is not XHTML, but that is beyond the
typical neophyte's understanding.

I don't know if the
libraries support it or not as, again, I don't care (I'd have to serve
it up as text/html anyhow).

They don't and see above. And no, it's not a crime to forget about real
XHTML as it is a dead issue on the Web (and has been for years, save for
parts of the mobile sector).

The only possible merit to XHTML is for
machines to more easily read the document -- not too concerned if my
client-side scripting works for a spider.

The issue is that library projects like jQuery ignorantly claim to
support something they don't.

No one is claiming the libraries are flawless. I don't know what you
(and presumably David) read that suggests otherwise.

There's a big difference between flawless and something that falls apart
every six months or so, requiring an incompatible "upgrade", re-testing,
etc. just to support the latest modern browsers (excepting Opera of
course) in their default configurations. It's crazy when you realize
that IE8 will be treated (by them) like Opera 6 in a few years (i.e.
they won't "care" about it). That's not a sound scripting or business
strategy.

And then there's the fact that, even with endless "upgrades", they never
get anything close to right (e.g. attribute handling in IE, which is
hardly a trivial concern for a *query* engine).

 

[S.T.]

You don't get it at all. Did you look at that example I showed you.
Did you consider it lackluster because it only had two columns? How
many columns do you think are wise? And BTW, it adjusts to one column
in most older mobile devices.

Here it is again:-

http://www.hartkelaw.net/

Other than it is waiting for a real logo and some real content, what do
you find "lackluster" about that?

Seriously? We're seriously off-topic but I'll play.

On an iPhone 3G I have to pinch and pull until I set the just the left
column in the viewport in order to possibly read copy without having to
scroll left-and-right on every line, and at that zoom it's still a
struggle to read... and my eyes aren't that bad yet.

If I then want to use the right-hand navigation I need to scroll over to
the right, where I have to pull to zoom in further to possibly read the
link text which is inexplicably set at 3/4's of browser default, a very
odd design choice for primary navigation. If I want to go back to the
main text it's another scroll and zoom correction.

This is not what I would call a mobile-friendly site. If one is willing
to jump through hoops, it's mobile-accessible. And that's a big "IF".

If mobile is actually relevant, embrace it. Cater to what a mobile user
wants, strip out the extraneous and ensure it's easy at very narrow
widths. That means it's own site:

www.yahoo.com -> m.yahoo.com
www.papajohns.com -> mobile.papajohns.com
www.digg.com -> m.digg.com

If mobile REALLY matters to a business, apps on the various dominant
platforms that solve specific tasks for the mobile user are the way to go.

PS: On a more traditional monitor with the browser maximized, the site's
main text is borderline unreadable. Seriously... hop on a 1600px+ width
monitor, maximize the browser and try and read the privacy policy page.
It's a struggle to pull the eye across ~30 words to the beginning of the
next line. Aim for 12-14 words per column (like Usenet) without forcing
the user to resize his browser to do so.

At least we agree on XHTML.

 

[David Mark]

Seriously? We're seriously off-topic but I'll play.

On an iPhone 3G I have to pinch and pull until I set the just the left
column in the viewport in order to possibly read copy without having to
scroll left-and-right on every line, and at that zoom it's still a
struggle to read... and my eyes aren't that bad yet.

Or you could just close the second column. The fluid layout takes care
of the rest, but I don't remember what the minimum width is set to, so
it may need a slight adjustment to avoid horizontal scrolling in those
devices.

It was written before these full-featured mobile browsers were an issue,
so perhaps I need to make some adjustments to the layout. Still,
there's no way it should require a separate site. I did test it in lots
of phones at the time and the handheld style sheets made it work
perfectly as a single-column layout in every one of them. These were
displays that had no shot at working with multiple columns. Clearly the
game has changed a bit since then and whenever my client gets their
content together I will test on iPhones/iPods/etc and adjust as
necessary (but won't create a whole new site).

If I then want to use the right-hand navigation I need to scroll over to
the right, where I have to pull to zoom in further to possibly read the
link text which is inexplicably set at 3/4's of browser default, a very
odd design choice for primary navigation. If I want to go back to the
main text it's another scroll and zoom correction.

I agree that 75% is too small. The site has been in a holding pattern
for years. I'm sure I will adjust the grid whenever I get some real
content to put into it. Didn't look particularly bad in anything I
tested two years ago, but I didn't realize I had left the navigation
text so small. Still, adjusting something like that does not require a
second site (in fact 75% on the desktop is not ideal either).

This is not what I would call a mobile-friendly site. If one is willing
to jump through hoops, it's mobile-accessible. And that's a big "IF".

As mentioned, at the time it was written, it was a _very_ mobile
friendly site (one of the few such examples out there AFAIK). These
newer mobile devices are closer to a desktop experience, so they ignore
handheld style sheets. And I'd venture it is far closer to friendly in
iPhones - for example - than the typical Website. It won't take a whole
new site to bridge the gap, that much is for sure.

If mobile is actually relevant, embrace it. Cater to what a mobile user
wants, strip out the extraneous and ensure it's easy at very narrow
widths. That means it's own site:

www.yahoo.com -> m.yahoo.com
www.papajohns.com -> mobile.papajohns.com
www.digg.com -> m.digg.com

Or just adjust the font sizes a bit. Making a whole new site seems a
hard way to go.

If mobile REALLY matters to a business, apps on the various dominant
platforms that solve specific tasks for the mobile user are the way to go.

That's beside the point. They can still hit your Website with the browser.

PS: On a more traditional monitor with the browser maximized, the site's
main text is borderline unreadable.

I don't consider long lines to be ideal, but I don't think they are at
all unreadable.

Seriously... hop on a 1600px+ width
monitor, maximize the browser and try and read the privacy policy page.
It's a struggle to pull the eye across ~30 words to the beginning of the
next line. Aim for 12-14 words per column (like Usenet) without forcing
the user to resize his browser to do so.

Yes, I know, it needs a max-width rule for the paragraphs.

At least we agree on XHTML.

It's a dead issue on the Web and has been for years.

 

[Matt Kruse]

That's crazy.  Virtually everyone carries a mobile browser these days

Where is your evidence? I would guess that the number of people who
access the web via mobile device is in the single-digit percentages.

Mobile browsers are important right now (and have been for years).

They are somewhat important, to some people. Certainly not a priority
for most. Yet.

Matt Kruse

 

[David Mark]

Where is your evidence? I would guess that the number of people who
access the web via mobile device is in the single-digit percentages.

We had this discussion years ago. Virtually everybody has a phone.
Virtually all phones have browsers (and have for years). So re-read
what I said as you seem to be responding to something other point.

And so what if only single digit percentages use the browsers regularly?
And that's just a guess on your part anyway.

They are somewhat important, to some people. Certainly not a priority
for most. Yet.

But, as usual, you don't get it. Your site doesn't have to be
_unusable_ (as many are) in any browser (tiny or not). If you use
jQuery, many mobile devices will refuse to load the page as the assets
are too large (at least that was my experience with them a couple of
years back). The latest and greatest mobile devices (e.g. iPhones)
won't _cache_ jQuery, which is a self-imposed disaster, particularly
when you know you are only utilizing a tiny percentage of the script.
And then there is the fact that most mobile browsers are limited in
their capabilities, so you have to use progressive enhancement, which
jQuery makes impossible by "smoothing over" the important details about
the environment (i.e. providing a static API that blows up in
environments that it isn't capable of handling).

And, as for the "yet" bit. Do you plan to go back and re-write every
site you ever made whenever you feel like mobile "matters?" Seems like
a short-sighted approach and will be very hard on your clients' wallets.

 

[Matt Kruse]

I want an argument where one
side presents a premise drawn on various facts (which David has done)
and the other side counters the premise with facts of their own (which
no one appears to have done).

Done many, many times. And unilaterally, unjustifiably dismissed every
time by DM.

DM has answers for people who fit exactly within the constraints that
he places on how software should be written. Unfortunately, most of
the development world finds themselves in very different situations,
where his answers don't fit. And then he screams louder and stomps his
feet because no one will listen to him.

He reminds me of the linux zealots who just can't understand how
_anyone_ could continue using Windows, who constantly reminds everyone
how broken Windows is, who blogs about its problems and errors, and
who designs the coolest, most awesome software for linux users but
doesn't understand why it hasn't revolutionized the world yet. The
fact is, most people use Windows. And if you don't understand why, and
you refuse to understand why, and you are incapable of understanding
all the factors that go into the decision, and you stubbornly insist
that everyone is wrong and should switch to linux immediately, then
you're going to continue preaching your sermon to an empty church. And
you're going to continue having little if any impact on the world
around you. Which is exactly where DM finds himself. And yet he still
can't quite figure out why.

Question: If DM has the answer that most people should be looking for,
why aren't most people following his suggestions?

Answer: Because he doesn't understand what most people are looking
for, and doesn't have a real answer for those people anyway.

IMO,

Matt Kruse

 

[Matt Kruse]

We had this discussion years ago.  Virtually everybody has a phone.
Disagree

Virtually all phones have browsers (and have for years).  
Disagree

So re-read
what I said as you seem to be responding to something other point.

I'm responding to your exaggeration: "Virtually everyone carries a
mobile browser these days".

And so what if only single digit percentages use the browsers regularly?
 And that's just a guess on your part anyway.

Indeed. It might be high.

And, as for the "yet" bit.  Do you plan to go back and re-write every
site you ever made whenever you feel like mobile "matters?"

Probably, because I think desktop browsers and mobile browsers justify
two different approaches to presenting the content, and m.mysite.com
is a smart move for now.

Also, since most sites won't be concerned about mobile traffic right
now, it's best for most of them to not worry about it in the near
future until things settle down a bit and the direction and technology
of the mobile web is more solid. Investing now simply won't pay off
for most companies, IMO.

Matt Kruse

 

[David Mark]

Done many, many times. And unilaterally, unjustifiably dismissed every
time by DM.

No, that's the opposite of what occurred. Every time I point out one of
jQuery's many flaws, you claim it isn't something you care about. What
are the last five letters in jQuery, again? If it can't _read_
dcouments straight, it is a failure. It doesn't matter if you "don't
care" about attribute X or Y (or heights, widths, etc.) Virtually none
of the mentioned shortcomings are documented either, so how would you
know what you are supposed to "care" about?

Did you care about ActiveX being disabled in corporate environments
before I pointed out that jQuery would unceremoniously blow up in such
cases or were you oblivious like the jQuery developers? Yeah, they
eventually fixed it (after I beat them over the head with it for
_years_), but think of how many scattered versions of jQuery there are
out there right now (many of which exhibit this fatal flaw). Maybe if
you had listened instead of dismissing everything as "edge cases",
things wouldn't be such a mess (after all, Resig and co. listen to you
at least some of the time).

DM has answers for people who fit exactly within the constraints that
he places on how software should be written.

That's ridiculous. If you can't measure an element's dimensions or read
its attributes with any reasonable reliability, you can't possibly have
a firm DOM scripting foundation. When has such folly ever worked (for
any sort of software). It's like a calculator that sometimes gives the
wrong answers (and degrades over time without constant, expensive
maintenance until all of the answers are wrong). Endless rewrites are
not a good strategy for the Web (for reasons that I hope are obvious by
now).

Unfortunately, most of
the development world finds themselves in very different situations,
where his answers don't fit.

That's pure lunacy. Often I'm the guy they call to clean up their
messes (and the cleanup techniques haven't changed much over the years).
If you would just learn instead of fixating on the messenger, you would
understand.

And then he screams louder and stomps his
feet because no one will listen to him.

I'd say that nobody is listening to _you_ at this point (and I'm
definitely a different story).

He reminds me of the linux zealots who just can't understand how
_anyone_ could continue using Windows, who constantly reminds everyone
how broken Windows is, who blogs about its problems and errors, and
who designs the coolest, most awesome software for linux users but
doesn't understand why it hasn't revolutionized the world yet. The
fact is, most people use Windows. And if you don't understand why, and
you refuse to understand why, and you are incapable of understanding
all the factors that go into the decision, and you stubbornly insist
that everyone is wrong and should switch to linux immediately, then
you're going to continue preaching your sermon to an empty church.

All irrelevant apples and oranges (as usual). Where's your brain?

And
you're going to continue having little if any impact on the world
around you. Which is exactly where DM finds himself. And yet he still
can't quite figure out why.

That's also ridiculous. I've had far more impact on your "real world"
than you care to admit. Who is it that keeps getting things fixed in
jQuery (for example?) Sure as hell not you. In fact, you have tried to
parrot my ideas to jQuery from time to time and are usually shouted
down. We've seen it over and over, so why continue to delude yourself?

Question: If DM has the answer that most people should be looking for,
why aren't most people following his suggestions?

But they do (albeit years later in most cases). You are just being
disingenuous (also as usual).

Answer: Because he doesn't understand what most people are looking
for, and doesn't have a real answer for those people anyway.

You are not one to comment on understanding; that's for sure.

 

[David Mark]

Disagree

You are just indefatigably disagreeable. I can't help you there.

Disagree

Same. Even throw-away phones have had browsers since the middle part of
the last decade. Where have you been?

I'm responding to your exaggeration: "Virtually everyone carries a
mobile browser these days".


Indeed. It might be high.

Or low. So why throw out made-up statistics?

Probably, because I think desktop browsers and mobile browsers justify
two different approaches to presenting the content, and m.mysite.com
is a smart move for now.

No, it is actually _less_ smart today as the two are obviously
converging. And I didn't have problems with most of the older phones
either.

Also, since most sites won't be concerned about mobile traffic right
now, it's best for most of them to not worry about it in the near
future until things settle down a bit and the direction and technology
of the mobile web is more solid. Investing now simply won't pay off
for most companies, IMO.

Investing? Two sites are more expensive than one. Furthermore, one
site that (sort of) works on the desktop, but blows up in mobile devices
is certainly a bad idea.

 

[David Mark]

Matt Kruse wrote:

[...]

He reminds me of the linux zealots who just can't understand how
_anyone_ could continue using Windows, who constantly reminds everyone
how broken Windows is, who blogs about its problems and errors, and
who designs the coolest, most awesome software for linux users but
doesn't understand why it hasn't revolutionized the world yet. The
fact is, most people use Windows.

And, though irrelevant to browser scripting, perhaps you missed the
success of the new Macs. Put a hell of dent in Windows, didn't they?
And what do they run?

 

[Garrett Smith]

We're gonna have to agree to disagree on the main premise, whether
jQuery actually works. You're telling me it doesn't work and is chock
full of errors, but that doesn't match my experience.

What it means for something to work is that that thing fulfills a
contract of functioning in the way it has been specified to function.

If JQuery is expected to be a "cross browser, CSS3 Compliant" selector
engine, as the website states, then jQuery does not work.

JQuery is not a "CSS3 Compliant" selector engine.

Other claims on jQuery homepage include: "fast and concise" and
"lightweight footprint". When compared to something like Dojo, those
claims may seem correct, but then almost anything is lightweight
compared to Dojo except maybe Ext-js (YUI 3 bulking, too).

The other things on the jQuery homepage include graphics, lists of
well-known companies using jQuery, lists of books on jQuery. Seminars on
learning jQuery. All of these things contribute to appeal to popularity,
but cannot be used as stipulations for defining "works".

If, however, by "works", you mean that you used it did what you wanted,
then we have a different definition of "works".

[...]

 

[Matt Kruse]

What it means for something to work is that that thing fulfills a
contract of functioning in the way it has been specified to function.

Very little - if any - software "fulfills a contract of functioning"
100% of the time, without problems. I use many pieces of software
every day that surely have countless unresolved bugs. Yet they still
provide much value to me. I'd say they "work" as long as those
problems do not cause a problem for me, despite their existence.

In that vain, jQuery "works" because it does not cause a problem for
most users, despite its flaws. It works. Perfectly? No. But it works.

The idealistic, unachievable goal of software development is bug-free
perfection. No piece of software - including jQuery - should be judged
by that measure. Instead, you have to look at the big picture and many
factors, of which technical robustness if just one.

Matt Kruse

 

[David Mark]

Very little - if any - software "fulfills a contract of functioning"
100% of the time, without problems.

Now ain't that the truth. Particularly browser scripting libraries,
which are pretty much crap shoots.

I use many pieces of software
every day that surely have countless unresolved bugs. Yet they still
provide much value to me.

So what? It's stupid to stick with something you _know_ is broken when
better alternatives have existed for _years_.

I'd say they "work" as long as those
problems do not cause a problem for me, despite their existence.

But you are programming for the public, not yourself.

In that vain, jQuery "works" because it does not cause a problem for
most users, despite its flaws. It works. Perfectly? No. But it works.

Most users?! How do you figure that? You've been in their forums.

The idealistic, unachievable goal of software development is bug-free
perfection.

You are just babbling (as usual).

No piece of software - including jQuery - should be judged
by that measure.

Perfect is clearly out of the realm of possibility for that thing,
despite the fact that it's just a silly script. It's not even _close_
to perfect after all of these years because they designed something they
had no idea how to build.

Instead, you have to look at the big picture and many
factors, of which technical robustness if just one.

Babbling. You practically begged me to post a better library than
jQuery years ago and here you are still clinging to and apologizing for
jQuery. And you have tried to tell them over and over about various
"badly broken" (your words) methods and they didn't even understand that
there was a problem (let alone fix them). Still, here you are
apologizing further. How goofy is that?

Every app, book and online example out there uses the "badly broken"
attr method. Nobody seems to be able to define what it is _supposed_ to
do, let alone what it does in reality (which changes randomly from one
release to the next). The queries aren't compatible with other
libraries, the specs or the newly-added QSA layer. It's pure madness to
use something that fouled up on a Website. I know, you think that
saving a few lines of code here or there matters, but how so when you
have to add thousands of lines of demonstrably dubious code to achieve
these "savings?"

And, again, you admittedly can't even upgrade the piece of junk. Why
you would be happy with 1.2x in an IE6-only environment is beyond me as
I've demonstrated how screwed up that version is in IE6. Be fair, all
of them are screwed up in IE6, but the older ones are far worse.

 

[Matt Kruse]

So what?  It's stupid to stick with something you _know_ is broken when
better alternatives have existed for _years_.

Your logic is flawed. I know technically better alternatives exist
than Windows, yet I still use it. Again, the point you never seem to
acknowledge - there are more factors than just the technical quality
of a solution. You continually choose to ignore that.

You are just babbling (as usual).

This is how you dismiss any statement you don't like.

Matt Kruse

 

[David Mark]

Your logic is flawed. I know technically better alternatives exist
than Windows, yet I still use it.

Your focus is blurry. We are talking about browser scripting libraries,
specifically jQuery. You have been waffling for years about it. It's
broken, it's not, etc. The end result is you still defend this silly
script, which is getting worse every day. You do realize that the whole
"Sizzle" thing is a fraud, right? It's a superficial speed boost at the
expense of (even more) inconsistent behavior. Meanwhile, gEBI, gEBTN,
etc. are virtually 100% reliable cross-browser (even in off-brands,
older versions of the majors, mobile UA's, etc.) It's madness to
continue on the jQuery course at this point (as, in reality, has been
for years).

Again, the point you never seem to
acknowledge - there are more factors than just the technical quality
of a solution. You continually choose to ignore that.

Not when it comes to a silly (and fairly trivial) script that is little
more than an awkward QSA wrapper at this point. And, of course, in
browsers without QSA, it works slightly differently. Consistency was
supposed to be the selling point of this thing, remember? Well, and
"conciseness" which is ludicrous as it is a 70K hit to start with. And
speed, which we know is a joke at this point. What's left to cling to?
A brand name?

This is how you dismiss any statement you don't like.

No, babbling is babbling (and that's seemingly all you are good for).

 

[Matt Kruse]

Every time I point out one of
jQuery's many flaws, you claim it isn't something you care about.

Not quite, but it would be fair if I did.

It's similar to you pointing out that my car will blow up if I push it
to 120mph on a Sunday during a full moon. That's interesting, but if I
know that I will never do that, then it's not a convincing argument
for me to stop driving it.

Did you care about ActiveX being disabled in corporate environments
before I pointed out that jQuery would unceremoniously blow up in such
cases
No

or were you oblivious like the jQuery developers?  Yeah, they
eventually fixed it (after I beat them over the head with it for
_years_)

Actually, I politely pointed it out to them and it was fixed the same
day. I got results, you didn't.

That's ridiculous.  If you can't measure an element's dimensions or read
its attributes with any reasonable reliability, you can't possibly have
a firm DOM scripting foundation.

You read like a wikipedia article on logical fallacies.

That's also ridiculous.  I've had far more impact on your "real world"
than you care to admit.  Who is it that keeps getting things fixed in
jQuery (for example?)  Sure as hell not you.  In fact, you have triedto
parrot my ideas to jQuery from time to time and are usually shouted
down.  We've seen it over and over, so why continue to delude yourself?

jQuery forum archives surely point to the opposite.

You know what would be interesting, DM? If you wrote up a convincing
article detailing the reasons why a developer should use My Library
instead of jQuery, and the process by which they should do so. You
could target it at business web app developers, for example. Be sure
to cover all the factors that would matter to such a user of jQuery,
not just technical points about attributes and dimensions. That
writeup might actually be useful.

Do I expect you to actually do anything like that? Umm, no. Of course
not.

Matt Kruse

 

[David Mark]

Not quite, but it would be fair if I did.

You don't care that a query-based DOM scripting library can't query
straight? Then I guess you don't care about cross-browser (or even
cross-IE!) consistency. That's an odd stance.

It's similar to you pointing out that my car will blow up if I push it
to 120mph on a Sunday during a full moon. That's interesting, but if I
know that I will never do that, then it's not a convincing argument
for me to stop driving it.

Another ridiculous comparison. When very basic queries fail to achieve
consistent results, even in the very latest browsers, it's time to admit
defeat (though it is clear you never will).

No

But anyone aspiring to publish documents to the _Web_ better care about it.

Actually, I politely pointed it out to them and it was fixed the same
day. I got results, you didn't.

No, you would never have even _known_ about it if I hadn't pointed it
out over and over as a ridiculous oversight. Cause and effect.

You read like a wikipedia article on logical fallacies.

And how do such articles read? You really are king of inappropriate
(and often incomprehensible) similes.

jQuery forum archives surely point to the opposite.

You say that assuming I won't bother to post links to your futile
attempts to communicate my ideas (the selected option "issue" in Webkit
comes to mind). And how about that 100+ post thread about attr? That
went nowhere (and it was a full two years after I first raised the issue
with Resig). They are clearly not capable of writing a cross-browser
script and you are clearly ineffectual at enlightening them. Perhaps
you are too polite to be effective? Personally, I wouldn't bother with
them at this point.

You know what would be interesting, DM?

Gee, what MK?

If you wrote up a convincing
article detailing the reasons why a developer should use My Library
instead of jQuery, and the process by which they should do so.

Why would that interest you? You should know the basic reasons by now.

You
could target it at business web app developers, for example. Be sure
to cover all the factors that would matter to such a user of jQuery,
not just technical points about attributes and dimensions. That
writeup might actually be useful.

It's been done to death (sans any mention of My Library). And I grow
weary of you dismissing attribute issues as attributes are the basic
building blocks of elements, which add up to documents, which are then
queried (often by attributes). How you can ignore the fact that you
can't get/set dimensions of elements (or documents or windows)
consistently with this magic 70K+ blob of JS is also beyond belief.
What does it do right again?

Do I expect you to actually do anything like that? Umm, no. Of course
not.

You should have all of the information you need at this point. And what
sort of a disingenuous crank would say something like that after I
published a 10000+ example (in part due to their incessant badgering)
and enough reasons to switch to it to choke a newsgroup.

 

[David Mark]

You don't care that a query-based DOM scripting library can't query
straight? Then I guess you don't care about cross-browser (or even
cross-IE!) consistency. That's an odd stance.


Another ridiculous comparison. When very basic queries fail to achieve
consistent results, even in the very latest browsers, it's time to admit
defeat (though it is clear you never will).


But anyone aspiring to publish documents to the _Web_ better care about it.


No, you would never have even _known_ about it if I hadn't pointed it
out over and over as a ridiculous oversight. Cause and effect.


And how do such articles read? You really are king of inappropriate
(and often incomprehensible) similes.


You say that assuming I won't bother to post links to your futile
attempts to communicate my ideas (the selected option "issue" in Webkit
comes to mind). And how about that 100+ post thread about attr? That
went nowhere (and it was a full two years after I first raised the issue
with Resig). They are clearly not capable of writing a cross-browser
script and you are clearly ineffectual at enlightening them. Perhaps
you are too polite to be effective? Personally, I wouldn't bother with
them at this point.


Gee, what MK?


Why would that interest you? You should know the basic reasons by now.


It's been done to death (sans any mention of My Library). And I grow
weary of you dismissing attribute issues as attributes are the basic
building blocks of elements, which add up to documents, which are then
queried (often by attributes). How you can ignore the fact that you
can't get/set dimensions of elements (or documents or windows)
consistently with this magic 70K+ blob of JS is also beyond belief.
What does it do right again?


You should have all of the information you need at this point. And what
sort of a disingenuous crank would say something like that after I
published a 10000+ example (in part due to their incessant badgering)
and enough reasons to switch to it to choke a newsgroup.

10000+ lines in one example, not 10000+ examples.