[jquery-dev] Re: attr() is still very broken in 1.4a1
Oh, how true my daddy was: Son (he said) always make the manual first and then give it to the customers. And then son, wait for the dust to settle. And then my son, then start making, whatever is that thing, you are selling my son ... --DBJ On Dec 18, 8:30 pm, John Resig jere...@gmail.com wrote: 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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
At the risk of jumping into a conversation that's a little beyond me,
I'd like to throw in 2 cents as a long time jquery user.
I can follow the arguments being made by those who think attr is
broken. But I agree with John and company that the attr function does
what it's supposed to do. It returns the attribute values of DOM
elements. This argument seems to be a definitional one. DOM Element !
= HTML source. Regardless of what the original html source says, once
it's parsed into a DOM it's a living structure with values that
change. I tend to think of the HTML as the original values of DOM
attributes, but subject to change. jQuery operates on the DOM and as
such, it should return computed values as a matter of course. This
conflation of DOM and source is probably something that does come up a
lot for beginners and may be part of the learning curve for jQuery.
But I think if the docs make the distinction clear and consistently
return computed values, then it's something everyone can get used to.
With that being said, I can see it also being useful to be able to get
at the original attribute values specified in the source. I don't have
any ideas about this and honestly, I've never had a specific need to
do it. But perhaps a plugin geared towards this would be better.
$.htmlattr ?
:Marco
On Dec 17, 3:45 pm, Matt m...@thekrusefamily.com wrote:
On Dec 17, 2:26 pm, Leeoniya leeon...@gmail.com wrote:
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.
Just to clarify, in the case of width the width() method would get
called in both cases.
So
$o.attr('width') == $o.width()
and
$o.attr('width',5) == $o.width(5)
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.
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
The results of calling an API should be very predictable, not open to interpretation and having 10 different outcomes depending on what you pass in, forcing a user to consult a big table to see what they can expect to get back for each input parameter. IMO. That was my concern with the .attr(any_jQuery_method) change, it meant that certain attribute names behave very differently than others; even when those magic names are documented it would no doubt surprise many users. It doesn't seem that burdensome to make the person call .height () if they really want the current height, rather than the css height property or the html height attribute. That's the great thing about .height(), it can mean whatever we want it to mean because it doesn't carry the history and implied meanings of .css(height) or .attr(height). As a counterpoint to that statement, I'll point out that in IE many values return auto when queried by .css(), while other browsers return the real measurements. The end result of that is many people who test lightly on IE will write code that ends up doing parseInt (auto, 10) and getting NaN. Then they try passing that back into jQuery and complain when it throws an error trying to set the value to NaNpx. Here's one example of many: http://dev.jquery.com/ticket/4915 So I see the problem we're trying to fix here, I'm just not sure if the proposed solution is the right fix. -- 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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
I am afraid, that I will not be the only confused one...
I, for one, am very much confused.
Never ever, would I have guessed that .attr('height') would report a
value on elements that don't have an explicit height `attr`ibute.
Should I now expect $(element).attr('color') to work as an alias for
`.css('color')`? How about other properties, such as 'border-width'
or 'offset'? (*wanders off to a different browser tab to try for
himself*)
--
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
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.
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
On Dec 17, 10:29 am, John Resig jere...@gmail.com 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.
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).
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.
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?
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.
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
On Dec 17, 11:41 am, John Resig jere...@gmail.com wrote:
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).
Careful... that opens a can of worms.
If I have html like:
textarea rows=5 style=height:500px;/textarea
Then what should .attr('rows') return? The computed value is surely
not 5, but you can't get a computed value. Toss out that attribute?
Same would go for any attribute that can be over-ridden by css:
tabletrtd bgcolor=red style=background-color:blue;test/
table
attr('bgcolor') = ???
input size=5 style=width:500px;
attr('size') = ???
So do you make a list of presentation attributes and not support them
also? (there are quite a few)
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.
The attribute still is! The computed height is not. With a method
named attr(), I would expect the former, not the latter.
Getting the current, computed, value is much more useful and
practical to everyday users.
Only if it is logical and predictable. People calling attr() are
programmers, not casual computer users. The results of calling an API
should be very predictable, not open to interpretation and having 10
different outcomes depending on what you pass in, forcing a user to
consult a big table to see what they can expect to get back for each
input parameter. IMO.
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).
Hmmm... $('object data=.../').attr('data') = ???
You may run into a number of cases that may need special handling,
at which point you have to have really good documentation about the
intent of the method and what to expect. And as you go forward, you'll
probably find more oops, I didn't think of that situations where
this logic causes problems.
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
On Dec 17, 2:26 pm, Leeoniya leeon...@gmail.com wrote:
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.
Just to clarify, in the case of width the width() method would get
called in both cases.
So
$o.attr('width') == $o.width()
and
$o.attr('width',5) == $o.width(5)
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.
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.
[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()...
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.
Also there is a jQuery.attrFn.bind. Why?
Am I missing something?
--
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 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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
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.
I have to correct me, that code will call elem.setAttribute(), but
$(xml).find(foo).attr({height: 180cm})
will call .height()
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.
And you are completely fine with such discrepancy between
.attr({height: 180}) and .attr(height, 180),
and between
.attr({ click: function(){ /*..*/ } }) and .attr(click, function(){ /
*..*/ }) ?
Because bind can take an object that can set multiple events
simultaneously. .bind({ click: fn, mouseover: fn2 })
Anyway I would remove that just because there is .bind({...}) and .attr
({...}) for setting multiple events simultaneously. .attr({ bind:
{...} }) is certainly dirty. Also bind is an action, not an
attribute.
--
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
I have to correct my correcting:
Both .attr({height: 180}) and .attr(height, 180) will
call .height().
Still there still is big discrepancy between
.attr({ click: function(){/*..*/} }) and .attr(click, function(){/
*..*/})
Adding that there is no (for now) symmetry between
attr(height, ...) and attr(height)
I am afraid, that I will not be the only confused one...
On Dec 17, 7:50 am, Robert Katić robert.ka...@gmail.com wrote:
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.
I have to correct me, that code will call elem.setAttribute(), but
$(xml).find(foo).attr({height: 180cm})
will call .height()
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.
And you are completely fine with such discrepancy between
.attr({height: 180}) and .attr(height, 180),
and between
.attr({ click: function(){ /*..*/ } }) and .attr(click, function(){ /
*..*/ }) ?
Because bind can take an object that can set multiple events
simultaneously. .bind({ click: fn, mouseover: fn2 })
Anyway I would remove that just because there is .bind({...}) and .attr
({...}) for setting multiple events simultaneously. .attr({ bind:
{...} }) is certainly dirty. Also bind is an action, not an
attribute.
--
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
Karl,
it is not only href that has problems, seems all attributes having
an URI string as value have to be read in the way you described.
Some of them are: action, cite, codebase, data, href, longdesc,
lowsrc, src, usemap.
In IE6/7 elements have a predefined number of attributes (minimum 80,
varies depending on the element).
Further complication comes from the fact that IE6/7 getAttribute does
not always return string when a value is present.
document.body.getAttribute(onload); // function
document.body.getAttribute(style); // object (not null)
As an example go to http://www.google.com; with IE6 and other
browsers and type this in the URL:
javascript:alert(document.getElementsByTagName('textarea')
[0].getAttribute('style'));
You will have to add .cssText in IE6/7 to read a slightly similar
value:
javascript:alert(document.getElementsByTagName('textarea')
[0].getAttribute('style').cssText);
I don't think all these cases/differences are currently handled and I
don't think they can be handled in a reasonable way.
Diego
On 14 Dic, 16:49, Karl Swedberg k...@englishrules.com wrote:
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 Swedbergwww.englishrules.comwww.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
athttp://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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
On Dec 14, 12:31 am, John Resig jere...@gmail.com wrote:
For example, documenting that disabled/selected/etc. are expected to
return boolean values. Documenting the expected value returned from
zIndex. Documenting what happens with relative URL resolution across
browsers.
THEN we can go back and fill in the test suite as appropriate.
[...]
To start I've created a page that's a rough dump of the contents in
the HTML 4 spec:http://www.w3.org/TR/html4/index/attributes.html
Into the following page:http://docs.jquery.com/How_Attributes_Work
I think this is a great approach, and I hope it goes somewhere. How
exactly can I help with it?
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'));
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?
Two other points:
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;
}
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);
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
On Dec 15, 10:24 am, Diego Perini diego.per...@gmail.com wrote:
it is not only href that has problems, seems all attributes having
an URI string as value have to be read in the way you described.
Some of them are: action, cite, codebase, data, href, longdesc,
lowsrc, src, usemap.
The root cause, if I'm not mistaken, is that IE masks the element
attributes with properties when calling getAttribute(). So in the case
of url's, the full resolved url is stored in the property of the
object.
a.href==a.getAttribute('href')
If you want the true attribute value, this is when you have to specify
the second argument of 2.
You will have to add .cssText in IE6/7 to read a slightly similar
value:
javascript:alert(document.getElementsByTagName('textarea')
[0].getAttribute('style').cssText);
I don't think all these cases/differences are currently handled and I
don't think they can be handled in a reasonable way.
This case seems to be handled with this code:
if ( !jQuery.support.style notxml name == style ) {
if ( set ) {
elem.style.cssText = + value;
}
return elem.style.cssText;
}
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.
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
On Dec 15, 11:21 am, John Resig jere...@gmail.com wrote:
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
Ah, I see. The description in the source is misleading.
Note that this only happens before the page is done loading (if you
fire the check in window.onload it works fine). Also, an option may
exist in an optgroup element, so simply accessing
parentNode.selectedIndex isn't sufficient. How about this:
// In Safari, if no option is explicitly selected and the first
// option gets selected by default, this option will report
// selected==false _while the page is still loading_. Accessing the
// containing select element causes the option to set its
// selected state correctly. Since options may be nested in
// optgroup elements, access two levels up just to be safe.
// Simply accessing the .selectedIndex property even if it doesn't
// exist shouldn't cause a problem in any browsers.
// http://ejohn.org/files/bugs/selected/
if ( name == selected elem.parentNode ) {
elem.parentNode.selectedIndex;
if (elem.parentNode.parentNode)
{ elem.parentNode.parentNode.selectedIndex; }
}
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.
Never seen that problem, and I'm too lazy to look for it. I'll trust
you on that one. May want to add a note to that effect in the source.
Explanatory documentation is valuable.
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
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.
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
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. Rethinking, maybe I was too hard with objections, and your arguments are mostly valid. However, there are some problems (for me) that are brought by introducing attrFn. Firstly, you are using attrFn magic with XML documents too. I hope it is not intentional. Secondly, you are exposing attrFn to jQuery. This would be dangerous if used by users that would be able to overwrite and break attr() very easily. In production scenario it would be very bed. At the end, I would be more careful by filling attrFn (i.e. data, append, prepend). 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. Well, I am not a fan of adding set() (or similar) either. 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). Certainly it wasn't in my intention to diminish the great job done in that area. However I am not a fan of the current live() API because it is not giving full control to me (see http://groups.google.com/group/jquery-dev/browse_frm/thread/1240ad6bc98693af#). For that reason I am generally using manual delegation instead of live (). 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? If I am still not divulging something, it is because it is still only a vague idea or it is not good enough to me (I am lazy). Although I am not liking everything in the API, I haven't pushed patches (making pull request) that would change the API. If I will do that, that will be only after discussing it, and with your agreement. Of course. -- 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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
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.
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
[jquery-dev] Re: attr() is still very broken in 1.4a1
On Dec 13, 6:06 pm, John Resig jere...@gmail.com wrote:
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.
David Mark is an ass. Unfortunately, he's an ass who has a very deep
understanding of js and makes very good observations about code
quality and robustness. Since I value critical looks and logic and
algorithms, and I use and develop for jQuery frequently, I find myself
in a position where both sides of the debate are valuable to me.
Trying to find the common ground sometimes proves frustrating.
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.
The group is growing increasingly irrelevant, but there are a number
of quality contributors who have very good understandings of the js
language. They can spot problems and identify potential issues better
than most. Although the environment is hostile and populated by many
guys I probably would not care to hang out with personally, sometimes
it's worthwhile to ignore all that and just focus on the objective
arguments being made. I can definitely sympathy with not wanting to
tread those waters, but that seems kind of like a see no evil, hear
no evil attitude.
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.
Unfortunate, but understood.
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.
Some of the people there (David Mark especially) seem to have personal
issues with jQuery. Maybe jQuery stole their girlfriend in high school
or beat them up on the playground. I don't know. Their bias ends up
being a vendetta, and even if they have reasonable criticisms they end
up being lost in their diatribes. I don't understand the hostility.
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.
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.
I think one of the core problems is understanding what attr() is
intended to do. Clearly it is not just a get/setAttribute wrapper.
Clearly it is not just meant to access the properties of elements. It
is a mixture of several different ways to access attributes of an
element, and it apparently tries to pick the best approach and give
the user what they want. Calling height() instead of accessing
a .height property or doing getAttribute('height') may give some users
what they expect, but is it predictable? What if I really do want the
'height' property, and not the current computed value? How will I know
which I am going to get?
If my current markup has an 'xxx' attribute and jQuery successfully
gets the attribute value, but then later adds a xxx() method and
returns that value instead, upgrading jQuery will break my code. But
how could I have known that this would happen? Knowing what attr()
will do has become entirely unpredictable, and even writing test cases
becomes difficult because it's not clear what the method is _supposed_
to do.
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. Unfortunately, many plugins and examples use it quite a bit.
Since this single method is such a consistent base of attack on
jQuery's quality and robustness, and because it is used so often in
code, I think it would be a good idea to clarify what attr() is really
intended to do and put it into words. As it is now, I'm not sure
anyone can really concisely describe it.
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
I think one of the core problems is understanding what attr() is intended to do. Clearly it is not just a get/setAttribute wrapper. Clearly it is not just meant to access the properties of elements. It is a mixture of several different ways to access attributes of an element, and it apparently tries to pick the best approach and give the user what they want. 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. Unfortunately, for me, it seams that jQuery API is going to prefer beginner users with cost of ignoring true potentials (i.e. live()). I love jQuery, and I hope will still love it in future. -- 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
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
On Dec 11, 11:10 am, John Resig jere...@gmail.com wrote:
1) It still confuses properties and attributes, which is its biggest
problem. Behavior is unpredictable. This is bad.
Do you have any specific examples?
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.
2) It looks like new code was added to call the jQuery method if the
requested attribute is in jQuery.fn. But what about attributes like
height or wrap? It won't retrieve the attribute value, but
instead, runs the height() or wrap() methods!
The wrap one was a mistake (the code in 1.4a1 covered too many
methods) it's since been scaled back. In the case of height, for
example, we definitely do want to get the height value as reported by
.height(), especially since it's likely to be more accurate than
trying to get elem.height.
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.
3) The list in jQuery.props is still incomplete
Do you have any specific examples?
cellPadding, useMap, accessKey, et al.
4) The special cases list is still incomplete
Do you have any specific examples?
How about 'action'?
5) It forces values to be strings, so I can't set attributes like attr
('onclick',function(){...}) which in theory should work just fine. In
FF, for example, el.setAttribute('onclick',function(){...}) works as
expected.
I don't think that's a case that we particularly want to support,
though. In 1.4 you can just do: .attr(click, function(){}) and it
would work (albeit tied into the full event system, which is much
better).
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.
Referenced is a good, robust review of attribute handling with test
cases that should probably be in the jQuery test suite:
http://www.cinsoft.net/attributes.html
I don't see a particular license on those tests - are they available
under an MIT license?
You'd have to contact the author, not sure about that. But the cases
being tested are certainly something that can be written again on
their own. I just saw that you've made some progress on this, which is
great.
Any hopes of fixing it up soon?
Specific filed bugs and test cases would certainly accelerate the process.
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.
It's been pointed out that most users don't really need to interact
with attributes to begin with. In most cases, they want to get/set
properties of objects, not their attributes. A prop() method might be
more clear, along with attr() if you really, really need to get/set
attributes. Mixing the two (and trying to throw in xml support!) just
makes the whole thing kind of a mess.
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.
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.
