Just got word from Paul Irish that David Mark is refusing to provide
an open license for his attribute test suite - in fact he's
threatening legal action against me and the Software Freedom
Conservancy if we should "cop[y] one word or the tiniest aspect of the
design". Naturally, that branch with the test suite has been
completely deleted.
This attitude is why I refuse to read anything in comp.lang.javascript
and every single time I even get a whiff of what goes on over there I
completely regret it.
Matt, I definitely welcome your help or feedback to the jQuery
project, but please provide your own test cases, test suites, and bug
reports from now on - this goes for anyone else as well. As far as I'm
concerned comp.lang.javascript is completely tainted and using any
code or recommendations from them will be ignored.
This is pretty amusing, actually - threatening legal action against
others for using common-sense test cases is a sure-fire way to make
sure that no one with any sense will read or use the contents in
comp.lang.javascript again.
So it goes. If anyone that hasn't read the aforementioned thread/tests
is interested in writing up some more-comprehensive attribute tests
for us we'd definitely appreciate it.
--John
On Fri, Dec 11, 2009 at 4:08 PM, John Resig <jere...@gmail.com> wrote:
>> For example:
>> <input type="checkbox" id="x" readonly="readonly">
>>
>> $('#x').attr('readonly') === true
>>
>> This is a boolean property of the element, not its attribute value.
>> The name attr() implies that it deals with attributes. But the code
>> actually gets/sets properties as the first line of business. I would
>> expect to get back the string "readonly".
>
> Interesting that you expect that since that directly contradicts the
> test suite that you recommended. (It requires the boolean properties
> to always return true or false.) Currently (according to the suite)
> the only boolean property that jQuery fails on is "ismap".
>
>> But isn't the attr() method supposed to get the height _attribute_
>> value? If the attribute is set to "5" and I manipulate it via js, I
>> still want to get "5" if I look for the attribute value. Otherwise I
>> would just call height().
>>
>> So now the attr() method either calls a jQuery method, gets/sets an
>> element's property, or gets/sets an element's attribute. How is a user
>> supposed to know what to expect? What exactly is the attr() method
>> intended to do, if not get/set an element's attributes?
>>
>> Calling attr() becomes a crap-shoot, because you can never be sure
>> what it's going to do inside.
>
> I disagree - if anything it helps to bring clarity to the API.
> .attr("width") and .width() now return the same value. No reason to
> try and return elem.style.width or elem.width if they're not going to
> provide a consistent cross-browser value.
>
>>> > 3) The list in jQuery.props is still incomplete
>>> Do you have any specific examples?
>>
>> cellPadding, useMap, accessKey, et al.
>
> Out of those we already support useMap - I see a few more edge cases
> in the aforementioned test suite, doesn't seem hard to integrate those
> (although it hardly seems like a systemic issue in this regard).
>
>>> > 4) The "special" cases list is still incomplete
>>> Do you have any specific examples?
>>
>> How about 'action'?
>
> Ah, in that how the URL is resolved - sure, that's a reasonable fix,
> just adding it to the current list of checks.
>
>> But now you have an setAttribute wrapper that causes a script error
>> when passed values that would work just fine with setAttribute(). This
>> seems like a step backwards.
>
> It's only a backwards step if you're attempting to use .attr() as a
> glorified way to set DOM 0 events - which is not really something that
> jQuery is designed for nor does it encourage.
>
>> This is core functionality, and filing/patching bugs on specific
>> problems with individual attributes wouldn't be very helpful. In fact,
>> that's perhaps what lead to the method being in the state it is (with
>> attmpted special cases for tabindex, selected, etc). Instead, I think
>> someone needs to step back and identify _exactly_ what it is that attr
>> () is supposed to do, and then code to that standard. Kind of hard now
>> that you want to maintain backwards-compatibility with this kind of
>> hybrid functionality, though. Throwing in the hidden execution of
>> jquery methods when trying to retrieve attribute values just adds to
>> the confusion even more, and I'm not sure what exactly attr() is
>> trying to accomplish if that is seen as necessary.
>
> At least looking at the current test suite results I'm not really
> seeing any major systemic issues. Of the 9 currently failing tests in
> Firefox 3.5 8 of them are cases where the suite is expecting a null
> value when an attribute doesn't exist. A few of these I would want to
> investigate more but in general I'm not seeing the need for so much
> chicken-littling.
>
> In short, constructive ways of contributing include: filing bugs,
> constructing test cases, and building reproducible test suites. The
> linked-to test suite definitely helps to push this in the right
> direction. We can fix bugs based upon that and if we see systemic
> issues with the method we can certainly rewrite it. Since 1.4 final
> isn't out yet there is still room to make some backwards-incompatible
> changes (especially if we start reporting null instead of the default
> value for attributes).
>
> --John
>
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
