Prev: Crockford is going to speak again today
Next: Want / Need Genuine Google Adsense Account for Rs.300/-
From: David Mark on 2 Apr 2010 10:07
S.T. wrote:
> On 3/31/2010 9:16 PM, RobG wrote:
>> On Apr 1, 8:35 am, "S.T."<a...(a)anon.com> wrote:
>>> On 3/31/2010 1:57 PM, David Mark wrote:
>>>
>>>> I don't think it takes an endless "rant" to get across what Richard has
>>>> already said: it is *insane* to just jQuery to read and write form
>>>> control values.
>>>
>>> Richard sent the poster off to, in the true spirit of the cljs FAQ, a
>>> verbose ~8 page technical analysis of the subject - albeit, after
>>> answering the OP's question.
>>
>> Richard first concisely and thoroughly answered the OPs question[1],
>> then provided a link to a resource that provides more general help
>> regarding access to form controls. The thinly veiled criticism in your
>> response seems to find fault with that.
>>
>> Perhaps you'd rather the OP posted in the jQuery "Getting started"
>> forum, where the chance of getting any answer at all is little better
>> than 50/50 and the chance of getting an accurate, comprehensive answer
>> such as that offered by Richard is very nearly zero.
>
> I didn't have a problem with Richard's answer of the OP's question. I
> even mentioned he answered the question. Perhaps I should have added he
> answered it well, which he did.
>
> However then adding it's "insane" to use jQuery for this and steering
> him/her to an 8-page technical thesis as the preferred alternative is
> quite a leap of faith.

Eight whole pages? And don't you think it would be well worth the time
for programmers who seek to manipulate form controls to know the
technical details. As Richard noted, if you can understand the elements
collection, you have all you need to write bullet-proof scripts in this
area that will run in virtually _any_ existing browser (and likely all
future browsers as well). Seems well worth the "effort" required to get
through it. I mean, how many pages are in the average children's book?

>
>>
>>> The vastly overcomplicated 'resource' is an
>>> excellent example of why projects such as jQuery are so popular
>>
>> By comparison, the simplistic jQuery documentation is more concise
>> mostly because it is not only inaccurate, but incomplete. It includes
>> gems like:
>>
>> "In the case of<select multiple="multiple"> elements,
>> the .val() method returns an array containing each
>> selected option."
>>
>> Does val() really return (references to) elements, or their values?
>
> Really? The method's name doesn't provide a hint?

A hint that is seemingly contradicted by the less-than-technical
explanation. And what was the point of calling it "val" rather than
something like "inputValue" (less typing?)

>
>> Where is the explanation of the handling of the value attribute and
>> text content for option elements?
>
> Isn't that more an HTML spec?

It is, and isn't that something that the aspiring jQuery ninja should
know about? They certainly won't learn it from the jQuery
documentation, so posting a link to the "voluminous" FAQ article, which
links to the specs, would seem prudent. The only leap of faith was to
think that jQuery users would care to wade through eight whole pages
(too busy gettin' stuff done in their "real world").

> If an option doesn't have a value
> attribute, it's value is the contents of the option.

Here's the rub. John Resig has _never_ understood the difference
between property values and attributes. This is one of many cases where
such ignorance is likely to bite the blissfully ignorant users of his
"software". See how that works? It's not about bugs, but a (very) bad
design by people who don't know near enough to create a good one. Of
course, some psuedo-intellectual apologist lunatics will tell you that's
just a minor detail that they don't "care" about. :)

>
> ... and on and on. The jQuery docs aren't perfect but they're pretty
> good.

No they aren't. They are a far cry from any flavor of good. And they
will never approach good as the authors do not understand the subject
well enough to explain it to others.

> Trying to document every possible contingency leads to something
> like the cljs FAQ, which is a clear example of "too many cooks in the
> kitchen" and complete overkill for the casual DOM scripter.

Casual DOM scripter? Would you hire such a person to enhance your
public presence? We are talking about programming, not skateboarding.
First  |  Prev  | 
Pages: 1 2 3
Prev: Crockford is going to speak again today
Next: Want / Need Genuine Google Adsense Account for Rs.300/-