Absolute element offsets--exercise in futility
David Mark
script like jQuery (or whatever) was only an issue if calling apps
made use of the parts touched by the loosely organized "team" of
developers.
Unfortunately, when you first attempt to take the giant leap from
browser sniffing to feature detection (all at once and ten years
late), you end up with fingerprints all over everything.
I recently noticed a plug for jQuery's reenactment of that favorite of
browser scripting neophytes: calculating offset positions. For the
uninitiated, a cross-browser solution to calculate *absolute* offsets
(from the "origin" of the HTML element) is strictly an academic
exercise. Production apps are *never* designed to rely on such
problematic measurements.
Since the early part of the century, "solutions" involved two
branches, one for IE using the proprietary getBoundingClientRect
(recently adopted by FF and Opera) and a loop adding offsetLeft/Top
(plus clientLeft/Top) properties in everything else. Occasionally, a
third branch would use getBoxObjectFor (now deprecated) in Mozilla-
based browsers. In a few specific contexts, viable solutions are
possible. In a general sense, attempting to solve this "problem" at
all is madness.
As jQuery's old rendition of this classic used browser sniffing
exclusively, the version of the offset method in 1.3x has changed
radically. As would be expected, so has its behavior across the
handful of browsers supported by jQuery. Certainly this is part of
the reason that jQuery only supports browsers released in the last
couple of years.
A useful and pragmatic function would have been one that calculated
the offset from its nearest positioned parent. For example, the body:
http://groups.google.com/group/jquery-dev/browse_thread/thread/5107d8bf230a3721#
"Greetings, fellow developers!
First of all, I would like to thank you guys for putting in so much
time and effort on this amazing framework. This will be basically a
repost of another email I sent to jquery ui, along with a ticket
filled on their bug tracking system, regarding to the behaviour of one
of the widgets in the presence of a positioned body element."
Poor bastard.
"Just write your own function that uses jquery's return value and adds
in your calculations for your offset body.
Matt Kruse"
Sure, use a just-released version of an impossible absolute position
function then adjust to suit!
Two more studied opinions on the OP's dilemna:
"Regardless of jQuery support or not, I am the only one who thinks
positioning the body is kind of weird? what's between the body and the
viewport limits, limbo?"
Yes, silly. That's the part you *don't* want to measure.
"No, you're not the only one. I, too was wondering why someone would
need to position the body."
The OP tried to be sane and asked for help. He got one disinegenuous
detour from a fanboy and tittering from the resident technicians.
More futility on this front:
http://groups.google.com/group/jquery-dev/browse_thread/thread/8f258f8d9ef4a23f#
http://groups.google.com/group/jquery-dev/browse_thread/thread/6b8770d069db1872
At least one of those recommends transplanting the 1.2x absolute
position function into 1.3x. Abbie something?
So what will they invent to smooth out the differences between jQuery
versions?
rf
> It was recently opined here that upgrading a complex, interdependent
> script like jQuery
Do we really need any more shit about jQuery here?
It's a dog. Let it die.
David Mark
> David Mark wrote:
> > It was recently opined here that upgrading a complex, interdependent
> > script like jQuery
>
> Do we really need any more shit about jQuery here?
I think this issue is about more than jQuery. Though, as is usually
the case, it is the poster child for futility.
>
> It's a dog. Let it die.
It is going to need some help. :)
Matt Kruse
> [snip more jQuery ramblings]
Your mantra is getting boring.
Once again, you toss out something to the effect of "look how stupid
these people are!" yet offer no real incite into the problem or the
solution.
Yet I'm kind of flattered that you seem to be following my posts about
jQuery. It's cute.
> Production apps are *never* designed to rely on such
> problematic measurements.
You are fortunate that you can stay within your box. Not all
developers work in that mode.
Matt Kruse
David Mark
> On Apr 12, 5:19 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > [snip more jQuery ramblings]
Ramblings?
>
> Your mantra is getting boring.
>
> Once again, you toss out something to the effect of "look how stupid
> these people are!" yet offer no real incite into the problem or the
> solution.
You don't pick up anything on a first read, do you? I offered insight
into several issues.
>
> Yet I'm kind of flattered that you seem to be following my posts about
> jQuery. It's cute.
I don't follow your posts. I searched for "jQuery", "offset" and
"bug."
>
> > Production apps are *never* designed to rely on such
> > problematic measurements.
>
> You are fortunate that you can stay within your box. Not all
> developers work in that mode.
I know. Some dumbshits would actually measure all the way to the top
of the HTML and then try to work backwards to the positioned body.
Some might even recommend such an approach to newcomers (possibly with
a version of a debunked script that they themselves haven't even
used.) Nothing surprises me anymore.
And, as you know, theirs looks suspiciously like my take, just years
too late. If I am the one who designed the box and I tell you the box
isn't worth getting into, what does that mean to you? Remember what I
said about browser sniffing, attributes vs. properties, etc.? Am I
wrong on this one or shouldn't you be listening?
David Mark
>
> > [snip more jQuery ramblings]
>
> Your mantra is getting boring.
>
> Once again, you toss out something to the effect of "look how stupid
> these people are!" yet offer no real incite into the problem or the
> solution.
>
Here's an incite (sic) for you:
New IE branch:
jQuery.fn.offset = function() {
if ( !this[0] ) return { top: 0, left: 0 };
if ( this[0] === this[0].ownerDocument.body ) return
jQuery.offset.bodyOffset( this[0] );
var box = this[0].getBoundingClientRect(), doc = this
[0].ownerDocument, body = doc.body, docElem = doc.documentElement,
clientTop = docElem.clientTop || body.clientTop || 0, clientLeft =
docElem.clientLeft || body.clientLeft || 0,
top = box.top + (self.pageYOffset || jQuery.boxModel &&
docElem.scrollTop || body.scrollTop ) - clientTop,
left = box.left + (self.pageXOffset || jQuery.boxModel &&
docElem.scrollLeft || body.scrollLeft) - clientLeft;
return { top: top, left: left };
};
Old IE branch:
var box = elem.getBoundingClientRect();
// Add the document scroll offsets
add(box.left + Math.max(doc.documentElement.scrollLeft,
doc.body.scrollLeft),
box.top + Math.max(doc.documentElement.scrollTop,
doc.body.scrollTop));
// IE adds the HTML element's border, by default it is medium which is
2px
// IE 6 and 7 quirks mode the border width is overwritable by the
following css html { border: 0; }
// IE 7 standards mode, the border is always 2px
// This border/offset is typically represented by the clientLeft and
clientTop properties
// However, in IE6 and 7 quirks mode the clientLeft and clientTop
properties are not updated when overwriting it via CSS
// Therefore this method will be off by 2px in IE while in quirksmode
add( -doc.documentElement.clientLeft, -
doc.documentElement.clientTop );
Beware of long comments like that. The line that follows is obviously
a mistake and was identified as such to John Resig (as you well
know.) This is the simplest of the two branches (obviously.) Care to
look at the other?
It has been changed (a year and a half later) along with virtually
everything else in this script (e.g. browser sniffing, attributes, XML
documents, etc.), with virtually no documentation of what has changed
and why. No innovation either, just lots of undocumented changes.
Most apps, widgets, etc. didn't need an absolute position function and
there were much better ones written in 2003 (certainly ones that would
work in IE quirks mode!) What possessed you to recommend this re-
imagining, which you have never installed? It's called "jQuery?"
Lawrence Krubner
My sense is that JQuery is growing in popularity. I recall 3 years ago
my graphic designer friends were trying to figure out how to use
prototype/scriptaculous so they could get cool visual transitions into
their pages without having to use Flash. But at some point in the last
18 months, it seems to me there has been some kind of mass conversion
to JQuery. In 2006 I got a lot of phone calls that went "Hey, I can't
get scriptaculous to work, can you help me?" but nowadays it is always
"Hey, I can't get jQuery to work, can you help me?"
Consider what Shelly Powers writes in her 2007 book, Adding Ajax. This
is from page 93:
"One library that's gaining popularity is jQuery, available at
http://jquery.com. It's small, fast, and provides fundamental cross-
browser methods to work with the DOM rather than higher-order effects.
The Interface library, found at http://interface.eyecon.ro, provides
higher-order effects for jQuery, similar to what script.aculo.us
provides for Prototype.
...jQuery provides a high degree of chainability, which is the ability
to chain function calls, one after the other. This type of
functionality requires that the library object methods return a
reference to the object itself, which is used in the next method in
the chain. Creating effects using jQuery is greatly simplified because
of this chaining."
So long as jQuery continues to get favorable press, such as this, I
suspect its popularity will continue to climb. Especially when the
favorable coverage is coming from a respected publishing house such as
O'Reilly.
Lawrence Krubner
> On Apr 12, 6:32 am, "rf" <r...@z.invalid> wrote:
>
> > David Mark wrote:
> > > It was recently opined here that upgrading a complex, interdependent
> > > script like jQuery
>
> > Do we really need any more shit about jQuery here?
>
> I think this issue is about more than jQuery. Though, as is usually
> the case, it is the poster child for futility.
Surely you are smart enough to understand the rich irony of attacking
"futility" when you are using the newsgroup comp.lang.javascript to
gripe about a library that is getting favorable coverage from major
publishing houses and from the magazines that graphic designers read?
Take, for instance, this article in Smashing Magazine:
http://www.smashingmagazine.com/2009/01/15/45-new-jquery-techniques-for-a-good-user-experience/
At least in my world, the adoption of jQuery is being driven by
graphic designers who want to get cool visual effects on to their web
pages, but without using Flash. And the designers I know read sites
like Smashing Magazine, rather than comp.lang.javascript
The other thing driving the adoption of jQuery is its use in themes
that then become inspirations for other themes. Consider this post by
Darren Hoyt:
http://www.darrenhoyt.com/2008/09/14/notes-on-the-agregado-theme/
"We did run into some trouble here: for the jQuery bit to work, each
<a> tag in the nav needed a class of “trigger”, but wp_list_categories
only attaches a class to the <li>. So Matt was able to use a bit of
jQuery magic to dynamically add the class, although it’s not visible
in the source code unless you’re inspecting with a tool like Firebug.
It was cool to see how that was done and it’s already inspired a
couple more ideas for future themes."
Thousands of designers look to Hoyt's work for inspiration, so the
fact that Hoyt is using jQuery validates the decision to use jQuery in
the minds of all the designers who are imitating him.
David Mark
> On Apr 12, 6:32 am, "rf" <r...@z.invalid> wrote:
>
> > David Mark wrote:
> > > It was recently opined here that upgrading a complex, interdependent
> > > script like jQuery
>
> > Do we really need any more shit about jQuery here?
>
> > It's a dog. Let it die.
>
> My sense is that JQuery is growing in popularity. I recall 3 years ago
Has grown. Is at the apex of its absurdity. In short, jQuery claims
to be "Write Less. Do More." I say, even if it was, it pales in
comparison with "Write Once. Do Nothing." jQuery is introducing
"overhauls" in the year 2009 on issues that were settled in 2001,
still doesn't have them right (as evidenced by the disruption in
upgrading the script and/or its dependencies) and the authors do not
appear to understand most of the issues anyway.
> my graphic designer friends were trying to figure out how to use
> prototype/scriptaculous so they could get cool visual transitions into
Your graphic designer friends shouldn't play with browser scripting.
> their pages without having to use Flash. But at some point in the last
Admirable ambition. Of course, they likely shouldn't play with Flash
either (usually involves Other People's Scripts.)
> 18 months, it seems to me there has been some kind of mass conversion
> to JQuery. In 2006 I got a lot of phone calls that went "Hey, I can't
> get scriptaculous to work, can you help me?" but nowadays it is always
> "Hey, I can't get jQuery to work, can you help me?"
Prototype died out. jQuery is next. That's what happens to bad
ideas.
>
> Consider what Shelly Powers writes in her 2007 book, Adding Ajax. This
> is from page 93:
Who?
>
> "One library that's gaining popularity is jQuery, available athttp://jquery.com. It's small, fast, and provides fundamental cross-
> browser methods to work with the DOM rather than higher-order effects.
Small is relative. So is fast. Compared to any context-specific
solution, jQuery is bloated and slow. No app actually needs to query
by all of those selectors, set attributes directly, calculate absolute
positions on arrays of elements, XML and HTML alike, etc. Certainly
no app needs to do all of those things that slowly, that expensively
and that *badly*.
Cross-browser? Not even close. With the rate that jQuery apps rot,
tickets ripen on the vine and the list of supported browsers shortens,
it won't be long before every supported browser will have QSA and
animations built-in. So it is a multi-browser mechanical Turk, manned
by neophytes with features rapidly approaching superfluous.
Even worse, as we have seen, the miserable thing introduced its own
list of jQuery quirks and incompatibilities, negating the recent
stability among the quasi-standards-based browsers and somehow failing
to grasp basic issues present in IE6/7 prior to the release of IE8.
Shelly shouldn't write books about browser scripting.
>
> The Interface library, found athttp://interface.eyecon.ro, provides
> higher-order effects for jQuery, similar to what script.aculo.us
> provides for Prototype.
Who cares?
>
> ...jQuery provides a high degree of chainability, which is the ability
> to chain function calls, one after the other. This type of
> functionality requires that the library object methods return a
> reference to the object itself, which is used in the next method in
> the chain. Creating effects using jQuery is greatly simplified because
> of this chaining."
The chaining strategy is completely idiotic and ill-advised
(especially for beginners.) It requires the use of a debugger in IE
and, as we have seen, such debuggers are not even in use by the jQuery
developers.
Still, any object method can be chained in Javascript, they just have
to:
return this;
That's it. It's stupid. Don't do it. Doesn't matter if it is the
primary allure of a terrible script that has Shelly and others under
its spell. It is still a terrible idea.
>
> So long as jQuery continues to get favorable press, such as this, I
From Shelly? I wouldn't listen to her.
> suspect its popularity will continue to climb. Especially when the
> favorable coverage is coming from a respected publishing house such as
> O'Reilly.
Have to talk to them.
Garrett Smith
> On Apr 12, 9:41 am, Matt Kruse <m...@thekrusefamily.com> wrote:
>> On Apr 12, 5:19 am, David Mark <dmark.cins...@gmail.com> wrote:
>>
[...]
>
> I know. Some dumbshits would actually measure all the way to the top
> of the HTML and then try to work backwards to the positioned body.
> Some might even recommend such an approach to newcomers (possibly with
> a version of a debunked script that they themselves haven't even
> used.) Nothing surprises me anymore.
>
> And, as you know, theirs looks suspiciously like my take, just years
> too late. If I am the one who designed the box and I tell you the box
> isn't worth getting into, what does that mean to you? Remember what I
> said about browser sniffing, attributes vs. properties, etc.? Am I
> wrong on this one or shouldn't you be listening?
What I understand you are saying is that the jQuery offsets plugin was
inspired by code you wrote. Did I get that right?
If I understand you correctly: Why do you think so?
Garrett
David Mark
What plugin? I am talking about the offset function in the jQuery
script.
>
> If I understand you correctly: Why do you think so?
>
It is obvious.
Garrett Smith
Her book is full of the most outlandish factual falsehoods.
Aside from that, I can't even agree with general opinion, either.
| In an ideal world, everyone who visits your website would use the same
| type of operating system and browser and would have JavaScript
| enabled. Your site would never be acessed via a mobile phone...
Can't agree at all! I'm a NoScript user. I like using different browsers
and OS's.
Garrett
Garrett Smith
Apparently, according to you, it is not obvious that we are talking
about the same thing.
In fact, we are talking about the same thing. jquery offset was a plugin
before it became part of core. Calling jQuery.fn.offset a "plugin" was
not the best way to communicate what I was talking about.
SO. Now that we're clear on that, please clarify if it is in fact your
claim that the jQuery offset plugin was inspired by your code and if it
is your claim, then please explain.
Garrett
Lawrence Krubner
There is a strange kind of unreality haunting this newsgroup. The
attitude seems to be "I don't want people to use these libraries, so I
will close my eyes and cover my ears and say nyah nyah nyah nyah until
people stop using them."
When I say I'm getting more requests for help from designers who are
using jQuery, I'm simply reporting what has actually happened.
David Mark
Yes, how is that the "ideal" world? I'm sure Shelly goes on to
explain how the "real" world is very scary, jQuery is your friend,
etc.
Amazing how so many books became instantly obsolete on this latest
rewrite. All of those plugins that are breaking were obviously based
on examples from books like this. Now that everything has changed
(again), I guess you have to buy the revised editions.
As for the browsers, I don't know what phone Shelly is using, but most
have decent browsers now. Of course, most don't work very well (if at
all) with jQuery. :(
And why should I care if an end-user disables scripting? Though I
suppose for jQuery users, disabled scripting is a leg up.
Lawrence Krubner
Lawrence Krubner
>
> > On Apr 12, 6:32 am, "rf" <r...@z.invalid> wrote:
>
> > > David Mark wrote:
> > > > It was recently opined here that upgrading a complex, interdependent
> > > > script like jQuery
>
> > > Do we really need any more shit about jQuery here?
>
> > > It's a dog. Let it die.
>
> > My sense is that JQuery is growing in popularity. I recall 3 years ago
>
> Has grown. Is at the apex of its absurdity. In short, jQuery claims
> to be "Write Less. Do More." I say, even if it was, it pales in
> comparison with "Write Once. Do Nothing." jQuery is introducing
> "overhauls" in the year 2009 on issues that were settled in 2001,
> still doesn't have them right (as evidenced by the disruption in
> upgrading the script and/or its dependencies) and the authors do not
> appear to understand most of the issues anyway.
>
> > my graphic designer friends were trying to figure out how to use
> > prototype/scriptaculous so they could get cool visual transitions into
>
> Your graphic designer friends shouldn't play with browser scripting.
No doubt no one should write a line of code, even in a light weight
scripting language, until they have completed their Ph.d in computer
science at Stanford, yet in the real world, people often do write code
before their Ph.d is complete.
David Mark
I only know of one thing and that is what I was talking about. I
assumed you were talking about something else.
>
> In fact, we are talking about the same thing. jquery offset was a plugin
> before it became part of core. Calling jQuery.fn.offset a "plugin" was
> not the best way to communicate what I was talking about.
Okay.
>
> SO. Now that we're clear on that, please clarify if it is in fact your
> claim that the jQuery offset plugin was inspired by your code and if it
> is your claim, then please explain.
We've been over this ad nauseum. The original offset code was all
browser sniffing. God only knows what "inspired" that mish-mash. I
don't care to go over this endlessly, but this is yet another function
critiqued in the Fall of 2007. A couple of months after that, we (you
included) had a long talk about these absolute positioning functions,
including discussions of the one in my library. I've since seen
similar code pop up in other absolute positioning functions, including
jQuery's latest stab. I've seen Resig refer to the feature testing
technique as "detect and inject." Of course, he had it backwards.
Sample from jQuery offset circa October 2007:
// Mozilla and Safari > 2 does not include the border on offset
parents
// However Mozilla adds the border for table or table cells
if ( mozilla && !/^t(able|d|h)$/i.test(offsetParent.tagName) || safari
&& !safari2 )
border( offsetParent );
if ( jQuery.offset.doesNotAddBorder && !
(jQuery.offset.doesAddBorderForTableAndCells && /^t(able|d|h)$/i.test
(elem.tagName)) )
top += parseInt( computedStyle.borderTopWidth, 10) || 0,
left += parseInt( computedStyle.borderLeftWidth, 10) || 0;
Those long-winded offset.* properties are figured by styling and
injecting created DIV's and then measuring their computed styles
against expected outcomes. My last (and most absurdly unneeded)
version of this function, which had evolved since before the turn of
the century, did the same thing in the same way with similarly named
variables. Why they are exposing these properties to outside
intervention is anyone's guess though.
So mine was published in February of last year. It was discussed here
and certainly compared to jQuery at some point. In fact, this is one
of the functions that Matt Kruse kept demanding that I publish to
"prove" that I could write better code than Resig (as if that
mattered.) Resig himself asked where my version of this was when I
first panned his script. You think he suddenly lost interest two
months later? Another demand was the also unneeded getAttribute
wrapper, which was apparently less than inspirational.
The jQuery people are known to read this group and are certainly not
unfamiliar with my criticism. I suppose it is possible that some
third party was inspired, making this an indirect homage.
SO, there you go.
[snip]
David Mark
There's that "real world" again. In this world, do all programmers
have advanced degrees from Stanford? Regardless, it is a fact that
most people who play with Javascript are ill-advised to do so.
Furthermore, most Websites are degraded, rather than enhanced by
browser scripting. In extreme cases, perfectly good documents are
rendered unusable. Why should a graphic designer want to do something
like that?
Lawrence Krubner
Good designers build usable sites that degrade gracefully. Bad
designers build sites that are unusable for a significant portion of
the people who visit their sites. Good designers, such as Darren Hoyt
(darrenhoyt.com) insist on valid markup, clean CSS, minimal HTML and
Javascript that enhances a site, but which in no way limits the use of
the site. And Darren Hoyt uses jQuery in the themes that he builds.
And the designers who imitate him probably do as well.
Lawrence Krubner
> Those long-winded offset.* properties are figured by styling and
> injecting created DIV's and then measuring their computed styles
> against expected outcomes. My last (and most absurdly unneeded)
> version of this function, which had evolved since before the turn of
> the century, did the same thing in the same way with similarly named
> variables. Why they are exposing these properties to outside
> intervention is anyone's guess though.
>
> So mine was published in February of last year. It was discussed here
> and certainly compared to jQuery at some point. In fact, this is one
> of the functions that Matt Kruse kept demanding that I publish to
> "prove" that I could write better code than Resig (as if that
> mattered.) Resig himself asked where my version of this was when I
> first panned his script. You think he suddenly lost interest two
> months later? Another demand was the also unneeded getAttribute
> wrapper, which was apparently less than inspirational.
Why don't you just publish your scripts as a library then? If people
like your ideas, then your library will become popular. There is a lot
of competition out there, among the various libraries. The good rises
to the top. Surely offering something to the public would be more
useful than griping about other people's work? How much of your life
do you really want to spend posting to comp.lang.javascript, ranting
about the degree to which your ideas are better than everyone else's?
David Mark
Right. Not sites that break after a year or two, unless you exchange
a complicated, interdependent blob of Javascript, most of which was
probably unused.
> designers build sites that are unusable for a significant portion of
> the people who visit their sites.
Correct.
> Good designers, such as Darren Hoyt
Who?
> (darrenhoyt.com) insist on valid markup, clean CSS, minimal HTML and
Whatever.
> Javascript that enhances a site, but which in no way limits the use of
> the site. And Darren Hoyt uses jQuery in the themes that he builds.
> And the designers who imitate him probably do as well.
And therein lies the rub. Valid markup, clean CSS, minimal HTML
(semantic?), etc. is how you build a proper document. You don't
slather jQuery all over it as it will break it for lots of people
immediately and slowly approach unusable for all.
Think of each version of jQuery as a time capsule for John Resig's
misconceptions. If you write stuff on top of it and then have to swap
the whole thing for another collection of misconceptions, chances are
that your stuff is going to break. Unit testing is an expensive
process, so what sort of strategy is that?
As for Mr. Hoyt. His site has a big old horizontal scroll bar at 800
x 600 and uses XHTML transitional markup (of course.) He's living in
the year 2000, just like Resig. Who told you he was a "good designer?"
David Mark
Interesting take. Of course, it is the exact opposite of reality.
The reality is that lots of people are listening intently, including
the authors of the libraries, book publishers, Web startups, etc.
>
> When I say I'm getting more requests for help from designers who are
> using jQuery, I'm simply reporting what has actually happened.
We know the history. Thanks.
David Mark
- Matt Kruse, October 2007
Or was that not a direct quote?
> like your ideas, then your library will become popular. There is a lot
I don't want my library to become popular. You clearly haven't read
my thoughts on browser scripting in general.
> of competition out there, among the various libraries. The good rises
> to the top. Surely offering something to the public would be more
> useful than griping about other people's work?
Kruse again? Or are you serious? Okay, the next steps are:
1. Wait until I publish what you are after (already happened)
2. Disappear for a year or so
3. Come back and start the whole damned conversation over again
> How much of your life
> do you really want to spend posting to comp.lang.javascript, ranting
> about the degree to which your ideas are better than everyone else's?
You clearly haven't read too many of my posts (or anything else I have
published.) You should read first, write second.
Osmo Saarikumpu
> There is a strange kind of unreality haunting this newsgroup.
We don't think so :)
> When I say I'm getting more requests for help from designers who are
> using jQuery, I'm simply reporting what has actually happened.
I guess you just made somebody's point there? If it was such a
cool-crosbrowser-library why would them deezigners need your help?
Best wishes,
Osmo
Lawrence Krubner
This is intellectually lazy on your part. You could have just as
easily asked "What makes these scripts so popular with designers?"
Or ever better: "Why do graphic designers use these pre-package
scripts? Why don't they write their own code from scratch?"
David Mark
> On Apr 12, 5:33 pm, Osmo Saarikumpu <o...@weppipakki.com> wrote:
>
> > Lawrence Krubner wrote:
> > > There is a strange kind of unreality haunting this newsgroup.
>
> > We don't think so :)
>
> > > When I say I'm getting more requests for help from designers who are
> > > using jQuery, I'm simply reporting what has actually happened.
>
> > I guess you just made somebody's point there? If it was such a
> > cool-crosbrowser-library why would them deezigners need your help?
>
> This is intellectually lazy on your part. You could have just as
> easily asked "What makes these scripts so popular with designers?"
Most Web designers are incompetent (including your jQuery-propagating
idol.) Anyone who has spent even a minute on the Web knows that.
>
> Or ever better: "Why do graphic designers use these pre-package
> scripts? Why don't they write their own code from scratch?"
AFAIK, nobody here has ever said anything about writing all of your
own code from scratch, yet it is invariably the first rhetorical
question out of the gate from every doubting neophyte that shows up.
Where do you get that?
Osmo Saarikumpu
> This is intellectually lazy on your part.
Must be, 'cause I still can't see much light in your argument. I have no
interst in any JS library. Thus, I'm not driven by affections, either way.
> You could have just as
> easily asked "What makes these scripts so popular with designers?"
I fail to see how this question would change anything. Isn't it a
classic example of ad populum?
> Or ever better: "Why do graphic designers use these pre-package
> scripts? Why don't they write their own code from scratch?"
Or: why do flies like shit? Why don't they fancy veggies?
I guess that the intelectually lazy would answer: because they do not
know better && because they can't. I'm sorry, but at least in my lazy
eyes, you are majoring in making points hindering your position.
Best wishes,
Osmo
Eric Bednarz
> This is intellectually lazy on your part. You could have just as
> easily asked "What makes these scripts so popular with designers?"
Because they are graphic (I suppose you mean) designers, so they
a) don’t understand any of the problems and cannot judge its quality
b) the API will likely appeal to them because they are not programmers
> Or ever better: "Why do graphic designers use these pre-package
> scripts?
Are you seriously thinking that there is a relation between success and
quality (in any field)?
> Why don't they write their own code from scratch?"
Eyeroll. Speaking about lazy, you haven’t been lurking here, right?
Something you missed that you could just as easily have asked is:
“What idiot would assign programming tasks to designers?”
IMO it is fair to say that jQuery is to javascript what Frontpage
Express was to HTML. :-)
Lawrence Krubner
> Lawrence Krubner <lkrub...@geocities.com> writes:
> > This is intellectually lazy on your part. You could have just as
> > easily asked "What makes these scripts so popular with designers?"
>
> Because they are graphic (I suppose you mean) designers, so they
> a) don’t understand any of the problems and cannot judge its quality
> b) the API will likely appeal to them because they are not programmers
>
> > Or ever better: "Why do graphic designers use these pre-package
> > scripts?
>
> Are you seriously thinking that there is a relation between success and
> quality (in any field)?
>
> > Why don't they write their own code from scratch?"
>
> Eyeroll. Speaking about lazy, you haven’t been lurking here, right?
>
> Something you missed that you could just as easily have asked is:
> “What idiot would assign programming tasks to designers?”
That's just it. These pre-packaged scripts allow designers to get a
wide variety of effects without having to learn how to program. The
market demand for these scripts is exactly that they enable designers
to do something new, without necessitating their spending time
learning a new skill. This is something you could easily figure out
for yourself. The people on this newsgroup seem intelligent, so if
they are unable to figure out something so obvious, then they are
being deliberately obtuse.
Lawrence Krubner
David, you've a remarkably poor memory. Just earlier today you wrote:
"Compared to any context-specific solution, jQuery is bloated and
slow."
Check it out, you can read your own words here:
http://groups.google.com/group/comp.lang.javascript/msg/dc9b78773cf5b7db
David Mark
It isn't meant to be a brain-teaser. People do crazy things. Like
supposing that learning jQuery requires no time. As we've seen, the
maintenance alone will kill you. It's far more volatile than the
browsers it tries to abstract.
David Mark
> On Apr 12, 5:58 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Apr 12, 5:48 pm, Lawrence Krubner <lkrub...@geocities.com> wrote:
>
> > AFAIK, nobody here has ever said anything about writing all of your
> > own code from scratch, yet it is invariably the first rhetorical
> > question out of the gate from every doubting neophyte that shows up.
> > Where do you get that?
>
> David, you've a remarkably poor memory. Just earlier today you wrote:
>
> "Compared to any context-specific solution, jQuery is bloated and
> slow."
I remember that like it was yesterday.
>
> Check it out, you can read your own words here:
>
> http://groups.google.com/group/comp.lang.javascript/msg/dc9b78773cf5b7db
Why? Certainly I said nothing about writing everything from scratch.
I think I am starting to see where this is coming from.
Eric Bednarz
> That's just it. These pre-packaged scripts allow designers to get a
> wide variety of effects without having to learn how to program.
Who are those “graphic designers” I keep hearing about, as if it were a
real profession that needs trained individuals? Pushing pixels across
the screen is a matter of having the right software installed and
pressing some buttons (I foresee great entertainment value here).
> The
> market demand for these scripts is exactly that they enable designers
> to do something new,
Huh? How do you something new with pre-packaged effects? You will be
happy to learn that unlike David, the cheap cheesy message of
e.g. prototype/ligthbox usage offends me more than its code base.
> without necessitating their spending time
> learning a new skill.
This brings up a good point. I actually think there is a big market for
this stuff, the rent-a-ninja-online business for clients who want a
funky website without necessitating their spending money on people who
charge for skills. That makes sense to me.
Garrett Smith
> Lawrence Krubner <lkru...@geocities.com> writes:
>
>> This is intellectually lazy on your part. You could have just as
>> easily asked "What makes these scripts so popular with designers?"
>
> Because they are graphic (I suppose you mean) designers, so they
> a) don’t understand any of the problems and cannot judge its quality
> b) the API will likely appeal to them because they are not programmers
>
>> Or ever better: "Why do graphic designers use these pre-package
>> scripts?
>
> Are you seriously thinking that there is a relation between success and
> quality (in any field)?
>
What does "success" mean to you?
Garrett
Gregor Kofler
> These pre-packaged scripts allow designers to get a wide
> variety of effects without having to learn how to program.
No, that's /the/ misconception.
According to your logic graphics designers are supposed to congratulate
me upon my decision to use one of those fancy predefined webpage
templates, because it enables me to do "professional layouts" without
having to learn the basics of design. (Who cares if colors of fonts don't
match the chosen template, or the template doesn't match the CD of the
customer.)
Gregor
--
http://www.gregorkofler.com
http://web.gregorkofler.com - vxJS, a JS lib in progress
Gregor Kofler
[snip]
> Why don't you just publish your scripts as a library then?
Yawn... The usual implied "if you can't do better, stop critizing". Apart
from that you *can* download Mark's scripts. But then: Are you capable of
assessing the code quality?
beegee
> That's just it. These pre-packaged scripts allow designers to get a
> wide variety of effects without having to learn how to program. The
> market demand for these scripts is exactly that they enable designers
> to do something new, without necessitating their spending time
> learning a new skill. This is something you could easily figure out
> for yourself. The people on this newsgroup seem intelligent, so if
> they are unable to figure out something so obvious, then they are
> being deliberately obtuse.
I guess. I also guess that programmers, not designers will end up
doing the maintenance on most of these sites (that is, if the site
does anything besides look pretty). I think a lot of companies who
follow the pack fail to understand what the "big boys" are really
doing. They are not hiring designers to code the front end. They
hire designers to design the front end and programmers to code it. If
production of web sites was truly designer driven then what you say
might be true but all you need to do is look at the sites linked to by
Smashing magazine to see a certain low-level of functionality common
to most (though I personally really like looking at them).
Those of us who fear having to maintain sites coded with jQuery have
more to fear from back end javascript generators like Rails
(prototype) and Microsoft MVC (jQuery). Those systems spit out
unreadable javascript at an alarming rate.
Bob
David Mark
> Lawrence Krubner <lkrub...@geocities.com> writes:
> > That's just it. These pre-packaged scripts allow designers to get a
> > wide variety of effects without having to learn how to program.
>
> Who are those “graphic designers” I keep hearing about, as if it were a
> real profession that needs trained individuals? Pushing pixels across
> the screen is a matter of having the right software installed and
> pressing some buttons (I foresee great entertainment value here).
>
> > The
> > market demand for these scripts is exactly that they enable designers
> > to do something new,
>
> Huh? How do you something new with pre-packaged effects? You will be
> happy to learn that unlike David, the cheap cheesy message of
> e.g. prototype/ligthbox usage offends me more than its code base.
I hate them just as much in the end-user role. You ought to see this
YUI-based monstrosity I was just dealing with. I love it when prats
decide they just have to have a "lightbox" and proceed to wreck an
otherwise useful document. The most outrageous examples (e.g.
Reddit's login) render critical UI elements off-screen and make it
impossible to scroll them into view. I don't bother complaining about
these things (who does?) as some fool on the other end will just
respond with drivel about "edge cases" and all of the great feedback
they get from their users. (!)
When you write this stuff, it makes it all the more aggravating when
some neophyte who wants to add jQuery or YUI or whatever to their
profile causes you to lose the form you just filled out, breaks your
browser, opens 30 HTTP connections on every navigation, etc. I have
really come to hate the Web lately.
My technical criticism is not just about code quality either. The
whole idea (a large, generalized solution for all browser scripting
occasions) was a foolish one. This is perhaps one of the worst trends
in software history and it couldn't come at a worse time for the Web
(browsers were finally starting to settle down and act alike.) For
most of the last decade, IE has been a constant, yet people are
rushing to adopt a script that is still mystified by things like
quirks mode. Ironically, it is often served with transitional XHTML,
which is completely incompatible with the script (not to mention IE.)
If there are two things you don't bet on at this point, they are John
Resig and HTML error correction.
[snip]
David Mark
> Lawrence Krubner <lkrub...@geocities.com> writes:
> > This is intellectually lazy on your part. You could have just as
> > easily asked "What makes these scripts so popular with designers?"
>
> Because they are graphic (I suppose you mean) designers, so they
> a) don’t understand any of the problems and cannot judge its quality
> b) the API will likely appeal to them because they are not programmers
>
> > Or ever better: "Why do graphic designers use these pre-package
> > scripts?
>
> Are you seriously thinking that there is a relation between success and
> quality (in any field)?
>
> > Why don't they write their own code from scratch?"
>
> Eyeroll. Speaking about lazy, you haven’t been lurking here, right?
My favorite is "Why don't you write all of your sites in
assembler?!!!" This is usually parroted by people who have no idea
what assembly language is (they just thought it sounded like a geek-
chic thing to say.)
>
> Something you missed that you could just as easily have asked is:
> “What idiot would assign programming tasks to designers?”
Lots of them, but fewer now than three months back.
>
> IMO it is fair to say that jQuery is to javascript what Frontpage
> Express was to HTML. :-)
I always hear that jQuery is to Javascript as C is to assembler.
Kernighan, Ritchie and... Resig? Doesn't quite fit does it?
http://groups.google.com/group/jquery-en/browse_thread/thread/ee5b53d4982aefb5
How can it take so much work to be so utterly incompetent? These
people are too busy writing to stop and read anything.
Matt Kruse
> http://groups.google.com/group/jquery-en/browse_thread/thread/ee5b53d...
> How can it take so much work to be so utterly incompetent? These
> people are too busy writing to stop and read anything.
I just think it shows that people using jQuery are not usually hard-
core programmers, and quite often not very familiar with javascript.
People get confused. It's allowed in life.
See, jQuery exists to fill a need that you (and many here) do not
have. That is, to provide an API that more closely matches what the
user is trying to accomplish and to implement it in the best possible
(although often not ideal) way. Setting obj.style.display="block" may
be obvious to you, but $(obj).show() is way more obvious to someone
new to scripting or who doesn't have a lot of time to invest in
getting this part correct. You already understand the problem. jQuery
is not trying to help you. Move on.
This is the point that has been and will continue to be lost on you.
jQuery solves a problem that you don't have. jQuery does not solve the
problems that you do have. Therefore, you shouldn't use jQuery. Easy!
But no matter how much it may annoy you, people want to abstract
browser scripting and not worry about the details. THAT is the problem
that jQuery is trying to solve. For someone making a page for their
child's basketball team without much experience in web development, a
library like jQuery will allow them to add some animations, maybe make
some tabs, perhaps even show pictures in a little "lightbox" that
impresses all the other parents. Good for them! They don't care about
browser compatibility, attributes, offset bodies, or browser sniffing.
All they care about is making something kind of spiffy and fun, and it
works. Were it not for libraries like jQuery, learning about the DOM
and CSS and cross-browser scripting would be out of their reach.
jQuery brings web development to the masses. That's why it's
successful.
"But look at its technical flaws!" you keep yelling to the empty
streets.
So? That is not the criteria on which it is being judged! Maybe by
you, yes. But that's why you despise it. Others don't care as much
about that (if at all) and instead are judging it on factors that you
care nothing about.
But you are still so fixated on your view of the problem that you lack
the ability to see it from another's perspective. You cannot seem to
comprehend how someone would willingly and knowingly accept a solution
that has technical faults, yet you surely do it every day as well -
just in areas that you are not a knowledgeable expert. Surely the
arrogant experts in those areas must laugh at you as well, call you
stupid, and wonder how anyone could be so ridiculous as to make the
choices that you do.
You read a thread where clearly someone is confused and needs
guidance, you re-post it to another group as an example of stupidity,
then call the people utterly incompetent. Rather than taking 1 minute
of your time to help another fellow human being out with even the
slightest bit of wisdom (since you were obviously reading the thread
anyway). See, that pretty much _defines_ an arrogant asshole. And
that's why it's so easy for so many people to just ignore you.
Matt Kruse
David Mark
> On Apr 13, 5:33 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> >http://groups.google.com/group/jquery-en/browse_thread/thread/ee5b53d...
> > How can it take so much work to be so utterly incompetent? These
> > people are too busy writing to stop and read anything.
>
> I just think it shows that people using jQuery are not usually hard-
> core programmers, and quite often not very familiar with javascript.
> People get confused. It's allowed in life.
I think that a collection of ostensible jQuery experts put their heads
together to solve a trivial browser scripting problem with their
favorite tool and turned it into a Chinese fire drill. The solution
that was ultimately recommended was a ridiculous end-around for a
script that is obviously just getting in the way. Did you see all of
those attr calls?
So much for the large and active developer community argument. These
discussions are taking place a week *after* I spelled out their
glaring, ten years too late oversight regarding the attr method. This
is one of many examples posted recently indicating that jQuery over-
complicates and even outright prevents the simplest of operations due
to abject incompetence. If that wasn't enough, the misconceptions are
ever-shifting, so it is as I once heard another disastrous API
(Windows) described, like stapling Jello.
>
> See, jQuery exists to fill a need that you (and many here) do not
> have. That is, to provide an API that more closely matches what the
> user is trying to accomplish and to implement it in the best possible
> (although often not ideal) way.
Your mind's gone. We aren't talking about anything close to
idealism. We are talking outright failures, maddening misconceptions
and near-constant upgrades of a script that is now almost completely
superfluous (they lopped off too many supported browsers for their own
good.)
> Setting obj.style.display="block" may
> be obvious to you, but $(obj).show() is way more obvious to someone
> new to scripting or who doesn't have a lot of time to invest in
> getting this part correct.
Who conducted that study? Dot notation, assignment and display style
rules are pretty easy concepts to grasp. jQuery or no jQuery, anyone
scripting a Website needs those concepts, just as they need to know
the difference between attributes and properties. The jQuery example
makes obj look like a variable, also uses dot notation and throws in a
method call. There's no telling exactly what that line of code will
do without delving into the show method.
show: function(speed,callback){
if ( speed ) {
return this.animate( genFx("show", 3), speed, callback);
} else {
for ( var i = 0, l = this.length; i < l; i++ ){
var old = jQuery.data(this[i], "olddisplay");
this[i].style.display = old || "";
if ( jQuery.css(this[i], "display") === "none" ) {
var tagName = this[i].tagName, display;
if ( elemdisplay[ tagName ] ) {
display = elemdisplay[ tagName ];
} else {
var elem = jQuery("<" + tagName + " />").appendTo("body");
display = elem.css("display");
if ( display === "none" )
display = "block";
elem.remove();
elemdisplay[ tagName ] = display;
}
jQuery.data(this[i], "olddisplay", display);
}
}
// Set the display of the elements in a second loop
// to avoid the constant reflow
for ( var i = 0, l = this.length; i < l; i++ ){
this[i].style.display = jQuery.data(this[i], "olddisplay") || "";
}
return this;
}
},
So much for symmetry. I find the comment about reflows very
interesting. Of course, reflows are another awful side-effect of
jQuery-speak.
> You already understand the problem. jQuery
> is not trying to help you. Move on.
obj.style.display="block";
Read it again. Why is that a problem? Works in virtually anything.
Want to know for sure if it will?
if (typeof obj.style.display == 'string') {
...
}
Sadly, that logic could have made for a useful "show" function. As it
is, it is just one more bizarre strand of code from the latest capsule
of wasted time. As such, it is guaranteed to change over time,
changing the meaning of code foolish enough to call the jQuery show
method, rather than setting a property.
And half the jQuery people are now doing this:
jQuery(obj).show();
Concise? Easy to understand?
We've constructor that starts with a lowercase letter, a hundred
function calls (at least), one of which could have been avoided by
including the new operator and code that over-complicates and obscures
the meaning of a very basic operation.
>
> This is the point that has been and will continue to be lost on you.
You have no point. A script that manages to get in the way of finding
an element by ID in an XHR response, setting properties of DOM nodes,
positioning in IE quirks mode, etc. and manages to fumble around with
such basic operations for *three years*, during which time browsers
changed very little, is not progress. It's not helping *anyone*.
That's why the Web is such a mess.
> jQuery solves a problem that you don't have. jQuery does not solve the
> problems that you do have. Therefore, you shouldn't use jQuery. Easy!
It solves no problems, the support people have no idea how to make it
solve problems and the developers are obviously asleep. Are you
really still here recommending this to... anyone? Last I recall, your
list of stipulations and exclusions was growing rapidly and you had
admitted that you used a patched version of the thing.
>
> But no matter how much it may annoy you, people want to abstract
> browser scripting and not worry about the details. THAT is the problem
> that jQuery is trying to solve. For someone making a page for their
> child's basketball team without much experience in web development, a
> library like jQuery will allow them to add some animations, maybe make
> some tabs, perhaps even show pictures in a little "lightbox" that
> impresses all the other parents. Good for them! They don't care about
Unless they are blind, spastic, use mobile devices, hate Javascript,
use older browsers, use new browsers, etc., etc.
But I am willing to stipulate that such a trivial vanity page may be
the only justification for such a script. It's like using AOL's
builders to create a home page.
> browser compatibility, attributes, offset bodies, or browser sniffing.
But see, those things are going to get fouled up for them anyway. The
point is that scripts that don't work result in pages that don't
function as intended. That miserable "lightbox" you propose is
impossible to do properly with jQuery as there is no mechanism for
progressive enhancement. It's a can of blunders.
> All they care about is making something kind of spiffy and fun, and it
> works.
That "it works" line really irritates me. Works in what for whom? I
bet some of those parents have jobs and use IE (hint.)
> Were it not for libraries like jQuery, learning about the DOM
> and CSS and cross-browser scripting would be out of their reach.
No, the browsers stabilized about the time Prototype and jQuery came
out. They are the wave of the past. Each build was another time
capsule, all done with mirrors (browser sniffing.) All a complete
waste of time. The resulting widespread ignorance is not a good thing
either (as evidenced here.)
> jQuery brings web development to the masses. That's why it's
> successful.
You sound like a TV commercial.
>
> "But look at its technical flaws!" you keep yelling to the empty
> streets.
Odd, seems a lot of people (particularly you) are listening. You feel
my influence on the browser scripting world is lacking? And, once
again, we are not talking about flaws here. Remember those Pintos
from the 70's that blew up on rear-impact collisions? That was a
technical flaw. If the car didn't drive at all, that would be
analogous to jQuery's integrity. The progress you think you see is
analogous to a projected image of a street scene viewed through the
window. Are you there yet?
>
> So? That is not the criteria on which it is being judged! Maybe by
> you, yes. But that's why you despise it. Others don't care as much
Despise it? I'd "despise" it only half as much if *you* would just
shut up about it. You do realize that in the larger scheme of things,
*you* dropped the ball on jQuery. I gave you the answers and your dog
ate them. Now, in 2009, you are back to argue the same nonsense? I
hate jQuery? I never tried to help jQuery? If you would spend half
the time fixing your favorite script as trying to convince everyone
that I am the problem, you'd have a lot more success.
> about that (if at all) and instead are judging it on factors that you
> care nothing about.
Misjudging it, based on misinformation.
>
> But you are still so fixated on your view of the problem that you lack
> the ability to see it from another's perspective. You cannot seem to
> comprehend how someone would willingly and knowingly accept a solution
> that has technical faults, yet you surely do it every day as well -
Again, these are not technical faults. These are the script tripping
over itself to make very simple operations into a nightmare.
> just in areas that you are not a knowledgeable expert. Surely the
> arrogant experts in those areas must laugh at you as well, call you
> stupid, and wonder how anyone could be so ridiculous as to make the
> choices that you do.
Where are you going with this?
>
> You read a thread where clearly someone is confused and needs
> guidance, you re-post it to another group as an example of stupidity,
Yes. I think it is a prime example of the absurdity of jQuery's two
biggest "selling points": support and documentation. It also
demonstrates that not only does jQuery confuse issues with HTML and
XHTML, but with XHR responses as well. That's quite a hat trick. All
of that flailing seems like a lot of work for something that is
supposed to make browser scripting easier. BTW, have you un-patched
and upgraded your version yet or are you still cool with the browser
sniffing? Most of those sniffs are for IE, IE8 is out and it is quite
unlike IE6/7 (which are still botched in the latest jQuery.)
> then call the people utterly incompetent. Rather than taking 1 minute
They are and they are your support. The Marx Brothers could have done
a better job on that one. Are these people even vaguely familiar with
the jQuery code? If not, what makes them so confident in it? I have
asked you that before, but didn't get a very good answer. You've got
to ask if these people are vaguely familiar with XHR, HTML, the DOM,
etc. What *do* these people know other than jQuery gibberish? What
is behind the gibberish? See the problem?
> of your time to help another fellow human being out with even the
OMFG. This one is in your lap. If you had paid the slightest
attention to what I said back in 2007, jQuery would have been fixed
(as much as it can be fixed) a long time ago. You dropped the ball.
And again, I am not a member of that group. You are, but you didn't
see fit to help out a fellow human being either. :( Better to come in
here and argue impossible points with me? How is that helping?
As usual, you are as hypocritical as you are annoying. How long are
you going to go on with this act?
> slightest bit of wisdom (since you were obviously reading the thread
> anyway). See, that pretty much _defines_ an arrogant asshole. And
> that's why it's so easy for so many people to just ignore you.
>
You know, that's the second time you've called me that. I think you
should cut your losses at this point. Don't you have something better
to do anyway?
Matt Kruse
> Dot notation, assignment and display style
> rules are pretty easy concepts to grasp. jQuery or no jQuery, anyone
> scripting a Website needs those concepts, just as they need to know
> the difference between attributes and properties.
Not necessarily.
> obj.style.display="block";
> Read it again. Why is that a problem? Works in virtually anything.
Well, obviously the code that is there is trying to correct for
different browsers using block, table-row, etc. A single show()
function tries to hide those implementation details from the
developer, so it "just works" in whatever case they use it in.
> > jQuery solves a problem that you don't have. jQuery does not solve the
> > problems that you do have. Therefore, you shouldn't use jQuery. Easy!
> It solves no problems
Obviously you are mistaken.
> But I am willing to stipulate that such a trivial vanity page may be
> the only justification for such a script.
Thank you.
> It's like using AOL's
> builders to create a home page.
Perhaps similar. Or FrontPage, or Dreamweaver, or Visual Basic, et al.
jQuery is entry-level javascript for the masses. And when used
appropriately, it works very well. When developers try to use it for
things beyond its capabilities (as is often the case), it fails. Just
as when you try to do a robust real-time app in VB, you will fail. But
if you want to make a quick app to gather basketball scores for your
league, VB might be quite sufficient. There is a sliding scale between
convenience and robustness.
> That miserable "lightbox" you propose is
> impossible to do properly with jQuery as there is no mechanism for
> progressive enhancement.
Who says that's a requirement?
> > jQuery brings web development to the masses. That's why it's
> > successful.
> You sound like a TV commercial.
I'm the ShamWow! guy.
> You do realize that in the larger scheme of things,
> *you* dropped the ball on jQuery.
Nah, I think I have a good perspective.
> I gave you the answers and your dog ate them.
Which one? I have three.
> BTW, have you un-patched
> and upgraded your version yet or are you still cool with the browser
> sniffing? Most of those sniffs are for IE, IE8 is out and it is quite
> unlike IE6/7 (which are still botched in the latest jQuery.)
I use jQuery mostly in IE6-only environments, so IE8 doesn't concern
me. I very rarely use jQuery on any public-facing sites.
> OMFG. This one is in your lap. If you had paid the slightest
> attention to what I said back in 2007, jQuery would have been fixed
> (as much as it can be fixed) a long time ago. You dropped the ball.
You must have me confused with someone else. I am not the author or
jQuery or on its dev team or even a contributor to its bug-tracking
system. I'm just a user who occasionally voices his thoughts.
> And again, I am not a member of that group. You are, but you didn't
> see fit to help out a fellow human being either. :(
I don't read most of the threads in there. Didn't even notice that
one.
> Better to come in
> here and argue impossible points with me? How is that helping?
Good question. I argue impossible points with you for three reasons, I
think.
1) Because I want others who are looking for information about jQuery
to hear a more balanced view between the people who praise jQuery
naively and people like you who say it's total trash. There is a
middle ground, and anyone looking for a reasonable view will hopefully
find the discussions between us and use them to arrive at their own
conclusions.
2) I always like having a knowledgeable, vocal challenger to any
beliefs I may hold. It makes me examine things and I'm usually better
off for it.
3) Because I tend to discuss things ad nauseam, especially when I feel
like someone is missing the point. It's a personality flaw. I'm
working on it. Or not.
> Don't you have something better to do anyway?
Yeah, probably. My lego sculpture of John Resig is almost complete...
Matt Kruse
Gregor Kofler
>> BTW, have you un-patched
>> and upgraded your version yet or are you still cool with the browser
>> sniffing? Most of those sniffs are for IE, IE8 is out and it is quite
>> unlike IE6/7 (which are still botched in the latest jQuery.)
>
> I use jQuery mostly in IE6-only environments, so IE8 doesn't concern me.
> I very rarely use jQuery on any public-facing sites.
Er... I don't get it. You are constantly defending jQuery for being a
tool to the inexperienced web author, yet at the same time you admit,
that one has to be aware of the limitiations of the library (which I
suppose the casual web author lacks entirely) *plus* you hardly use it on
public webpages.
How does this measure up?
Timo Reitz
>>> still cool with the browser sniffing? Most of those sniffs are for
>>> IE, IE8 is out and it is quite unlike IE6/7 (which are still botched
>>> in the latest jQuery.)
>> I use jQuery mostly in IE6-only environments, so IE8 doesn't concern
>> me. I very rarely use jQuery on any public-facing sites.
>
> Er... I don't get it. You are constantly defending jQuery for being a
> tool to the inexperienced web author, yet at the same time you admit,
> that one has to be aware of the limitiations of the library (which I
> suppose the casual web author lacks entirely) *plus* you hardly use it on
> public webpages.
>
> How does this measure up?
He tries to trick the competitors into using jQuery, so they don't pose a
threat to him.
David Mark
> Am Tue, 14 Apr 2009 08:15:21 -0700 schrieb Matt Kruse:
>
> >> BTW, have you un-patched
> >> and upgraded your version yet or are you still cool with the browser
> >> sniffing? Most of those sniffs are for IE, IE8 is out and it is quite
> >> unlike IE6/7 (which are still botched in the latest jQuery.)
>
> > I use jQuery mostly in IE6-only environments, so IE8 doesn't concern me.
> > I very rarely use jQuery on any public-facing sites.
>
> Er... I don't get it. You are constantly defending jQuery for being a
> tool to the inexperienced web author, yet at the same time you admit,
> that one has to be aware of the limitiations of the library (which I
> suppose the casual web author lacks entirely) *plus* you hardly use it on
> public webpages.
Yeah, it was "IT approved" a week ago. Now he's down to girl scout
sites and IE6-only Intranets. Of course, jQuery doesn't work for shit
on IE6.
>
> How does this measure up?
Apparently, it is for people confused by things like this:
el.style.display = 'block';
Of course, in many cases, that reduces to:
el.style.display = '';
So much for jQuery's "help" with table rows. As if anyone who doesn't
understand the above should be working on a Website and using a script
that turns that straightforward logic into hundreds of winding
function calls. Also, notice how none of the libraries has figured
out visibility?
Creates expandos on elements too. Everything in jQuery does. I heard
Resig mention that "no major library" would ever work without
expandos, certainly not if events are involved. You can't make this
stuff up.
Apparently it has been conceded that jQuery has no progressive
enhancement capabilities at all. I thought that was a selling point
for the "Unobtrusive Javascript" movement. (?)
Matt Kruse
> Er... I don't get it. You are constantly defending jQuery for being a
> tool to the inexperienced web author, yet at the same time you admit,
> that one has to be aware of the limitiations of the library
Most inexperienced developers will not hit upon the limitations in the
beginning. When they do, I hope they will know enough to look beyond
jQuery and start deciding when it should and shouldn't be used. I've
been an advocate of this all along - you have to know when to "unroll"
your jQuery code and write POJS. I hate it when people want to do
everything "the jQuery way". I've always been against attaching lots
of events on $(document).ready(). I've always advised people against
blindly using plugins. The jQuery UI project is way too heavy for my
tastes. Some jQuery proponents seem to think jQuery is the best
solution for every situation, and I don't like that view at all.
jQuery provides convenience. As with _any_ tool that provides
convenience, it has limitations. Once you start hitting the
limitations, you have to start deciding if it's time to move to
another tool or method.
> *plus* you hardly use it on public webpages.
Well first, I rarely create public webpages except for my own personal
use.
> How does this measure up?
I really don't see where the confusion is. jQuery is a tool. It works
well within its limitations. If you are a beginner or you can accept
its limitations, then it offers convenience which may be useful to
you. That's it.
Matt Kruse
Matt Kruse
> Yeah, it was "IT approved" a week ago.
There are a number of large companies that have "standardized" on
jQuery for their web sites and/or internal apps. In some cases, other
libraries may not be used. So knowing how to use it is helpful.
> Of course, jQuery doesn't work for shit on IE6.
Funny, because I've used it quite a bit with IE6 without problems.
> Apparently, it is for people confused by things like this:
> el.style.display = 'block';
> Of course, in many cases, that reduces to:
> el.style.display = '';
I'm sure you know this, but if you're showing a table row that is
hidden by CSS rules by default, then setting the display to '' will
not work.
Setting it to 'block' is correct in some browsers, incorrect in
others.
If you're suggesting that all developers should know all this before
attempting to hide/show a table row, yet jQuery conveniently lets them
do it without ever learning these details, then it's easy to see why
people choose the jQuery route.
That's the _whole point_ of adding a layer over top of technology.
Even when you're using POJS, you're depending on countless layers of
technology, each with its own flaws. Surely you don't consider the
potential technical problems in the ethernet implementation or the
router you are connected to before deciding whether you should rely on
it. Users of jQuery have simply decided that the level of complexity
in writing javascript for web applications has exceeded a threshold of
discomfort, and they will accept convenience at the price of some
compatibility or robustness.
Just look at .NET. Talk about a monster. It's way more horrendous than
most things jQuery-related, IMO. Yet countless businesses depend on
it, web sites are built on it, some developers love it, and it
certainly seems like the best choice for some people. Good for them!
Or maybe we should go tell them how stupid they are and point out all
the flaws and browser-incompatibilities in the js it spits out.
> Apparently it has been conceded that jQuery has no progressive
> enhancement capabilities at all. I thought that was a selling point
> for the "Unobtrusive Javascript" movement. (?)
It certainly has capabilities. It's just insufficient to handle it in
a robust way. Which, I would guess, many developers don't care about
to begin with.
Matt Kruse
Garrett Smith
> On Apr 14, 11:59 am, Gregor Kofler <use...@gregorkofler.com> wrote:
>> Er... I don't get it. You are constantly defending jQuery for being a
>> tool to the inexperienced web author, yet at the same time you admit,
>> that one has to be aware of the limitiations of the library
>
> Most inexperienced developers will not hit upon the limitations in the
> beginning.
On the other hand...
Inexperienced developers will try stuff that a more experienced
developer would know better to try.
For example, a beginner might modify Object.prototype and wonder why
jQuery adds a call to "ready" with his function as a callback and why
jQuery does the same call to jQuery.fn.one.
A more experienced developer (who is working to build a shared codebase)
would not modify Object.prototype.
A beginner might wonder why document.write does not work in "ready"
sometimes (depends on browser). A more experienced developer would
figure out what ready does right away and not use document.write there
(or anywhere).
Garrett
David Mark
> On Apr 14, 1:16 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Yeah, it was "IT approved" a week ago.
>
> There are a number of large companies that have "standardized" on
> jQuery for their web sites and/or internal apps. In some cases, other
> libraries may not be used. So knowing how to use it is helpful.
>
> > Of course, jQuery doesn't work for shit on IE6.
>
> Funny, because I've used it quite a bit with IE6 without problems.
You are funny.
>
> > Apparently, it is for people confused by things like this:
> > el.style.display = 'block';
> > Of course, in many cases, that reduces to:
> > el.style.display = '';
>
> I'm sure you know this, but if you're showing a table row that is
> hidden by CSS rules by default, then setting the display to '' will
> not work.
"Hidden" by default? There's a recipe for disaster.
> Setting it to 'block' is correct in some browsers, incorrect in
> others.
Good thing most scripts never need to do this. Certainly it isn't
something a neophyte should need abstracted (and certainly not as
badly as it is abstracted in jQuery.) The first thing you tell them
is that display:none does not normally belong in a CSS file.
I'm reminded of a line in an old movie that goes something like:
"Every time you go to a good crime, there are fifty ways you can fuck
it up. If you can name twenty-five of them, you're a genius (and you
ain't no genius.)"
jQuery multiplies the fifty ways by a hundred and then randomly
changes the rules from one version to the next. Think the old "show"
looks anything like the new one?
Who do you suppose will go back and swap out the entire jQuery library
when the next new browser comes out (or you discover that it doesn't
work that well with the latest releases.) Think a neophyte can debug
and test this spaghetti factory on top of whatever gibberish they
wrote? Nobody would bother. They sites just get thrown out like
disposable diapers. That is not how the Web works and certainly not
how business works.
> If you're suggesting that all developers should know all this before
> attempting to hide/show a table row, yet jQuery conveniently lets them
> do it without ever learning these details, then it's easy to see why
> people choose the jQuery route.
See above. There's nothing convenient about it. And how many
neophytes does it take to "hide/show" a table row (realize we aren't
even talking about visibility here?) Would you assign such a task to
a team of neophytes, knowing they are 100% reliant on the knowledge
and experience of other jQuery users?
>
> That's the _whole point_ of adding a layer over top of technology.
I know about layers, thank you.
[snip more about layers]
>
> Just look at .NET. Talk about a monster. It's way more horrendous than
I've seen it. It seems to be finally dying out.
> most things jQuery-related, IMO. Yet countless businesses depend on
> it, web sites are built on it, some developers love it, and it
> certainly seems like the best choice for some people. Good for them!
No, to hell with them. You can't help some people. Now they want to
toss jQuery on top of .NET. Good luck with that!
> Or maybe we should go tell them how stupid they are and point out all
> the flaws and browser-incompatibilities in the js it spits out.
BTDT. As with any large group, some listen, some don't. Make no
mistake, .NET is history.
>
> > Apparently it has been conceded that jQuery has no progressive
> > enhancement capabilities at all. I thought that was a selling point
> > for the "Unobtrusive Javascript" movement. (?)
>
> It certainly has capabilities. It's just insufficient to handle it in
> a robust way. Which, I would guess, many developers don't care about
> to begin with.
Don't care about progressive enhancement? When did something that
"enables you to build kick-ass Web applications" that "degrade
gracefully" in "all browsers" become a script exclusively for girl
scout sites? Hope none of their parents are on dial-up.
You've got a primitive culture with little or no written history,
passing down old wives' tales and superstitions. They can't (or
won't) read for comprehension, analyze problems or debug code. And
these are the developers! They barely ever ask for a jQuery version
when charged with investigating an issue. Why? They really believe
that jQuery is some sort of magical browser tamer that always works
with "all browsers." We know it changes every revision (seemingly
every other month) and the list of "supported browsers" is constantly
pruned, which indicates that it is a very bad script for a Website (at
least one that wants to last more than a couple of months!)
Coming full circle, I see you opened a ticket on the - each -
function. Good for you! Of course, the only thing that happened
since is that some native added a comment noting that Richard's
analysis was flawed and the cited thread only existed to criticize
jQuery. What was that, a month ago? No word on attr, removeAttr or
offset. I think they've used up their mulligans for the year.
Would you be willing to buy a book on this?
David Mark
God knows they wouldn't use *that* "ready" method at all. If we are
talking about neophytes, the only advice for them is to use the onload
attribute of the body. Unfortunately, that wasn't "unobtrusive"
enough for people like John Resig.
Matt Kruse
> "Hidden" by default? There's a recipe for disaster.
That's a false over-generalization. If you are trying to be super
accessible and all that, sure, don't hide things by default. But
internal webapps rarely have those types of concerns.
> And how many
> neophytes does it take to "hide/show" a table row (realize we aren't
> even talking about visibility here?)
I think it's fairly common, actually. Click on a row to expand
"details" below it in another row.
> > Just look at .NET. Talk about a monster. It's way more horrendous than
> I've seen it. It seems to be finally dying out.
Perspective, I guess. In some areas it's growing.
> BTDT. As with any large group, some listen, some don't. Make no
> mistake, .NET is history.
Everything is history at some point. I hope .NET dies out sooner
rather than later. But that doesn't change the fact that it's built by
a huge company, has lots of devoted developers who swear by it, is the
back-bone of mission-critical webapps and web sites, and must satisfy
a need for a huge number of people, even if you think it is horrible.
Sounds a lot like jQuery (s/huge company/ninja/).
> Hope none of their parents are on dial-up.
People still use dial-up?
> I see you opened a ticket on the - each - function.
I don't think I did? I did make a comment on an existing ticket, and I
posted suggestions to the dev mailing list, referencing the thread
here.
> Would you be willing to buy a book on this?
Sure, if by "book" you mean "pdf file" and by "buy" you mean "download
for free".
Matt Kruse
Lawrence Krubner
> On Apr 12, 7:44 pm, Lawrence Krubner <lkrub...@geocities.com> wrote:
>
>
> > > On Apr 12, 5:48 pm, Lawrence Krubner <lkrub...@geocities.com> wrote:
>
> > > AFAIK, nobody here has ever said anything about writing all of your
> > > own code from scratch, yet it is invariably the first rhetorical
> > > question out of the gate from every doubting neophyte that shows up.
> > > Where do you get that?
>
> >David, you've a remarkably poor memory. Just earlier today you wrote:
>
> > "Compared to any context-specific solution, jQuery is bloated and
> > slow."
>
> I remember that like it was yesterday.
>
>
>
> > Check it out, you can read your own words here:
>
> >http://groups.google.com/group/comp.lang.javascript/msg/dc9b78773cf5b7db
>
> Why? Certainly I said nothing about writing everything from scratch.
> I think I am starting to see where this is coming from.
David, you don't seem to understand your own argument. When a
programmer writes code, they can do one of two things:
1.) Reuse old code, that is, use a library.
2.) Write new code from scratch.
Any reuse of old code means you're using a library. It doesn't matter
if that library is informal - just some functions you wrote that you
like to reuse because you're comfortable with them - or formal and
public like jQuery or Prototype or mootools.
You've argued against libraries, which means you are in favor of
writing new code, from scratch. Anything that is a "context-specific
solution", written just for one specific solution, involves writing
new code from scratch.
Lawrence Krubner
> Am Sun, 12 Apr 2009 16:36:34 -0700 schrieb Lawrence Krubner:
>
> > These pre-packaged scripts allow designers to get a wide
> > variety of effects without having to learn how to program.
>
> No, that's /the/ misconception.
>
> According to your logic graphics designers are supposed to congratulate
> me upon my decision to use one of those fancy predefined webpage
> templates, because it enables me to do "professional layouts" without
> having to learn the basics of design. (Who cares if colors of fonts don't
> match the chosen template, or the template doesn't match the CD of the
> customer.)
The standard I'd use is "How can we meet the customer's needs, at the
lowest possible cost, for a given level of quality?" That doesn't mean
that things should be low quality or low cost, but rather, that they
should be the lowest cost per whatever quality the client needs. Some
clients need very high levels of quality, and some only need very low
levels of quality.
You are critical of those pre-package templates that only cost $29.99
(or sometimes they are free), but I'd argue that, for a certain class
of customer, those ultra-cheap templates are very successful. I've
seen sites where the owners simply want to run a simple store, selling
fishing gear, and the web site is a sideline to their real business.
And these sites only generate $100 or $200 a week in sales, and
therefore do not justify great expense. But the owners of such sites
deserve to be congratulated for pulling together a working business
model. The sites may not look great, but they are sufficient, and the
business is able to attract customers. If you were to argue that the
site should be built to a higher level of quality, you'd have to prove
that the higher quality would bring in additional sales.
Some very ugly sites are extremely successful. Jason Fried has argued
that Drudge Report is one of the most successful sites on the web, and
I agree with his reasoning:
The use of pre-package effects, such as those provided by jQuery UI,
are exactly like the $29.99 templates. They do an excellent job of
meeting the needs of a certain class of web site owner.
Lawrence Krubner
> Am Sun, 12 Apr 2009 14:06:40 -0700 schrieb Lawrence Krubner:
>
> [snip]
>
> > Why don't you just publish your scripts as a library then?
>
> Yawn... The usual implied "if you can't do better, stop critizing". Apart
> assessing the code quality?
I'd never argue that Mark should stop criticizing anyone. I'm arguing
that, if his scripts are freely available, and no one uses them, then
perhaps they are not as useful as he thinks they are.
Your use of the word "quality" suggests that there is a single
dimension by which we can measure code. Your implication is that we
can use some official standard of code quality. Perhaps you're imaging
a standard such as "How well does this code conform to well known,
agreed upon principles of software design?"
However, there are many other, equally valid, dimensions by which code
can be measured. For instance:
1.) How useful do people find this code?
2.) How easy to use do people find this code?
If people find code un-useful, or if they find it hard to work with,
then I'd argue it is worth very little, regardless of its conformance
to some well known standards of software design.
Lawrence Krubner
Work on websites should be lead by the designers for the reasons I
outlined here:
http://www.teamlalala.com/blog/2009/03/01/the-problem-with-php-frameworks/
In general, designers have a better grasp of what customers, and what
the actual users of the websites, want. Computer programmers spend all
day thinking about how machines think, but designers spend all day
thinking about humans think. Web sites developed with a design lead
process tend to be more intuitive and usable than the sites where
programmers have control over the process. Web sites developed in
shops where the programmers dominate tend to deliver the requested
features, but in ways that damage the user experience.
Lawrence Krubner
> On Apr 12, 6:51 pm, Eric Bednarz <bedn...@fahr-zur-hoelle.org> wrote:
>
>
>
> > Lawrence Krubner <lkrub...@geocities.com> writes:
> > > This is intellectually lazy on your part. You could have just as
> > > easily asked "What makes these scripts so popular with designers?"
>
> > Because they are graphic (I suppose you mean) designers, so they
> > a) don’t understand any of the problems and cannot judge its quality
> > b) the API will likely appeal to them because they are not programmers
>
> > > Or ever better: "Why do graphic designers use these pre-package
> > > scripts?
>
> > Are you seriously thinking that there is a relation between success and
> > quality (in any field)?
>
> > > Why don't they write their own code from scratch?"
>
> > Eyeroll. Speaking about lazy, you haven’t been lurking here, right?
>
> My favorite is "Why don't you write all of your sites in
> assembler?!!!" This is usually parroted by people who have no idea
> what assembly language is (they just thought it sounded like a geek-
> chic thing to say.)
>
>
>
> > Something you missed that you could just as easily have asked is:
> > “What idiot would assign programming tasks to designers?”
>
> Lots of them, but fewer now than three months back.
Ah, yes. Because of your courageous willingness to stand against the
conventional wisdom, the world is coming around to your way of seeing
things. The millions of people who carefully read comp.lang.javascript
everyday have been dazzled by the brilliance of your arguments. That
respected publishing houses like O'Reilly have published books saying
positive things about jQuery is of no matter. They have learned the
errors of their ways. Surely any day now you'll be receiving a
personal letter of apology from O'Reilly himself, asking forgiveness
for the damage he may have caused by publishing books that expressed
opinions you disagree with. That popular magazines and popular
designers are recommending libraries like jQuery is a point we can,
and should, ignore. All that matters is how daring you've been, and
how you've won over all of society with the strength of your
arguments.
Garrett Smith
> On Apr 12, 8:01 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> On Apr 12, 7:44 pm, Lawrence Krubner <lkrub...@geocities.com> wrote:
>>
>>> On Apr 12, 5:58 pm,DavidMark<dmark.cins...@gmail.com> wrote:
>>>> On Apr 12, 5:48 pm, Lawrence Krubner <lkrub...@geocities.com> wrote:
>>>> AFAIK, nobody here has ever said anything about writing all of your
>>>> own code from scratch, yet it is invariably the first rhetorical
>>>> question out of the gate from every doubting neophyte that shows up.
>>>> Where do you get that?
>>> David, you've a remarkably poor memory. Just earlier today you wrote:
>>> "Compared to any context-specific solution, jQuery is bloated and
>>> slow."
>> I remember that like it was yesterday.
>>
>>
>>
>>> Check it out, you can read your own words here:
>>> http://groups.google.com/group/comp.lang.javascript/msg/dc9b78773cf5b7db
>> Why? Certainly I said nothing about writing everything from scratch.
>> I think I am starting to see where this is coming from.
>
> David, you don't seem to understand your own argument. When a
> programmer writes code, they can do one of two things:
>
> 1.) Reuse old code, that is, use a library.
>
> 2.) Write new code from scratch.
>
It seems that in (1), code reuse implies using a library. I have to
disagree with that. Strongly.
For a search of "code reuse", you might stumble on the first hit:-
http://en.wikipedia.org/wiki/Code_reuse
For a more formal education on effective code reuse, I recommend the
book "Agile Software Development" (that is not in the FAQ).
Garrett
Garrett Smith
> On Apr 13, 4:10 am, Gregor Kofler <use...@gregorkofler.com> wrote:
>> Am Sun, 12 Apr 2009 16:36:34 -0700 schrieb Lawrence Krubner:
>>
>>> These pre-packaged scripts allow designers to get a wide
>>> variety of effects without having to learn how to program.
>> No, that's /the/ misconception.
>>
>> According to your logic graphics designers are supposed to congratulate
>> me upon my decision to use one of those fancy predefined webpage
>> templates, because it enables me to do "professional layouts" without
>> having to learn the basics of design. (Who cares if colors of fonts don't
>> match the chosen template, or the template doesn't match the CD of the
>> customer.)
>
> The standard I'd use is "How can we meet the customer's needs, at the
> lowest possible cost, for a given level of quality?" That doesn't mean
> that things should be low quality or low cost, but rather, that they
> should be the lowest cost per whatever quality the client needs.
This statement:-
Some
> clients need very high levels of quality, and some only need very low
> levels of quality.
>
is a disturbing representation of what I see in the state of the art in
front end engineering.
I do take pride in my work and do not produce unprofessional quality code.
Garrett
Lawrence Krubner
> On Apr 13, 10:39 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>
I have. At the various web design firms that I've worked at, I've had
to work closely with designers. Over the last 10 years, I've gotten to
know what they need and what they don't need. I've also had long
conversations with clients, what they want, what goals they are trying
to acheive.
I've also had countless friends come up to me and say "I'd like to
learn how to build web sites." I've taught several. The experience has
helped me see what concepts they find easy to grasp, and which
concepts they find difficult to grasp.
Given those experiences, I understand why jQuery is gaining in
popularity. It answers a real need.
> > But no matter how much it may annoy you, people want to abstract
> > browser scripting and not worry about the details. THAT is the problem
> > that jQuery is trying to solve. For someone making a page for their
> > child's basketball team without much experience in web development, a
> > library like jQuery will allow them to add some animations, maybe make
> > some tabs, perhaps even show pictures in a little "lightbox" that
> > impresses all the other parents. Good for them! They don't care about
>
> Unless they are blind, spastic, use mobile devices, hate Javascript,
> use older browsers, use new browsers, etc., etc.
>
> But I am willing to stipulate that such a trivial vanity page may be
> the only justification for such a script. It's like using AOL's
> builders to create a home page.
You are expressing contempt for the software AOL makes available so
that people can build a simple web page. And, really, your entire
argument is based on this straight-forward elitism. Take away the
elitism, and you have no argument at all. Once a person realizes that
AOL's simple web page builder answers a real market need, then the
person also understands how other efforts to make the web simple
answers real market needs.
Lawrence Krubner
> > On Apr 14, 11:59 am, Gregor Kofler <use...@gregorkofler.com> wrote:
> >> Er... I don't get it. You are constantly defending jQuery for being a
> >> tool to the inexperienced web author, yet at the same time you admit,
> >> that one has to be aware of the limitiations of the library
>
> > Most inexperienced developers will not hit upon the limitations in the
> > beginning.
>
> On the other hand...
>
> Inexperienced developers will try stuff that a more experienced
> developer would know better to try.
People who are inexperienced often try things that experienced people
know to avoid. This is true about rock climbing. It is true about
investing. It is true about romance. It is true about travel. It is
true about all things that humans can experience. You have no point to
make.
Lawrence Krubner
> On Apr 14, 3:51 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>
> Who do you suppose will go back and swap out the entire jQuery library
> when the next new browser comes out (or you discover that it doesn't
> work that well with the latest releases.) Think a neophyte can debug
> and test this spaghetti factory on top of whatever gibberish they
> wrote? Nobody would bother. They sites just get thrown out like
> disposable diapers. That is not how the Web works and certainly not
> how business works.
And yet, businesses use jQuery. Apparently this is the way business
works.
> > Just look at .NET. Talk about a monster. It's way more horrendous than
>
> I've seen it. It seems to be finally dying out.
> > Or maybe we should go tell them how stupid they are and point out all
> > the flaws and browser-incompatibilities in the js it spits out.
>
> BTDT. As with any large group, some listen, some don't. Make no
> mistake, .NET is history.
There is a delusional quality to much of your writing. That your
exaggerations and bold pronunciations have nothing to do with reality
doesn't seem to bother you at all.
Lawrence Krubner
> Lawrence Krubner wrote:
> > This is intellectually lazy on your part.
>
> interst in any JS library. Thus, I'm not driven by affections, either way.
>
> > You could have just as
>
> > easily asked "What makes these scripts so popular with designers?"
>
> classic example of ad populum?
>
> > Or ever better: "Why do graphic designers use these pre-package
>
> Or: why do flies like shit? Why don't they fancy veggies?
Flies like shit because shit is full of the nutrients they need. Shit
helps flies accomplish their main evolutionary goal of gaining enough
resources to reproduce. Shit is useful to flies.
What you do with this comparison, thoughtlessly and carelessly, is
take the cultural value that humans assign to shit and then mistakenly
assign it to flies. But why would flies care what humans think about
shit? Why would a fly worry whether humans give great value, or little
value, to shit?
The comparison demonstrates a kind of intellectual laziness that has
been rife in this thread.
Andrew Poulos
> In general, designers have a better grasp of what customers, and what
If you don't test with real users using someone trained in usability you
are, at best, guessing.
> the actual users of the websites, want. Computer programmers spend all
> day thinking about how machines think, but designers spend all day
> thinking about humans think. Web sites developed with a design lead
> process tend to be more intuitive and usable than the sites where
Without proper usability testing you would never really know if a site
is usable.
> programmers have control over the process. Web sites developed in
> shops where the programmers dominate tend to deliver the requested
> features, but in ways that damage the user experience.
You talk of "user experience" as though there's some absolute one can
ascribe to.
Andrew Poulos
Lawrence Krubner
Did you read the wiki page that you are linking to? The beginning of
the third paragraph says:
"The software library is a good example of code reuse. "
Garrett Smith
Are you referring to the Shelly Powers book again?
They have learned the
> errors of their ways. Surely any day now you'll be receiving a
> personal letter of apology from O'Reilly himself, asking forgiveness
> for the damage he may have caused by publishing books that expressed
> opinions you disagree with.
In argument, it is important to distinguish between fact and opinion.
That popular magazines and popular
> designers are recommending libraries like jQuery is a point we can,
> and should, ignore. All that matters is how daring you've been, and
> how you've won over all of society with the strength of your
> arguments.
>
Sarcasm is mpt always conveyed as sarcasm on the Net. Sarcasm can also
be an indirect way of posing an argument. I think I am making the
correct interpretation of what you wrote as being entirely sarcastic.
This is comp.lang.javascript. Popularity means jack shit here. If you
want popular, go visit Ajaxian.
Garrett
Garrett Smith
I read it. I did not assume that someone would make the mistake of
affirming the consequent.
You stated:
| Reuse old code, that is, use a library.
To conclude that using a library means that effective code reuse has
taken place would be incorrect.
1) Using a library might be a form of code reuse, but that would not
necessarily make the reuse effective.
2) Reused code might be new and might not come from a library. This can
happen when creating abstractions for the parts that vary.
Garrett
Thomas 'PointedEars' Lahn
> David Mark wrote:
>> "Hidden" by default? There's a recipe for disaster.
>
> That's a false over-generalization. If you are trying to be super
> accessible and all that, sure, don't hide things by default. But
> internal webapps rarely have those types of concerns.
That few businesses and organizations realize that they need accessible
applications on the inside, too, is no argument at all against creating such
applications. For example, since quite a few years in Germany (2002 CE),
Austria (2004), and Switzerland (2004) external and internal Web sites of
state-related organizations must be designed accessible *by law* (they must
meet WCAG 1.0 A+), and at least German and Swiss law also reinforces that
disabled people have to be employed (also in private companies) if they are
qualified for the job.
<http://de.wikipedia.org/wiki/Barrierefreies_Internet>
The U.S. Americans with Disabilities Act (ADA) is dated 1998 as well as
Section 508 of the Rehabilitation Act. Other countries have similar
legislation; if not, they are going to because of globalization.
<http://en.wikipedia.org/wiki/Web_accessibility>
Go tell them that they need to redesign/exchange/update the system because
now both the senior not-disabled field staff and the newly employed
disabled/aged office assistant need to access it, and let them have a good
laugh.
Again, it is your shortsightedness that lets you overlook the
all-too-obvious possibilities.
PointedEars
Thomas 'PointedEars' Lahn
The point is, Lawrence (if that's your real name), that these things tend to
have much a smaller impact on the lives of everyone. If you alone go climb
a rock inexperienced and fall down or are stuck above, only you are injured
or dead. If you invest in the wrong stocks, only you are going to lose
money (save that you are a hedge funds manager, but who's the greater
fool?). If you go wrong about romance, only you and perhaps the other
person might find yourselves alone. If you book the wrong trip, only you
might find yourself dissatisfied (or captured or killed). (Of course, in
any of those cases, your family, relatives and friends might suffer with you.)
If instead you create a script library that hundreds are supposed to use, if
you don't have the minimum clue, and if your library is advertised so that
those hundreds who are building on it also think they don't need to have a
minimum clue (i.e. if you are John Resig), and thousands of equally clueless
people use that which is built on it on a hundred thousands of Web sites, in
the end millions are going to suffer from your initial and ongoing mistakes.
For the mistakes made from conception to design to implementation to
production do multiply, and it stands to reason (as if it was not evident
already) that they are not easily fixed by then, especially if none of the
involved people had the minimum clue in the first place.
HTH
PointedEars
Gregor Kofler
> and some only need very low
> levels of quality.
Never met anyone who *needs* (or wants) that. They probably don't want to
pay for it.
Gregor
--
http://www.gregorkofler.com
http://web.gregorkofler.com - vxJS, a JS lib in progress
Gregor Kofler
> I'd never argue that Mark should stop criticizing anyone. I'm arguing
> that, if his scripts are freely available, and no one uses them, then
> perhaps they are not as useful as he thinks they are.
You never heard of this "marketing" thing? Right?
> Your use of the word "quality" suggests that there is a single dimension
> by which we can measure code.
Not a "single dimension", but several best practices, inherent to the
different programming languages and environments.
> However, there are many other, equally valid, dimensions by which code
> can be measured. For instance:
>
> 1.) How useful do people find this code?
>
> 2.) How easy to use do people find this code?
You never heard of this "marketing" thing? Right?
> If people find code un-useful, or if they find it hard to work with,
> then I'd argue it is worth very little, regardless of its conformance to
> some well known standards of software design.
Makes one wonder why BASIC has completely disappeared...
How many "developers" have evaluated the various libraries available? And
how many have just jumped the jQuery bandwagon without second thought?
99%? 99.5%?
Garrett Smith
> On Apr 12, 2:25 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> On Apr 12, 1:51 pm, Lawrence Krubner <lkrub...@geocities.com> wrote:
>>
>>> On Apr 12, 6:32 am, "rf" <r...@z.invalid> wrote:
>>>> David Mark wrote:
>>>>> It was recently opined here that upgrading a complex, interdependent
>>>>> script like jQuery
>>>> Do we really need any more shit about jQuery here?
>>>> It's a dog. Let it die.
>>> My sense is that JQuery is growing in popularity. I recall 3 years ago
>> Has grown. Is at the apex of its absurdity. In short, jQuery claims
>> to be "Write Less. Do More." I say, even if it was, it pales in
>> comparison with "Write Once. Do Nothing." jQuery is introducing
>> "overhauls" in the year 2009 on issues that were settled in 2001,
>> still doesn't have them right (as evidenced by the disruption in
>> upgrading the script and/or its dependencies) and the authors do not
>> appear to understand most of the issues anyway.
>>
>>> my graphic designer friends were trying to figure out how to use
>>> prototype/scriptaculous so they could get cool visual transitions into
>> Your graphic designer friends shouldn't play with browser scripting.
>>
>>> their pages without having to use Flash. But at some point in the last
>> Admirable ambition. Of course, they likely shouldn't play with Flash
>> either (usually involves Other People's Scripts.)
>>
>>> 18 months, it seems to me there has been some kind of mass conversion
>>> to JQuery. In 2006 I got a lot of phone calls that went "Hey, I can't
>>> get scriptaculous to work, can you help me?" but nowadays it is always
>>> "Hey, I can't get jQuery to work, can you help me?"
>> Prototype died out. jQuery is next. That's what happens to bad
>> ideas.
>>
>>
>>
>>> Consider what Shelly Powers writes in her 2007 book, Adding Ajax. This
>>> is from page 93:
>> Who?
>
>
> Her books are listed here:
>
> http://www.amazon.com/exec/obidos/search-handle-url/ref=ntt_athr_dp_sr_1?_encoding=UTF8&search-type=ss&index=books&field-author=Shelley%20Powers
I already stated that the Shelly Powers book is full of factually false
statements.
An earlier post you made discussed "opinions" in books published by
O'Reilly. As I said in response to that, it is important to distinguish
between facts and opinions.
Facts are things like:-
| In addition to the ECMAScript reserved words, there are
| JavaScript-specific words implemented in most browsers that are
| considered reserved by implementation. Many are based in the
| Browser Object Model--objects such as document and window. Though
| not a definitive list, Table 2-3 includes the more common words.
|
| Table 2-3. Typical reserved words in browsers
| alert eval location open
| array focus math
...
a factual statement regarding reserved words of the "Browser Object Model".
Another fact:-
| Many times, variables and functions have one or more words
| concatenated into a unique identifier, following a format
| popularized in other languages, and frequently referred to as
| /CamelCase/:
|
| validateName
| firstName
|
| This approach makes the varible much more readable, though
| dashes or underscores between the variable "words" works as
| well:
|
| validate-name
| first_name
another factual statement, this time regarding syntax, not reserved words.
That statement is followed by:-
| Though you can use $, number, or underscore to begin a variable, your
| best bet is to start with a letter.
That is two pages of Shelly Powers. Practically every page is loaded
with stuff like that.
| Null and Undefined.
| The division between literals, simple data types, and objects
| is blurred in JavaScript, nowhere more so then when looking at two
| that represent nonexistannce or incomplete existance: null and
| undefined.
|
| A /null/ variable is one that has been defined but hasn't been
| assigned a value. The following is an example of a null variable:
|
| alert(sValue); //results in JavaScript error because sValue is
| // (wrapped) not declared first.
On the proceeding page, she provides advice for how to handle this
problem when using several JS libraries:-
| When using several JS libraries and fairly complex code, it's not
| unusual for a variable to not get set, and trying to use it in an
| expression can have adverse effects -- usually a JavaScript error. One
| approach to test variables if you're unsure of their state is to use
| the variable in a conditional test, such as the following:
|
| if(sValue) ... // if not null and initialized, expression is true;
| // (wrapped) otherwise false.
|
| We'll look at conditional statements in the next chapter, but the
| expression consisting of just the variable sValue evaluates to |true|
| if sValue has been declared and initialized; otherwise, the result of
| the expression is false.
|
| if (sValue) // not true, as variable has not been declared, and
| // (wrapped) is therefore null
|
| var sValue;
| if (sValue) // variable is not null, but it's still not true, as
| // (wrapped) variable has not been defined (initialized with a value)
|
| var sValue = 1;
|
| if(sValue) // true now, as the variable has been set, which
| automatically declares it.
|
Opinions, OTOH, expresses personal or unproven belief.
For example:-
| No doubt no one should write a line of code, even in a light weight
| scripting language, until they have completed their Ph.d in computer
| science at Stanford, yet in the real world, people often do write code
| before their Ph.d is complete.
- could be considered your opinion and would serve as an example of
"opinion" in the general sense.
Another meaning of opinion applies to professional expert advice. (My
doctor's opinion, the judge's opinion, etc). I don't see how that would
be relevant here; Shelly Powers is not an authoritative expert.
Garrett
Matt Kruse
> I already stated that the Shelly Powers book is full of factually false
> statements.
Wow... the quotes you cite are awesome. This is for real? Seriously?
No wonder people have the perception that javascript is funky and hard
to understand, when the people who get paid to write books about it
can't even get it right.
I can imagine a person new to js, after reading her advice, writing a
simple test script...
var 123-abc = "test";
WTF!? Why doesn't this work? There must be something really obscure
happening here. Man, Javascript is HARD! jQuery to the rescue!!!
Matt Kruse
Garrett Smith
LOL. You've got to have a sense of humor!
The funny thing is she contradicts herself in a few places on what a
valid identifier is.
That is not the only O'Reilly javascript book you'll find advocating the
use of jquery. Take a look at: JavaScript, The Missing Manual, by David
McFarland.
Another book that is chock full of bs from cover to cover.
This is what it has come to.
> Matt Kruse
Garrett
Lawrence Krubner
> It was recently opined here that upgrading a complex, interdependent
> made use of the parts touched by the loosely organized "team" of
> developers.
>
> Unfortunately, when you first attempt to take the giant leap from
> browser sniffing to feature detection (all at once and ten years
> late), you end up with fingerprints all over everything.
>
> I recently noticed a plug for jQuery's reenactment of that favorite of
> browser scripting neophytes: calculating offset positions. For the
> uninitiated, a cross-browser solution to calculate *absolute* offsets
> (from the "origin" of the HTML element) is strictly an academic
> exercise. Production apps are *never* designed to rely on such
> problematic measurements.
>
> Since the early part of the century, "solutions" involved two
> branches, one for IE using the proprietary getBoundingClientRect
> (recently adopted by FF and Opera) and a loop adding offsetLeft/Top
> (plus clientLeft/Top) properties in everything else. Occasionally, a
> third branch would use getBoxObjectFor (now deprecated) in Mozilla-
> based browsers. In a few specific contexts, viable solutions are
> possible. In a general sense, attempting to solve this "problem" at
> all is madness.
>
> As jQuery's old rendition of this classic used browser sniffing
> exclusively, the version of the offset method in 1.3x has changed
> radically. As would be expected, so has its behavior across the
> handful of browsers supported by jQuery. Certainly this is part of
> the reason that jQuery only supports browsers released in the last
> couple of years.
>
> A useful and pragmatic function would have been one that calculated
> the offset from its nearest positioned parent. For example, the body:
>
> http://groups.google.com/group/jquery-dev/browse_thread/thread/5107d8...
>
> "Greetings, fellow developers!
>
> First of all, I would like to thank you guys for putting in so much
> time and effort on this amazing framework. This will be basically a
> repost of another email I sent to jquery ui, along with a ticket
> filled on their bug tracking system, regarding to the behaviour of one
> of the widgets in the presence of a positioned body element."
>
> Poor bastard.
>
> "Just write your own function that uses jquery's return value and adds
> in your calculations for your offset body.
>
> Matt Kruse"
>
> Sure, use a just-released version of an impossible absolute position
> function then adjust to suit!
I think this blog post by Drew McLellan offers a good point about why
libraries like jQuery are useful:
"Despite some efforts to make my script play nice and integrate with
other JavaScript that may be in use on the page, a lot of users still
found the script problematic. Whilst I was checking for existing
onload event handlers in the page before adding mine, other scripts
don’t necessarily do that and so could overwrite my event handler
causing the script not to work. Not my fault, but still not good for
those with the problem.
With the rise of JavaScript libraries over the last couple of years,
the ecosystem has got a lot more friendly. Rather than having a page
running a mishmash of different scripts running in different
methodologies, the adoption of a library brings with it shared
methodology and infrastructure. That means you can do things like set
an onload handler and not worry that your code will not get executed –
the library is managing that across all the JavaScript that may be on
the page. This also means that there’s a lot less code that needs to
be written per-script, as you can tap into what the library already
has on offer. So it made sense to me to re-implement SuperSleight
using a common JavaScript library."
http://allinthehead.com/retro/338/supersleight-jquery-plugin
RobG
[...]
> I think this blog post by Drew McLellan offers a good point about why
> libraries like jQuery are useful:
>
> "Despite some efforts to make my script play nice and integrate with
> other JavaScript that may be in use on the page, a lot of users still
> found the script problematic. Whilst I was checking for existing
> onload event handlers in the page before adding mine, other scripts
> don’t necessarily do that and so could overwrite my event handler
> causing the script not to work. Not my fault, but still not good for
> those with the problem.
Apparently Drew's choice of jQuery was motivated by difficulty adding
an event listener that was not affected by other scripts. Given the
small number of modern browsers supported by jQuery, it surely would
not have been too much work to add a listener using a bog standard
addEventListener/attachEvent function.
> With the rise of JavaScript libraries over the last couple of years,
> the ecosystem has got a lot more friendly. Rather than having a page
> running a mishmash of different scripts running in different
> methodologies, the adoption of a library brings with it shared
> methodology and infrastructure.
The key here is "the adoption of *a* library". Apparently the use of
a single library or framework is a strategy to enforce a particular
coding style or design strategy. There are a couple of flaws in that:
1. Not everyone may agree on the use of the same library, they often
bump into each other.
2. Using a library doesn't force any particular design paradigm on
developers, though there are similarities of how they are used. If
you add a listener directly to a DOM property, it doesn't matter what
library has been used, someone else can easily replace it. If you add
it using host DOM methods (e.g. addEventListener or attachEvent) the
listener can't be removed without a reference. The fact that a
library was or wan't used (most probably[1]) makes no difference.
3. Even if the users of a particular library all use the same
implementation methodology with the same library, it has nothing to do
with his issue.
A simple, generic answer to Drew's dilema is to include a simple
(perhaps 6 lines of code[2]) function or routine to add his listener.
But instead he's chosen to re-write is code to fit with jQuery, then
impose a restriction that it can only be used in browsers that jQuery
supports. He doesn't even have to write it, there are plenty already
published in this group (though searching for one will likey take
longer than writing it).
The funniest part is that his code is only needed in one browser
version - IE 6 - so his addListener function can be maybe 3 lines of
code and in any case can be done with conditional comments - no onload
listener needed at all. Where's the need for a library now?
> That means you can do things like set
> an onload handler and not worry that your code will not get executed –
> the library is managing that across all the JavaScript that may be on
> the page.
Rubbish. If an element is replaced with a clone of itself, whether
handlers are kept depends on the browser and how the listener was
attached. A library doesn't help at all there[1].
If the issue is stopping other code from removing his listener, if he
uses addEventListener or attachEvent then the possibility of that
occurring is reduced to near zero (other listeners might affect event
propigation, but libraries don't help with that[1]).
> This also means that there’s a lot less code that needs to
> be written per-script, as you can tap into what the library already
> has on offer. So it made sense to me to re-implement SuperSleight
> using a common JavaScript library."
So rather then using well known standard methodologies for development
to avoid clashes between scripts written by different authors,
McLellan thinks that if you mandate everyone use the same library
somehow side effects wont happen. Wishful thinking.
McLellan has the classic "general case" dilema - the more general the
code is written, the more difficult it is to cover every case. Rather
than either write his code to be useful in a reasonably wide set of
browsers or state the restrictions on its use, he simply uses jQuery
to provide a filter of unsuitable browsers. Don't blame him if your
browser isn't supported, blame the jQuery development team!
1. Some libraries may have their own cache of the listeners that have
been added using the library's functions and may allow those listeners
to be carried over to replaced nodes. Some attempt their own version
of propigation.
2. Given the limited set of modern browsers supported by libraries
like jQuery
--
Rob
Garrett Smith
Not knowing how to handle event registration? Oh, jQUery, that has to be
the answer.
> With the rise of JavaScript libraries over the last couple of years,
> the ecosystem has got a lot more friendly. Rather than having a page
> running a mishmash of different scripts running in different
Mishmash of different scripts running in different methodologies?
I'm not 100% sure what "running in different methodologies" means.
Of what is described, I'm getting the picture like a mess of incompetence.
> methodologies, the adoption of a library brings with it shared
> methodology and infrastructure. That means you can do things like set
> an onload handler and not worry that your code will not get executed –
Funny. I don't have that problem.
> the library is managing that across all the JavaScript that may be on
> the page. This also means that there’s a lot less code that needs to
> be written per-script, as you can tap into what the library already
> has on offer. So it made sense to me to re-implement SuperSleight
> using a common JavaScript library."
>
> http://allinthehead.com/retro/338/supersleight-jquery-plugin
>
>
| Of course, if you wanted to fix PNGs for the entire page, you can just
| apply it to the body element. For all sorts of reasons, it’s better to
| be specific if you can.
Using a |for in| loop would onload be a bad idea (locks up browser
momentarily). Putting it inside a jQuery.each is a much worse idea. I
don't have time for much of a code review of that.
Reading more Drew McClellan:-
http://allinthehead.com/retro/337/the-cost-of-accessibility
| As a web developer, there’s little I dislike more than building sites
| to be accessible.
Yikes! He goes on to say how accessibility is a pain in the "backside".
THen he goes on to discuss "The Magical World of JavaScript"
| The Magical World of JavaScript
|
| A big challenge we face as web developers is dealing with unknown
| variables.
(LOL, just got a Shelly Powers/Alpha Bits deja vu there).
To which the answer is:
| Enter Cappuccino and Atlas
| This is the space that the Cappuccino framework operates in. The team
| behind Cappuccino, 280 North bill it as a framework for building
| “desktop-caliber applications that run in a web browser”. They
| certainly seem to deliver on that promise, too. Just take a look at
| their demonstration 280 Slides product – an amazingly desktop-like
| tool in the style of Apple Keynote. This stuff is mind-blowingly cool.
"mind-blowingly cool".
That is about as interesting or useful as anything else Lawrence Krubner
has posted.
Garrett
Andrew Poulos
> Reading more Drew McClellan:-
> http://allinthehead.com/retro/337/the-cost-of-accessibility
>
> | As a web developer, there’s little I dislike more than building sites
> | to be accessible.
>
> Yikes! He goes on to say how accessibility is a pain in the "backside".
I took him to mean; although accessibility is important, building an
accessible web site can be difficult.
Andrew Poulos
Thomas 'PointedEars' Lahn
Not more difficult as writing proper HTML in the first place.
PointedEars
Jeremy J Starcher
> Andrew Poulos wrote:
>>
>> I took him to mean; although accessibility is important, building an
>> accessible web site can be difficult.
>
> Not more difficult as writing proper HTML in the first place.
Valid HTML 4.01 strict is a good start and making an accessible page[1],
but it isn't the end. Full accessibility includes providing alternative
content for images, audio and video as well as careful, for example.
< http://www.jan.wvu.edu/media/webpages.html > makes a nice summary of
several different things to keep in mind.
[1] Accessible in this context meaning more than just "can" be used. It
means "designed for" alternative (non-visual) user agents.
David Mark
> On Apr 14, 6:21 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > "Hidden" by default? There's a recipe for disaster.
>
> That's a false over-generalization. If you are trying to be super
> accessible and all that, sure, don't hide things by default. But
> internal webapps rarely have those types of concerns.
That is ridiculous. If you declare a display:none rule in CSS,
expecting to override it with script, you have just committed the
textbook accessibility blunder of creating a document that is
unreadable with script. Hard to imagine as the jQuery definition of
progressive enhancement applies only to script or no script (there is
no middle ground to be had.)
So, you are new to browser scripting and you define such a rule in CSS
and use:
el.style.display = '';
Oops, doesn't work. Now the aspiring author knows he/she has taken a
wrong turn. So they remove the CSS rule and now they may have FoUC,
which is simple enough to deal with (and a good lesson to learn.)
Now, you propose to call some ridiculous, ever-changing function that
requires computed styles, expandos, etc. *and* allows the beginner to
gloss right over a critical and crucial to understand blunder.
>
> > And how many
> > neophytes does it take to "hide/show" a table row (realize we aren't
> > even talking about visibility here?)
>
> I think it's fairly common, actually. Click on a row to expand
> "details" below it in another row.
So, use this:
el.style.display = '';
Simple, concise, one line, works in virtually every UA ever released,
doesn't change meaning over time, etc. Why, you could even
encapsulate that line in a function, perhaps asigning it only if:
typeof document.documentElement.style.display == 'string';
Now you know how to hide/show elements only if it is possible to do so
(some agents can't do it.) I'll leave the FoUC line as an exercise.
>
> > > Just look at .NET. Talk about a monster. It's way more horrendous than
> > I've seen it. It seems to be finally dying out.
>
> Perspective, I guess. In some areas it's growing.
>
> > BTDT. As with any large group, some listen, some don't. Make no
> > mistake, .NET is history.
>
> Everything is history at some point. I hope .NET dies out sooner
> rather than later. But that doesn't change the fact that it's built by
> a huge company, has lots of devoted developers who swear by it, is the
> back-bone of mission-critical webapps and web sites, and must satisfy
> a need for a huge number of people, even if you think it is horrible.
> Sounds a lot like jQuery (s/huge company/ninja/).
>
> > Hope none of their parents are on dial-up.
>
> People still use dial-up?
As you've been told, *lots* of people use dial-up. You know those
people with iPhones? Those are on dial-up at least some of the time.
Depending on the country and demographic, a significant percentage of
your prospective audience may be on dial-up. Broadband is expensive
in some areas. And regardless of the specific bandwidth or size of
the scripts involved, wasted time on worthless scripts means less time
for content.
>
> > I see you opened a ticket on the - each - function.
>
> I don't think I did? I did make a comment on an existing ticket, and I
> posted suggestions to the dev mailing list, referencing the thread
> here.
Whatever, the point is that the natives tore it down as an affront to
their idol. It would be more useful to add a balancing criticism
section to the jQuery Wikipedia entry. The current entry is an
infomercial. Certainly there are enough sources at this point to back
up a contrary view.
What's the point of an object that gathers DOM element references,
just to run them through a broken - each - conveyor to sputtering
grinders called attr, removeAttr, show, etc. You really expect
anything useful (or even predictable) to come of that, after all we
have seen in the last week?
And, as you well know, the big selling point for the wannabe are the
"plugins":
Just skip to the last message. They are re-enacting the year 2000 in
2009.
>
> > Would you be willing to buy a book on this?
>
> Sure, if by "book" you mean "pdf file" and by "buy" you mean "download
> for free".
I was referring to those jQuery books which should now be moved to the
fiction section. Who would buy such a thing now?
David Mark
> On Apr 12, 8:01 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> > On Apr 12, 7:44 pm, Lawrence Krubner <lkrub...@geocities.com> wrote:
>
> > > On Apr 12, 5:58 pm,DavidMark<dmark.cins...@gmail.com> wrote:
>
> > > > On Apr 12, 5:48 pm, Lawrence Krubner <lkrub...@geocities.com> wrote:
>
> > > > AFAIK, nobody here has ever said anything about writing all of your
> > > > own code from scratch, yet it is invariably the first rhetorical
> > > > question out of the gate from every doubting neophyte that shows up.
> > > > Where do you get that?
>
> > >David, you've a remarkably poor memory. Just earlier today you wrote:
>
> > > "Compared to any context-specific solution, jQuery is bloated and
> > > slow."
>
> > I remember that like it was yesterday.
>
> > > Check it out, you can read your own words here:
>
> > >http://groups.google.com/group/comp.lang.javascript/msg/dc9b78773cf5b7db
>
> > Why? Certainly I said nothing about writing everything from scratch.
> > I think I am starting to see where this is coming from.
>
> David, you don't seem to understand your own argument. When a
> programmer writes code, they can do one of two things:
>
> 1.) Reuse old code, that is, use a library.
>
> 2.) Write new code from scratch.
No, the unit of measure for Javascript code is the function, not the
"library." And how ridiculous is it to imply that I don't understand
my own position?
>
> Any reuse of old code means you're using a library. It doesn't matter
Nope.
> if that library is informal - just some functions you wrote that you
> like to reuse because you're comfortable with them - or formal and
> public like jQuery or Prototype or mootools.
There is nothing "formal" about any of those three. Are you kidding?
>
> You've argued against libraries, which means you are in favor of
> writing new code, from scratch. Anything that is a "context-specific
> solution", written just for one specific solution, involves writing
> new code from scratch.
Again, no.
David Mark
> On Apr 13, 4:10 am, Gregor Kofler <use...@gregorkofler.com> wrote:
>
> > Am Sun, 12 Apr 2009 16:36:34 -0700 schrieb Lawrence Krubner:
>
> > > These pre-packaged scripts allow designers to get a wide
> > > variety of effects without having to learn how to program.
>
> > No, that's /the/ misconception.
>
> > According to your logic graphics designers are supposed to congratulate
> > me upon my decision to use one of those fancy predefined webpage
> > templates, because it enables me to do "professional layouts" without
> > having to learn the basics of design. (Who cares if colors of fonts don't
> > match the chosen template, or the template doesn't match the CD of the
> > customer.)
>
> The standard I'd use is "How can we meet the customer's needs, at the
> lowest possible cost, for a given level of quality?" That doesn't mean
> that things should be low quality or low cost, but rather, that they
> clients need very high levels of quality, and some only need very low
> levels of quality.
Per whatever quality the client needs? I put it to you that most
clients do not need to maintain jQuery (or anything like it.) They
sure as hell don't need most of things usually done with jQuery. The
people who like "lightboxes" are the designers. They want sell "Ajax
sites." Get it?
>
> You are critical of those pre-package templates that only cost $29.99
> (or sometimes they are free), but I'd argue that, for a certain class
> of customer, those ultra-cheap templates are very successful. I've
> seen sites where the owners simply want to run a simple store, selling
> fishing gear, and the web site is a sideline to their real business.
> And these sites only generate $100 or $200 a week in sales, and
> therefore do not justify great expense. But the owners of such sites
> deserve to be congratulated for pulling together a working business
> model. The sites may not look great, but they are sufficient, and the
> business is able to attract customers. If you were to argue that the
> site should be built to a higher level of quality, you'd have to prove
> that the higher quality would bring in additional sales.
You take forever to say nothing. One thing is for sure, jQuery (or
the like) is a huge mistake for a commerce site. Don't be an idiot.
>
> Some very ugly sites are extremely successful. Jason Fried has argued
> that Drudge Report is one of the most successful sites on the web, and
> I agree with his reasoning:
>
> http://www.37signals.com/svn/posts/1407-why-the-drudge-report-is-one-...
I don't know who Jason Fried is, but I do know that domain. You are
actually citing those people? If Jason wrote that miserable slide
show of theirs, I suspect he was fried.
>
> The use of pre-package effects, such as those provided by jQuery UI,
> are exactly like the $29.99 templates. They do an excellent job of
> meeting the needs of a certain class of web site owner.
"Pre-package effects" in jQuery UI? You don't even know what you are
talking about.
David Mark
> On Apr 13, 4:32 am, Gregor Kofler <use...@gregorkofler.com> wrote:
>
> > Am Sun, 12 Apr 2009 14:06:40 -0700 schrieb Lawrence Krubner:
>
> > [snip]
>
> > > Why don't you just publish your scripts as a library then?
>
> > Yawn... The usual implied "if you can't do better, stop critizing". Apart
> > from that you *can* downloadMark'sscripts. But then: Are you capable of
> > assessing the code quality?
>
> I'd never argue that Mark should stop criticizing anyone. I'm arguing
> that, if his scripts are freely available, and no one uses them, then
> perhaps they are not as useful as he thinks they are.
That's not what you said at all. And there is a big difference
between freely available and freeware. By the same token, there is
quite a difference between posted and marketed to death.
There is also the typical fixation on the past, which is central to
arguments for things like jQuery (e.g. everybody is using them!)
>
> Your use of the word "quality" suggests that there is a single
> dimension by which we can measure code. Your implication is that we
> can use some official standard of code quality. Perhaps you're imaging
> a standard such as "How well does this code conform to well known,
> agreed upon principles of software design?"
Considering the current topic, you come off as a buffoon. Was that
your intent?
>
> However, there are many other, equally valid, dimensions by which code
> can be measured. For instance:
>
> 1.) How useful do people find this code?
Put it this way, if your code adds one and one and comes up with
three, somebody may still find it useful. That doesn't mean it is
good for them.
>
> 2.) How easy to use do people find this code?
They aren't having a very easy time of it at the moment. And
regardless, these things make it very easy to delude yourself. You
may think you have done something wonderful in ten minutes, but the
reality is very different.
>
> If people find code un-useful, or if they find it hard to work with,
> then I'd argue it is worth very little, regardless of its conformance
> to some well known standards of software design.
What code are you arguing about?
David Mark
> On Apr 13, 10:26 am, beegee <bgul...@gmail.com> wrote:
>
>
>
> > On Apr 12, 7:36 pm, Lawrence Krubner <lkrub...@geocities.com> wrote:
>
> > > That's just it. These pre-packaged scripts allow designers to get a
> > > wide variety of effects without having to learn how to program. The
> > > market demand for these scripts is exactly that they enable designers
> > > to do something new, without necessitating their spending time
> > > learning a new skill. This is something you could easily figure out
> > > for yourself. The people on this newsgroup seem intelligent, so if
> > > they are unable to figure out something so obvious, then they are
> > > being deliberately obtuse.
>
> > I guess. I also guess that programmers, not designers will end up
> > doing the maintenance on most of these sites (that is, if the site
> > does anything besides look pretty). I think a lot of companies who
> > follow the pack fail to understand what the "big boys" are really
> > doing. They are not hiring designers to code the front end. They
> > hire designers to design the front end and programmers to code it. If
> > production of web sites was truly designer driven then what you say
> > might be true but all you need to do is look at the sites linked to by
> > Smashing magazine to see a certain low-level of functionality common
> > to most (though I personally really like looking at them).
>
> > Those of us who fear having to maintain sites coded with jQuery have
> > more to fear from back end javascript generators like Rails
> > (prototype) and Microsoft MVC (jQuery). Those systems spit out
> > unreadable javascript at an alarming rate.
>
> Work on websites should be lead by the designers for the reasons I
> outlined here:
>
> http://www.teamlalala.com/blog/2009/03/01/the-problem-with-php-framew...
>
Not interested in your outlines, but does "choosing jQuery" fall under
the category of "leading" Websites?
David Mark
> On Apr 13, 6:33 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> > On Apr 12, 6:51 pm, Eric Bednarz <bedn...@fahr-zur-hoelle.org> wrote:
>
> > > Lawrence Krubner <lkrub...@geocities.com> writes:
> > > > This is intellectually lazy on your part. You could have just as
> > > > easily asked "What makes these scripts so popular with designers?"
>
> > > Because they are graphic (I suppose you mean) designers, so they
> > > a) don’t understand any of the problems and cannot judge its quality
> > > b) the API will likely appeal to them because they are not programmers
>
> > > > Or ever better: "Why do graphic designers use these pre-package
> > > > scripts?
>
> > > Are you seriously thinking that there is a relation between success and
> > > quality (in any field)?
>
> > > > Why don't they write their own code from scratch?"
>
> > > Eyeroll. Speaking about lazy, you haven’t been lurking here, right?
>
> > My favorite is "Why don't you write all of your sites in
> > assembler?!!!" This is usually parroted by people who have no idea
> > what assembly language is (they just thought it sounded like a geek-
> > chic thing to say.)
>
> > > Something you missed that you could just as easily have asked is:
> > > “What idiot would assign programming tasks to designers?”
>
> > Lots of them, but fewer now than three months back.
>
> Ah, yes. Because of your courageous willingness to stand against the
> conventional wisdom, the world is coming around to your way of seeing
> things.
There's no real wisdom to stand against. Tap it and the whole
argument falls right over.
> The millions of people who carefully read comp.lang.javascript
You are such an idiot. Do you think this is the only place such ideas
are discussed? Are you really ignorant of the fact that this
newsgroup has more influence on these stupid library efforts than
their authors?
> everyday have been dazzled by the brilliance of your arguments.
Your words.
> That
> respected publishing houses like O'Reilly have published books saying
> positive things about jQuery is of no matter.
Fixated on the past. Who cares how many books on jQuery have been
published in the last few years. They all turned out to be wrong.
[snip]
David Mark
> On Apr 14, 12:02 am, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> > On Apr 13, 10:39 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>
> > > On Apr 13, 5:33 pm,DavidMark<dmark.cins...@gmail.com> wrote:
>
> > > >http://groups.google.com/group/jquery-en/browse_thread/thread/ee5b53d...
> > > > How can it take so much work to be so utterly incompetent? These
> > > > people are too busy writing to stop and read anything.
>
> > > I just think it shows that people using jQuery are not usually hard-
> > > core programmers, and quite often not very familiar with javascript.
> > > People get confused. It's allowed in life.
>
> > I think that a collection of ostensible jQuery experts put their heads
> > together to solve a trivial browser scripting problem with their
> > favorite tool and turned it into a Chinese fire drill. The solution
> > that was ultimately recommended was a ridiculous end-around for a
> > script that is obviously just getting in the way. Did you see all of
> > those attr calls?
>
> > So much for the large and active developer community argument. These
> > discussions are taking place a week *after* I spelled out their
> > glaring, ten years too late oversight regarding the attr method. This
> > is one of many examples posted recently indicating that jQuery over-
> > complicates and even outright prevents the simplest of operations due
> > to abject incompetence. If that wasn't enough, the misconceptions are
> > ever-shifting, so it is as I once heard another disastrous API
> > (Windows) described, like stapling Jello.
>
> > > See, jQuery exists to fill a need that you (and many here) do not
> > > have. That is, to provide an API that more closely matches what the
> > > user is trying to accomplish and to implement it in the best possible
> > > (although often not ideal) way.
>
> > Your mind's gone. We aren't talking about anything close to
> > idealism. We are talking outright failures, maddening misconceptions
> > and near-constant upgrades of a script that is now almost completely
> > superfluous (they lopped off too many supported browsers for their own
> > good.)
>
> > > Setting obj.style.display="block" may
> > > be obvious to you, but $(obj).show() is way more obvious to someone
> > > new to scripting or who doesn't have a lot of time to invest in
> > > getting this part correct.
>
> > Who conducted that study?
>
> I have. At the various web design firms that I've worked at, I've had
> to work closely with designers. Over the last 10 years, I've gotten to
> know what they need and what they don't need. I've also had long
> conversations with clients, what they want, what goals they are trying
> to acheive.
>
> I've also had countless friends come up to me and say "I'd like to
> learn how to build web sites." I've taught several. The experience has
> helped me see what concepts they find easy to grasp, and which
> concepts they find difficult to grasp.
>
> Given those experiences, I understand why jQuery is gaining in
> popularity. It answers a real need.
>
> > > But no matter how much it may annoy you, people want to abstract
> > > browser scripting and not worry about the details. THAT is the problem
> > > that jQuery is trying to solve. For someone making a page for their
> > > child's basketball team without much experience in web development, a
> > > library like jQuery will allow them to add some animations, maybe make
> > > some tabs, perhaps even show pictures in a little "lightbox" that
> > > impresses all the other parents. Good for them! They don't care about
>
> > Unless they are blind, spastic, use mobile devices, hate Javascript,
> > use older browsers, use new browsers, etc., etc.
>
> > But I am willing to stipulate that such a trivial vanity page may be
> > the only justification for such a script. It's like using AOL's
> > builders to create a home page.
>
> You are expressing contempt for the software AOL makes available so
> that people can build a simple web page. And, really, your entire
> argument is based on this straight-forward elitism. Take away the
> elitism, and you have no argument at all. Once a person realizes that
> AOL's simple web page builder answers a real market need, then the
> person also understands how other efforts to make the web simple
> answers real market needs.
No, stupid. People are using the equivalent of AOL's builders to
create e-commerce sites, credit card forms, etc. Go read for a while.
David Mark
> On Apr 14, 7:21 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Apr 14, 3:51 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>
> > Who do you suppose will go back and swap out the entire jQuery library
> > when the next new browser comes out (or you discover that it doesn't
> > work that well with the latest releases.) Think a neophyte can debug
> > and test this spaghetti factory on top of whatever gibberish they
> > wrote? Nobody would bother. They sites just get thrown out like
> > disposable diapers. That is not how the Web works and certainly not
> > how business works.
>
> And yet, businesses use jQuery. Apparently this is the way business
> works.
A business that makes a foolish mistake? Who ever heard of such a
thing?
[snip]
David Mark
No it doesn't. It is another clueless maniac trying to "fix" PNG's
with scripted DirectX twiddling and browser sniffing. IE6 shipped ten
years ago. Use its built-in mechanism (conditional comments) to
include whatever extraneous CSS or scripts you need to replace or fix
PNG's. No other browser will ever see them. End of story.
[snip]
David Mark
> On Apr 14, 10:46 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>
> > On Apr 14, 6:21 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > "Hidden" by default? There's a recipe for disaster.
>
> > That's a false over-generalization. If you are trying to be super
> > accessible and all that, sure, don't hide things by default. But
> > internal webapps rarely have those types of concerns.
>
> That is ridiculous. If you declare a display:none rule in CSS,
> expecting to override it with script, you have just committed the
> textbook accessibility blunder of creating a document that is
> unreadable with script. Hard to imagine as the jQuery
Oops, without.
Matt Kruse
> > That's a false over-generalization. If you are trying to be super
> > accessible and all that, sure, don't hide things by default. But
> > internal webapps rarely have those types of concerns.
> That is ridiculous. If you declare a display:none rule in CSS,
> expecting to override it with script, you have just committed the
> textbook accessibility blunder of creating a document that is
> unreadable with script.
Luckily many of us never have to worry about that, even if we know
what the problem is and how to handle it.
> > People still use dial-up?
> As you've been told, *lots* of people use dial-up.
I don't know anyone, and luckily I don't have to be concerned about
it. Creating public sites for as many users as possible from anywhere
in the world is kind of a pain.
> > > I see you opened a ticket on the - each - function.
> > I don't think I did? I did make a comment on an existing ticket, and I
> > posted suggestions to the dev mailing list, referencing the thread
> > here.
> Whatever, the point is that the natives tore it down as an affront to
> their idol.
Actually, John Resig replied to my post on the dev list about each()
and said these were good ideas and he would see about working them in.
We'll see if they make it into a future release.
> I was referring to those jQuery books which should now be moved to the
> fiction section. Who would buy such a thing now?
I would never have bought a jQuery book. It is sufficiently simple
that no book purchase would be justified. Unless it has pictures of
Ninjas.
Matt Kruse
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Andrew Poulos wrote:
>>> I took him to mean; although accessibility is important, building an
>>> accessible web site can be difficult.
>> Not more difficult as writing proper HTML in the first place.
>
> Valid HTML 4.01 strict is a good start and making an accessible page[1],
> but it isn't the end. Full accessibility includes providing alternative
> content for images, audio and video as well as careful, for example.
That runs under "proper HTML" in my book.
An important advantage of HTML over other formats is that it degrades
gracefully by default. It is only that so few people seem to be able to
make good use of that feature. They rather ignore it and build ugly
script-only workarounds instead. And then they complain how hard it would
be to make HTML documents accessible.
(You may quote me on that.)
PointedEars
David Mark
> On Apr 16, 5:53 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > That's a false over-generalization. If you are trying to be super
> > > accessible and all that, sure, don't hide things by default. But
> > > internal webapps rarely have those types of concerns.
> > That is ridiculous. If you declare a display:none rule in CSS,
> > expecting to override it with script, you have just committed the
> > textbook accessibility blunder of creating a document that is
> > unreadable with script.
>
> Luckily many of us never have to worry about that, even if we know
> what the problem is and how to handle it.
So, hiding content away from those without scripting (e.g. many blind
people) is a minor concern? Are you really saying it is difficult to
hide/show elements without committing such an obvious blunder?
>
> > > People still use dial-up?
> > As you've been told, *lots* of people use dial-up.
>
> I don't know anyone, and luckily I don't have to be concerned about
> it. Creating public sites for as many users as possible from anywhere
> in the world is kind of a pain.
Welcome to the Web. See why jQuery is no good for it at all?
>
> > > > I see you opened a ticket on the - each - function.
> > > I don't think I did? I did make a comment on an existing ticket, and I
> > > posted suggestions to the dev mailing list, referencing the thread
> > > here.
> > Whatever, the point is that the natives tore it down as an affront to
> > their idol.
>
> Actually, John Resig replied to my post on the dev list about each()
> and said these were good ideas and he would see about working them in.
> We'll see if they make it into a future release.
What possible difference would that make? Also, re-read that thread.
Some plugin authors shot it down as they are using some undocumented
(or more undocumented than usual) method signature. Good luck!
>
> > I was referring to those jQuery books which should now be moved to the
> > fiction section. Who would buy such a thing now?
>
> I would never have bought a jQuery book. It is sufficiently simple
You know that is a lie. If not, re-read *this* thread.
> that no book purchase would be justified. Unless it has pictures of
> Ninjas.
One has a picture of a samurai on the cover. Appropriate for such an
inaccurate book.
Thomas 'PointedEars' Lahn
> Valid HTML 4.01 strict is a good start and making an accessible page[1],
> but it isn't the end. Full accessibility includes providing alternative
> content for images, audio and video as well as careful, for example.
>
> < http://www.jan.wvu.edu/media/webpages.html > makes a nice summary of
> several different things to keep in mind.
If one gets to be a Ph.D. for spreading this amount of FUD and nonsense
about HTML and accessibility, I want my diploma right now.
PointedEars
David Mark
Actually, I was thinking of another domain. However, the one above
uses XHTML transitional and Prototype, so their reasoning on "ugly
sites" isn't of much interest either.
The Natural Philosopher
> On Thu, 16 Apr 2009 23:57:17 +0200, Thomas 'PointedEars' Lahn wrote:
>> Andrew Poulos wrote:
>>> I took him to mean; although accessibility is important, building an
>>> accessible web site can be difficult.
>> Not more difficult as writing proper HTML in the first place.
>
> Valid HTML 4.01 strict is a good start and making an accessible page[1],
> but it isn't the end. Full accessibility includes providing alternative
> content for images, audio and video as well as careful, for example.
>
Indeed. Always bear in mind that your site, advertising expensive sports
equipment for the extremely physically able, must be accessible by a
broke brainless amoeba using IP over carrier pigeon transport at 20
bytes a day, running lynx on a an 8086 Venix machine.
To design your site otherwise, is to engaeg in illegal discrimination
aginst penniless amoebae.
> [1] Accessible in this context meaning more than just "can" be used. It
> means "designed for" alternative (non-visual) user agents.
Exactly. Make sure the olfactory plugins are available. And work.
Andrew Poulos
> Jeremy J Starcher wrote:
>> On Thu, 16 Apr 2009 23:57:17 +0200, Thomas 'PointedEars' Lahn wrote:
>>> Andrew Poulos wrote:
>>>> I took him to mean; although accessibility is important, building an
>>>> accessible web site can be difficult.
>>> Not more difficult as writing proper HTML in the first place.
>>
>> Valid HTML 4.01 strict is a good start and making an accessible
>> page[1], but it isn't the end. Full accessibility includes providing
>> alternative content for images, audio and video as well as careful,
>> for example.
>>
>
> Indeed. Always bear in mind that your site, advertising expensive sports
> equipment for the extremely physically able, must be accessible by a
> broke brainless amoeba using IP over carrier pigeon transport at 20
> bytes a day, running lynx on a an 8086 Venix machine.
>
> against penniless amoebae.
>
>
>> [1] Accessible in this context meaning more than just "can" be used.
>> It means "designed for" alternative (non-visual) user agents.
>
> Exactly. Make sure the olfactory plugins are available. And work.
Almost as funny as imaging you at a meeting explaining that the reason
why no people who rely on assistive technologies can access the
information on the pages you were paid to build is that you don't care
(about them).
Andrew Poulos
Gregor Kofler
> Indeed. Always bear in mind that your site, advertising expensive sports
> equipment for the extremely physically able, must be accessible by a
> broke brainless amoeba using IP over carrier pigeon transport at 20
> bytes a day, running lynx on a an 8086 Venix machine.
>
> To design your site otherwise, is to engaeg in illegal discrimination
> aginst penniless amoebae.
>
>
>> [1] Accessible in this context meaning more than just "can" be used.
>> It means "designed for" alternative (non-visual) user agents.
>
> Exactly. Make sure the olfactory plugins are available. And work.
I suppose meaningful semantics and properly filled alt and/or title
attributes would already deal with 90% of the shortcomings of todays
webpages when it comes to accessibility.
Gregor
--
http://www.gregorkofler.com
http://web.gregorkofler.com - vxJS, a JS lib in progress
The Natural Philosopher
Amoebae don't lobby governments.
For website design, they, and wood pigeons, may safely be ignored.
> Andrew Poulos
The Natural Philosopher
> Am Fri, 17 Apr 2009 09:33:27 +0100 schrieb The Natural Philosopher:
>
>> Indeed. Always bear in mind that your site, advertising expensive sports
>> equipment for the extremely physically able, must be accessible by a
>> broke brainless amoeba using IP over carrier pigeon transport at 20
>> bytes a day, running lynx on a an 8086 Venix machine.
>>
>> To design your site otherwise, is to engaeg in illegal discrimination
>> aginst penniless amoebae.
>>
>>
>>> [1] Accessible in this context meaning more than just "can" be used.
>>> It means "designed for" alternative (non-visual) user agents.
>> Exactly. Make sure the olfactory plugins are available. And work.
>
> I suppose meaningful semantics and properly filled alt and/or title
> attributes would already deal with 90% of the shortcomings of todays
> webpages when it comes to accessibility.
>
beings you probably are heading for a site design that will immediately
eliminate all but that lowest 1% of potential accessors.
And you certainly shouldn't be using javascript in any meaningful way.
'For everyone else, there is the telephone'..
Like homosexuality, I don't object to 'accessibility'. I just don't want
it to be made compulsory.
I note that everyiones favorite Irish airline, is proposing to weigh
people as well as their luggage, and charge accordingly. Is this
discrimination against fat people, or is not doing it discrimination
against thin people?
I think we should pass a law making the laws of physics allow aeroplanes
to fly on the same fuel, regardless of how much they weigh.
God, it seems, is a great discriminator. Why, apparently Heaven is a
closed shop, reserved for good Christians only. Manifestly unfair.
I bet they have flash movies there.
> Gregor
>
>