Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
I read through the thread again last evening, and mulled it over last
night, and I now agree that there is just too much room for confusion
(at least at this point) especially since .attr() has always behaved
in a particular manner. We can re-explore the issue once we have a
better grasp of how all the existing attributes behave.
I've left in the functionality that was there but severely limited it
- you can only use it from an object and only if you pass in 'true' as
the second argument, like so:
.attr({ height: 10, html: ... }, true)
More importantly though, the functionality is now exposed as a
quick-setter for newly-created DOM elements, like so (which is,
ultimately, the result I was trying to achieve with the .attr()
changes anyway):
$(div, { height: 10, html: ..., id: test, click: fn })
Note that the above doesn't take a context, thus it only works on the
current document (which is fine, since we wouldn't want to use the
method setters on non-HTML documents anyway), and it looks for an
argument that matches isPlainObject(). Also note that it doesn't work
with selectors or more-complicated HTML strings - only for standalone
element creation (div, div/, and div/div - for example).
The code is landed here along with test cases:
http://github.com/jquery/jquery/commit/d40083c866738727aa7ffd7f13d2955bc9575d5e
--John
On Thu, Dec 17, 2009 at 3:26 PM, Leeoniya leeon...@gmail.com wrote:
i agree with matt on this 100%.
an attr() method should return the attribute's value, always. there
are way too many common cases when interpretation would make this
method unreliable and unusable. making something that has so much
functionality overlap with css() is not good at all, especially when
it is both a getter and a setter. attr('width') would get the computed
width but attr('width', '5') sets the width attribute? there's too
much room for ambiguity in my opinion.
if anything it is much more confusing for beginners, not easier...when
an attr() method returns NOT the value of attr, and will cause MANY
more problems than is solves. when you're a beginner, you dont need
magic methods with names that imply specific strict functionality.
you can introduce a new method..maybe getComputed(), .computed() or
something similar.
Leon
--
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.
--
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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
# jere...@gmail.com / 2009-12-18 12:52:08 -0500:
I read through the thread again last evening, and mulled it over last
night, and I now agree that there is just too much room for confusion
Thanks for the consideration! IMO (and from my experience) .attr is
needlessly magic and inconsistent (esp. Matt's point regarding readonly
is spot on).
More importantly though, the functionality is now exposed as a
quick-setter for newly-created DOM elements, like so (which is,
ultimately, the result I was trying to achieve with the .attr()
changes anyway):
$(div, { height: 10, html: ..., id: test, click: fn })
Note that the above doesn't take a context, thus it only works on the
current document (which is fine, since we wouldn't want to use the
method setters on non-HTML documents anyway),
What about (i)frames?
--
Roman Neuhauser
--
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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
What about (i)frames? In that case just use the jQuery inside the (i)frame. I'm fine punting on that as well. Optimized for the very-most-common case. --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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
I'm curious about what the rationale was for having .attr('height')
return the same thing as .css('height'). Was it just in case people
use the wrong method?
I could see the usefulness of having .attr('height') return the actual
attribute value in cases where, for example, I needed to see whether
the current height of an element is less than or greater than the
height set by the attribute.
--Karl
On Dec 17, 2009, at 11:29 AM, John Resig wrote:
I would be much more convinced if there were examples where:
1) People were legitimately using inline-specified height/width and in
a way that was different from specifying the value in pixels and in
way that was superior to using CSS.
2) The returned result from .height() (not .attr('height'), since
that's been temporarily disabled) was somehow different from the
expected value.
For the moment ignore XML documents, I think it probably makes sense
to disable attrFn on XML documents.
--John
On Thu, Dec 17, 2009 at 6:45 AM, alexander farkas
a.farkas...@googlemail.com wrote:
The way how jQuery does mixing properties with attributes is a very
clever thing. One simple API for multiple different things is a very
nice thing, but has its constraints.
An example:
jQuery returns the value-property on form-elements, instead of the
value-attribute. This is a really good thing, because
a) a lot of novice developers don´t know about the difference and are
expecting this behavior
b) more advanced developers know the difference, but want in general
to know the value-property of a form element
With other words the developer gets what he/she wants/expects here.
But if jQuery starts to make .attr('height') equal to .height(), the
behavior becomes very unexpected. Everybody knows that the height-
attribute can be simply overridden by using css. This is why a
developer would use height to get the height-dimension of an element
and if a developer wants to know what the height-attribute, he would
call attr('height').
If you change your API to this behavior you will
a) break existing code
a) do unexpected things
b) you don´t have a jQuery-method, wich returns the height-/width-
attribute anymore
To be clear:
I think, you did a great job mixing properties and attributes and if
you know start to take this a step further, I am also on your side,
but you have to make wisley decissions (and small steps) here.
If you can solve the discrepancy in event-binding with attr, Robert
is
mentioing, it could be a nice feature, but please don´t do this with
height/width!
On 17 Dez., 11:28, Már Örlygsson mar.orlygs...@gmail.com wrote:
Never ever, would I have guessed that .attr('height') would
report a
value on elements that don't have an explicit height `attr`ibute.
Somehow I have the feeling that it would be useful for developers to
be able to access plain old element attributes - in a cross-browser
way - without any overt aliasing/magic.
--
Már
--
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
.
--
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
.
--
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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
Just to clarify: .attr(height) no longer exists.
--John
On Thu, Dec 17, 2009 at 11:47 AM, Karl Swedberg k...@englishrules.com wrote:
I'm curious about what the rationale was for having .attr('height') return
the same thing as .css('height'). Was it just in case people use the wrong
method?
I could see the usefulness of having .attr('height') return the actual
attribute value in cases where, for example, I needed to see whether the
current height of an element is less than or greater than the height set by
the attribute.
--Karl
On Dec 17, 2009, at 11:29 AM, John Resig wrote:
I would be much more convinced if there were examples where:
1) People were legitimately using inline-specified height/width and in
a way that was different from specifying the value in pixels and in
way that was superior to using CSS.
2) The returned result from .height() (not .attr('height'), since
that's been temporarily disabled) was somehow different from the
expected value.
For the moment ignore XML documents, I think it probably makes sense
to disable attrFn on XML documents.
--John
On Thu, Dec 17, 2009 at 6:45 AM, alexander farkas
a.farkas...@googlemail.com wrote:
The way how jQuery does mixing properties with attributes is a very
clever thing. One simple API for multiple different things is a very
nice thing, but has its constraints.
An example:
jQuery returns the value-property on form-elements, instead of the
value-attribute. This is a really good thing, because
a) a lot of novice developers don´t know about the difference and are
expecting this behavior
b) more advanced developers know the difference, but want in general
to know the value-property of a form element
With other words the developer gets what he/she wants/expects here.
But if jQuery starts to make .attr('height') equal to .height(), the
behavior becomes very unexpected. Everybody knows that the height-
attribute can be simply overridden by using css. This is why a
developer would use height to get the height-dimension of an element
and if a developer wants to know what the height-attribute, he would
call attr('height').
If you change your API to this behavior you will
a) break existing code
a) do unexpected things
b) you don´t have a jQuery-method, wich returns the height-/width-
attribute anymore
To be clear:
I think, you did a great job mixing properties and attributes and if
you know start to take this a step further, I am also on your side,
but you have to make wisley decissions (and small steps) here.
If you can solve the discrepancy in event-binding with attr, Robert is
mentioing, it could be a nice feature, but please don´t do this with
height/width!
On 17 Dez., 11:28, Már Örlygsson mar.orlygs...@gmail.com wrote:
Never ever, would I have guessed that .attr('height') would report a
value on elements that don't have an explicit height `attr`ibute.
Somehow I have the feeling that it would be useful for developers to
be able to access plain old element attributes - in a cross-browser
way - without any overt aliasing/magic.
--
Már
--
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.
--
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.
--
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.
--
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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
Like Karl said, I have had cases where I want to compare the current
height of an element with what was specified. I've also had cases
where height=x were hard-coded in the html and I wanted to access
the value (without having control over the html to use css, just
injecting script into the page).
We don't provide a way to get at the original height, or color, or
left offset of an element via .css() and somehow people still manage -
I'm not sure why this should be any different. Additionally it's not
clear that .height() would be returning a different value than the one
that was originally embedded in the page (at least until it's further
manipulated - at which point the current value is the expected result
anyway).
Much of this comes back to the intention of .attr() - I think that
.attr() should work more like .css(). Giving you the current,
computed, attribute value - and should actively try to route around
unexpected values (such as .value returning useless values on selects
or making sure that rowSpan and colSpan will always return a value on
TDs even if one isn't set).
I'm not sure that a good way to define requirements is to ask whether
or not anyone would do it that way, and whether they had a good enough
reason to do so. When attr() retrieves property/attribute values in
almost all other cases, and the user can easily map the results to the
source, then introducing new behavior with height() etc only adds
confusion. You cannot explain simply what value will be returned,
because the height() logic is convoluted. And it considers margins and
padding, etc, which is _not_ the same as the height of the element
itself.
Here is my argument: Users can already get the computed height using
height(). There is no compelling reason to return the computed height
when doing attr('height'). In fact, making this change _removes_
functionality, and forces the user to manually code property/attribute
access if they want to retrieve the value in the source.
Actually, the compelling reason is that the specified attribute height
will quickly lose sync with the actual height of the element.
iframe height=100.../
$(iframe).height( 1 ).attr(height)
// 100... but it's height isn't 100 any more.
Getting the current, computed, value is much more useful and
practical to everyday users. height attributes are simply a bit of
legacy left over from ancient documents (as is bgcolor and inline
onTYPE event handlers). If we cut the crufty legacy code we can build
APIs that are much more cohesive and match the intentions and
expectations of the user better.
On a related note, you said that the inserted method-calling
functionality was too broad. What attributes do you plan to map to
methods - just height and width? Or more?
Initially it mapped to anything in jQuery.fn. Now it just maps to some
of the common getter/setters in jQuery: val, css, html, text, data,
width, height, and offset (and the events).
--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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
Actually, the compelling reason is that the specified attribute height will quickly lose sync with the actual height of the element. iframe height=100.../ $(iframe).height( 1 ).attr(height) // 100... but it's height isn't 100 any more. Getting the current, computed, value is much more useful and practical to everyday users. height attributes are simply a bit of legacy left over from ancient documents (as is bgcolor and inline onTYPE event handlers). If we cut the crufty legacy code we can build APIs that are much more cohesive and match the intentions and expectations of the user better. An alternative that might work here - and one that would go together with a mapping of the available attributes - is to simply deprecate the use of certain attributes (height, width, bgcolor, onTYPE, etc. come to mind off hand). It's pretty easy to do if we just point people towards the alternatives that we already provide. Then we can focus all of our energy on just making the remaining set of attributes work identically (and expectedly) across all platforms. --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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
The only time that I can think of where one would want to use
.attr('onclick', function() { /.../ }); is Highslide... it actually runs
a regex on each A tag to see if the string hs.expand is in the onclick
attribute.
Rick Waldron wrote:
I've been reading this thread right along and I apologize for being
the late one to the party, and I wasn't going to bother, because its
not at the core of the discussion, but I'm still perplexed.
Why would you want to use:
.attr('onclick', function() { /../ });
When exists:
.click(function() { /../ })
.bind('click', function() { /../ })
.live('click', function() { /../ })
.
Or, this? What practical application does this have? Where a dev would
set the height of an element with the height of the same element.
$o.attr('height',$o.attr('height'))
...I understand that in the context of test cases, round-trip value
getting/setting ensures that methods are reliable, but in the real world?
Perhaps my understanding of javascript beyond jquery is the reason,
but I've never, not even once, had an issue with attr() doing what *I
intended* it to do - like I said, it could be because I'm not
expecting it to do anything particularly zany, like setting a value
with the same value from the same source.
Also, for a method that you're so quick to call broken, I decided to
do a reality check of code that is expected to *always and only work
with jQuery*... I dug through jQuery UI 1.7.2 and i found something
not-too-shocking: only 1 occurrence of getAttribute (in
datepicker... line 6166), 1 occurrence of setAttributeNS() (in $.ui.*
) and 1 occurrence of removeAttributeNS() (in $.ui.*). 47 occurrences
of .attr() (a mix of string and object argument syntaxes) and 12
.removeAttr()'s
jQuery UI is more then expected to work browser independently, its
implied by its use.
Furthermore, after looking at that site you referenced several times
(that i will not copy/paste here), I second a move to 100% ban all
references, along with the newsgroup you cited. I realize you feel as
though ignoring certain sources might leave you in the dark, but my
advice would be to try and steer clear of bad information.
On Tue, Dec 15, 2009 at 3:22 PM, Matt m...@thekrusefamily.com
mailto:m...@thekrusefamily.com wrote:
On Dec 15, 11:32 am, John Resig jere...@gmail.com
mailto:jere...@gmail.com wrote:
I think this is a great approach, and I hope it goes
somewhere. How
exactly can I help with it?
Categorizing the types would be a great start. Types that should
just work, Types that should return booleans, types that we
obviously don't care about (attributes of isindex, for example), and
attributes that we provide better alternatives for (Using .click()
instead of .attr(onclick, fn), for example).
I will take a look at this. I may come to different conclusions than
you, but I will propose something. Having a dump of all the attributes
and documenting what to expect from each would be fantastic.
Because height() tries to do so much magic, it ends up that this:
$o.attr('height',$o.attr('height'));
I was 100% serious about a ban concerning everything from CLJ.
Please,
original ideas/concerns/bug reports/test cases only.
Seems petty to me. There is a good test case there that illustrates
the problem. I'm not going to reproduce it to shelter jQuery from CLJ.
Nevertheless, since attr() calls height() for both getter and setter,
the real problem is that
$o.height( $o.height() )
is not reliable in some cases. So perhaps the issue is there, instead
of with attr().
On the whole though, I'd recommend to just stop reading the group as
who knows what they will try to pull next.
I've never been a fan of head-in-the-sand. I can find the pearls of
wisdom in the posts there without taking anything personally. And
there is a lot of good, robust, deep stuff posted there that you won't
find in blog posts or discussions here. To each his own.
Matt Kruse
--
You received this message because you are subscribed to the Google
Groups jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
mailto:jquery-dev@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
mailto:jquery-dev%2bunsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
I've searched the source... maybe I missed it, but I cant find your
example...
http://highslide.com/highslide/highslide-full.js
http://highslide.com/highslide/highslide-full.jsRick
On Tue, Dec 15, 2009 at 5:03 PM, Robert E. Rothermel III
thirden...@gmail.com wrote:
The only time that I can think of where one would want to use
.attr('onclick', function() { /.../ }); is Highslide... it actually runs a
regex on each A tag to see if the string hs.expand is in the onclick
attribute.
Rick Waldron wrote:
I've been reading this thread right along and I apologize for being the
late one to the party, and I wasn't going to bother, because its not at the
core of the discussion, but I'm still perplexed.
Why would you want to use:
.attr('onclick', function() { /../ });
When exists:
.click(function() { /../ })
.bind('click', function() { /../ })
.live('click', function() { /../ })
.
Or, this? What practical application does this have? Where a dev would
set the height of an element with the height of the same element.
$o.attr('height',$o.attr('height'))
...I understand that in the context of test cases, round-trip value
getting/setting ensures that methods are reliable, but in the real world?
Perhaps my understanding of javascript beyond jquery is the reason, but
I've never, not even once, had an issue with attr() doing what *I intended
* it to do - like I said, it could be because I'm not expecting it to do
anything particularly zany, like setting a value with the same value from
the same source.
Also, for a method that you're so quick to call broken, I decided to do
a reality check of code that is expected to *always and only work with
jQuery*... I dug through jQuery UI 1.7.2 and i found something
not-too-shocking: only 1 occurrence of getAttribute (in datepicker... line
6166), 1 occurrence of setAttributeNS() (in $.ui.* ) and 1 occurrence of
removeAttributeNS() (in $.ui.*). 47 occurrences of .attr() (a mix of string
and object argument syntaxes) and 12 .removeAttr()'s
jQuery UI is more then expected to work browser independently, its
implied by its use.
Furthermore, after looking at that site you referenced several times
(that i will not copy/paste here), I second a move to 100% ban all
references, along with the newsgroup you cited. I realize you feel as though
ignoring certain sources might leave you in the dark, but my advice would be
to try and steer clear of bad information.
On Tue, Dec 15, 2009 at 3:22 PM, Matt m...@thekrusefamily.com wrote:
On Dec 15, 11:32 am, John Resig jere...@gmail.com wrote:
I think this is a great approach, and I hope it goes somewhere. How
exactly can I help with it?
Categorizing the types would be a great start. Types that should
just work, Types that should return booleans, types that we
obviously don't care about (attributes of isindex, for example), and
attributes that we provide better alternatives for (Using .click()
instead of .attr(onclick, fn), for example).
I will take a look at this. I may come to different conclusions than
you, but I will propose something. Having a dump of all the attributes
and documenting what to expect from each would be fantastic.
Because height() tries to do so much magic, it ends up that this:
$o.attr('height',$o.attr('height'));
I was 100% serious about a ban concerning everything from CLJ. Please,
original ideas/concerns/bug reports/test cases only.
Seems petty to me. There is a good test case there that illustrates
the problem. I'm not going to reproduce it to shelter jQuery from CLJ.
Nevertheless, since attr() calls height() for both getter and setter,
the real problem is that
$o.height( $o.height() )
is not reliable in some cases. So perhaps the issue is there, instead
of with attr().
On the whole though, I'd recommend to just stop reading the group as
who knows what they will try to pull next.
I've never been a fan of head-in-the-sand. I can find the pearls of
wisdom in the posts there without taking anything personally. And
there is a lot of good, robust, deep stuff posted there that you won't
find in blog posts or discussions here. To each his own.
Matt Kruse
--
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.comjquery-dev%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
I think these lines, for example:
isHsAnchor : function (a) {
return (a.onclick a.onclick.toString().replace(/\s/g, '
').match(/hs.(htmlE|e)xpand/));
},
That is some awful, awful, code. Considering that this code in no way
uses jQuery I don't see how making the changes would cause any
negative side effect.
--John
On Wed, Dec 16, 2009 at 12:08 PM, Rick Waldron waldron.r...@gmail.com wrote:
I've searched the source... maybe I missed it, but I cant find your
example...
http://highslide.com/highslide/highslide-full.js
Rick
On Tue, Dec 15, 2009 at 5:03 PM, Robert E. Rothermel III
thirden...@gmail.com wrote:
The only time that I can think of where one would want to use
.attr('onclick', function() { /.../ }); is Highslide... it actually runs a
regex on each A tag to see if the string hs.expand is in the onclick
attribute.
Rick Waldron wrote:
I've been reading this thread right along and I apologize for being the
late one to the party, and I wasn't going to bother, because its not at the
core of the discussion, but I'm still perplexed.
Why would you want to use:
.attr('onclick', function() { /../ });
When exists:
.click(function() { /../ })
.bind('click', function() { /../ })
.live('click', function() { /../ })
.
Or, this? What practical application does this have? Where a dev would set
the height of an element with the height of the same element.
$o.attr('height',$o.attr('height'))
...I understand that in the context of test cases, round-trip value
getting/setting ensures that methods are reliable, but in the real world?
Perhaps my understanding of javascript beyond jquery is the reason, but
I've never, not even once, had an issue with attr() doing what I intended it
to do - like I said, it could be because I'm not expecting it to do anything
particularly zany, like setting a value with the same value from the same
source.
Also, for a method that you're so quick to call broken, I decided to do
a reality check of code that is expected to always and only work with
jQuery... I dug through jQuery UI 1.7.2 and i found something
not-too-shocking: only 1 occurrence of getAttribute (in datepicker... line
6166), 1 occurrence of setAttributeNS() (in $.ui.* ) and 1 occurrence of
removeAttributeNS() (in $.ui.*). 47 occurrences of .attr() (a mix of string
and object argument syntaxes) and 12 .removeAttr()'s
jQuery UI is more then expected to work browser independently, its implied
by its use.
Furthermore, after looking at that site you referenced several times (that
i will not copy/paste here), I second a move to 100% ban all references,
along with the newsgroup you cited. I realize you feel as though ignoring
certain sources might leave you in the dark, but my advice would be to try
and steer clear of bad information.
On Tue, Dec 15, 2009 at 3:22 PM, Matt m...@thekrusefamily.com wrote:
On Dec 15, 11:32 am, John Resig jere...@gmail.com wrote:
I think this is a great approach, and I hope it goes somewhere. How
exactly can I help with it?
Categorizing the types would be a great start. Types that should
just work, Types that should return booleans, types that we
obviously don't care about (attributes of isindex, for example), and
attributes that we provide better alternatives for (Using .click()
instead of .attr(onclick, fn), for example).
I will take a look at this. I may come to different conclusions than
you, but I will propose something. Having a dump of all the attributes
and documenting what to expect from each would be fantastic.
Because height() tries to do so much magic, it ends up that this:
$o.attr('height',$o.attr('height'));
I was 100% serious about a ban concerning everything from CLJ. Please,
original ideas/concerns/bug reports/test cases only.
Seems petty to me. There is a good test case there that illustrates
the problem. I'm not going to reproduce it to shelter jQuery from CLJ.
Nevertheless, since attr() calls height() for both getter and setter,
the real problem is that
$o.height( $o.height() )
is not reliable in some cases. So perhaps the issue is there, instead
of with attr().
On the whole though, I'd recommend to just stop reading the group as
who knows what they will try to pull next.
I've never been a fan of head-in-the-sand. I can find the pearls of
wisdom in the posts there without taking anything personally. And
there is a lot of good, robust, deep stuff posted there that you won't
find in blog posts or discussions here. To each his own.
Matt Kruse
--
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.
--
You received this message because you are
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
Line 688... I saw it because I was trying to use .live() and this check
shot that to pieces... If the link doesn't pass this check it's assumed
to not be a Highslide link, even if the link has the highslide class
applied.
isHsAnchor : function (a) {
return (a.onclick a.onclick.toString().replace(/\s/g, '
').match(/hs.(htmlE|e)xpand/));
}
It's a bad idea, imho. The writers of the library assumed that every
link could have it's own custom display parameters as part of the
onclick handler... something like a onclick=return hs.expand(this, {
/* options */ }; ... The problem is that the options should still be
stored in an external JS to be semantic, and if you try to do a full
page of images (a gallery or contents table in a store) with Highslide
handlers on each image, it's an incredible amount of code fluff.
Rob
Rick Waldron wrote:
I've searched the source... maybe I missed it, but I cant find your
example...
http://highslide.com/highslide/highslide-full.js
Rick
On Tue, Dec 15, 2009 at 5:03 PM, Robert E. Rothermel III
thirden...@gmail.com mailto:thirden...@gmail.com wrote:
The only time that I can think of where one would want to use
.attr('onclick', function() { /.../ }); is Highslide... it
actually runs a regex on each A tag to see if the string
hs.expand is in the onclick attribute.
Rick Waldron wrote:
I've been reading this thread right along and I apologize for
being the late one to the party, and I wasn't going to bother,
because its not at the core of the discussion, but I'm still
perplexed.
Why would you want to use:
.attr('onclick', function() { /../ });
When exists:
.click(function() { /../ })
.bind('click', function() { /../ })
.live('click', function() { /../ })
.
Or, this? What practical application does this have? Where a dev
would set the height of an element with the height of the same
element.
$o.attr('height',$o.attr('height'))
...I understand that in the context of test cases, round-trip
value getting/setting ensures that methods are reliable, but in
the real world?
Perhaps my understanding of javascript beyond jquery is the
reason, but I've never, not even once, had an issue with attr()
doing what *I intended* it to do - like I said, it could be
because I'm not expecting it to do anything particularly zany,
like setting a value with the same value from the same source.
Also, for a method that you're so quick to call broken, I
decided to do a reality check of code that is expected to *always
and only work with jQuery*... I dug through jQuery UI 1.7.2 and i
found something not-too-shocking: only 1 occurrence of
getAttribute (in datepicker... line 6166), 1 occurrence of
setAttributeNS() (in $.ui.* ) and 1 occurrence of
removeAttributeNS() (in $.ui.*). 47 occurrences of .attr() (a
mix of string and object argument syntaxes) and 12 .removeAttr()'s
jQuery UI is more then expected to work browser independently,
its implied by its use.
Furthermore, after looking at that site you referenced several
times (that i will not copy/paste here), I second a move to 100%
ban all references, along with the newsgroup you cited. I realize
you feel as though ignoring certain sources might leave you in
the dark, but my advice would be to try and steer clear of bad
information.
On Tue, Dec 15, 2009 at 3:22 PM, Matt m...@thekrusefamily.com
mailto:m...@thekrusefamily.com wrote:
On Dec 15, 11:32 am, John Resig jere...@gmail.com
mailto:jere...@gmail.com wrote:
I think this is a great approach, and I hope it goes
somewhere. How
exactly can I help with it?
Categorizing the types would be a great start. Types that
should
just work, Types that should return booleans, types that we
obviously don't care about (attributes of isindex, for
example), and
attributes that we provide better alternatives for (Using
.click()
instead of .attr(onclick, fn), for example).
I will take a look at this. I may come to different
conclusions than
you, but I will propose something. Having a dump of all the
attributes
and documenting what to expect from each would be fantastic.
Because height() tries to do so much magic, it ends up
that this:
$o.attr('height',$o.attr('height'));
I was 100% serious about a ban concerning everything from
CLJ. Please,
original ideas/concerns/bug reports/test cases only.
Seems petty to me. There is a good test case there that
illustrates
the problem. I'm not going to reproduce it to shelter jQuery
from CLJ.
Nevertheless,
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
So... that example still doesn't use:
*.attr('onclick', function() { /.../ }); *
*
*
But I see where you're coming/going with this (as far as purpose, not
syntax). It simply adds more credence to my point, as it's getting/testing a
value, not setting.
*
*
Rick
*
*
On Wed, Dec 16, 2009 at 12:51 PM, Robert E. Rothermel III
thirden...@gmail.com wrote:
Line 688... I saw it because I was trying to use .live() and this check
shot that to pieces... If the link doesn't pass this check it's assumed to
not be a Highslide link, even if the link has the highslide class applied.
isHsAnchor : function (a) {
return (a.onclick a.onclick.toString().replace(/\s/g, '
').match(/hs.(htmlE|e)xpand/));
}
It's a bad idea, imho. The writers of the library assumed that every link
could have it's own custom display parameters as part of the onclick
handler... something like a onclick=return hs.expand(this, { /* options */
}; ... The problem is that the options should still be stored in an
external JS to be semantic, and if you try to do a full page of images (a
gallery or contents table in a store) with Highslide handlers on each image,
it's an incredible amount of code fluff.
Rob
Rick Waldron wrote:
I've searched the source... maybe I missed it, but I cant find your
example...
http://highslide.com/highslide/highslide-full.js
Rick
On Tue, Dec 15, 2009 at 5:03 PM, Robert E. Rothermel III
thirden...@gmail.com wrote:
The only time that I can think of where one would want to use
.attr('onclick', function() { /.../ }); is Highslide... it actually runs a
regex on each A tag to see if the string hs.expand is in the onclick
attribute.
Rick Waldron wrote:
I've been reading this thread right along and I apologize for being the
late one to the party, and I wasn't going to bother, because its not at the
core of the discussion, but I'm still perplexed.
Why would you want to use:
.attr('onclick', function() { /../ });
When exists:
.click(function() { /../ })
.bind('click', function() { /../ })
.live('click', function() { /../ })
.
Or, this? What practical application does this have? Where a dev would
set the height of an element with the height of the same element.
$o.attr('height',$o.attr('height'))
...I understand that in the context of test cases, round-trip value
getting/setting ensures that methods are reliable, but in the real world?
Perhaps my understanding of javascript beyond jquery is the reason, but
I've never, not even once, had an issue with attr() doing what *I
intended* it to do - like I said, it could be because I'm not expecting
it to do anything particularly zany, like setting a value with the same
value from the same source.
Also, for a method that you're so quick to call broken, I decided to
do a reality check of code that is expected to *always and only work with
jQuery*... I dug through jQuery UI 1.7.2 and i found something
not-too-shocking: only 1 occurrence of getAttribute (in datepicker... line
6166), 1 occurrence of setAttributeNS() (in $.ui.* ) and 1 occurrence of
removeAttributeNS() (in $.ui.*). 47 occurrences of .attr() (a mix of string
and object argument syntaxes) and 12 .removeAttr()'s
jQuery UI is more then expected to work browser independently, its
implied by its use.
Furthermore, after looking at that site you referenced several times
(that i will not copy/paste here), I second a move to 100% ban all
references, along with the newsgroup you cited. I realize you feel as though
ignoring certain sources might leave you in the dark, but my advice would be
to try and steer clear of bad information.
On Tue, Dec 15, 2009 at 3:22 PM, Matt m...@thekrusefamily.com wrote:
On Dec 15, 11:32 am, John Resig jere...@gmail.com wrote:
I think this is a great approach, and I hope it goes somewhere. How
exactly can I help with it?
Categorizing the types would be a great start. Types that should
just work, Types that should return booleans, types that we
obviously don't care about (attributes of isindex, for example), and
attributes that we provide better alternatives for (Using .click()
instead of .attr(onclick, fn), for example).
I will take a look at this. I may come to different conclusions than
you, but I will propose something. Having a dump of all the attributes
and documenting what to expect from each would be fantastic.
Because height() tries to do so much magic, it ends up that this:
$o.attr('height',$o.attr('height'));
I was 100% serious about a ban concerning everything from CLJ. Please,
original ideas/concerns/bug reports/test cases only.
Seems petty to me. There is a good test case there that illustrates
the problem. I'm not going to reproduce it to shelter jQuery from CLJ.
Nevertheless, since attr() calls height() for both getter and setter,
the real problem is that
$o.height( $o.height() )
is not reliable in some cases.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
I would note some problems (2):
If we have
$(xml).find(foo).attr(height, 180cm)
then you would expect calling elem.setAttribute() and not .height(), I
hope.
If so, there is a bug in jQuery.attr()...
So we could disable it on XML documents - but regardless, that is
definitely th exception.
Other think to take in consideration is that
$(div).attr(click, function(){ /*..*/ });
is not equivalent to
$(div).attr({
click: function(){ /*..*/ }
});
Infact in the first case we are setting click attributes with the
result of the function, while in the second case we are binding click
event, in theory (second case is still not ready?).
Not consistently at all.
Naturally, they aren't the case - the second is far superior. Setting
a DOM 0 expando property is simply so substitute for binding events
via jQuery.
Also there is a jQuery.attrFn.bind. Why?
Am I missing something?
Because bind can take an object that can set multiple events
simultaneously. .bind({ click: fn, mouseover: fn2 })
--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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
1) I cannot find the rationale for this. Or even where this bug is
discussed. Can anyone point me to it? I am curious.
// Safari mis-reports the default selected property of a hidden
option
// Accessing the parent's selectedIndex property fixes it
if ( name == selected elem.parentNode ) {
elem.parentNode.selectedIndex;
}
Hmm, I don't remember the bug off-hand but here's the reproduction:
Failing:
http://ejohn.org/files/bugs/selected/
Passing:
http://ejohn.org/files/bugs/selected/fixed.html
2) This seems like over-kill, still. Passing the second parameter will
never break things, so why not just pass it in every case?
var attr = !jQuery.support.hrefNormalized notxml special
// Some attributes require a special call on IE
? elem.getAttribute( name, 2 )
: elem.getAttribute( name );
could be simplified to:
var attr = elem.getAttribute(name,2);
Unfortunately that's not the case - I know that in older versions of
Opera if you tried to use the , 2 it would straight out crash the
browser - which is why we had to do the extra check. It's silly, of
course, since the extra argument shouldn't do anything.
--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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
I think this is a great approach, and I hope it goes somewhere. How
exactly can I help with it?
Categorizing the types would be a great start. Types that should
just work, Types that should return booleans, types that we
obviously don't care about (attributes of isindex, for example), and
attributes that we provide better alternatives for (Using .click()
instead of .attr(onclick, fn), for example).
After we tackle the attributes we should look at the most common
properties (like innerHTML, innerText, textContent, etc.) and at least
be able to tell users what to use instead or make sure that they're
supported by .attr() directly.
Also, to further illustrate why I think calling jQuery methods when
calling attr() is a bad idea, take a look at the example page our
great friend David Mark has set up (ignore the insulting url):
http://www.cinsoft.net/jquerysucks.html
Because height() tries to do so much magic, it ends up that this:
$o.attr('height',$o.attr('height'));
I was 100% serious about a ban concerning everything from CLJ. Please,
original ideas/concerns/bug reports/test cases only.
For example, writing up some tests that make sure that you can do:
var a = $(foo).attr(A);
$(foo).attr(A, a);
equals( a, $(foo).attr(A), Attributes did a round-trip and are still equal. );
Would probably be fine.
On the whole though, I'd recommend to just stop reading the group as
who knows what they will try to pull next.
actually gives wrong results. IMO, attr() should be reflexive in that
calling attr() to set a property with a value retrieved from attr()
should always maintain the same value. I just really think the whole
idea of calling methods when getting/setting attributes is bad. What
is the real basis for it?
I discussed this earlier in the thread with Robert Katić.
--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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
I will take a look at this. I may come to different conclusions than you, but I will propose something. Having a dump of all the attributes and documenting what to expect from each would be fantastic. Excellent, appreciate your help! Doing a Google Code Search yields lots of interesting edge cases that we'll want to figure out: http://www.google.com/codesearch?hl=enlr=q=\.attr\%28%22.*%3F%22+lang%3Ajavascriptsbtn=Search Seems petty to me. There is a good test case there that illustrates the problem. I'm not going to reproduce it to shelter jQuery from CLJ. I will take a look at this when I get a chance. I'm not going to copy his code, but if there are any similarities then he can sue me. Huh. Unfortunately we really don't want to deal with their bullshit, especially if they're threatening to sue us. As we're looking to transfer ownership of the code base over to the Software Freedom Conservancy we can't take code from tainted sources - and if you're unwilling to take responsibility for your code then we really won't be able to accept code submissions from you. Thankfully we can still use your help in figuring out a good situation for the attributes to be in. Looking forward to your input. Nevertheless, since attr() calls height() for both getter and setter, the real problem is that $o.height( $o.height() ) is not reliable in some cases. So perhaps the issue is there, instead of with attr(). That seems likely. I've never been a fan of head-in-the-sand. I can find the pearls of wisdom in the posts there without taking anything personally. And there is a lot of good, robust, deep stuff posted there that you won't find in blog posts or discussions here. To each his own. Naturally, it's a lot easier to not take it personally when they're not making personal insults against you and threatening to sue you. Thankfully we have people like Juriy Zaytsev that are providing useful ways of contributing to the larger community: http://thinkweb2.com/projects/prototype/ --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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
I've been reading this thread right along and I apologize for being the late
one to the party, and I wasn't going to bother, because its not at the core
of the discussion, but I'm still perplexed.
Why would you want to use:
.attr('onclick', function() { /../ });
When exists:
.click(function() { /../ })
.bind('click', function() { /../ })
.live('click', function() { /../ })
.
Or, this? What practical application does this have? Where a dev would set
the height of an element with the height of the same element.
$o.attr('height',$o.attr('height'))
...I understand that in the context of test cases, round-trip value
getting/setting ensures that methods are reliable, but in the real world?
Perhaps my understanding of javascript beyond jquery is the reason, but I've
never, not even once, had an issue with attr() doing what *I intended* it to
do - like I said, it could be because I'm not expecting it to do anything
particularly zany, like setting a value with the same value from the same
source.
Also, for a method that you're so quick to call broken, I decided to do a
reality check of code that is expected to *always and only work with jQuery*...
I dug through jQuery UI 1.7.2 and i found something not-too-shocking: only 1
occurrence of getAttribute (in datepicker... line 6166), 1 occurrence of
setAttributeNS() (in $.ui.* ) and 1 occurrence of removeAttributeNS() (in
$.ui.*). 47 occurrences of .attr() (a mix of string and object argument
syntaxes) and 12 .removeAttr()'s
jQuery UI is more then expected to work browser independently, its implied
by its use.
Furthermore, after looking at that site you referenced several times (that i
will not copy/paste here), I second a move to 100% ban all references, along
with the newsgroup you cited. I realize you feel as though ignoring certain
sources might leave you in the dark, but my advice would be to try and steer
clear of bad information.
On Tue, Dec 15, 2009 at 3:22 PM, Matt m...@thekrusefamily.com wrote:
On Dec 15, 11:32 am, John Resig jere...@gmail.com wrote:
I think this is a great approach, and I hope it goes somewhere. How
exactly can I help with it?
Categorizing the types would be a great start. Types that should
just work, Types that should return booleans, types that we
obviously don't care about (attributes of isindex, for example), and
attributes that we provide better alternatives for (Using .click()
instead of .attr(onclick, fn), for example).
I will take a look at this. I may come to different conclusions than
you, but I will propose something. Having a dump of all the attributes
and documenting what to expect from each would be fantastic.
Because height() tries to do so much magic, it ends up that this:
$o.attr('height',$o.attr('height'));
I was 100% serious about a ban concerning everything from CLJ. Please,
original ideas/concerns/bug reports/test cases only.
Seems petty to me. There is a good test case there that illustrates
the problem. I'm not going to reproduce it to shelter jQuery from CLJ.
Nevertheless, since attr() calls height() for both getter and setter,
the real problem is that
$o.height( $o.height() )
is not reliable in some cases. So perhaps the issue is there, instead
of with attr().
On the whole though, I'd recommend to just stop reading the group as
who knows what they will try to pull next.
I've never been a fan of head-in-the-sand. I can find the pearls of
wisdom in the posts there without taking anything personally. And
there is a lot of good, robust, deep stuff posted there that you won't
find in blog posts or discussions here. To each his own.
Matt Kruse
--
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.comjquery-dev%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
John, that last resource you posted is great, kangax is the man. Rick On Tue, Dec 15, 2009 at 4:40 PM, John Resig jere...@gmail.com wrote: I will take a look at this. I may come to different conclusions than you, but I will propose something. Having a dump of all the attributes and documenting what to expect from each would be fantastic. Excellent, appreciate your help! Doing a Google Code Search yields lots of interesting edge cases that we'll want to figure out: http://www.google.com/codesearch?hl=enlr=q= \.attr\%28%22.*%3F%22+lang%3Ajavascriptsbtn=Search Seems petty to me. There is a good test case there that illustrates the problem. I'm not going to reproduce it to shelter jQuery from CLJ. I will take a look at this when I get a chance. I'm not going to copy his code, but if there are any similarities then he can sue me. Huh. Unfortunately we really don't want to deal with their bullshit, especially if they're threatening to sue us. As we're looking to transfer ownership of the code base over to the Software Freedom Conservancy we can't take code from tainted sources - and if you're unwilling to take responsibility for your code then we really won't be able to accept code submissions from you. Thankfully we can still use your help in figuring out a good situation for the attributes to be in. Looking forward to your input. Nevertheless, since attr() calls height() for both getter and setter, the real problem is that $o.height( $o.height() ) is not reliable in some cases. So perhaps the issue is there, instead of with attr(). That seems likely. I've never been a fan of head-in-the-sand. I can find the pearls of wisdom in the posts there without taking anything personally. And there is a lot of good, robust, deep stuff posted there that you won't find in blog posts or discussions here. To each his own. Naturally, it's a lot easier to not take it personally when they're not making personal insults against you and threatening to sue you. Thankfully we have people like Juriy Zaytsev that are providing useful ways of contributing to the larger community: http://thinkweb2.com/projects/prototype/ --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.comjquery-dev%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en. -- 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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
I use .attr() to get the href attribute value, too. If you
use .getAttribute(), IE6 and IE7 require a second argument to really,
truly get the attribute: somelink.getAttribute('href', 2)
--Karl
Karl Swedberg
www.englishrules.com
www.learningjquery.com
On Dec 14, 2009, at 10:05 AM, Scott Sauyet wrote:
On Dec 13, 11:27 pm, Matt m...@thekrusefamily.com wrote:
I'm not going to jump into these murky waters, but I want to follow up
on this bit:
As it is now, I always recommend that attr() be avoided in code, and
if someone uses it in code I am looking at, I tell them to remove it.
It's too fragile and the logic that it is intending to code is not
well documented, so we can't depend on it. Luckily, it's easily coded
around.
The only place I use attr extensively is when I want the href value of
a link for further manipulation to unobtrusively convert non-JS
functionality to JS functionality, most commonly when the href is for
a document fragment. Do you think it's bad practice to call
var myDiv=$(item.attr('href'));
Obviously I could go down to getAttribute, but I've never had a
problem using it like this.
-- Scott
--
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
.
--
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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
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
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
Well, I have to admit that I am not too happy in which direction attr () is going. Adding to much magic is not simplifying the API to me. If we (John) wont an method that can do everything (including bindings!), than I would prefer it as an separate method (set() ?) leaving rest of API as much as possible consistent and well defined. I disagree. Being able to set all the (useful) properties of a DOM element via a single object structure can be very useful - and I see no reason not to overload the existing .attr() behavior if it already covers most of the functionality well and if there are no conflicts. I especially think that it's important to integrate it into .attr() so that we can effectively deprecate bad ways of setting DOM attributes or properties. For example, instead of doing .attr(innerHTML, some html) we can offer the much saner .attr(html, some html) same with .attr(onclick, fn) becoming .attr(click, fn) - both of these are removing the weirdness of the existing DOM APIs by providing something that's much better. Placing this in a separate function creates un-needed ambiguity. I dislike it for the same reason that I dislike having an extra .prop() method for setting just DOM object properties. We should be able to provide a unified API for setting information (called 'attr' in jQuery, mostly for legacy reasons - it actually was 'set' back when jQuery was first released) and work to meet the user's expectations based upon that. Unfortunately, for me, it seams that jQuery API is going to prefer beginner users with cost of ignoring true potentials (i.e. live()). How's that? .live() has seen considerable improvements since 1.3.2 both in the form of features (context limiting, data support), cross browser compatibility (submit, change, focus, blur, mouseenter, mouseleave), and performance (huge speed-ups to .closest() and node checking). As far as I know I've also landed every patch you've submitted to the jQuery Github fork queue. Perhaps there's something else that you're not divulging? --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.
Re: [jquery-dev] Re: attr() is still very broken in 1.4a1
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.
