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:
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
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
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
# 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
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
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
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
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
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
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?
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.
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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,
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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')
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
45 matches
Mail list logo
