Re: [jquery-dev] Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.
tato wrote:
Thax,
First the excuses. This is a discussion about the future.
However, this future is in front of us.
Browser's between incompatibility in ajax was need JS Library /
jQuery, and was very helpful. It is, I agree.
But even if there is compatibility, jQuery support of xhr is useful.
Future browser with WebSockets implemented, I want compatibility
between them.
But I think, even if there is compatibility, jQuery support of ws is
useful too. Rather less code ;-)
Less code?
var ws = new WebSocket(ws://example.com);
ws.onmessage = function(msg) {
// ...
};
How much shorter can jQuery possibly make that?
WS is a bi-directional non-HTTP socket which needs a dedicated server.
It's non-HTTP, but it's on-HTTP too.
I think, WS is a real bi-directional on-HTTP shares available socket,
isn't it?
I tested on mod_pywebsocket, that is a Web Socket extension for Apache
HTTP Server. IETF specification is, The Web Socket default port is 80
or 443.
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-44#section-1.5
http://code.google.com/p/pywebsocket/
http://blog.chromium.org/2009/12/web-sockets-now-available-in-google.html
WS' handshake is HTTP-like. The only HTTP in WS is a handshake that
immediately upgrades the connection to the WebSocket protocol leaving
HTTP behind.
WS isn't HTTP, it completely breaks the request-response model of HTTP,
it just encapsulates itself in HTTP. If WebSockets were HTTP websocket
urls would be http:// not ws://
The purpose of the HTTP handshake iirc is primarily so that existing
load balancing technologies, proxy servers like varnish, etc... meant
for http can still be used (in pipe mode ignoring contents mostly) and
also so WS doesn't require another port which is default-blocked in most
cases.
You do realize that WS cannot be used in most shared hosting setups?
Most shared hosts use apache, which as I recall buffers http
requests/responses meaning WS won't work on the other side, and the
users obviously can't install new modules. To use WS you need some sort
of VPS, Cloud server, dedicated server, etc... Anything but a shared host.
That there is likely a good portion of the jQuery userbase.
WS is simply faster because it doesn't need all the extra cruft in a
HTTP call
I think so too. XHR requires a lot of headers, and many connections.
WS is Handshake header 'GET / demo HTTP/1.1 ...', only once.
WS is so friendly for network and servers. Moreover, faster on HTTP.
With Best regards, for into the good future
On 1月19日, 午前2:27, Daniel Friesen nadir.seen.f...@gmail.com wrote:
I don't like the idea. At this point there is no reason to believe that
any browser with WebSockets implemented will break spec and need a
compatibility layer (the primary reason jQuery has ajax). I don't see
how jQuery could add any functionality to WebSockets, the api is already
quite nice, not to mention there are a large number of calls and parts
to the api, so there would be a pile of jQuery code just matching up the
api to make calls you could make without jQuery at all.
In any case, comparing WS to XHR in terms of speed is completely
pointless. XHR is a way to make a HTTP call from JS. WS is a
bi-directional non-HTTP socket which needs a dedicated server. They have
completely different purposes and use cases, speed is irrelevant to a
comparison. WS is simply faster because it doesn't need all the extra
cruft in a HTTP call and it's an open dedicated connection between the
browser and the server that doesn't close after every message.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
...
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--
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] WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.
I don't like the idea. At this point there is no reason to believe that any browser with WebSockets implemented will break spec and need a compatibility layer (the primary reason jQuery has ajax). I don't see how jQuery could add any functionality to WebSockets, the api is already quite nice, not to mention there are a large number of calls and parts to the api, so there would be a pile of jQuery code just matching up the api to make calls you could make without jQuery at all. In any case, comparing WS to XHR in terms of speed is completely pointless. XHR is a way to make a HTTP call from JS. WS is a bi-directional non-HTTP socket which needs a dedicated server. They have completely different purposes and use cases, speed is irrelevant to a comparison. WS is simply faster because it doesn't need all the extra cruft in a HTTP call and it's an open dedicated connection between the browser and the server that doesn't close after every message. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] tato wrote: WebSockets is very faster than xhr. I think jQuery had better support WebSockets in Core. The following Samples of text mining are speed comparison, WS vs XHR. at my Office(same bloga.jp), the speed difference was following. /* need Chrome4.0.249.0 + or Safari nightly */ http://bloga.jp/ws/jq/wakachi/mecab/wakachi.html case websocket (pipeline) 156 msec case XML HTTP request (parallel Ajax) 4978 msec # 31-fold http://bloga.jp/ws/jq/wakachi/mecab/ruby.html case websocket (pipeline) 339 msec case XML HTTP request (parallel Ajax) 1506 msec # 4-fold (http://code.google.com/p/websocket-sample/) eg. W3C The Web Sockets API http://dev.w3.org/html5/websockets/ IETF The Web Socket protocol http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-44 My jQuery plugin for WS http://plugins.jquery.com/project/ws -- 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] aborting Ajax calls the success callback
Isn't that a loose use of the term success originating in confusion caused by abstraction? We call it success because that's it's a word describing what we expect it to do. The browser's actual xhr has no concept of success on it's own, that is determined by the library/application based on completion, http error codes, etc... The real success we are firing that method in jQuery on to xhr is actually the concept of completion of the xhr call, coupled with a non-fatal status code. The browser ends up firing success because by calling abort we cancel all the remote interaction and bring it to it's finished state, hence it is complete. readyState == 4 is really DONE, not success, it's an indication that the xhr has been opened and whether it succeeded, failed, or aborted the request is over and is no longer doing anything. I think calling error: with a statusText of abort would be the more intuitive way of handling this. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] John Resig wrote: It's not really clear what it should call - maybe it should only call the complete request and neither the error or success. When I looked into it recently some browsers called success and some called nothing (Opera). I normalized it to success across the board but I'm open to further debate. --John On Sat, Jan 16, 2010 at 7:47 PM, alexander farkas a.farkas...@googlemail.com wrote: Is it intended, that aborting an Ajax will call the complete calback with the status success + the success-callback? In most cases noone wants to handle an aborted request in his success-callback. I think, you should introduce a new xhr-event/callback 'abort'. -- 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] Activate event
I ran into something interesting when reading the svg spec and ended up doing some testing. I ran into the onactivate event. activate is essentially the way a tags work. In other words the event fires on a onclick and also when onkeypress is fired for the enter key on an element. Looking a bit up on Wikipedia's list of dom events there are 3 variants listed: activate DOMActivate and command. Command isn't supported by any browser that I know of. However Firefox, Konqueror, and Safari all support DOMActivate, and IE7 supports activate. Opera does not appear to support any of them. So it appears to be supported natively by gecko, webkit, khtml, and trident. So 4/5 of the major engines, presto being the last. And it can be emulated mostly in other browsers by binding a click and onkeypress event and testing for the Enter key in the keypress event. I think the activate event would be a good thing to support in the next version of jQuery with a bit of cross-compatibility in jQuery.event and a $().activate helper. It's something few bother to do in every app they develop, and as a result when overriding links in webapps and doing event delegated things most developers just stick with onclick events and don't bother to replicate the actual range of interactivity with links which is click, enter, and accesskey. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] -- 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: Activate event
Dave Methvin wrote:
I ran into the onactivate event. activate is essentially the way a
tags work. In other words the event fires on a onclick and also when
onkeypress is fired for the enter key on an element.
I'm sure it's documented, but since you've already read about
it :)
How does this differ from focus? When would you use it?
Focus is different than activating a link.
Focus will fire when you tab over the link (there's also bubbling issues
without some tricks).
Activate basically behaves the exact same as a href on an a does.
href=javascript:foo(); and $a.activate(function(e) { foo(); }); will
basically behave the same.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--
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: Activate event
Ugh... I was under the impression that click events only fire when you click on something. Aye, activate is supposed to fire in all those cases as well. Click's current behavior now seams to really be activate in a confusingly named guise. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] Dave Methvin wrote: Activate basically behaves the exact same as a href on an a does. Sorry I'm still not understanding the difference. The href is an attribute of the link, not an event. It sounded like activate was an event. AFAIK click is fired by the browser in three cases: when the user clicks the link, when the link has focus and the user presses Enter, or when the link has an accessKey attribute and the user types that accessKey. Does activate fire in all those cases as well? Do you have some reference urls that explain it all? -- 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] Any thought on Event filter?
I believe something like keypress[shift+e] was proposed in one
discussion, : conflicts with namespacing.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Jeremy Chone wrote:
Hi,
Any thought has been given on adding filter on event. For example
a) Called when enter will be pressed.
$(#myTextInputField).bind(keypress:enter,function(e){...});
b) Called when a digit is pressed.
$(#myTextInputField).bind(keypress:0-9,function(e){...});
c) Called when mouseenter with the key shift is pressed
$(#myTextInputField).bind(mouseenter:shift,function(e){...});
d) Called when mouseenter with the keys shift and ctrl are pressed
$(#myTextInputField).bind(mouseenter:shiftctrl,function(e){...});
I am not sure this would be the right notation, but it will definitely
simplify some code and make it less error prone.
Jeremy,
--
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: Change this when binding element
I made a post about how confusing people may find the name bind some
time ago. Suggested renaming bind to something like event, and keeping
bind as an alias of course. That was rejected.
I don't get what you are talking about a fn.bind() implementation in
jQuery, or what you mean by available in just one function though.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Rick Waldron wrote:
John,
While I'm glad to see a scope arg available, i still think this is
negligent to the future of jQuery and ES standards. I really think a
fn.bind() implementation would ideal (since it would be jQuery-wide
and not just available in one function), but as I've noted in the past
and is exampled here, beginners may find this syntax a bit boggling:
$(foo).bind('event', fn.bind(bar) );
Rick
--
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: Change this when binding element
Rick Waldron wrote:
Available, as in the scope argument is being retrofitted to an
existing function, and ONLY to that function.
I don't get what you are talking about a fn.bind() implementation in
jQuery, or what you mean by available in just one function though.
Read ES5.
function.prototype.bind()
I already read ES5, I use portions of ES5 in a number of js server-based
projects already.
However I don't get ONLY one function, since the whole point of
.bind() is to bind a `this` onto ONE function with one call. It's not
bind otherwise.
So I don't see any limitation. Unless you are under the
misinterpretation that after you have called .bind() on one function you
have modified that function and bound it's `this`. .bind() doesn't
modify the function, it returns a new one.
From ES5 15.3.4.5 Function.prototype.bind
The bind method takes one or more arguments, thisArg and (optionally)
arg1, arg2, etc, and returns a *new*
function object by performing the following steps:
So this is valid ES5 code.
use strict;
var a = function() { alert(this); };
var a1 = a.bind(a);
var a2 = a.bind(b);
a(); // Alerts undefined
a1(); // Alerts a
a2(); // Alerts b
On Mon, Dec 28, 2009 at 7:43 PM, Daniel Friesen
nadir.seen.f...@gmail.com mailto:nadir.seen.f...@gmail.com wrote:
I made a post about how confusing people may find the name bind some
time ago. Suggested renaming bind to something like event, and keeping
bind as an alias of course. That was rejected.
I don't get what you are talking about a fn.bind() implementation in
jQuery, or what you mean by available in just one function though.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
[http://daniel.friesen.name]
Rick Waldron wrote:
John,
While I'm glad to see a scope arg available, i still think this is
negligent to the future of jQuery and ES standards. I really think a
fn.bind() implementation would ideal (since it would be jQuery-wide
and not just available in one function), but as I've noted in
the past
and is exampled here, beginners may find this syntax a bit boggling:
$(foo).bind('event', fn.bind(bar) );
Rick
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--
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] Change this when binding element
Bad place for the scope.
This is what anonymous inline functions are for. There's also ES5's
fn.bind(this); which can be implemented in ES3 as a prototype. Your
example is also a little screwed up with it's use of document.
this.a = '1';
var that = this;
$(document).bind('scroll', function() { that.myScroll(); });
or if you add a prototype to match ES5.
this.a = '1';
$(document).bind('scroll', this.myScroll.bind(this));
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Amina wrote:
Cross-posted Jquery-group:
I am suggestion for new small feaute in jQuery.
add a new proeprty to bind function. a Scope property.
sometimes I am binding a function inside object. So I need a solution
to change the scope of this function.
something like:
$().bind('click',data,scope,function)
For Example:
function myObj()
{
this.a='1'
document.bind('scroll',this.myScroll);
this.myScroll=function () {
//Now I am trying to get this.a
alert(this.a)}
//This is make an error becuase this is an HtmlElement
and not THIS
object
}
var a=new myObj();
One solution is to use the data property like:
function myObj()
{
document.bind('scroll',this,this.myScroll);
this.myScroll=function (data) {
//Now I am trying to get this.a
alert(data.a)}
}
But I am sure that changing the scope will work better.
--
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] A closet IE abuser
That article is junk. They're ONLY tracking a small 20k group of people who have signed up for their system, not the millions of relevant people. They're also tracking servers which aren't being used by people. They spout numbers like 80% (IE 2h a day) and 40% (IE 6h a day) saying those are people with secret IE abuse. Then admit a few sentences later that only half the people being tracked are using Firefox regularly. (They're including people who aren't even using browsers other than IE in the list of people that use standards compliant browsers but secretly sneak back to IE). Besides the bad stats source, if they did have a decent one it would still be questionable. No accounting for developers that need to open up IE and sit there hours making their software work specifically in IE after they spent days making it work in the first place. And the family computers with users that only use standards browsers, but have mothers and sisters that go and click the IE icon when they want to use the Internet. Hmm... IE reminds me of global warming. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] DBJDBJ wrote: http://www.infoworld.com/d/windows/are-you-secret-ie-abuser-140 -- 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] Four feature proposals
I like the first, there was an issue with multi-string .append where the
first one was '[' that resulted in me needing to use
document.createTextNode to work around it.
Don't like the second, I don't see the purpose and it looks like it
might have some issues working as an implementation.
Not really a fan of third.
Fourth, I don't think jQuery is the place for that, write a plugin.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Tobias Hoffmann wrote:
Attached are four extensions to jquery.
One is a
$.text('Test text') utility function, that simplifies cases like
$('div.content').append($.text('Test test m...@email.com
mailto:m...@email.com here'));
Second the same thing with
$.html('some divhtml/div with nbsp; everything')
Third the combination:
$.toHtml('some special')
which for example encodes the entities. Possible use case: nl2br():
$.html($.toHtml(text).replace('\n','br/\n'));
I think there should be /some/ way in jquery to accomplish these
(without completely replacing the div's content), and /I/ haven't
found them in the API.
Their implementation is simple - but improvements are welcome.
Fourth, a simple (but powerful) template engine (less than 2K):
E.g. with
div id=#templates style=display: none
div class=tdata1
Hello span class=tname/span.
div class=trep
span class=val1/spanspan class=val2/span
/div
div class=sub2
span class=twrongThis Text wants to be removed./span
divdiv class=deepaFirst/aa
href=#Link/a/div/div
/div
/div
/div
you can do:
$('#templates .tdata1').template({
'.tname': 'World i...@me.com mailto:i...@me.com',
'.trep': [
{'val1': 5, val2: ' beer'},
'Throw the old inner stuff away',
$('spanNEW/span')
],
'.sub .twrong': null,
'.sub div .deep': {
'a[href]': function (e) {
e.click(function () { alert('Yes!'); return false;});
}
}
}).insertAfter('...');
Or the simple examples:
$('spanTest/span').template('New text'); = long way to write
.text('New test')
$('spanTest/span').template($('delX/del')); = another way
to write .empty().append('delX/del')
$('spanTest/span').template(['A','B']); = short way to write ...
I'm not sure, whether a template engine should be part of core jquery.
But maybe the name is a bit misleading: think about it as
$.fn.contents /*_on_steroids*/ (args);
Comments, improvements, ... are welcome.
- Tobias
--
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: What's wrong in my code?
More like Google Groups strikes again. John already noted how bad Google Groups is in dealing with address spoofing. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] DBJDBJ wrote: This made me to immediately change my google password ... And to do a deep-scan on my (well protected) workstation :o( I have no clue what is this? Certainly not my post ! On Dec 8, 4:11 pm, John Resig jere...@gmail.com wrote: What? Never heard of that before... That's because it's not true. DBJDBJ, please at least try to provide correct information to people on this list, thanks. --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. -- 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: Ant build
Some info from google: http://www.kernel.org/pub/software/scm/git-core/docs/gitattributes.html#_checking_out_and_checking_in http://www.mail-archive.com/msys...@googlegroups.com/msg00093.html http://www.mail-archive.com/msys...@googlegroups.com/msg00088.html Looks like this can be solved in the repo itself for everyone using a .gitattributes file. Nothing new really, svn has a similar type of configuration. As I understand, in the svn world the trend is to make sure each individual developer adds a dozen or so lines to their global auto-props when they get commit access so that each and every file they create automatically gets the right props set on each of them individually. And if anyone is missing the props another commit is needed to fix any files they miss. ;) In the git world, it seams you can add one .gitattributes file with a bit of short config to affect every file in the repo and affect everyone who checks out the repo without needing to tell them Please set these personal auto-props settings in your personal global config that'll conflict with other projects you work on that want different settings than we want or you'll annoy all of us. Heh, yay git!? Now that I think about it. Did I set my auto-props right when I setup my new laptop ages ago? I retired from major MediaWiki development before then so I don't remember if I set it up right when I decided to checkout the repo to do some small commits. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] John Resig wrote: Ah, git is by default CRLFing files. To turn it off: git config core.autocrlf false That's... interesting. Yay git? --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: jQuery forward compatibility issues
dotnetCarpenter wrote: ... It's actually fun to think that even thought IE rightly deserve a lot bashing for stopping browser innovation, it was the first browser to support image transparency, persistent storage, gradient ect. haha! ^_^ And then you look at what they did in ie8 to all those features which people have patterns for that make use of filter along with w3 drafts and other -vendor- extensions to make work in all browsers. Of course, that includes opacity which people have been writing extra cruft for already because of ie. http://realtech.burningbird.net/graphics/css/opacity-returns-ie8 You used to only need this to get nice browser compatible opacity: opacity: .5; filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50); zoom: 1; ^_^ Now you need: opacity: .5; -ms-filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50); filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50); zoom: 1; So if you want to have IE8 compatibility you either need to go back to every place you ever used filter and add a second rule just for ie8. Or add a tag to all your web pages that have a use of filter: in them to downgrade IE8 to IE7 mode. ((Well, not that many people are using IE8... At least to browse Wikipedia)) That makes me wonder, did they screw up the js to? Does jQuery need an upgrade on it's opacity: fixes for IE8 in IE8 strict mode? Mmm... Gotta love preprocessed css, you don't need to worry about any of those. Maybe I'll add text shadow to my list. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] -- 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=.
[jquery-dev] Extending selectors to support custom objects
Now that I ran into the issue again I'm going to revive a bit of an old thread of mine. Extensibility: Extending init selectors to support application objects http://groups.google.com/group/jquery-dev/browse_thread/thread/c0743849212a360a/f797c0d2f54dd9cc The gist of the thread is talking about a feature letting you extend jQuery to handle custom objects properly. ie: If you have a Widget system in your app, you could extend jQuery so that $(widgetObject) and $(this).append(widgetObject); are smart enough to know how to handle the widget object (ie: Grabbing the proper dom note for the widget). Originally the discussion stopped because someone noted that you could override jQuery.fn.init with a proxy method to achieve this ability. I was doing some work today on our the version of the app the company I work for is building, and after spending some time tracking down a bug I ended up finding that it was caused by the fact that overriding .init actually doesn't handle this feature properly. .append(obj); goes directly into domManip and never makes it's way to init, so as a result this feature does not work. At the moment I'm working around this by hacking jQuery.clean with an extra, ugly proxy method. But either something has changed in jQuery since that time then, or this never worked from the start. This considered, I think this feature in one of three forms would be good: - Things which go directly to domManip make their way to init at some point so overriding it will work. - Making jQuery understand a callback name which it can look for in custom objects. ie: Add jQuerySelectCallback or whatever to your Widget's prototype and jQuery will use that to select the node. - The proposed feature of having a callback list jQuery understands which is used in init, and wherever else necessary to allow for this feature to work. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] -- 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=.
Re: [jquery-dev] suggestion: $.support.expression $.support.borderRadius...
Don't forget -khtml, WebKit also supports it, but I recall reports that
some versions of Konqueror support it using -khtml.
Also, it's future compat, but one of the Opera devs said that if they
did implement it in Opera they would be using -o-border-radius if not
the standard border-radius at that point.
The thing about border radius to be careful of though is -moz's
alternate method of specifying corners.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Enrique Meléndez Estrada wrote:
Hi,
Sorry if I'm completely wrong but I'd suggest to add to the core the
following supports (If you think they are interesting for everyone):
jQuery.support = {
// check if expressions exists (for IE7- and IE8, not in standard
IE8 mode...) so programatically and optimally
// you could add wc3 css standard behaviors not implemented in IEs...
expression : typeof div.style.setExpression !== undefined,
// check if the browser supports border-radius: return null (or
false) if not
// but if true, then return the css prefix to add to standard: ,
-moz-, -webkit- + border-radius
// This kind of check is used a lot in plugins, and I think this is
the fastest/easiest way...
borderRadius : (typeof div.style.borderRadius !== undefined) ?
: (typeof div.style.WebkitBorderRadius !== undefined) ? -webkit- :
(typeof div.style.MozBorderRadius !== undefined) ? -moz- : null;
}
Now I'm using functions like this:
function hasBorderRadius(){
var d = document.createElement(div).style;
if (typeof d.borderRadius !== undefined) return ;
if (typeof d.WebkitBorderRadius !== undefined) return -webkit-;
if (typeof d.MozBorderRadius !== undefined) return -moz-;
return null;
};
function hasSetExpression(){
var d = document.createElement(div).style;
return typeof d.setExpression !== undefined;
}
, thanks a lot
--
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=.
[jquery-dev] Re: Beans = Rubygems for Javascript
You may want to pay attention to the CommonJS group (formerly ServerJS; standardizing out-of-browser javascript). http://groups.google.com/group/commonjs There's a big discussion on packages going on now, and that as well as past discussions have bridged into the area of providing modules to the browser. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] weepy wrote: Hi, I've been working an attempt to bring a packaging system to javascript, similar to Rubygems et al Source is here = http://github.com/weepy/bean-server It's very straight foward. You can include scripts from anywhere like so : script src='http://bean-server/ =jquery,jquery.plugin,myvector,other_stuff'/script This will work in a standalone HTML or in your Rails/Django project. The files (beans) themselves are stored in a repo (I'm using ~/Beans at the moment) and each file can depend on other files by including the following comment at the top //= require jquery //= require jquery.autocomplete //= require ./lib/my_relative_file.js This is similar to the Sprockets syntax. It's working very well for me on my current projects and I wanted to get some feedback from the community. Cheers Jonah --~--~-~--~~~---~--~~ 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 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: $.ajax's error callback: Confusion with status codes and dataType
I don't see how passing you all the information is inflexible, on the contrary I would find writing a handler for a code and realizing there was another status code that needs the same handling to be what is really inflexible. If you have different handing based on different status codes then break up your handlers by what they do into diferent functions and simply write a switch statement that calls the relevant function. I don't see how that isn't flexible as the definition of flexibility in this case is the ability to bend the code to do something slightly different (like have a second status code share the handler of another) with easev(like adding a new case line into a switch). ~Daniel Friesen (DanTMan, Nadir Seen Fire) [http://daniel.friesen.name] On 7-Sep-09, at 3:24 PM, Nathan Bubna nbu...@gmail.com wrote: On Mon, Sep 7, 2009 at 12:08 PM, John Snydersjjsnyd...@rcn.com wrote: I would like to add my opinion. ... I do not think individual callbacks for each status code are a good idea. Why? Do you not use XHR with services where you need to do different things depending on which 4xx code (for example) you receive back? Or do you just prefer to organize your branching as a switch/case or if/elseif within an error callback? In my current app, fairly different handlers are required for say, 401 than 405 or 404, and embedding the branching within switch/case or if/elseif is ugly and inflexible. This also happens to be a feature which would be much simpler and better to implement in the core ajax code than in a plugin. --~--~-~--~~~---~--~~ 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 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: Add Cookie support
And I've worked on projects that don't need ajax or fx. I think this falls under the category of wanting a buildable jQuery where you can disable things you don't need, and enable extra features that you might want. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] lrbabe wrote: Hello Miksh, Most of my projects do not make use of any cookies. It is just perfect as a plugin. On Aug 20, 3:07 pm, miksh msha...@gmail.com wrote: Hi all, Cookie is a common and widely used functionality so it is deserved to be added into jQuery.Utilities rather than to be just a plug-in. Thanks Mike --~--~-~--~~~---~--~~ 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 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: JSON reviver option
IIRC json2 supports it... We could get around to fixing that old piece
of missing functionality in jQuery and kill two birds with one stone.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
I'd be wary of adding that - especially since it wouldn't work for
browsers that don't support JSON.parse.
--John
On Mon, Aug 17, 2009 at 3:12 AM, Mark Gibson jollyt...@gmail.com
mailto:jollyt...@gmail.com wrote:
Hi, any chance we could add a reviver option to the ajax settings for
JSON requests?
This could also be used by other plugins that parse JSON data too.
- Mark
Index: src/ajax.js
===
--- src/ajax.js (revision 6529)
+++ src/ajax.js (working copy)
@@ -182,7 +182,8 @@
json: application/json, text/javascript,
text: text/plain,
_default: */*
- }
+ },
+ jsonReviver: null
},
// Last-Modified header cache for next request
@@ -565,7 +566,7 @@
// Get the JavaScript object, if JSON is used.
if ( type === json ) {
if ( typeof JSON === object
JSON.parse ) {
- data = JSON.parse( data );
+ data = JSON.parse( data,
s.jsonReviver );
} else {
data = (new
Function(return + data))();
}
--~--~-~--~~~---~--~~
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
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: about iterators, closures and scope
Samer Ziadeh wrote:
On Fri, Aug 14, 2009 at 00:00, Daniel Friesen
nadir.seen.f...@gmail.com mailto:nadir.seen.f...@gmail.com wrote:
function Person() {
return Object.create(Person.prototype, {
first: { value: '' }
last: { value: '' }
});
}
oh ok, so then all i have to do is this? or do I have it wrong?
var boy = Person();
var girl = Person();
Yup, though to be technical both `new Person();` and `Person()` are
valid, since the return overrides the object created with new.
You could even chose to make those non-enumerable or lock them
with values.
Yeah I was reading over the specifications, but I haven't really
thought about it fully as to how implement it.
Not possible. The ability to change
enumerability/writability/configurability from JS is an ES5 addition.
--
Samer Ziadeh
www.samerziadeh.com http://www.samerziadeh.com
Let It Be
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--~--~-~--~~~---~--~~
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
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: about iterators, closures and scope
new Person() ES3 style:
create object, set prototype, run user code
Person() ES3 style with !instanceof chunk:
run user code, check for instanceof (walk the proto chain), create
object, set prototype, run user code
((To be technical; new Person() ES3 style with the !instanceof chunk)):
create object, set prototype, run user code, check for instanceof (walk
the proto chain)
Person() ES5 style:
run user code, create object, set prototype
new Person() ES5 style (object created by new being discarded):
create object, set prototype, run user code, create object, set prototype
take your pick, discard an object when adding a new that doesn't belong,
or run a function and walk the proto chain twice each when forgetting to
use new.
Other than using fake ES5 in environments where ES5 is not implemented I
don't see how the new ES5 stuff is any less efficient than the ES3 methods.
It's not like objects being created then quickly discarded is anything
new in JS.
foo.bar = baz; // creates a object to wrap foo so it can set .bar
on it, then discards that object.
Or rather in every day use:
foo.substr(1,1).toUpperCase(); // creates an object to wrap foo,
runs .substr, discards the object, wraps the new string literal in
another object, runs .toUpperCase(), discards the object.
Well, that's basically how it's supposed to behave, I'm not sure if any
of the interpreters optimized this case enough to avoid discarding
anything while mimicking the defined behavior.
And that's not the only thing ES5 adds, don't forget about strict mode.
Strict mode goes and improves programming using the old ES3
classfunction based approach.
script
strict mode;
function Person() {
this.first = '';
this.last = '';
}
new Person(); // Works, no instanceof overhead cruft
Person(); // Throws an error right away because undefined can't have
properties.
/script
In ES5 strict mode `this` inside functions is undefined instead of the
global object.
That means that instead of the this.first = ''; meaning window.first =
''; when you call Person() instead of `new Person()` it means
undefined.first = '';
Thus rather than setting a global property which depending on your code
may not throw for awhile and leak into the global object, it'll throw
right away because it can't access/set properties on undefined.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Andrea Giammarchi wrote:
Dude, I know what you mean and I use Objeect.create already via
vice-versa and no flags configuration but imho to better understand
benefits we should consider better examples. I forgot in this one
there is another thing to: call the init method over created instance.
So, again, our good old ES3 is still better than future alchemies for
that purpose, imho.
On Aug 14, 2009 10:08 AM, Pauan pcxunlimi...@gmail.com
mailto:pcxunlimi...@gmail.com wrote:
The example chosen was poor. It is true that the example could be
trivially implemented right now.
Object.create is most useful when either A) using inheritance without
functions, or B) when changing the enumerable, writable, and
configurable properties. In that case the extra code would be needed.
The example didn't demonstrate either of those cases, so of course it
looks like meaningless boilerplate.
As was said, You could even chose to make those non-enumerable or
lock them with values. That was the point, I believe. It allows you
not only to remove the new at the front of constructors, but also
allows you to configure property flags.
I already provided an example that shows how to do inheritance without
needing constructor functions at all, which I believe was the primary
intent of Object.create.
On Aug 14, 1:47 am, Andrea Giammarchi andrea.giammar...@gmail.com
mailto:andrea.giammar...@gmail.com
wrote:
We are not under a unified VM (syntax not usable) and I cannot spot
a single benefit using two c...
--~--~-~--~~~---~--~~
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
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: about iterators, closures and scope
Andrea Giammarchi wrote:
Daniel it is a non-sense and I tell you why.
strict aim is to guarantee future compatibility, right?
The choice of strict means hey cool and updated browser, you should
behave like that here!
So whatever happens there, under strict, it does not matter, 'cause
every other browser will simply use old behaviors which means we have
to both hard code and hard test because strict does not mean we
are sure that error will be generated, it simply means that some new
browser will eventually generate an error.
In few words strict simply open just another different scenario that
will make JavaScript development even more confusing 'cause we'll have
to handle both quirk and strict modes plus every discrepancy with both
quirk and strict modes we can have in every browser and its a part VM.
Strict mode is backwards compatible. (Precisely the reason why it's
`use strict;` not `use strict;`)
Strict mode is for the developers, not for the users. It doesn't matter
if your users are using browsers which have implemented ES5 or not. All
you do is hop into a browser that has implemented ES5 when testing and
it'll throw the errors so you don't fall into the potholes trying to
find where they came from.
Strict mode is a mode which disables and fixes a number of the old
counterintuitive and unexpected gotchas inside of JS, as well as
providing a mode where the engine has more opportunities to optimize and
make code run faster.
Cool? Just multiply by 2 every problem we have right now with
JavaScript, and this is ES5!
I am not complaining about ES5, I am just being realistic about what
this will mean for us.
Finally, as somebody said already ages ago, I better prefer to fix
JavaScript AS IS, rather than implement new not-usable stuff that only
few developers will get instantly right.
It is just my opinion.
Regards
On Fri, Aug 14, 2009 at 11:19 AM, Daniel Friesen
nadir.seen.f...@gmail.com mailto:nadir.seen.f...@gmail.com wrote:
new Person() ES3 style:
create object, set prototype, run user code
Person() ES3 style with !instanceof chunk:
run user code, check for instanceof (walk the proto chain), create
object, set prototype, run user code
((To be technical; new Person() ES3 style with the !instanceof
chunk)):
create object, set prototype, run user code, check for instanceof
(walk
the proto chain)
Person() ES5 style:
run user code, create object, set prototype
new Person() ES5 style (object created by new being discarded):
create object, set prototype, run user code, create object, set
prototype
take your pick, discard an object when adding a new that doesn't
belong,
or run a function and walk the proto chain twice each when
forgetting to
use new.
Other than using fake ES5 in environments where ES5 is not
implemented I
don't see how the new ES5 stuff is any less efficient than the ES3
methods.
It's not like objects being created then quickly discarded is anything
new in JS.
foo.bar = baz; // creates a object to wrap foo so it can set
.bar
on it, then discards that object.
Or rather in every day use:
foo.substr(1,1).toUpperCase(); // creates an object to wrap foo,
runs .substr, discards the object, wraps the new string literal in
another object, runs .toUpperCase(), discards the object.
Well, that's basically how it's supposed to behave, I'm not sure
if any
of the interpreters optimized this case enough to avoid discarding
anything while mimicking the defined behavior.
And that's not the only thing ES5 adds, don't forget about strict
mode.
Strict mode goes and improves programming using the old ES3
classfunction based approach.
script
strict mode;
function Person() {
this.first = '';
this.last = '';
}
new Person(); // Works, no instanceof overhead cruft
Person(); // Throws an error right away because undefined can't have
properties.
/script
In ES5 strict mode `this` inside functions is undefined instead of the
global object.
That means that instead of the this.first = ''; meaning window.first =
''; when you call Person() instead of `new Person()` it means
undefined.first = '';
Thus rather than setting a global property which depending on your
code
may not throw for awhile and leak into the global object, it'll throw
right away because it can't access/set properties on undefined.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
[http://daniel.friesen.name]
Andrea Giammarchi wrote:
Dude, I know what you mean and I use Objeect.create already via
vice-versa and no flags configuration but imho to better understand
benefits we should consider better examples. I forgot in this one
there is another thing to: call
[jquery-dev] Re: about iterators, closures and scope
Ya sorry.
Shame it's going away, I wanted to use it for my module inclusion
pattern server-side.
with( banana('io') )
with( banana('markup.visual.markdown') ) {
var html = MarkDown.parse(File('./foo.txt').content)
}
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Henry wrote:
On Aug 14, 12:48 pm, Daniel Friesenwrote:
snip
... , while a nice feature but widely misunderstood while() {}
prevents some potential optimizations so it's a
syntax error in strict mode, ... .
Presumably your intended target there was - with( x ){ ... } -, not
'while', as the former is as you describe, and the latter pretty
normal and harmless.
--~--~-~--~~~---~--~~
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
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: about iterators, closures and scope
Whether you think the global object being `this` is an error or not, it
doesn't change the fact these implied references to the global scope
create hard to track down bugs just my forgetting a single keyword some
random place in the code.
`this` makes perfect sense as undefined. You're creating a new object,
`this` is that object. You're calling a method on an object, `this` is
that object, you're calling foo() which you just defined in your local
scope, the global has nothing to do with `this`, it's not the object you
are calling it on, you're calling it on nothing, so your this is nothing.
`this` still refers to the global object in global scope;
var originalWindow = this;
If you are desperate to use that function this hack it's perfectly
possible as well.
var originalWindow = (function(){return this})();
(function(window) {
strict mode;
// strict mode code with a safe window
})(originalWindow);
But honestly, what possible kind of js programming have you done where
you're not writing your code in the global scope? JS doesn't make it
easy, or very possible to dynamically nest code inside of another
unrelated set of code. It's all run in global scope unless you use eval.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Andrea Giammarchi wrote:
Daniel,
I do not think the global object as default this is an error at all,
this is my point.
What does not make sense at all is to use a this referred to an
undefined value.
undefined is not an object so this which is a self-instance/scope
pointer does not make sense.
This is the most secure way to obtain the original global object and
we are loosing it with strict
var originalWindow = (function(){return this})();
so old browser with strict code cannot retrieve the native window if
it has been redefined somewhere else.
Do you understand what I mean?
strict will mean double test, double behavior, because of compatible
and not compatible browser ... it is truly simple to understand, you
resolve gotchas ? Trust me, you gonna create even more gotchas for
old browsers in this way.
Regards
On Fri, Aug 14, 2009 at 12:48 PM, Daniel Friesen
nadir.seen.f...@gmail.com mailto:nadir.seen.f...@gmail.com wrote:
Strict mode doesn't have new features, it has restrictions.
Strict mode adds nothing over what ES3 already has, it only places
restrictions on things which can cause issues or hinder the
ability for
the engine to optimize.
this in functions is undefined instead of global, eval cannot
dynamically inject new variables, eval cannot be renamed or passed
around in ways that make eval get indirectly called and potentially
inject code where it doesn't belong, `foo = 123` does not define an
implied global and throws instead, while a nice feature but widely
misunderstood while() {} prevents some potential optimizations so
it's a
syntax error in strict mode, there might have been one or two more.
Your code works fine whether it's run in ES3 or ES5. The difference is
that when testing using an ES5 browser a lot of gotchas like
forgetting
var in front of a variable throw errors instead of silently exhibiting
confusing behavior. As well any ES5 browser running the code has the
opportunity to optimize the code and run it faster.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
[http://daniel.friesen.name]
Andrea Giammarchi wrote:
Who talked about users here?
You put strict you do not have that common behavior, whatever
right
or wrong it is, but you cannot use new features for
compatibility reason.
Where exactly do you find a better development and debug pattern
with
this strategy?
--~--~-~--~~~---~--~~
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
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: about iterators, closures and scope
I won't argue that with is a misunderstood feature of JS. I liked it myself.
However I'm not a fan of your example. I like with() {} because of the
ability to import namespaces into a scope.
with(mylibrarysnamespace) {
mylibraryfunction(); // called without needing to do
mylibrarynamespace.mylibraryfunction();
}
For your example, the counterpart:
window.onload = function(){
var body = document.body;
body.appendChild(document.createElement(div))
.appendChild(document.createTextNode(hello));
body.firstChild.innerHTML += world;
};
Is much more efficient.
Even if your example did shave off the size (which in this case, it
actually makes it longer instead) it's inefficient for the interpreter
to run it.
You add up to 3 levels onto the scope chain. To get ahold of
createTextNode the interpreter has to check for
thenodeyoucreated.createTextNode, body.createTextNode, then finally
document.createTextNode. As opposed to just document.createTextNode
which gets the function you want directly.
Also, to be frank I found it hard to read. It took me a bit to decipher
it and convert it to that chunk above.
By the way, the example falls apart when dealing with fetching nodes and
setting attributes that may not be defined.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Andrea Giammarchi wrote:
with is another misunderstood feature of JS, imho, you have to be
truly a junior to make mistakes with that (and we all did common
mistakes when we were junior, is there anybody that blamed the
language rather than hisself?)
The only problem I can spot with with is not about developers but
the YUI compressor and machine parsers ... there is nothing wrong
there. I wonder which part is ambiguous for humans, if they know what
they are doing ...
onload = function(){
with(document){
with(body){
with(appendChild(createElement(div)))
appendChild(createTextNode(hello));
with(firstChild)
innerHTML += world;
}
}
};
... and script size is preserved ...
BTW, I have already done all these conversations years ago when I
become certified AS2 developers being a pro with AS1 and Macromedia
decided to change ActionScript (ECMA262) 2 times in 3 years ... good
stuff, except Macromedia does not exist anymore indeed and lost a lot
of money putting effort for something never truly adopted by
developers until somebody else put even more money (Adobe)
I do not like breaking stuff, ES5 supposes to avoid problems they had
with ES4 but if this is the direction, and this will be 'cause we
cannot do anything except adapt ourself, I do not think it will bring
any concrete benefit for developers except, as I've already said, a
lot of confusion added in the already most confused programming
language ever.
Regards
--~--~-~--~~~---~--~~
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
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: about iterators, closures and scope
To create an object in ES3, yes. (ES3; ECMAScript 3; Current JavaScript)
ES5 adds a new method which follow the proper prototypal method (ES5;
ECMAScript 5; The next version, ES4 was discarded)
Object.create(proto, {...});
The first argument is a prototype to give it:
Object.create(Foo.prototype); is roughly the same as,
in mozilla js:
({ __proto__: Foo.prototpe })
in normal js
function F() {}
F.prototype = Foo.prototype;
new F;
Just so you know the {...} is a object listing keys to add. Each key has
an object with data like value: (the value), or get: (a getter) and/or
set: (a setter), as well as the attributes enumerable (part of for-in
loops), writable (you can set it), and configurable (it can be removed
using `delete o.prop`)
There's a nice new idiom which involves using Object.create inside a
function, using that function's prototype as the proto, setting
properties, and returning that object. Essentially it does the same as
using `new Fn` except it gives you more control, and works whether you
use new or not.
There's also an interesting new strawman that was recently brought into
the harmony group, makes this possible:
function Foo() {
return {
[parent: Foo.prototype],
foo: I'm a value,
const _bar: You can't set or delete me after this,
};
}
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Samer Ziadeh wrote:
Isn't the 'new' a needed keyword?
On Thu, Aug 13, 2009 at 08:04, Andrea Giammarchi
andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote:
Python rules, and I mainly agree, except the day new will not be
necessary anymore we'll loose constructor duality, as functions,
and implicit injected init methods.
Regards
On Tue, Aug 11, 2009 at 3:46 AM, Daniel Friesen
nadir.seen.f...@gmail.com mailto:nadir.seen.f...@gmail.com wrote:
The requirement of new to create new js objects is an
unnecessary
piece of the language, in fact the need to use it disappears
in ES5 as
it's no longer the only way to create new objects with a set
prototype.
There's nothing strange about having a $ function and creating
an object
from it, in fact it's closer to real prototype-based
programming than
the `new Class` you see inside of JavaScript.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
[http://daniel.friesen.name]
--
Samer Ziadeh
www.samerziadeh.com http://www.samerziadeh.com
Let It Be
--~--~-~--~~~---~--~~
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
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: about iterators, closures and scope
function Person() {
return Object.create(Person.prototype, {
first: { value: '' }
last: { value: '' }
});
}
You could even chose to make those non-enumerable or lock them with values.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Samer Ziadeh wrote:
So how would this translate to the update method without the new keyword.
function Person() {
this.first = '';
this.last = '';
}
var boy = new Person();
var girl = new Person();
On Thu, Aug 13, 2009 at 21:48, Daniel Friesen
nadir.seen.f...@gmail.com mailto:nadir.seen.f...@gmail.com wrote:
To create an object in ES3, yes. (ES3; ECMAScript 3; Current
JavaScript)
ES5 adds a new method which follow the proper prototypal method (ES5;
ECMAScript 5; The next version, ES4 was discarded)
Object.create(proto, {...});
The first argument is a prototype to give it:
Object.create(Foo.prototype); is roughly the same as,
in mozilla js:
({ __proto__: Foo.prototpe })
in normal js
function F() {}
F.prototype = Foo.prototype;
new F;
Just so you know the {...} is a object listing keys to add. Each
key has
an object with data like value: (the value), or get: (a getter) and/or
set: (a setter), as well as the attributes enumerable (part of for-in
loops), writable (you can set it), and configurable (it can be removed
using `delete o.prop`)
There's a nice new idiom which involves using Object.create inside a
function, using that function's prototype as the proto, setting
properties, and returning that object. Essentially it does the same as
using `new Fn` except it gives you more control, and works whether you
use new or not.
There's also an interesting new strawman that was recently brought
into
the harmony group, makes this possible:
function Foo() {
return {
[parent: Foo.prototype],
foo: I'm a value,
const _bar: You can't set or delete me after this,
};
}
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
[http://daniel.friesen.name]
Samer Ziadeh wrote:
Isn't the 'new' a needed keyword?
On Thu, Aug 13, 2009 at 08:04, Andrea Giammarchi
andrea.giammar...@gmail.com
mailto:andrea.giammar...@gmail.com
mailto:andrea.giammar...@gmail.com
mailto:andrea.giammar...@gmail.com wrote:
Python rules, and I mainly agree, except the day new will
not be
necessary anymore we'll loose constructor duality, as functions,
and implicit injected init methods.
Regards
On Tue, Aug 11, 2009 at 3:46 AM, Daniel Friesen
nadir.seen.f...@gmail.com
mailto:nadir.seen.f...@gmail.com
mailto:nadir.seen.f...@gmail.com
mailto:nadir.seen.f...@gmail.com wrote:
The requirement of new to create new js objects is an
unnecessary
piece of the language, in fact the need to use it disappears
in ES5 as
it's no longer the only way to create new objects with a set
prototype.
There's nothing strange about having a $ function and
creating
an object
from it, in fact it's closer to real prototype-based
programming than
the `new Class` you see inside of JavaScript.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
[http://daniel.friesen.name]
--
Samer Ziadeh
www.samerziadeh.com http://www.samerziadeh.com
http://www.samerziadeh.com
Let It Be
--
Samer Ziadeh
www.samerziadeh.com http://www.samerziadeh.com
Let It Be
--~--~-~--~~~---~--~~
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
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: about iterators, closures and scope
Event callback: function(eventObject) { this = domnode }// Because
that's the way events have always worked
each() callback: function(index, sameAsThis) { this = item/domnode } //
Keeping the pattern
map() callback: function(index, sameAsThis) { this = item/domnode } //
Keeping the pattern
filter() callback: function(index) { this = item/domnode } // sorta
keeping the pattern
vs.
Event callback: function(eventObject) { this = domnode } // event
callbacks MUST use this as domnode, otherwise you destroy the api it was
based on
each() callback: function(item, index?) { ... }
map() callback: function(item, index?) { ... }
filter() callback: function(item, index?) { ... }
Whether you like it or not, jQuery is a library for working with the
dom. Thus when created each/map/filter had nothing to do with the array
methods that have only been put into browsers recently (yes, recently...
you are comparing standards set by new features, with decisions that
were made years ago; not the best comparison), they were created to give
control over the jQuery object's list of dom nodes. Thus, since all the
other apis which worked with dom nodes used `this` to refer to the dom
node that same api was used when writing those methods.
It's only a side effect that these methods happen to be usable on
non-domlist arrays. Though frankly, imho that is abuse, these methods
are not meant for that purpose, you can plainly see that in how $.fn.map
differs from Array.prototype.map in how it folds arrays into the list
rather than adding them as items.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Pauan wrote:
And how is it inferior to set the current item as an argument to the
callback? This is how Array.prototype.forEach works. It causes less
problems while providing the exact same functionality. Also, event
handlers are not the same as functions used to iterate over an object,
nor do they serve the same purpose, so one model doesn't necessarily
apply to the other.
On Aug 11, 6:10 am, Scott González scott.gonza...@gmail.com wrote:
There definitely is a reason for it. jQuery is a library for working
with the DOM, it is not a library meant to fix every problem with
JavaScript or to try to extend JavaScript in every possible way. When
using jQuery specifically to work with the DOM (probably 90% of what
you're using it for, and 100% of what the average user uses it for),
it makes perfect sense to set the context to the current item. Also,
native event handlers set the context to the event target, so jQuery
had an existing model to follow.
--~--~-~--~~~---~--~~
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
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: Recursive $.extend should manage loops
jQuery does reproduce loops:
var father = {
child : {}
}
father.child.father = father;
$.extends( {}, father )
The problem here is you are telling jQuery to recurse into things it
shouldn't be recursing into.
$.extends( true, .. ); is for when you want to duplicate nested objects,
rather than reference the same objects.
By definition, you are asking jQuery to:
Take {}
Take the keys in father:
for the child key:
create an object to make a duplicate using and place that onto {}.child
recurse into child:
for the father key:
create an object to make a duplicate using and place that onto
child.father
recurse into father:
for the child key:
create an object to make a duplicate using and place
that onto father.child
recurse into child:
...
There is no problem here, jQuery is following your orders just as you
give them.
If jQuery were to try and track circular references it would:
A) Make .extends extremely inefficient because it would have to store
just about everything it touches and make sure it doesn't recurse
B) No longer create duplicate objects as it was told to
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
ludovic wrote:
Hi,
I've got loops in my objects relations. Example :
var father = {
child : {}
}
father.child.father = father;
$.extends( true, {}, father ) causes a infinite loop.
Jquery should reproduce loops.
Regards,
Ludovic
--~--~-~--~~~---~--~~
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
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: prototypal inheritance as part of jQuery core?
ES5 + .extend is not necessary for this simple chunk.
(function($){
if (!Object.create)
var F = function(){};
$.beget = function (proto, props) {
if(Object.create)
var o = Object.create(proto);
else {
F.prototype = proto;
var o = new F;
}
for ( var k in props )
o[k] = props[k];
return o;
};
})(jQuery);
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Andrea Giammarchi wrote:
Dunno how many times that bedge has been optimized ;-)
(function(){
var F = function(){};
jQuery.beget = function (proto, props) {
F.prototype = proto;
return props ? $.extend(new F, props) : new F;
};
})();
Regards
On Thu, Jul 30, 2009 at 3:48 PM, Már Örlygsson
mar.orlygs...@gmail.com mailto:mar.orlygs...@gmail.com wrote:
Hi.
If it hasn't been already considered (and rejected), I'd like to float
the idea of adding support for prototypal inheritance into the jQuery
core library.
Something like this...
jQuery.beget = function (proto, props) {
var F = function () {};
F.prototype = proto;
var instance = new F();
return props ? $.extend(instance, props) : instance;
};
...becomes immensely powerful - especially during plugin development
when allowing users to extend/override default options
options = $.beget($.myplugin.defaults, options || {});
...and in various other common use cases - including $.fn.data()
assignments, etc.
I for one would love to see this feature added.
--
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-dev@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: about iterators, closures and scope
The requirement of new to create new js objects is an unnecessary
piece of the language, in fact the need to use it disappears in ES5 as
it's no longer the only way to create new objects with a set prototype.
There's nothing strange about having a $ function and creating an object
from it, in fact it's closer to real prototype-based programming than
the `new Class` you see inside of JavaScript.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Tarini wrote:
thanks guys for you answer but I know how to use $.each in OO context...
I would like to understand why jQuery works in this way..
What are the advantage using this inside closure instead of using a temp
arguments like the index? I see only disadvantage...
I also created a plugin (http://code.google.com/p/jquerycallback/) to
manage callback using OO but this remain one of the (few) aspects of
jQuery I don't like and I would like to get a reason :)
Also...
Thinking about OOP... are you really sure that jQuery isn't a OO library
(or framework as you prefer)?
Two considerations about this relationship between jQuery and OOP:
- jQuery selectors are a strange way to construct an object, an
alternative constructor starting from a dollar sign and not with new
keyword ( var divs = $(div) should be written as var divs = new
jQuery(div) )
- jQuery function (events, attributes, traversing, ecc...) are a lot of
methods of jQuery object... they aren't simple namespaced function in a
functional paradigm.
(alternative) constructor + a lot of methods = object oriented
programming
why not?
I hope to get some reply ;)
On Fri, 2009-08-07 at 07:37 -0700, aHeckman wrote:
@ludovic, javascript IS an object oriented language. There is no need
for simulation. It's just a different type of oop than classical.
function Person (name) {
this.name = name || 'Nobody';
}
Person.prototype = {
sayName: function () {
alert('Hi my name is ' + this.name);
}
};
var ludovic = new Person('ludovic')
On Aug 7, 8:13 am, ludovic ludothebe...@gmail.com wrote:
If you want to keep you function's context, you can still do
$('div').each( function() {
Context.myFunction( this );
} );
Anyway, I'm not sure it's a good idea to try to simulate object
oriented syntax with javascript.
It isn't an object oriented language and trying to make a language in
a foreign paradigm is always heavy.
But it is a personal opinion...
---
Ludovic
--~--~-~--~~~---~--~~
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
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: jquery events binding
I thought events were event.namespace you're suggesting the ability to
bind multiple namespaces to one event? Don't you mean multiple events to
one namespace?
And what's so bad about just using the normal object notation instead?
$(target).bind({
'example.start': new Function(),
'example.stop': new Function()
});
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
ludovic wrote:
Hi all,
I propose to add the following new feature in events binding :
var o = {
start : new Function(),
stop : new Function()
}
// Will be the same as
// $(target).bind( 'example.start', o.start );
// $(target).bind( 'example.stop', o.stop );
$(target).bind( 'example', o );
$(target).triggerHandler( 'example.start' ); // Will call start
function
It is very easy to implement, and would simplify interface. After
that, I would be great to normalize all components with the
following :
$(target).myComponent( {
events : {
start : new Function(),
stop : new Function()
},
myOtherParam : 'value'
}
As jquery supports namespaced events, it should support it fully.
Best regards,
--~--~-~--~~~---~--~~
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
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: prototypal inheritance as part of jQuery core?
Personally I think functionality should be put where it belongs, people should stop trying to shove functionality into jQuery turning it into a bloated framework. jQuery is great for node selection, jQuery is great for dom manipulation, jQuery is great for various forms of AJAX, jQuery is great for animation... jQuery isn't a library trying to add partial ES5 support to legacy browsers, a library providing a stdlib of array and string manipulation methods, a browser side module loading system, etc... Functionality like that should be done in separate JS frameworks built for those purposes. Like how I started my Wrench.js project as a library providing a stdlib of array and string manipulation methods. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] Már wrote: So, would jQuery and jQuery plugin developmers benefit from having some sort of (highly optimized of course ;) prototypal inheritance methods built into the core library? My vote: Yes. What do you guys think? -- 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-dev@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: prototypal inheritance as part of jQuery core?
There was another discussion on the mailing list about a plugin
authoring plugin. It actually allowed plugins that did things like
$(...).plugin().myPluginFunction().myOtherPluginFunctionWhichReturnsJQ().find(...);
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
tres wrote:
I think if plugin developers were to start utilizing a prototypal
inheritance, it would make the most sense to put it into the core.
This doesn't mean the current way of extending jQuery needs to change,
this just adds to it and makes an api much easier to write, understand
and use. As a plugin developer who has written many plugins (not
necessarily released) I have found it very, very frustrating to write
a plugin with more than 1 function in jQuery. I don't want to pass
'this' as a parameter, nor do I want to use the .dialog('open')
method. The former isn't the jQuery way and the latter just seems
dirty.
On Aug 6, 1:14 pm, aHeckman aaron.heckm...@gmail.com wrote:
I too believe prototypal inheritance should be left out.
But, in general, I'd love to see a change like this in jquery.ui ...
On Aug 5, 10:36 pm, tres treshug...@gmail.com wrote:
// would now allow
$('div').dialog().open();
// instead of
$('div').dialog('open');
--~--~-~--~~~---~--~~
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
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: Ticket #4946, jQuery.isObject
typeof fn === 'function'; // Some things like
document.createElement('object'); return wonky results
fn instanceof Function; // Breaks across iFrames
toString.call(fn) === [object Function]; // Works the same across
iFrames and returns more reliable results
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Andrea Giammarchi wrote:
About isFunction
I lost the point where toString.call(obj) === [object Function] was
introduced instead of obj instanceof function
I understand differences in IE so I wonder if two distinct callbacks
could solve the odyssey:
isFunction: function( obj ) {
return obj instanceof Function;
},
isDOMFunction: toString.call(window.alert) === [object Function] ?
function( obj ) {
return toString.call(obj) === [object Function];
}:
// IE only and only until standard native function manifest
function( obj ){
return !!obj typeof obj.toString === undefined
/^\s*\bfunction\b/.test(obj);
}
,
In this way we could consider that in every browser, and when
call/apply are supported, isFunction(fn) will guarantee call/apply
while a DOMFunction could require a try catch or a different behavior
for IE
switch(true){
case $.isFunction(fn): return fn.call(what, ever);
case $.isDOMFunction(fn): what.push.call(what, toArray(fn(ever)));
return what;
default: throw new Error(what tf?);
}
... or maybe not?
Regards
On Sun, Jul 26, 2009 at 4:09 PM, Andrea Giammarchi
andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote:
I usually encapsulate toString from Object.prototype and if
somebody breaks the rule it means we cannot trust anything
included typeof. So, in few words, nobody has intersts into break
this rule, imho.
On Jul 26, 2009 8:07 AM, DBJDBJ dbj...@gmail.com
mailto:dbj...@gmail.com wrote:
Also, IMHO this yields high level of encapsulation of an important
mechanism.
Which is a good thing.
And it is a fraction of a micro second slower then
Object.prototype.toString.call(x) === [object Object]
but it is more compact ...
In any case we are entering the subjective judgement phase, so I
think
we should stop here and leave it to jQuery team to use this or not...
--DBJ On Jul 26, 12:09 am, Andrea Giammarchi
andrea.giammar...@gmail.com
mailto:andrea.giammar...@gmail.com wrote:
I miss the point about regexp usage ... please tell me the
difference (in a real scenario) betwe...
On Sat, Jul 25, 2009 at 1:38 PM, DBJDBJ dbj...@gmail.com
mailto:dbj...@gmail.com wrote:This indeed woks : functi...
--~--~-~--~~~---~--~~
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
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: enhancing closest delegation
While what is being talked about here is confusing me, there are valid
uses for a method of restricting a .find based on a selector. That's a
feature I'd like to see.
$(NavFrame).find('.NavContent, .NavPic' /* some way of restricting to
outside nested .NavFrames */);
That being said, I don't like the context idea, to me a second
‘restrict’ argument makes the most sense. keep options relevant to X
method in X method's arguments
~Daniel Friesen (DanTMan, Nadir Seen Fire) [http://daniel.friesen.name]
On 23-Jul-09, at 8:08 AM, John Resig jere...@gmail.com wrote:
A big distinction between the two proposals is if DOMElement is not
contained in DOMElementContext:
$(DOMEelement,DOMElementContext).closest(body); returns $([]);
$(DOMEelement).closest(body,DOMElementContext); returns $(body);
I vote for the 2nd argument.
In what case would you want to find the closest() match but outside
of a context? What's the point of providing a context then if most
closest() queries will just ignore the context away?
--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-dev@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: Having valueOf() reflect length of collection - a good idea?
John Resig wrote:
I'm hesitant to add that (I've definitely thought about it, in the
past) because .valueOf() doesn't cover all comparison cases.
obj obj2 works (as you noted)
but if ( obj ) {} doesn't (it always returns true)
Additionally, in Firebug, the result shows up as a number rather than
something more useful (like a list of elements).
What about type hinting?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--John
On Thu, Jul 23, 2009 at 2:06 PM, James Padolsey
jamespadol...@googlemail.com mailto:jamespadol...@googlemail.com
wrote:
Just a thought; this would be quite useful IMO:
var paras = $('p'), uls = $('ul');
if (paras uls) {
// ...
}
I know it's not quite as readable (or as semantic) as:
if (paras.length uls.length) {
// ...
}
but still, it's one of those things that may as well be added, just
for the few situations where it may be useful.
jQuery.fn.valueOf = function(){return this.length;};
Unless it's got some other valid use (with jQuery)...?
--~--~-~--~~~---~--~~
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
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: $.ajax's error callback: Confusion with status codes and dataType
For what it's worth, `undefined` is an illegal JSON value. You could
pass undefined rather than null or an empty object because json ===
undefined would mean that the json failed since `undefined` is not a
legal json value like `null` and `{}` are.
On Jul 23, 6:33 am, Dave Methvin dave.meth...@gmail.com wrote:
But following that argumentation a 204 would always be an error
since any request expects something (XML by default), no?
Well, yeah I guess, except the situation where you were asking for
html or text and it could be returned as an empty string on a 204. I
want to define error and success in terms of whether it
successfully delivered the dataType requested, not the underlying http
status code that delivered it.
For example, let's say I request dataType:jsonand the server returns
200 but content that is not validjson. Somehow, $.ajax needs to let
me know about that. If it fires the success handler, what should
thejsonargument be? If it's an empty object or null, it doesn't capture
the fact there was an error. I won't have any indication that there
was a problem unless I try re-parsing the responseText myself.
In the 204+jsoncase you could certainly pass a null or empty object
to the success handler instead of firing the error handler, although
I'd prefer to have it fire an error. Alternate interpretations can
always be dealt with by using complete instead of error/success so
this seems like an issue of picking the interpretation with the least
surprise.
--~--~-~--~~~---~--~~
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
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: Having valueOf() reflect length of collection - a good idea?
O_o
wtf, I thought that valueOf was ignored for those kind of bools.
Taking another look, !! doesn't even run valueOf as I thought.
My comment was on the operator, and your comment about what jquery
shows up as in firebug if used.
jQuery.fn.valueOf = function(hint){
if ( hint === number )
return this.length;
return this.get(); // on a second note, it would be nice to use a
toArray() instead.
};
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
Nope.
var obj = { valueOf: function(){ return 0; } };
!!obj
true
obj.valueOf().constructor
Number()
It looks like it's returning the number as Number(0) rather than in
its primitive form.
--John
On Thu, Jul 23, 2009 at 5:49 PM, Daniel Friesen
nadir.seen.f...@gmail.com mailto:nadir.seen.f...@gmail.com wrote:
John Resig wrote:
I'm hesitant to add that (I've definitely thought about it, in the
past) because .valueOf() doesn't cover all comparison cases.
obj obj2 works (as you noted)
but if ( obj ) {} doesn't (it always returns true)
Additionally, in Firebug, the result shows up as a number rather
than
something more useful (like a list of elements).
What about type hinting?
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
[http://daniel.friesen.name]
--John
On Thu, Jul 23, 2009 at 2:06 PM, James Padolsey
jamespadol...@googlemail.com
mailto:jamespadol...@googlemail.com
mailto:jamespadol...@googlemail.com
mailto:jamespadol...@googlemail.com
wrote:
Just a thought; this would be quite useful IMO:
var paras = $('p'), uls = $('ul');
if (paras uls) {
// ...
}
I know it's not quite as readable (or as semantic) as:
if (paras.length uls.length) {
// ...
}
but still, it's one of those things that may as well be
added, just
for the few situations where it may be useful.
jQuery.fn.valueOf = function(){return this.length;};
Unless it's got some other valid use (with jQuery)...?
--~--~-~--~~~---~--~~
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
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: My solution for legacy web applications demanding IE6
jQuery isn't only for web apps. It's also for smaller websites. And it'd be a shame for show/hide to stop working in older browsers when it has no reason to. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] DBJDBJ wrote: @tres Voice of reason. Thanks @all Solution I am proposing will work even for M$FT. If and when (sort-of- a) supporting IE4-7 becomes not-feasible. They did the same solution but for XP. Instead of supporting legacy OS they delivered a virtual environment for legacy OS apps. I simply am suggesting the same for legacy web apps. jQuery and IE old : I am wondering why mainstream jQ supports IE6 actually? How many developers actually need and use that? Who and when will be developing an web app today , that will run on IE6 too ? 99% of web apps developed on jQ are new apps for new browsers. If I develop web app today, using jQ or not, I would certainly not promise it will run on IE6, or IE7. Certainly there are large customers still using IE6 for their corporate intranets, but they can introduce FF or Chrome in parallel. The number of developers actually developing today and supporting IE6 is very small. jQuery or not. In any case they should be easy to count. I vote for droping IE6 and IE7 support from jQuery. In the same time there should be a separate version that will support them. But not for ever. --~--~-~--~~~---~--~~ 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 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: enhancing closest delegation
http://dev.jquery.com/ticket/4072
I believe John liked it to when I mentioned it in the mailing list.
It was one of those things on my list of things missing in jQuery compared to
the bad local framework I wrote for an app at work.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
mike.helgeson wrote:
I propose adding a second argument to the closest method that will
act as the end point for searching up the document tree. It can behave
just like the context argument in the jQuery mother function. It
will optimize the performance of a common pattern I have seen in my
own code since the addition o this method.
$(table).bind(click,function( event ){
var $td = $( event.target ).closest(td, this );
});
Because I bound the handler to table I do not want to search an
higher than that element for selector matches. Furthermore, if there
was a selector match outside of the containing element, it could
potentially and accidentally be matched.
http://dev.jquery.com/ticket/4945
Any thoughts?
--~--~-~--~~~---~--~~
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
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: enhancing closest delegation
Not to mention it would either be broken, or be a complete hack.
$(selector, context); is actually an alias for
$(context).find(selector); And this.context isn't what was passed to
context.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Jörn Zaefferer wrote:
Working or not, having public API methods rely on the context-property
doesn't seem like a great idea - is that the case anywhere else?
Jörn
On Wed, Jul 22, 2009 at 11:32 PM, mike.helgesonmike.helge...@gmail.com
wrote:
That makes a lot of sense, except it does not work. The context
property of the jquery instance is always equal to the first element
when passing in DOM nodes. Unless I am mistaken.
On Jul 22, 4:33 pm, Brandon Aaron brandon.aa...@gmail.com wrote:
I think it should just stop at the context of the jQuery object. So
you'd do this instead:
$(table).bind(click, function( event ) {
var $td = $(event.target, this).closest(td);
});
--
Brandon Aaron
On Wed, Jul 22, 2009 at 1:07 PM, mike.helgesonmike.helge...@gmail.com
wrote:
I propose adding a second argument to the closest method that will
act as the end point for searching up the document tree. It can behave
just like the context argument in the jQuery mother function. It
will optimize the performance of a common pattern I have seen in my
own code since the addition o this method.
$(table).bind(click,function( event ){
var $td = $( event.target ).closest(td, this );
});
Because I bound the handler to table I do not want to search an
higher than that element for selector matches. Furthermore, if there
was a selector match outside of the containing element, it could
potentially and accidentally be matched.
http://dev.jquery.com/ticket/4945
Any thoughts?
--~--~-~--~~~---~--~~
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
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: Rename bind/unbind?
Renamed are best done by creating the new name and leaving the old
name around for compatibility.
This isn't a rename bind to something else and force everyone to
change it's a give a new standard name for bind leaving the old name
in place for old code so that new projects have a name they can use
which isn't ambiguous with ES5's .bind()
I kindof like .event()
On 17-Jul-09, at 9:19 AM, Gilles gil...@netxtra.net wrote:
element.bind('click', someFunction, this); - This way allow backward
compatibility.
Your way, renaming the functions the most uses in plug-in, will mean
an aweful lot of developers will have to go through their code and
update it. And to be honest I don't see how anything else could
describe better what the function already does.
--~--~-~--~~~---~--~~
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
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: Enhancement to the trim method
FF3.5's native (ie: likely faster than any js based trim) only trims
whitespace. So personally, I think that if we wanted a function to trim
specific characters it should be implemented in a separate function,
like a strip. That's basically how I did it in Wrench.js
http://wrench.monkeyscript.org/.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
George wrote:
Yep, I'm inclined to agree that trim() is for trimming!
The only little enhancement that I and several colleagues have often
considered is the ability to specify what character to trim off. (The
default being space of course)
George
On Jul 9, 8:34 pm, Daniel Friesen nadir.seen.f...@gmail.com wrote:
Ya, I see no reason to extend trim with functionality that has nothing
to do with trimming.
If you want to remove all whitespace from a string then just use
.replace(/\s+/g, ''); yourself, it's not like it's a substantial piece
of code at all.
If there is any enhancement to .trim it should be using a better method
of trimming (/^\s+|\s+$/g is slow,
seehttp://blog.stevenlevithan.com/archives/faster-trim-javascript) and/or
making use of native trim(); where available (FF3.5).
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Darko Romanov wrote:
Mmm.. I think space replacing doesn't deal (at all?) with trimming.
When I'm programming with a language X and I need to trim I search for
a function that does that job, when I need to strip away spaces I
usually replace that character with an empty string.
If we like the smallest size possible for jquery.js then I think this
would be the last thing we have to put into.
d
On Thu, Jul 9, 2009 at 5:26 PM, dotnetCarpenterjon.ronnenb...@gmail.com
wrote:
Hi all,
I've submitted Ticket #4848 (new enhancement) about a week ago and
would like to hear what you guys think. I think it's handy for
telephone numbers, bank accounts (IBAN/SWIFT) ect. I realize that
changing the core API (no regression) requires some merit. Am I the
only one who like this idea?
/**
* Uses a regular expression to remove whitespace from the given
string.
* @param {String} text The string to trim.
* @param {Boolean} [all] True to remove all white-space from the
text.
* @return {String}
*/
trim: function(text, all) {
var reg = all===true ? /\s+/g : /^\s+|\s+$/g;
return (text || ).replace(reg, '');
}
Cheers, Jon.
PS. noticed a post back in november 2008 about optimizing the trim
method but don't know what the conclusion was.
--~--~-~--~~~---~--~~
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
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: Status of $.browser
Conditional comments are a far better way to test for IE than
$.browser.msie is, and those alternate .css rules would be best in an
ie.css included via conditional comments.
As for setTimeout, it has no need for extra arguments. If you think you
need extra arguments to setTimeout, then you don't know how to use one
of JavaScript's core features, closures.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Andrea Giammarchi wrote:
I think a generic $.browser.IE could always be useful ... sometimes we
have to deal with pixel perfection and I cannot imagine how many
features detections we should do to understand if a table should be
360px rather than 358px cause of duplicated css padding rule ... what
I mean is that feature detection are not always possible.
Most simple example? redefine setTimeout making it accept extra
arguments as well. If you test this via timeout every sync script in
the meanwhile could have get it wrong.
I hope you got my point ( and I do not thing we will all agree into a
delayed timed execution environment, do we? )
Regards
On Mon, Jul 6, 2009 at 5:47 PM, Ralph Whitbeck
ralph.whitb...@gmail.com mailto:ralph.whitb...@gmail.com wrote:
Rick, from what I understand the reason we singled out Safari was
we were having an issue with fadeIn, here is the code I found in
subversion:
if ($.browser.safari) {
// Safari fadeIn fix- just display it straight.
$(#components a.SingleImage + currentPage +
_plcSideContent1).css(display, inline);
}
else {
$(#components a.SingleImage + currentPage +
_plcSideContent1).fadeIn(fast);
}
I'll have to get more info if you need it from the developer that
posted it when he get's back from lunch.
Thanks,
Ralph
On Mon, Jul 6, 2009 at 12:42 PM, Rick Waldron
waldron.r...@gmail.com mailto:waldron.r...@gmail.com wrote:
Ralph,
I'm just sort of curious... could you post up the
$.browser.safari scenario (explanation of goal as well as code
used to reach said goal)?
A little curious to see what was trying to be achieved.
Rick
On Mon, Jul 6, 2009 at 12:16 PM, Ralph Whitbeck
ralph.whitb...@gmail.com mailto:ralph.whitb...@gmail.com
wrote:
John,
From my experience, I clicked on those guides in the docs
and I felt overwhelmed with information when I was looking
for a quick solution to my problem. Just my two cents.
As per the SO discussion I just wanted to highlight the
comments mostly where developers say it's deprecated don't
use it and the other developers asking then what to do
instead.
Thanks,
Ralph
On Mon, Jul 6, 2009 at 12:02 PM, John Resig
jere...@gmail.com mailto:jere...@gmail.com wrote:
Re-wording the documentation from 'deprecated' to
'strongly discourage
the use of' (or something similar) might be ok. I'm
not sure what else
we can do on our end - we already link to a number of
guides that
provide good information on the subject matter.
As to the linked Stack Overflow discussion - perhaps
injecting a rule
into the stylesheet and then detecting to see if the
rule sticks might
work (not sure, just guessing off-hand).
--John
On Mon, Jul 6, 2009 at 11:53 AM, Ralph
Whitbeckralph.whitb...@gmail.com
mailto:ralph.whitb...@gmail.com wrote:
As of 1.3 $.browser is listed as deprecated in
support of jQuery.support.
The thinking is that developers should be basing
their checks on
functionality instead of user agent strings.
I think this is throwing a lot of novice jQuery
users as they see the word
deprecated and think that they shouldn't use it as
the method is going
away. From my understanding that method isn't going
away.
(http://osdir.com/ml/misc/2009-01/msg1.html
According to John R,
$.browser and version will remain in the core
indefinitely, despite being
deprecated...) For some cases it's really
difficult to determine what
piece of functionality to use to get the desired
result. For instance,
today, I noticed a coworker used $.browser.safari to
build code specific
[jquery-dev] Re: Locale support in jquery
jQuery.ui's datepicker has parse/format support and options can be used to localize both the datepicker and parsing/formatting. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] Ricardo wrote: Not a jQ plugin but worth a good look: http://www.datejs.com/ On Jul 2, 6:45 am, Ant anthony.johns...@antix.co.uk wrote: Hi, Does jQuery or a plugin provide number and date parsing for the current culture? There is support in the Microsoft.Ajax library, but I was a bit reluctant to add this to my project as its large and has a lot of overlap with jQuery. Ta, Ant --~--~-~--~~~---~--~~ 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 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: Join several JS scripts into one big file to lower http request
I like to write quick (manifest?) files for that purpose. jsfile1.js jsfile2.js lib/jquery.js Just yesterday I had to optimize the system I've been working on. I wrote a allinone.php cli script that would read the manifest files and build a combined .js and combined .css file then minify both of them. As well I modified the system to in debug/dev mode instead read those manifest files and output all the script tags instead of outputting one allinone tag for both. If you do it the dynamic way, be sure to do something where you compare the latest modified timestamp of all the js files and check to see if it's newer than the allinone file's timestamp and regenerate it if it is. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] Samer wrote: I found it tricky to use an automated combiner thingy in that it doesn't know the order of the javascripts to be added to the page. On Jul 3, 10:46 am, Thijs Houtenbos th...@thijshoutenbosdesign.nl wrote: You make a good point that you put an extra load on the server by compressing each time (even if only a little because gzip is pretty fast). But this can be solved by caching the resulting big JS file, whether you do this with a file cache (my solution) or memcache (should even be more efficient). I have measured significant speed improvements by caching and gzipping. And each time i even change a single byte I just refresh. And besides when you pack the code you just let the client side waste a lot of CPU with each page load. This wasted CPU will become non-trivial on older computers and browsers and definitely when your JS code becomes over several hundred KiB (like Jquery UI). When you are done developing and prepare a release you can also just minify the JS, and let the script add them together and gzip again. This will improve the compression without any performance hit on the client side (min + gzip works better than any packer). And a last note: minifying or packing the JS is no option when you need to debug that JS code. :-) Regards, THD On Fri, Jul 3, 2009 at 4:22 PM, Rebecca Murphey rmurp...@gmail.com wrote: Having PHP do the gzipping is inefficient, IMO. The PHP has to run every time someone requests the file anew; if you compress the files as part of the release process, then they are static files that the server simply has to serve. --~--~-~--~~~---~--~~ 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 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: IE issue with .append?
http://www.google.com/codesearch?hl=enlr=q=\%24\([%27%22]%3C[^%3C%3E%25]%2B[^%2F]%3E[%27%22]\)+lang%3Ajssbtn=Search
I would have thought there'd be more. Frankly it is a sane way to think,
jquery is dom manipulation and $('td') looks a lot like tag creation
rather than something than html being mixed into jQuery.
I for one have been thinking of $('...') as tag creation rather than
raw html, or thinking that jQuery did it's own quick parsing for ages.
Now I'll have to go back through 6 months of code to track down all the
code using that pattern.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
I'm hesitant to support that since it tends to promote passing in
malformed (X)HTML. At least with span attr='val'/ it's obvious that
it should be a standalone.
--John
On Tue, Jun 23, 2009 at 12:27 AM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
Ok, I agree that $('divspan/span') is just plain malformed html
and doesn't need support.
But to be honest $('span') looks like we're saying to create a span
node, and likewise $('span attr=val') like we're trying to create a
span with a single attr.
Originally when I found out about $('span') I wasn't thinking HTML, I
originally thought Oh yay, jQuery has a shortcut for
document.createElement, and after when I saw that $('span foo=bar /')
was possible I didn't think HTML, I still thought, createElement + attr
setting.
Would a patch that just makes $('span attr=val') work properly across
browsers be accepted?
That should be something simple like checking if it starts with and
ends with , contains no other 's and doesn't have a / before the
then insert a single / before the last before continuing.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
Unfortunately, there's not really a whole lot that we can do on our
end to fix a problem like that - short of including a full HTML
parser/DOM generator.
Now, I've written one:
http://ejohn.org/blog/pure-javascript-html-parser/
but it's probably just better to make sure that your injected HTML is
well-formed.
--John
On Mon, Jun 22, 2009 at 6:45 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
I ran into another IE issue with unclosed tag syntax inside node
creation (I personally like to leave the / out unless necessary most of
the time, especially since it flows fairly nice with .text(userVar)).
http://jsbin.com/ejote
span/span
span /
span/
span
span class=foo /
All work in ie7, ie8, opera, firefox, and midori.
However:
span class=foo
span class=foo
Fail in ie7 and ie8 while they work in firefox, midori, and opera.
Filed as: http://dev.jquery.com/ticket/4806
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
This is very helpful analysis. I've added it to my todo list. Could
you file a ticket with your test cases, as well? Thanks!
http://dev.jquery.com/newticket
--John
On Mon, Jun 22, 2009 at 4:33 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
Ok, narrowed it down.
Someone tells me that Konqueror isn't working for that page either so it
looks like IE8 and Konqueror may share this behavior.
From the looks of it $button.append( [ ); is working.
$('#bodyContent').append( [ ); // works
$('#bodyContent').append( [, ] ); // Invalid argument in IE8
console, works in FF Firebug console
$('#bodyContent').append( asdf, asdf ); // Invalid argument in IE8
console, works in FF Firebug console
$('#bodyContent').append( document.createTextNode([), ] ); // works
$('#bodyContent').append( spanfoo/span, ] ); // in IE8 console
only inserts the ']' the foo span is not inserted, works in FF Firebug
console
$('#bodyContent').append( spanasdf/span, spanqwerty/span );
// in IE8 console only inserts the qwerty span the asdf span is not
inserted, works in FF Firebug console
So this looks like an IE8 (maybe Konqueror) issue where when .domManip
is used (by something like .append) with more than one argument with the
first being a string a Invalid argument error is thrown if the first
argument is not a valid node string. If the first argument is a valid
node string, instead the first argument is ignored and the rest are
inserted.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
You say that you still have problems if you split apart the query.
So in this case $button.append( [ ) fails - correct?
What happens if you do:
$button.append( document.createTextNode([) )
--John
On Mon, Jun 22, 2009 at 2:09 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
I've been having trouble with a bit of jQuery that works in FF, Opera,
and Midori, but breaks in IE.
See http://animanga.wikia.com/wiki/Sandbox?allinone=0
The code: http://dev.wikia.com/wiki/ShowHide/code.js
(it's on a wiki
[jquery-dev] Re: IE issue with .append?
Can we update the documentation to also note that unclosed tags aren't
supported.
Malformed html is obvious, but people don't always think of a single tag
as malformed html.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
To be clear: jQuery supports the pattern, it just requires the closing /.
$(td/) // ok
$(td) // ambiguous, malformed, not ok
$(a href='http://google.com/'/) // ok
$(a href='http://google.com/') // ambiguous, malformed, not ok
--John
On Tue, Jun 23, 2009 at 10:37 AM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
http://www.google.com/codesearch?hl=enlr=q=\%24\([%27%22]%3C[^%3C%3E%25]%2B[^%2F]%3E[%27%22]\)+lang%3Ajssbtn=Search
I would have thought there'd be more. Frankly it is a sane way to think,
jquery is dom manipulation and $('td') looks a lot like tag creation
rather than something than html being mixed into jQuery.
I for one have been thinking of $('...') as tag creation rather than
raw html, or thinking that jQuery did it's own quick parsing for ages.
Now I'll have to go back through 6 months of code to track down all the
code using that pattern.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
I'm hesitant to support that since it tends to promote passing in
malformed (X)HTML. At least with span attr='val'/ it's obvious that
it should be a standalone.
--John
On Tue, Jun 23, 2009 at 12:27 AM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
Ok, I agree that $('divspan/span') is just plain malformed html
and doesn't need support.
But to be honest $('span') looks like we're saying to create a span
node, and likewise $('span attr=val') like we're trying to create a
span with a single attr.
Originally when I found out about $('span') I wasn't thinking HTML, I
originally thought Oh yay, jQuery has a shortcut for
document.createElement, and after when I saw that $('span foo=bar /')
was possible I didn't think HTML, I still thought, createElement + attr
setting.
Would a patch that just makes $('span attr=val') work properly across
browsers be accepted?
That should be something simple like checking if it starts with and
ends with , contains no other 's and doesn't have a / before the
then insert a single / before the last before continuing.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
Unfortunately, there's not really a whole lot that we can do on our
end to fix a problem like that - short of including a full HTML
parser/DOM generator.
Now, I've written one:
http://ejohn.org/blog/pure-javascript-html-parser/
but it's probably just better to make sure that your injected HTML is
well-formed.
--John
On Mon, Jun 22, 2009 at 6:45 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
I ran into another IE issue with unclosed tag syntax inside node
creation (I personally like to leave the / out unless necessary most of
the time, especially since it flows fairly nice with .text(userVar)).
http://jsbin.com/ejote
span/span
span /
span/
span
span class=foo /
All work in ie7, ie8, opera, firefox, and midori.
However:
span class=foo
span class=foo
Fail in ie7 and ie8 while they work in firefox, midori, and opera.
Filed as: http://dev.jquery.com/ticket/4806
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
This is very helpful analysis. I've added it to my todo list. Could
you file a ticket with your test cases, as well? Thanks!
http://dev.jquery.com/newticket
--John
On Mon, Jun 22, 2009 at 4:33 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
Ok, narrowed it down.
Someone tells me that Konqueror isn't working for that page either so
it
looks like IE8 and Konqueror may share this behavior.
From the looks of it $button.append( [ ); is working.
$('#bodyContent').append( [ ); // works
$('#bodyContent').append( [, ] ); // Invalid argument in IE8
console, works in FF Firebug console
$('#bodyContent').append( asdf, asdf ); // Invalid argument in
IE8 console, works in FF Firebug console
$('#bodyContent').append( document.createTextNode([), ] ); // works
$('#bodyContent').append( spanfoo/span, ] ); // in IE8 console
only inserts the ']' the foo span is not inserted, works in FF Firebug
console
$('#bodyContent').append( spanasdf/span, spanqwerty/span
); // in IE8 console only inserts the qwerty span the asdf span is not
inserted, works in FF Firebug console
So this looks like an IE8 (maybe Konqueror) issue where when .domManip
is used (by something like .append) with more than one argument with
the
first being a string a Invalid argument error is thrown if the first
argument is not a valid node string. If the first argument is a valid
node string, instead the first argument is ignored and the rest are
inserted.
~Daniel
[jquery-dev] IE issue with .append?
I've been having trouble with a bit of jQuery that works in FF, Opera, and Midori, but breaks in IE. See http://animanga.wikia.com/wiki/Sandbox?allinone=0 The code: http://dev.wikia.com/wiki/ShowHide/code.js (it's on a wiki, so you can see the history of editing) Using IE8's debugger tools (yay, finally MS rips of Firebug to give us a way to find out why IE is breaking /sarcasm) I've narrowed it down to $button.append( '[', $buttonLink, ']' ); Where jQuery's .append calls .clean which near the end calls fragment.appendChild( ret[i] ); fragment is the document, and i is 0, ret is 3 items in length containing the text node, span, and other text node. jQuery tries to appendChild to the document and IE decides it doesn't like it. Does this seem like a jQuery bug? Note: ya, I have tried splitting the append call into three separate ones, still causes the same issue on the first one. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] --~--~-~--~~~---~--~~ 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 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: IE issue with .append?
Ok, narrowed it down.
Someone tells me that Konqueror isn't working for that page either so it
looks like IE8 and Konqueror may share this behavior.
From the looks of it $button.append( [ ); is working.
$('#bodyContent').append( [ ); // works
$('#bodyContent').append( [, ] ); // Invalid argument in IE8 console,
works in FF Firebug console
$('#bodyContent').append( asdf, asdf ); // Invalid argument in IE8
console, works in FF Firebug console
$('#bodyContent').append( document.createTextNode([), ] ); // works
$('#bodyContent').append( spanfoo/span, ] ); // in IE8 console only
inserts the ']' the foo span is not inserted, works in FF Firebug console
$('#bodyContent').append( spanasdf/span, spanqwerty/span ); // in
IE8 console only inserts the qwerty span the asdf span is not inserted, works
in FF Firebug console
So this looks like an IE8 (maybe Konqueror) issue where when .domManip
is used (by something like .append) with more than one argument with the
first being a string a Invalid argument error is thrown if the first
argument is not a valid node string. If the first argument is a valid
node string, instead the first argument is ignored and the rest are
inserted.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
You say that you still have problems if you split apart the query.
So in this case $button.append( [ ) fails - correct?
What happens if you do:
$button.append( document.createTextNode([) )
--John
On Mon, Jun 22, 2009 at 2:09 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
I've been having trouble with a bit of jQuery that works in FF, Opera,
and Midori, but breaks in IE.
See http://animanga.wikia.com/wiki/Sandbox?allinone=0
The code: http://dev.wikia.com/wiki/ShowHide/code.js
(it's on a wiki, so you can see the history of editing)
Using IE8's debugger tools (yay, finally MS rips of Firebug to give us a
way to find out why IE is breaking /sarcasm) I've narrowed it down to
$button.append( '[', $buttonLink, ']' ); Where jQuery's .append calls
.clean which near the end calls fragment.appendChild( ret[i] ); fragment
is the document, and i is 0, ret is 3 items in length containing the
text node, span, and other text node. jQuery tries to appendChild to the
document and IE decides it doesn't like it.
Does this seem like a jQuery bug?
Note: ya, I have tried splitting the append call into three separate
ones, still causes the same issue on the first one.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--~--~-~--~~~---~--~~
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
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: IE issue with .append?
http://dev.jquery.com/ticket/4805
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
This is very helpful analysis. I've added it to my todo list. Could
you file a ticket with your test cases, as well? Thanks!
http://dev.jquery.com/newticket
--John
On Mon, Jun 22, 2009 at 4:33 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
Ok, narrowed it down.
Someone tells me that Konqueror isn't working for that page either so it
looks like IE8 and Konqueror may share this behavior.
From the looks of it $button.append( [ ); is working.
$('#bodyContent').append( [ ); // works
$('#bodyContent').append( [, ] ); // Invalid argument in IE8 console,
works in FF Firebug console
$('#bodyContent').append( asdf, asdf ); // Invalid argument in IE8
console, works in FF Firebug console
$('#bodyContent').append( document.createTextNode([), ] ); // works
$('#bodyContent').append( spanfoo/span, ] ); // in IE8 console only
inserts the ']' the foo span is not inserted, works in FF Firebug console
$('#bodyContent').append( spanasdf/span, spanqwerty/span ); //
in IE8 console only inserts the qwerty span the asdf span is not inserted,
works in FF Firebug console
So this looks like an IE8 (maybe Konqueror) issue where when .domManip
is used (by something like .append) with more than one argument with the
first being a string a Invalid argument error is thrown if the first
argument is not a valid node string. If the first argument is a valid
node string, instead the first argument is ignored and the rest are
inserted.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
You say that you still have problems if you split apart the query.
So in this case $button.append( [ ) fails - correct?
What happens if you do:
$button.append( document.createTextNode([) )
--John
On Mon, Jun 22, 2009 at 2:09 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
I've been having trouble with a bit of jQuery that works in FF, Opera,
and Midori, but breaks in IE.
See http://animanga.wikia.com/wiki/Sandbox?allinone=0
The code: http://dev.wikia.com/wiki/ShowHide/code.js
(it's on a wiki, so you can see the history of editing)
Using IE8's debugger tools (yay, finally MS rips of Firebug to give us a
way to find out why IE is breaking /sarcasm) I've narrowed it down to
$button.append( '[', $buttonLink, ']' ); Where jQuery's .append calls
.clean which near the end calls fragment.appendChild( ret[i] ); fragment
is the document, and i is 0, ret is 3 items in length containing the
text node, span, and other text node. jQuery tries to appendChild to the
document and IE decides it doesn't like it.
Does this seem like a jQuery bug?
Note: ya, I have tried splitting the append call into three separate
ones, still causes the same issue on the first one.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--~--~-~--~~~---~--~~
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
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: IE issue with .append?
I ran into another IE issue with unclosed tag syntax inside node
creation (I personally like to leave the / out unless necessary most of
the time, especially since it flows fairly nice with .text(userVar)).
http://jsbin.com/ejote
span/span
span /
span/
span
span class=foo /
All work in ie7, ie8, opera, firefox, and midori.
However:
span class=foo
span class=foo
Fail in ie7 and ie8 while they work in firefox, midori, and opera.
Filed as: http://dev.jquery.com/ticket/4806
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
This is very helpful analysis. I've added it to my todo list. Could
you file a ticket with your test cases, as well? Thanks!
http://dev.jquery.com/newticket
--John
On Mon, Jun 22, 2009 at 4:33 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
Ok, narrowed it down.
Someone tells me that Konqueror isn't working for that page either so it
looks like IE8 and Konqueror may share this behavior.
From the looks of it $button.append( [ ); is working.
$('#bodyContent').append( [ ); // works
$('#bodyContent').append( [, ] ); // Invalid argument in IE8 console,
works in FF Firebug console
$('#bodyContent').append( asdf, asdf ); // Invalid argument in IE8
console, works in FF Firebug console
$('#bodyContent').append( document.createTextNode([), ] ); // works
$('#bodyContent').append( spanfoo/span, ] ); // in IE8 console only
inserts the ']' the foo span is not inserted, works in FF Firebug console
$('#bodyContent').append( spanasdf/span, spanqwerty/span ); //
in IE8 console only inserts the qwerty span the asdf span is not inserted,
works in FF Firebug console
So this looks like an IE8 (maybe Konqueror) issue where when .domManip
is used (by something like .append) with more than one argument with the
first being a string a Invalid argument error is thrown if the first
argument is not a valid node string. If the first argument is a valid
node string, instead the first argument is ignored and the rest are
inserted.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
You say that you still have problems if you split apart the query.
So in this case $button.append( [ ) fails - correct?
What happens if you do:
$button.append( document.createTextNode([) )
--John
On Mon, Jun 22, 2009 at 2:09 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
I've been having trouble with a bit of jQuery that works in FF, Opera,
and Midori, but breaks in IE.
See http://animanga.wikia.com/wiki/Sandbox?allinone=0
The code: http://dev.wikia.com/wiki/ShowHide/code.js
(it's on a wiki, so you can see the history of editing)
Using IE8's debugger tools (yay, finally MS rips of Firebug to give us a
way to find out why IE is breaking /sarcasm) I've narrowed it down to
$button.append( '[', $buttonLink, ']' ); Where jQuery's .append calls
.clean which near the end calls fragment.appendChild( ret[i] ); fragment
is the document, and i is 0, ret is 3 items in length containing the
text node, span, and other text node. jQuery tries to appendChild to the
document and IE decides it doesn't like it.
Does this seem like a jQuery bug?
Note: ya, I have tried splitting the append call into three separate
ones, still causes the same issue on the first one.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--~--~-~--~~~---~--~~
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
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: IE issue with .append?
Ok, I agree that $('divspan/span') is just plain malformed html
and doesn't need support.
But to be honest $('span') looks like we're saying to create a span
node, and likewise $('span attr=val') like we're trying to create a
span with a single attr.
Originally when I found out about $('span') I wasn't thinking HTML, I
originally thought Oh yay, jQuery has a shortcut for
document.createElement, and after when I saw that $('span foo=bar /')
was possible I didn't think HTML, I still thought, createElement + attr
setting.
Would a patch that just makes $('span attr=val') work properly across
browsers be accepted?
That should be something simple like checking if it starts with and
ends with , contains no other 's and doesn't have a / before the
then insert a single / before the last before continuing.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
Unfortunately, there's not really a whole lot that we can do on our
end to fix a problem like that - short of including a full HTML
parser/DOM generator.
Now, I've written one:
http://ejohn.org/blog/pure-javascript-html-parser/
but it's probably just better to make sure that your injected HTML is
well-formed.
--John
On Mon, Jun 22, 2009 at 6:45 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
I ran into another IE issue with unclosed tag syntax inside node
creation (I personally like to leave the / out unless necessary most of
the time, especially since it flows fairly nice with .text(userVar)).
http://jsbin.com/ejote
span/span
span /
span/
span
span class=foo /
All work in ie7, ie8, opera, firefox, and midori.
However:
span class=foo
span class=foo
Fail in ie7 and ie8 while they work in firefox, midori, and opera.
Filed as: http://dev.jquery.com/ticket/4806
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
This is very helpful analysis. I've added it to my todo list. Could
you file a ticket with your test cases, as well? Thanks!
http://dev.jquery.com/newticket
--John
On Mon, Jun 22, 2009 at 4:33 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
Ok, narrowed it down.
Someone tells me that Konqueror isn't working for that page either so it
looks like IE8 and Konqueror may share this behavior.
From the looks of it $button.append( [ ); is working.
$('#bodyContent').append( [ ); // works
$('#bodyContent').append( [, ] ); // Invalid argument in IE8
console, works in FF Firebug console
$('#bodyContent').append( asdf, asdf ); // Invalid argument in IE8
console, works in FF Firebug console
$('#bodyContent').append( document.createTextNode([), ] ); // works
$('#bodyContent').append( spanfoo/span, ] ); // in IE8 console
only inserts the ']' the foo span is not inserted, works in FF Firebug
console
$('#bodyContent').append( spanasdf/span, spanqwerty/span ); //
in IE8 console only inserts the qwerty span the asdf span is not inserted,
works in FF Firebug console
So this looks like an IE8 (maybe Konqueror) issue where when .domManip
is used (by something like .append) with more than one argument with the
first being a string a Invalid argument error is thrown if the first
argument is not a valid node string. If the first argument is a valid
node string, instead the first argument is ignored and the rest are
inserted.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
You say that you still have problems if you split apart the query.
So in this case $button.append( [ ) fails - correct?
What happens if you do:
$button.append( document.createTextNode([) )
--John
On Mon, Jun 22, 2009 at 2:09 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
I've been having trouble with a bit of jQuery that works in FF, Opera,
and Midori, but breaks in IE.
See http://animanga.wikia.com/wiki/Sandbox?allinone=0
The code: http://dev.wikia.com/wiki/ShowHide/code.js
(it's on a wiki, so you can see the history of editing)
Using IE8's debugger tools (yay, finally MS rips of Firebug to give us a
way to find out why IE is breaking /sarcasm) I've narrowed it down to
$button.append( '[', $buttonLink, ']' ); Where jQuery's .append calls
.clean which near the end calls fragment.appendChild( ret[i] ); fragment
is the document, and i is 0, ret is 3 items in length containing the
text node, span, and other text node. jQuery tries to appendChild to the
document and IE decides it doesn't like it.
Does this seem like a jQuery bug?
Note: ya, I have tried splitting the append call into three separate
ones, still causes the same issue on the first one.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post
[jquery-dev] Re: A element click event, event.target.pathname
Regexes aren't slow. Regex stuff on strings is actually quite fast, and
from the standpoint of practical speed there is no significant difference.
An example of what you're trying to do that I could fix up would be handy.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
pbcomm wrote:
True. On the other hand that would mean calling more functions and
using slow regex.
I would think prepending / if .browser.msie is faster.
On Jun 18, 3:42 pm, Daniel Friesen nadir.seen.f...@gmail.com wrote:
Another option you have is grabbing .attr('href') and using a regex to
extract the portion you want.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
pbcomm wrote:
I'm working with A elements and checking the pathname on click to
provide different actions depending on link (href) path.
But I do see what you mean, it will require setting the pathname
property on the element.
On Jun 18, 3:24 pm, John Resig jere...@gmail.com wrote:
Unfortunately that would involve changing the property on the DOM
object itself, which is something that jQuery doesn't handle.
Which element(s) are you working with that have the pathname associated
with it?
--John
On Thu, Jun 18, 2009 at 2:06 PM, pbcommpbc...@gmail.com wrote:
The pathname property of links is missing a leading slash on IE and I
was wondering if this should be the fix event functionality.
--~--~-~--~~~---~--~~
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
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: Adding a change event on a hidden field
Rather than making events implied you should be using something like
$(input).val(newValue).trigger('change');
There's a good reason why input.value; doesn't trigger onchange events.
Think if it this way. If you wrote an onchange event which when the
content of and input which would take the value of the field, put it
through a filter (like stripping out extra characters and normalizing
things like case to form a simple id or format things like phone
numbers) and then set that back onto the value what would happen when
you set the new value? If setting .value programmability triggered the
change event your onchange would be fired again... And perhaps again...
and so on. An onchange would become an easy way to accidentally create
an infinite loop within the dom that isn't desired.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
BaBna wrote:
Thanks for that Rick!
Yes, it works but this way is too heavy with the setInterval/
setTimeout: I need to do that on the fly, and I can have tens of
elements using this behavior.
Actually, I'd better explain what I am trying to achieve here: maybe
you're aware of an issue with IE6 where the SELECT elements can't be
overlayed by a DIV with a superior zIndex.
There are 2 ways to avoid this problem: hiding all the select below
the DIV or using fake selects instead. It is this solution that I
want to adopt, but I still want my fake select fields to react
correctly to the jQuery val() function. This, used with the field ID,
will change the value of a hidden field, and when this field changes,
I want the corresponding action to be triggered on my fake select.
So if with val() I change the value of my field, the corresponding
text will be visible in my fake select, and in the list this item will
have been replaced by the previous value...
The code I have added in the val() function is, I think, the most
efficient way for being able to trigger the change function on any
hidden field. However, as I love jQuery and hate to have my own
twisted script instead of the standard, I wonder if people think it
could be implemented in the core or if someone would have a better
global solution to that problem...
Cheers!
On Jun 17, 2:40 pm, Rick Waldron waldron.r...@gmail.com wrote:
Take a look here:
http://jsbin.com/ayivo
I've commented the steps I took. Its a bit hackish but the behaviour is what
you're looking for. I'm sure a better way exists.
Rick
On Wed, Jun 17, 2009 at 8:01 AM, BaBna thomas.na...@gmail.com wrote:
Hi,
I would like to be able to trigger a function when the value of a
hidden field is changed through val() - and I want this event to be
attached to the field itself, not to the val() action.
As events are only users' triggered a hidden field doesn't trigger
onchange natively. I have seen a lot of implementations using various
plug-ins for mutation events, but was not very happy about them -
they're heavy and I got some errors.
Therefore I have added a line at the very end of the val() function:
if(o.nodeName(this,select)){
...
}
else{
this.value=K;
// Here's my line:
if(this.type=='hidden'){$(this).change()}
}
}
}
)}
That works fine in IE6, FF and Chrome - haven't tested on other
browser.
Would it be useful to add this?
Thanks!
Here's an example:
html
head
script type=text/javascript src=_shared/js/jquery-1.3.2.min.js/
script
script type=text/javascript
$(function(){
$(#hiddenField).change(function(e){
alert($(this).val());
});
setTimeout('$(#hiddenField).val(wooloo);',2000);
});
/script
/head
body
input type=hidden id=hiddenField value=BaBna /br /
/body
/html
--~--~-~--~~~---~--~~
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
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: $('#Test').val(null); IE vs. the rest
http://dev.jquery.com/ticket/4388 Though I thought there was a bigger
master bug for this.
It's because of how for a long time jQuery has checked for undefined
arguments rather than checked for the length of the arguments.
As a result:
.css('width', undefined); would be interpreted as a css getter rather
than a css setter and without warning return a css value instead of the
jQuery object, as a result if you tried to chain from it you would
magically in an unexpected way get errors about it not being defined.
The same issue applied to a large number of jQuery methods like .attr,
.val, etc... which work as both getters and setters.
I was under the impression that this was on the todo list, rather than
already fixed, cause I could swear I ran into this while working with
the 1.3 series.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
Daniel -
I'm not familiar with this issue - is there a ticket related to it?
--John
On Tue, Jun 16, 2009 at 11:11 PM, Daniel
Friesennadir.seen.f...@gmail.com wrote:
Hmmm? Clarifying, has $(el).css('width', undefined).someOtherFnMethod();
been fixed?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
It's always a good idea to either use a ||'' or cast your data to a string
or other proper datatype when using jQuery, a large number of the methods
will have somewhat undesirable results if you try using null or undefined,
it's a known issue.
Oh, I wouldn't go that far. We've patched any null/undefined issues
that we've found. I'm not aware of any outstanding issues (save for
the one mentioned in this thread). Pointers to any others would be
appreciated.
vdhant: You should file a bug with this point in it:
http://dev.jquery.com/newticket
--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-dev@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: $('#Test').val(null); IE vs. the rest
var item = { ..., 'DataItem10of20' : null, ... };
$('#TextBox10of20').val(item.DataItem10of20||'');
It's always a good idea to either use a ||'' or cast your data to a string or
other proper datatype when using jQuery, a large number of the methods will
have somewhat undesirable results if you try using null or undefined, it's a
known issue.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
vdhant wrote:
Not really, because I have simplified my case a little and it actually
looks a little more like this:
input type=text id=TextBox10of20 /
.
script
var item = { ..., 'DataItem10of20' : null, ... };
$('#TextBox10of20').val(item.DataItem10of20);
/script
Cheers
Anthony
On Jun 17, 10:20 am, samer samerzia...@gmail.com wrote:
You can try passing an empty string $('#Test').val('');
I don't know whyt it's behaving that way though
On Jun 16, 8:01 pm, vdhant vdh@gmail.com wrote:
Hi guys
I have the following case:
input type=text id=Test /
script
$('#Test').val(null);
/script
See working example here:http://jquery.nodnod.net/cases/421
In IE (i have tested in IE7), it puts the words null into the textbox
in all other browsers it puts nothing into the textbox. Why is this???
Cheers
Anthony
--~--~-~--~~~---~--~~
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
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: $('#Test').val(null); IE vs. the rest
Hmmm? Clarifying, has $(el).css('width', undefined).someOtherFnMethod();
been fixed?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
John Resig wrote:
It's always a good idea to either use a ||'' or cast your data to a string
or other proper datatype when using jQuery, a large number of the methods
will have somewhat undesirable results if you try using null or undefined,
it's a known issue.
Oh, I wouldn't go that far. We've patched any null/undefined issues
that we've found. I'm not aware of any outstanding issues (save for
the one mentioned in this thread). Pointers to any others would be
appreciated.
vdhant: You should file a bug with this point in it:
http://dev.jquery.com/newticket
--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-dev@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: Prepare for IE6's death
It's not the point of this thread, but it got me thinking about something. IE8 doesn't have the same memory problems as IE6 and IE7 does it? Is anyone interested in pulling all the IE targeted code out of jquery and checking out how much that speeds everything up for the other browsers that don't need it? Most definitely all that extra slow code targeted at memory leaks in IE. I say this while thinking of people who are working on project that already use so much HTML5 features that they don't support IE6/7 anyways. And also things like AIR projects where you are guaranteed a WebKit environment where you AFAIK never need to worry about that extra stuff. It would be interesting if we could maintain another build (conditional comments?) which was targeted at projects which don't support IE anyways, and environments like AIR where the rendering engine is known and guaranteed. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] Sam Collett wrote: IE7 does have native XMLHttpRequest, but even then jQuery does not use it... I think because it does not work with file:// URIs. --Sam 2009/6/6 diogobaeder diogobae...@gmail.com mailto:diogobae...@gmail.com OK... fine for me... but doesn't IE7 have its own XMLHttpRequest implementation, for example? I thought it did... Anyway, the worst part is getting rid of IE6, because the majority of the users who use IE7 leave automatic update on on their Windows boxes... as soon as IE8 pops out in the automatic updates, we'll see a huge jump in market share from IE8... Diogo On Jun 5, 11:16 am, John Resig jere...@gmail.com mailto:jere...@gmail.com wrote: I can't think of a single thing that we could remove from jQuery that wouldn't also affect IE 7.0. The JavaScript and DOM implementations in IE 6 and 7 are virtually identical - and because of that there's really no reason for us to stop actively supporting IE 6 (at least not until both 6 and 7 are dead - who knows when that will be). --John On Fri, Jun 5, 2009 at 10:04 AM, Diogo Baeder diogobae...@gmail.com mailto:diogobae...@gmail.com wrote: Hi there, What do you guys think of preparing the next versions of jQuery for IE6's death, when its use comes below, say, 0,5%, putting comments next to the methods? For example: // TODO: Remove upon IE6's death I mean, it would be great to remove all those workarounds we have to use only for IE6, like ActiveXObject... or am I wrong? Regards, Diogo --~--~-~--~~~---~--~~ 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 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: Creation of elements not working
Why are you even bothering with an onclick attribute?
for (var i = 0; i totalPages; i++)
if (i != currPage - 1)
$('a href=javascript:void(0)')
.click((function(i) { return function(e) { showPage(i + 1); };
}(i))
.text(i + 1)
.appendTo('#resultspaging');
else
$('span class=page').text(i + 1).appendTo('#resultspaging');
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
androcles wrote:
Hi. I'm having some issues on jquery, specifically with safari. I
need to create dynamic links for paging, so I use this code inside a
for statement
for (var i = 0; i totalPages; i++)
if (i != currPage - 1)
$('a/a').attr('href', 'javascript:void(0)')
.attr('onclick', 'showPage(' + (i + 1) + ')')
.html(i + 1)
.appendTo('#resultspaging');
else
$('span/span').addClass('page').html(i + 1).appendTo
('#resultspaging');
This shows ok on Firefox. In safari, the onclick attributes are not
rendered, so my links are totally inactive. It works if I set the JS
function to the 'href' attribute, but there is another place where I
neet to set a 'onclick' attribute to a 'tr' element, that doesn't has
'href' attribute.
http://portal.anacafe.org/CoffeeSearchSystem/
--~--~-~--~~~---~--~~
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
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: IE6 rules the roost and shows no signs of leaving anytime soon.
But of course there is still the problems with the ability to browse the web. I wish at the least companies would get out of the Upgrade IE or stick with IE6 mentality. Pick a browser (Firefox, Opera, Safari, or Chrome) and install it on the computers. You can run any of the browsers and still keep IE6 on the machine. And there is no need to covert the old system or test it cause you still have the old browser for that. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] Jules wrote: On Jun 5, 3:34 am, Henry rcornf...@raindrop.co.uk wrote: On Jun 4, 5:23 pm, Gilles wrote: snip Not allowing automatic OS updaters can be an IT department's deliberate policy. You could be talking about the company I work for. We are using an extensively customised packaged CRM system written in asp that use IE6 as the client. From the business point of view, upgrading the system gives them nothing new and the cost for converting/testing will be very expensive and unnecessary. --~--~-~--~~~---~--~~ 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 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: [Dumb] find() method normal behavior ?
Yes, .andSelf() exists specifically for the case where someone wants
.find() to also include the previous selection.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Erik Beeson wrote:
I believe that's expected behavior. For your second example, I think
you'd want to use filter(...) instead of find(...).
--Erik
On Tue, May 26, 2009 at 5:38 PM, yodza yodza.fr
http://yodza.fr@gmail.com http://gmail.com wrote:
Is it the normal behavior of the find() method to search the passed
expression ONLY within child nodes of a wrapped set ?
(which is not explicitly specified in the documentation:
http://docs.jquery.com/Traversing/find#expr)
ol
li id=oneOne/li
li id=twoTwo/li
li id=threeThree/li
/ol
$('ol').find('[id^=t]') // retrieving id=t*
[li#two, li#three]
$('li').find('[id^=t]') // retrieving id=t*
[ ]
--~--~-~--~~~---~--~~
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
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: new $
;) I still see an if statement there, heh.
I prefer the conditional comments + build system approach.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
DBJDBJ wrote:
... If a user uses new $ this user simply does not truly understand/
know
JavaScript but fortunately will not harm anybody...
No it wont, unless this user is a team leader and starts blaming
jQuery on everything.
And this happens much more than anyone here (it seems) realises.
But. This is another subject.
PS:
jQuery.fast = false ;
jQuery.error_code = 0xABCD ;
function(selector, context) {
if ( ! jQuery.fast)
if(this instanceof jQuery)
throw new Error( jQuery.error_code, Can
not new $());
return new jQuery.fn.init(selector, context);
}
On May 14, 2:59 pm, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
to do that you need to change the contructor:
function(selector, context) {
if(this instanceof jQuery)
throw new Error(Can not new $());
return new jQuery.fn.init(selector, context);
}
this means an extra if for each jQuery call, something not that welcome for
performances reason. At the same time, jQuery itself relies in this
JavaScript peculiarity, so I would not create conflicts between jQuery
developers and users.
If a user uses new $ this user simply does not truly understand/know
JavaScript but fortunately will not harm anybody.
On Thu, May 14, 2009 at 10:23 AM, DBJDBJ dbj...@gmail.com wrote:
Ah, new $, is possible and therefore not barred ... Left in there as a
sort of a land-mine for the newcomers ? Or as an esoteric test for GC
developers ? Highly useless it seems to me.
Back to reality and jQuery. $ is defined as:
function(selector, context) {
// The jQuery object is actually just the init constructor
'enhanced'
return new jQuery.fn.init(selector, context);
}
Maybe I am just searching for ECMA harmony, but will $() definition
that throws an exception if new-ed , be usefull :
try {
new $ ;
} catch ( x )
{
// x. message == Can not new $()
}
Au-contraire : will this hurt anyone ? Is exception throwing
porgramming idiom damaging for jQuery?
--DBJ
PS: if Python was choosen as a Netscape scripting language, World
would be a better place ... If nothing else its name is less
ridiculous ... ;o)
On May 14, 9:04 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
it's called JavaScript :D
jokes a part, every function is a constructor as well so new function is
always valid.
If the function returns an object, it does not matter which new is
because
it will be an instance of returned object one.
if it is a primitive it will simply be lost:
var a = new function(){return 123;};
// a is an instance of anonymous function
this allows us to create Python like initializations:
function PythonLike(){
return this instanceof arguments.callee ? this : new
arguments.callee;
};
alert(PythonLike() instanceof PythonLike);
alert(new PythonLike() instanceof PythonLike);
true in both cases
jQuery returns a new jQuery.prototype.init where init method shares the
same
prototype ... better now? :-)
On Wed, May 13, 2009 at 11:57 PM, DBJDBJ dbj...@gmail.com wrote:
Why is this allowed :
var jq = new $ ;
Does it matter?
-- DBJ
--~--~-~--~~~---~--~~
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
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: Readonly attribute handled differently in IE7 and FF
$(input[name$='DateString']:not([readonly]))
I don't know if jQuery supports [!readonly], if it does then that's an
alternative to :not([readonly]);
readonly is a boolean property, in XML/HTML this means that only it's presence
is required. If it is present the property is true, if it is absent the
property is false.
Thus you use a simple [readonly] to check for the existence of the readonly
attribute. And in your case surround that with a :not() to check for things
without readonly.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
dmcmeans wrote:
Using jQuery 1.3.1, the following line works in IE8 and FF.
$(input[name$='DateString']:not([readonly='readonly']),input[name
$='DateString']:not([readonly='true'])).datepicker
( dpOptions ).addClass( date ).attr( maxlength, 12 );
But does not in IE7. I had to alter it to
$(input[name$='DateString']:not([readonly='true'])).datepicker
( dpOptions ).addClass( date ).attr( maxlength, 12 );
Because I have to support IE7, my workaround is to break it out
$(input[name$='DateString']).each( function(i) {
$(this).addClass( date ).attr( maxlength, 12 );
var ls_val = $(this).attr(readonly);
if ( ls_val == false ) {
$(this).datepicker( dpOptions );
}
});
which works well enough, just not as appealing.
This appears to be a bug in jQuery. Any thoughts?
David
--~--~-~--~~~---~--~~
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
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: Exception Thrown When Getting CSS Value
The problem there is I don't think it's a good idea to throw out output
which makes this kind of thing illegal:
e.style.margin = $(node).css('margin');
Which is why I made note of a technique like so:
var top = ..., right = ..., ...;
return {
top: top, right: right, bottom: bottom, left: left,
0: top, 1: right, 2: bottom, 3: left,
toString: function() { return [top, right, bottom, left].join(' '); }
};
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Stephen McKamey wrote:
In thinking more about the deeper problem, it seems to me an array of
the values is the right answer. Each value in the array would
correspond to the value returned if querying the simple property. I
am unable to think of a CSS compound property that doesn't denote its
parts delimited by whitespace. This means that it would be possible
to return meaningful data.
So if the browser returns 5px 5px 5px 5px then jQuery returns an
array of values simply in the order the browser gives it, but if it
returns 5px then it acts as it currently does. Then the user of
this method can determine if it is compound or not based upon if it is
handed a collection or scalar value. Then the method using the value
can grab the appropriate piece of information and not need to re-
implement the parsing/retrieval logic.
On May 7, 9:51 am, Stephen McKamey step...@jsonfx.net wrote:
Yes, I agree that the use-case is in question. We ran into this when
a using the autogrow plugin:
http://plugins.jquery.com/project/autogrow
This plugin should be modified to check the appropriate sides and
handle correctly.
On the other hand, I don't think that crashing is an appropriate
response from jQuery. I would be happy if it simply returned the
string value as this is at least recoverable and makes more sense than
Error: invalid argument.
On May 6, 8:08 pm, Brandon Aaron brandon.aa...@gmail.com wrote:
I believe that is exactly what we are trying to do. There is an ongoing
discussion about how to handle retrieval of CSS shorthand properties in the
ticket 4295 (http://dev.jquery.com/ticket/4295). I think most of the
confusion, at least for me, has been around the use-case for getting the
short-hand. The reason for my first question... trying to understand the
actual need. From this thread (and the ticket) it sounds like maybe the
developer just needs to copy the padding from one element to another.
Reasonable use-case but what about when the developer wants to copy the
background property. Isn't it more confusing to support just a subset
versus all the shorthands? Maybe a better solution is to find a better way
to copy CSS from one element to another... if that really is the primary
use-case for supporting CSS shorthand properties.
--
Brandon Aaron
On Wed, May 6, 2009 at 9:36 PM, Matt Kruse m...@thekrusefamily.com wrote:
On May 6, 8:28 pm, Brandon Aaron brandon.aa...@gmail.com wrote:
Out of curiosity... what are you expecting back from the call to padding
when it is different for top/bottom vs left/right?
I think an equally valid question is... what does jQuery intend to do
in such situations? Clearly, crashing is not the best option.
Anything that causes the code to completely crash should be avoided by
either checking for valid input (if some inputs are considered
invalid) or by deciding how to handle cases that don't have obvious
answers (like this case). It's not enough, IMO, to ignore the tough
questions of how jQuery should behave and point to an alternative. :)
In the example case:
#foo { padding: 5px 10px; }
you may want to consider returning [5,10,5,10] for example.
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
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: Exception Thrown When Getting CSS Value
See bug 4295: http://dev.jquery.com/ticket/4295
Combined css properties like padding and margin are actually
inconsistent across browsers when they come from the stylesheet.
I sympathize though, I do a huge amount of css cloning myself and this
kind of thing gets in the way.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Stephen McKamey wrote:
We've run into an issue where, when a style (padding in this case)
with multiple parts (5px 3px in this case) is being set by a
stylesheet (rather than inline) is accessed in IE6/7/8, jQuery 1.3.2
causes the exception Error: Invalid argument. The exception is
thrown in the middle of the awesome hack by Dean Edwards on line
835.
Has anyone else experienced this, and is there a known workaround?
Here is a simple example which demonstrates it (in Internet Explorer):
html
head
style type=text/css#foo { padding: 5px 10px; }/style
script type=text/javascript src=http://ajax.googleapis.com/ajax/
libs/jquery/1.3.2/jquery.js/script
script type=text/javascript
$(function() {
alert($(#foo).css(padding));
});
/script
/head
body
textarea id=foo/textarea
/body
/html
--~--~-~--~~~---~--~~
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
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: globalEval in high conflict situations.
There was someone who did some work on a jQuery JSONP plugin which did
more than the simple stuff jQuery does, including onerror callbacks. It
was done using an iframe trick as well.
An iframe is a bit of a possibility.
if( window.jQuery !=== jQuery)
var iframe = create iframe
iframe.contentWindow.jQuery = jQuery;
create script tag and insert
jQuery(iframe).remove();
However the issue with the iframe sandbox is that the document and
whatnot isn't properly available.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Andrea Giammarchi wrote:
I feel called in the cause ... globalEval just evaulate code, if it
causes problems, you need a sandbox to run multiple version of jQuery
or whatever library (a sandbox for each library) and a manager to
delegate tasks to the right sandbox when you need it.
What's a sandbox? ... poorly speaking, an iframe and its window object
with its global variables (libraries included)
Hope this help.
Best Regards
On Wed, Apr 22, 2009 at 6:22 PM, John Resig jere...@gmail.com
mailto:jere...@gmail.com wrote:
Hmm... I do understand your predicament (wanting the
dynamically-loaded script to use the right version of jQuery). I'm
trying to imagine situations where your change could cause potential
problems, but I'm not sure, yet.
FWIW, this problem also affects getScript when pulling scripts from an
outside domain (and it can't be fixed used the technique described
here since there's no window of opportunity where the global jQuery
variable could be changed).
I also note that you only change 'jQuery' and not '$' - it seems like
both would be necessary, in this case.
But, again, I'm worried about the external affects of manipulating the
global variables.
--John
On Wed, Apr 22, 2009 at 1:04 PM, Mark Gibson jollyt...@gmail.com
mailto:jollyt...@gmail.com wrote:
Hi, I'm using jQuery in a high conflict situation, ie. multiple
versions of jQuery in one page.
Unfortunately I have no way around this other than not using the
latest jQuery.
So first off, jQuery 1.2 is loaded and noConflict() called.
Later, jQuery 1.3.2 is loaded and fed into a closure as such:
(function($) {
...
})( jQuery.noConflict(true) );
Within the closure if I try to dynamically load some html that
contains script then the script will be executed with jQuery 1.2 as
the global jQuery object.
I believe it would be more appropriate to temporarily set the global
jQuery to the one loading the script, ie. 1.3.2 in this case.
I've got two demo's, first without the patch, second with the patch:
http://test3.internal.adaptavist.net/~mgibson/versions/load1.html
http://test3.internal.adaptavist.net/%7Emgibson/versions/load1.html
http://test3.internal.adaptavist.net/~mgibson/versions/load2.html
http://test3.internal.adaptavist.net/%7Emgibson/versions/load2.html
It this worth considering, shall I raise a ticket?
Here's the patch:
Index: src/core.js
===
--- src/core.js (revision 6319)
+++ src/core.js (working copy)
@@ -290,7 +290,10 @@
// Inspired by code by Andrea Giammarchi
//
http://webreflection.blogspot.com/2007/08/global-scope-evaluation-and-dom.html
var head =
document.getElementsByTagName(head)[0] ||
document.documentElement,
- script =
document.createElement(script);
+ script =
document.createElement(script),
+ globaljQuery = window.jQuery;
+
+ window.jQuery = jQuery;
script.type = text/javascript;
if ( jQuery.support.scriptEval ) {
@@ -303,6 +306,8 @@
// This arises when a base node is used
(#2709).
head.insertBefore( script, head.firstChild );
head.removeChild( script );
+
+ window.jQuery = globaljQuery;
}
},
--~--~-~--~~~---~--~~
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
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: globalEval in high conflict situations.
Ugh, quick, rename!
IMHO something like .document() would be better.
At some point I had a thought it would be nice to do something like:
$('#foo iframe:document body')
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Brandon Aaron wrote:
Well for example the changes I've made allow you to get the
width/height of a different document/window by passing them into
jQuery...
$('iframe').contents().width() // should return the width of the
iframe document
Another example is the css method that use to be restricted to its
loaded window to return computed styles in Firefox.
--
Brandon Aaron
On Wed, Apr 22, 2009 at 4:49 PM, Julian Aubourg
aubourg.jul...@gmail.com mailto:aubourg.jul...@gmail.com wrote:
Sounds awesome but will it feature a way to change the internal
window and document references globally for an instance of jQuery?
Or is it an additional parameter? (just how of curiosity)
2009/4/22 Brandon Aaron brandon.aa...@gmail.com
mailto:brandon.aa...@gmail.com
Just an FYI... yesterday I checked in some patches that enable
several window/document dependent methods to work with other
windows/documents than the one jQuery is loaded in. I believe
there are still some patches to be made but overall jQuery
1.3.3 should operate better under situations like this.
--
Brandon Aaron
On Wed, Apr 22, 2009 at 4:41 PM, Julian Aubourg
aubourg.jul...@gmail.com mailto:aubourg.jul...@gmail.com
wrote:
Yep, the someone was me. And as Daniel points out, the
problem with sandboxing is that it is permeable but not
transparent.
You could go around onstart manipulations by hacking the
script (i.e. point to window.top rather than window) but
you'd also have to hack into all of the script's
functionalities (as soon as it involves document
manipulation without any given context -- i.e. a parameter
that is the group of nodes to act on). And, beside, you'd
need to hack jQuery itself too.
But from an engine point of view, I think what could be
interesting would be to have a way to make jQuery
sandboxed in an iframe and have its internal window
reference being redirected. Something like a
jQuery.setContextWindow() function. But I'm pretty
confident this would mean quite some refactoring within
jQuery itself, wouldn't it? Unless redefining the window
variable within the jQuery main function closure would be
enough?
Anyway, this would make it possible to have an iframe
content like this:
script src=JQUERY_URL /
scriptjQuery.setContextWindow(window.top);/script
script src=OTHER_SCRIPT_URL /
The icing on the cake would be to have access to this
context window with something like
jQuery.getContextWindow() so that plugins could use it and
be as transparently sandboxed as jQuery itself.
2009/4/22 Daniel Friesen nadir.seen.f...@gmail.com
mailto:nadir.seen.f...@gmail.com
There was someone who did some work on a jQuery JSONP
plugin which did
more than the simple stuff jQuery does, including
onerror callbacks. It
was done using an iframe trick as well.
An iframe is a bit of a possibility.
if( window.jQuery !=== jQuery)
var iframe = create iframe
iframe.contentWindow.jQuery = jQuery;
create script tag and insert
jQuery(iframe).remove();
However the issue with the iframe sandbox is that the
document and
whatnot isn't properly available.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Andrea Giammarchi wrote:
I feel called in the cause ... globalEval just
evaulate code, if it
causes problems, you need a sandbox to run multiple
version of jQuery
or whatever library (a sandbox for each library) and
a manager to
delegate tasks to the right sandbox when you need it.
What's a sandbox? ... poorly speaking, an iframe and
its window object
with its global variables (libraries included)
Hope this help.
Best Regards
On Wed, Apr 22, 2009 at 6:22 PM, John Resig
jere...@gmail.com mailto:jere...@gmail.com
mailto:jere...@gmail.com
[jquery-dev] Re: Structure Plugin Authoring
shugartweb.com is offline. Could we get a github repo or something so
the code is always available and open to work with?
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
tres wrote:
Btw, Daniel, I have changed the API to accomodate this.
jQuery.plugin.add('name', func || objectOfFuncs), will now add a
static plugin and can be called like jQuery.name() or
jQuery.name().method1();
Static methods can be applied also by giving a static keyword with the
function name:
jQuery.plugin.add('name', {
someInstanceMethod : fucntion() {},
'static:myStaticMethod' : function() {}
});
then can be called: jQuery.name().someInstanceMethod() or
jQuery.name.myStaticMethod();
and
jQuery.fn.plugin.add('name', func || objectOfFuncs), will add it to
jQuery's prototype and can be called jQuery('selector').name().
jQuery.plugin.remove('name') and jQuery.fn.plugin.remove('name') work
in a similar way.
I'm putting together a full documentation and examples soon.
-Trey
On Mar 5, 1:34 pm, Daniel Friesen nadir.seen.f...@gmail.com wrote:
I think it could do with the ability to handle methods on jQuery itself
instead of being limited to just jQuery.fn, perhaps a second
object/function to addPlugin;
Likewise I'd prefer jQuery.options over jQuery.fn.options;
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com]
-Nadir-Point Wiki-Tools (http://nadir-point.com) (http://wiki-tools.com)
-MonkeyScript (http://monkeyscript.org)
-Animepedia (http://anime.wikia.com)
-Narutopedia (http://naruto.wikia.com)
-Soul Eater Wiki (http://souleater.wikia.com)
treshug...@gmail.com wrote:
There has been a lot of activity about plugin authoring and how it can
be more structured and extensible. I've posted a couple of comments on
some threads and sent an email to John, but I thought I'd create a new
thread since I haven't had any feedback yet. John, I understand you
probably get a lot of email and are very busy.
I've written a plugin that I'd like to get feedback on from you guys.
It's still evolving, but should be stable in what it currently is
designed to do and I have found it invaluable when authoring larger,
more advanced plugins. It would be nice to see similar functionality
built into jQuery as I think others would also find it useful.
Link:http://plugins.jquery.com/project/plugin-authoring
Cheers,
Trey
--~--~-~--~~~---~--~~
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
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: selector on elements like id=name[2]
DBJDBJ wrote:
Maybe one can do this, as jQ author writes: weird characters in its
ID . But this is a bad programming practice.
Why would anyone do that? When was the last time (if ever) you did
that? If Matt Brenna want to do some indexing of some elements there
are much safer,scaleable and robust ways to do this. Like using data()
method etc ... Or in a spirit of HTML5, and to be 'future proof' one
might do something like this :
input type=text data-no=1 data-tag=firstname /
input type=text data-no=2 data-tag=firstname /
And before HTML5 browsers become mainstream Matt can use jQuery :
$(input[data-no=1][data-tag=firstname])
This in my mind is the right kind of advice to give to (jQ) beginers
(no offence Matt ;o). But again I have to remind you: this forum is
not a place for that.
Also I could not make this work :
// function from Frequently_Asked_Questions
function jq(myid) { return '#'+myid.replace(/:/g,\\:).replace(/\./
g,\\.);}
$(document.body).append(div id='A[2]' /div) ;
$(jq(A[2])).length
/*
0
*/
It must be something obvious but I do not see it ?
-- DBJ
The function doesn't have any code to escape the []'s
Try this one:
function jq(myid) { return '#'+myid.replace(/([:\.\[\]])/g,\\$1);}
As for use of the [] in id's, I do not believe this has anything to do
with making id's indexable or whatever. At the least not for any of my
reasons to do it.
In the context of programming on the server side I find this perfectly
reasonable:
HTML::labeledInput($label, $name, $value=); - label
for={$name}{$label}/labelinput type=text name={$name}
id={$name} value={$value} /
HTML::labeledInput(FooBar, foobar[1]); - label
for=foobar[1]FooBar/labelinput type=text name=foobar[1]
id=foobar[1] value= /
name and id serve two different purposes. Name is the only one you can
use to submit an input's data. And id is the only one that works for
making labels work. But I see little value in forcing extra unnecessary
inputs, or rewriting id's in some messy way that makes it harder to do
things client side. So I wouldn't doubt that there are html libaries
that do this kind of thing.
On Apr 16, 1:03 pm, Richard D. Worth rdwo...@gmail.com wrote:
On Wed, Apr 15, 2009 at 12:23 PM, Daniel Friesen
nadir.seen.f...@gmail.comwrote:
Fact is that jQuery does support using characters like :[] by escaping
them with a \ and that should be noted when someone does not know.
It's noted here:
http://docs.jquery.com/Frequently_Asked_Questions#How_do_I_select_an_...
- Richard
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com]
-Nadir-Point Wiki-Tools (http://nadir-point.com) (http://wiki-tools.com)
-MonkeyScript (http://monkeyscript.org)
-Animepedia (http://anime.wikia.com)
-Narutopedia (http://naruto.wikia.com)
-Soul Eater Wiki (http://souleater.wikia.com)
--~--~-~--~~~---~--~~
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
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: What does this error message mean?
Barely anyone actually bothers to do it + You never said you did = We assume you may not have done it and suggest it ~Daniel Friesen (Dantman, Nadir-Seen-Fire) Pink Pig wrote: On Apr 16, 1:04 am, David Zhou da...@nodnod.net wrote: On Thu, Apr 16, 2009 at 12:48 AM, Pink Pig b...@grandcentralapartments.com wrote: On Apr 15, 7:11 pm, Ricardo ricardob...@gmail.com wrote: Try a search for '@' in the plugin files, it shouldn't be hard. On Apr 15, 3:59 am, Pink Pig b...@grandcentralapartments.com wrote: Maybe you guys should stop patting yourselves on the back long enough to straighten out the documentation and synchronize everything. I'm not in the core team, but hello? Well, hello yourself. Obvious everyone in the world is a total idiot but you. I don't know what made you take that tone in that last paragraph in your second email or in this most recent email, but no one's response so far warrants such treatment. Your initial email pointed to a fairly straight-forward case of using the removed @ syntax, so that's what people told you. You didn't give notice or any indication of third party plugins until your second email, where you decided that the best way to garner help was to end on a snarky remark. Ricardo's advice is pretty sound: if it's complaining about @, then it means one of your plugins is using @. Do a search through them and see if that's the case. I'll try not to be snarky, but I fail to see any justification for the assumption that I haven't already done this. --~--~-~--~~~---~--~~ 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 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: selector on elements like id=name[2]
HTML5 removes that restriction on id's, and I can't think of a single
browser that even follows that restriction.
There are a lot of convoluted things inside of the HTML4 spec which
browsers don't bother implementing, and we don't bother following, nor
do browsers.
Saying that we shouldn't handle id's without [] because standards
defines that we shouldn't, is like saying we shouldn't use innerHTML
because it's not defined in standards.
Fact is that jQuery does support using characters like :[] by escaping
them with a \ and that should be noted when someone does not know.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
DBJDBJ wrote:
Thanks Nick,
Also would not this forum be better without advices like :
...[] is used for attributes. Use the backslash to escape them for
use as
part of an id...
And, yes this is not a discussion for this forum, too ..
-- DBJ
On Apr 15, 11:26 am, Nick Fitzsimons n...@nickfitz.co.uk wrote:
Indeed; [ and ] are not actually valid characters in an id attribute,
according to HTML 4.01:
http://www.w3.org/TR/html401/types.html#type-name
'ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
followed by any number of letters, digits ([0-9]), hyphens (-),
underscores (_), colons (:), and periods (.).'
Just to confuse the issue, [ and ] _are_ permitted in name attributes;
whereas id attributes are of type NAME, name attributes are of type
CDATA:
http://www.w3.org/TR/html401/types.html#type-cdata
On Wed, April 15, 2009 9:39 am, DBJDBJ wrote:
Even better: do not use them at all , as part of an id ...
On Apr 14, 6:58 pm, Daniel Friesen nadir.seen.f...@gmail.com wrote:
[] is used for attributes. Use the backslash to escape them for use as
part of an id.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Mat Brennan wrote:
Hi all,
Not sure if this is even relevant to the development side of the
group.
I've noticed if i have something such as:
input type=text name=firstname[1] id=firstname[1] /
input type=text name=firstname[2] id=firstname[2] /
And then i use a selector such as
$(#firstname[2]) then nothing is returned; In fact even
document.getElementsById('firstname[2]') will return nothing. I'm not
sure if it's being turned into an array internally or if i'm
misinterpreting how getElementById works but it's been bugging me.
I dont need a solution on how to select the element i already figured
I could do something like:
$([id='firstname[2]']); which works fine but what I am curious to
know is why the behavior is so odd for this type of id.
Thanks guys,
Much appreciated.
--
Nick Fitzsimonshttp://www.nickfitz.co.uk/
--~--~-~--~~~---~--~~
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
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: selector on elements like id=name[2]
[] is used for attributes. Use the backslash to escape them for use as
part of an id.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Mat Brennan wrote:
Hi all,
Not sure if this is even relevant to the development side of the
group.
I've noticed if i have something such as:
input type=text name=firstname[1] id=firstname[1] /
input type=text name=firstname[2] id=firstname[2] /
And then i use a selector such as
$(#firstname[2]) then nothing is returned; In fact even
document.getElementsById('firstname[2]') will return nothing. I'm not
sure if it's being turned into an array internally or if i'm
misinterpreting how getElementById works but it's been bugging me.
I dont need a solution on how to select the element i already figured
I could do something like:
$([id='firstname[2]']); which works fine but what I am curious to
know is why the behavior is so odd for this type of id.
Thanks guys,
Much appreciated.
--~--~-~--~~~---~--~~
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
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: Firefox 3, Chrome issue with table and css(name,value)
Mind showing all the code you are using? It looks like more of a issue with other code rather than that code. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) Rodney wrote: I am having problems using something as simple as: $(.filterable tr:odd).css(background-color, white); table class=filterable It works in IE7, but not Firefox 3.0.8 or Chrome (latest stable). I'm using jQuery 1.3.2. One thing to note is that filterable is not defined in any css stylesheets. Could the issue be I'm only defining filterable in my jQuery and not in CSS? Would that be considered an invalid XHTML issue? --~--~-~--~~~---~--~~ 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 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: Color library
1) Signup for a open source account on github 2) On http://github.com/dantman/jquery.color/tree/master hit the fork button to create your own (git is distributed) 3) Checkout your own private repo after running the config commands github suggests, using `git clone g...@github.com:USERNAME/jquery.color.git`. 4) Push changes back to your repo with `git push origin master` When you make a change to the library you can go back to my repo and use the pull request button to poke me to pull our changes into my repo. Likewise I can do the same to poke you to pull my changes into your repo. That second step is key, it's important that people use github's fork option rather than cloning and creating their own empty repo. Doing that makes the repos show up at http://github.com/dantman/jquery.color/network which displays a graph showing all the people who have forked it and the differences between each person's repos. It's good for finding other people's improvements to incorporate too. `git init` is for starting a new empty repo, `git clone` is for starting a new repo based on an existing one (checking it out; it also sets up the remote origin), `git status` tells you the current status of what will be committed and what's changed, `git diff` will tell you the differences between the filesystem's state and what will be committed (NOT the current state of the repo like in svn), `git branch` is for managing branches (these are easier to handle than in svn, so use them freely whenever you are doing something long), `git checkout` switches between branches, `git add` adds changes to the index to be committed (it's not just for adding files), `git rm` removes files, `git stash` can stash changes. And of course `git commit` commits the index. I never bother with `git log`, git-gui can be quite useful and gives you access to gitk and something similar to `git add --patch` which is basically an interactive mode that lets you select only specific chunks of diffs that you want to commit (see http://tomayko.com/writings/the-thing-about-git). Some imporant terms; The index is basically a kind of commit limbo. You `git add` the changes you want to make into the index, and when done use `git commit` to commit those changes as a commit. Your trunk, or active branch is normally master Normally you have a remote called origin which is normally your own public repo. `git clone` sets whatever repo you clone from as the origin. Something that takes a little getting used to with branches is the filesystem. git basically occupies an absolute single filesystem space. So you create branches with `git branch` and `git checkout somebranch` basically alters the filesystem to become that branch. (On a nix system you may want to use a bash trick to put the name of the current branch into your prompt) ^_^ Fun fact, you can alter the last commit you made. So if you make a typo in your commit message you can fix it before you push it to the repo. You can use `git remote add daniel git://github.com/dantman/jquery.color.git` to make it so that you can `git pull daniel` my changes into your repo. I really like git and the distributed model. It's almost like giving every random person commit access. Dealing with jQuery's svn repo often gives me a number of annoyances. Since I can't commit (even locally) I can't get an easy diff to a previous local version (when I'm dealing with things like two separate changes which depend on one common change). And everything is always stuck in diffs, I can't go and commit anything somewhere and just tell someone to put that change into the main repo. So with git, basically any random person can just clone the repo, commit into it, and publicize their changes publicly so you can pull them back into the main repo without worrying about random people you give commit access breaking it. Not only that but using github you can get a nice view of all the distributed repos and differences. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) Mark Gibson wrote: Nice one Daniel, I'll check it out when I get time - gonna have to do a bit of a crash course in git first :) 2009/4/2 Daniel Friesen nadir.seen.f...@gmail.com: I started a GitHub repo: http://github.com/dantman/jquery.color/tree/master I also added full rgb support for alpha values. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) Mark Gibson wrote: Hi Daniel, Sorry for the delay, been on holiday. The code seems to be accessible at present. I've done a lot of work on it over the last week, so it's probably quite different to the last time you looked. I keep meaning to start a git hub repo for it, but never get round to it - may have a look into it later today after I've cleared my mountain of mail. http://test3.internal.adaptavist.net/~mgibson/color/ 2009/3/28 Daniel Friesen nadir.seen.f...@gmail.com: I was thinking of doing some work on the Color library today but it looks like the code isn't
[jquery-dev] Re: Color library
I started a GitHub repo: http://github.com/dantman/jquery.color/tree/master I also added full rgb support for alpha values. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) Mark Gibson wrote: Hi Daniel, Sorry for the delay, been on holiday. The code seems to be accessible at present. I've done a lot of work on it over the last week, so it's probably quite different to the last time you looked. I keep meaning to start a git hub repo for it, but never get round to it - may have a look into it later today after I've cleared my mountain of mail. http://test3.internal.adaptavist.net/~mgibson/color/ 2009/3/28 Daniel Friesen nadir.seen.f...@gmail.com: I was thinking of doing some work on the Color library today but it looks like the code isn't accessible anymore. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) --~--~-~--~~~---~--~~ 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 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: Selection problems with multiple elements
If /this/ is a node as I expect it is in that context, it should
actually be $(this).find('.quantite');
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Gilles wrote:
Bonjour!
Stupid question, but you have made sure to wrap your code inside $
(function(){ /* your code */ }); yes?
As otherwise JQuery might have trouble locating what you need if it
isn't.
Also could you provide the HTML source as rendered by the browser, it
makes copy/pasting/testing easier :)
$(this ~ .quantite) is wrong tho i believe it should be $(this
+'.quantite') as this is a variable
(unless it is interpreated as variable between double quote like in
PHP, but I am pretty sure it doesn't)
On Mar 31, 3:14 pm, elpatator romain.simi...@gmail.com wrote:
Although Jquery offers multiple ways in selecting DOM elements, I
can't figure out how to do this, as i'm not that good at it.
Here's the deal :
my html goes like this
logic:iterate id=ligneCommande name=commande
property=lignesCommande indexId=index
div class=ligneArticlec:set
var=nbLigneCommandes
value=${nbLigneCommandes+1} /
bean:define id=articleId
name=ligneCommande
property=article.id /
div class=blocGauchebean:define
id=articleId
name=ligneCommande
property=article.id /
img class=visuelArticle
src=/images/visuelsArticles/dim1/$
{ligneCommande.article.articleReference.reference}_dim1.jpg
height=60 width=60 /
span class=libelleArticle
bean:write
name=ligneCommande
property=article.articleReference.libelle /
/span
/div
div class=blocDroit
span class=prixUnitaire
bean:write
name=ligneCommande
property=prixUnitaire format=
formatKey=main.format.prix/
input
type=hidden class=prixProduit name=prix${index}
value=${ligneCommande.prixUnitaire}/input
input type=hidden
name=montantDeLigne${index} value=$
{ligneCommande.prixTotal}/input
/span
table class=calculette
tr
td
html:text
styleClass=quantite
property=quantiteLigneCommande(${ligneCommande.id}) styleId=$
{ligneCommande.id}/
/td
td
img
class=plus src=/images/quantiteIncrement.gif
alt=Plus /
/td
td
img
class=moins src=/images/quantiteDecrement.gif
alt=Moins /
/td
/tr
/table
div
id=montantDeLigneAfficher${index} class=prixTotal
bean:write
name=ligneCommande property=prixTotal format=
formatKey=main.format.prix /
/div
/div
div class=clear/div
/div
div class=clear/div
/logic:iterate
As you can see, I iterate on each line, that's named .ligneArticle ;
What I wish to do is, on click on
img class=plus src=/images/quantiteIncrement.gif alt=Plus / or
img class=moins src=/images/quantiteDecrement.gif alt=Moins /,
traverse back up from my button, in order to get it's current (and
unique) lingneArticle, to get back down and work on quantity input.
Right now, my js looks likes this :
$(.plus).click(function (){
var quantite = $(this ~ .quantite).val();
quantite++;
if (quantite=0
[jquery-dev] Re: Enhancement suggestion: .css(['prop', 'prop', 'prop']);
Ticket has been opened: http://dev.jquery.com/ticket/4461
On Mar 21, 3:15 am, Daniel Friesen nadir.seen.f...@gmail.com wrote:
At work when I was writing my own JavaScript framework (partly inspired
in API by jQuery) I ran into a number of times where I needed to grab a
series of css values and set them all onto another, as a result I ended
up coming up with another type of input to .css;
$(someNode).css(['backgroundColor', 'backgroundImage', 'width', 'height',
'position', 'top', 'left']);
Basically I made .css accept a single array of property names to grab.
The return is a object with property keys and values set on them. The
absolute beauty of this, was that you could take that same object and
set it onto another note, or even use it to revert.
var cssCache = $(node).css(['display', 'width', 'height']);
// Do a bunch of stuff to node that modifies all that kind of css.
$(node).css(cssCache); // Revert to the original values
Though I do take note now, another possibility which might fit in better
with .addClass and .bind might be something like.
$(someNode).css('backgroundColor backgroundImage width height position top
left');
Though the fact that the difference between 'width' and 'width height'
is the difference between .css returning a string or an array, so it
might be worth it to use the array input format to avoid confusion.
Any thoughts? This worth opening an enhancement ticket?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
--~--~-~--~~~---~--~~
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
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: Inserting content with each?
var img = $(.gallery img);
$(img).each(function() {
$(#bild_spel div ul).append( $('li/').append(this) );
});
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Gilles wrote:
For some reason your answer doesn't show on here. You might have mail
me directly, anyway if you want to insert the element straight away
instead of creating a new image element maybe the fact that you are
mixing string variable and an object in your appen() might cause the
problem.
In your code if you alert this you will see that it isn't img
src=.. but an object, an image tag object, so i think your code
fail because you are tying to append a string and an object together.
this is not a string. Try appending this on its own and see which
result it gives.
This should work (also wont be wrapped in li)
var img = $(.gallery img);
$(img).each(function() {
$(#bild_spel div ul).append(this);
});
You'll just need to wrap it in your li somewhere else
On Mar 30, 12:17 pm, Gilles gil...@netxtra.net wrote:
Might want to try something like this instead:
$(.gallery img).each(function()
{
$('#bild_spel div ul').append('liimg src= '+$(this).attr
('src')+' alt=/li');
});
haven't tested it but I believe it's correct :)
On Mar 30, 11:48 am, smurkas marcus.dalg...@gmail.com wrote:
Hello.
I have a situation where I have grabbed a couple of images off a page
and want to insert them again into an unordered list. Grabbing the
images was no problem but I don't know what to write when inserting
them again.
The code below does not result in the images being inserted again,
instead each list item contains
[object HTMLImageElement] as text. I also tried wrapping this in $
(this) but that didn't work either. The solution is probably dead
simple but right now I am missing it. Can anyone help me out?
var img = $(.gallery img);
$(img).each(function() {
$(#bild_spel div ul).append('li'+this+'/li');
});
Kindly, Marcus.
--~--~-~--~~~---~--~~
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
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: feature request: retrieving :hover css properties
No framework supports it because it's not possible without it being a
hack. You can't select a :hover state because it's not a node. And .css
is not meant to be used in that way either. .css works on a style tag,
or queries for computed styles. It has absolutely nothing to do with
modifying css rules which is what is required for :hover
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Alexandre Plennevaux wrote:
ok submitted http://dev.jquery.com/ticket/4434 it's in the hands of
the jquery team to decide now.
thanks to you all for an interesting investigation !
On Fri, Mar 27, 2009 at 10:16 AM, Gilles gil...@netxtra.net wrote:
Catching up the CSS on :hover would sure be interesting to see and
quite unique as I believe most javascript framework out there do not
support it.You could do some interesting thing with it I guess, use
the CSS property of hover to set the skin of some javascript button/
widget, so you end up just editing CSS to have a nice jquery effect
and basic styling if javascript off.
I'll be suprise if the team didn't think about it yet tho, as it is
often highlited as what javascript selector engine can't get.
On Mar 27, 7:49 am, Alexandre Plennevaux aplennev...@gmail.com
wrote:
do you guys think i should suggest that it be included in the jquery
core, allowing to do
var myColor = $('a:hover').css('background-color');
?
i have no idea about the cost/benefit ratio, i just think that it
feels right to store styling in the stylesheet rather than in
metadata quirks.
On Fri, Mar 27, 2009 at 2:14 AM, Danny d.wac...@prodigy.net wrote:
I honestly have never profiled it, so I don't know. It does not
involve any AJAX or other additional http access. It does n regular
expression comparisions, where n is the number of CSS rules in all
your stylesheets.
On Mar 26, 7:05 pm, Alexandre Plennevaux aplennev...@gmail.com
wrote:
ok, so if i understand this correctly, this method does not bring in a
heavy overhead?
--~--~-~--~~~---~--~~
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
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: CONTEXT LOGIC
Context is not scope!
Context's purpose is not to narrow down querying. It is perfectly valid
to use a selector without context. Context's purpose is for sorting out
document context.
You're telling me that my $('#foo .someclass'); selectors are slow
because they don't have context, which is a horrible lie.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
DBJDBJ wrote:
Can we just have next jQuery(selector, context) version throw an
exception,
IF context argument is not jQ instance or dom element exception will
be thrown. As simple as that.
I would even suggest going even further. Throw an exception if context
argument is not given.
Make context mandatory. And make it right.
Otherwise people will start blaming jQuery for slow pages, instead of
sorting out their lazy $(selector) calls without any context given
to act as a SCOPE to narrow down the querying of the dom document
tree ...
On Mar 26, 3:04 pm, Daniel Friesen nadir.seen.f...@gmail.com wrote:
Example 1 is invalid jQuery.
Example 2's speed comparison to Example 3 is trivial. In fact Example 2
has an advantage to it. Do remember IE6's bug with getElementById,
jQuery's selectors have code to fix that bug.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)DBJ wrote:
// jq132-vsdoc.js, line # 145
return jQuery(context).find(selector);
From this one might draw following Conclusions :
C1: if context is not a dom document jQ will find things faster
because the scope of the search is narrow(er)
C2: if context above is a single dom node (aka element) jQ will
find things the fastest, please refer to: jq132-vsdoc.js, line # 107
(please everyone use this structure in a discussion :
body
span id='people'
span id='person' name='john' /span
span id='person' name='bad robot' /span
!-- and so on --
/span
/body
)
We are in the royal mess because we have no crystal clear and
unambigious terminology here. On top of that one important term is
missing:
SCOPE.
Right now we have this (by now apparently) ambiguous term: CONTEXT.
Sometimes it is (acts like, is used for) scope and sometime it does not.
1 :: $([name], #people ) // CONTEXT
(internaly: selector := #people [name], context := document )
2 :: $([name], $(#people) ) // SCOPE
(internaly: selector := [name], context := element with id 'people' )
3 :: $([name], document.getElementByID(people) ) // SCOPE
(internaly: selector := [name], context := element with id 'people' )
Do we all agree with the above? If not we have to, I think.
Furthermore. Line 3:: above is the fastest possible $() , because it
boils down to :
$( document.getElementByID(people)).find([name]) ;
This provides immediate and narrow scope for Sizzle to work in.
(reminder: jQuery.find = Sizzle )
And last but not the least :o)
Please refer to : jq132-vsdoc.js, line # 100
What am I asking for is to enforce this in jQuery. Nothing much and
nothing else. So :
$( selector:string, context:string )
Should be forbidden. should throw an exception.
The non-enforcing style of jQuery sometimes bears no fruit. The above
line is now possible, same as just saying : $() , because jQuery
authors think it is a good thing not to slap junior or senior but
lazy jQuery users, when they do these kind of coding.
But. It is a fact that companies are using jQuery. The more they use
it, the more problems they have with code that uses context in a wrong
way. And. 90% of coders actualyl use no context at all. The badly
written code mushroms and slows things down exponentially. One way out
if that (mess?) would be to enforce proper usage of context and define
the term SCOPE. Explain it to people and gently force them to use it.
2009/3/26 Daniel Friesen nadir.seen.f...@gmail.com:
I disagree. First thing to note is there are two definitions of context.
jQuery(selector).context; And jQuery(selector, context);
They are two different things which overlap just a bit.
jQuery(selector).context; Is the document context. It is the only
context that is stored in jQuery.
jQuery(selector, context); Is a node/document context for the query.
It's primary purpose is to establish document context so that jQuery
knows what document (current document, an iframe, another frameset) to
perform selectors in and use when constructing new document nodes to
insert. It does have the ability to be used to limit the scope of a
query, however that is unintuitive and makes programs confusing to read.
Your pagination example would be better handled in a different way:
$('.pagination .pagelist'); // jQuery selectors are not single-level.
Don't think everything needs to be separated into contexts. Most of the
time it doesn't
var pagination = $('.pagination');
$(pagination).find('.pagelist
[jquery-dev] Re: Need help with an IE issue (of course!)
code += init.join(';')+';';
and
for (i = 0; i jsl-1; i++) code += init[i]+';';
Don't output the same.
For the first one will be ; the second one will stay
It's possible that IE has an issue with eval(;); if I understand this
thread right.
Side note, you should be using for (var i = 0
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Gilles wrote:
Ok, I don't have the bug anymore, but my script is no longer working
(and I know why so at least I know where to look)
For information purposes all I did was changed this line
code += init.join(';')+';';
to this line and the error message went away
for (i = 0; i jsl-1; i++) code += init[i]+';';
only issue is, I use an alert to display code afterward and this is
what happens:
1. When the first line is used the alert will display the code to eval
perfectly, but the error message will be there and the code doesn't
work
2. When the second line is used the alert is blank, and of course
there is no error because it eval('');
Note the jsl-1 is temporary it's just in my example need the ui core
so removed 1 out of the new length to avoid undefined being inserted
in the code, at start I thought that it was the reason for the alert
being blank, but it isn't)
Both lines of code works perfectly as expected in FF3 (haven't tried 2
yet) and Safari 4 (accordion bit jerky on it like on ie)
http://codeserenity.com/jquery/scriptless/demo4.html - for demo - code
same as above but 4, working on it so might not always work :p
So my guess is join() and += in IE don't work the same. I don't know
why the code variable becomes blank tho. The only silly thing I think
of is maybe the return of eval is ''. My only worry is that if I can
make it not blank I'll just get the error again.
Oh, and only tried on IE7 so far as well for the bug, not IE6 or IE8.
On Mar 27, 5:18 pm, Gilles gil...@netxtra.net wrote:
Thanks for that great tip, I'll try to keep that in mind :)
On Mar 27, 3:21 pm, Tony Dillon tony.dil...@gmail.com wrote:
Hi Karl,
Boy, these sure are some of the hardest problems to track down This is
why I always try to do my comparisons using the format:
if( 'constant' == $variable )
so it gets picked up as an error by the compiler (because of course you
can't assign a variable to a string constant).
Hope this helps you avoid future problems.
Be well,
Tony
On Fri, Mar 27, 2009 at 3:09 PM, Gilles gil...@netxtra.net wrote:
Thanks for pointing it out Karl, will go fix that now, can't believe I
type that wrong.
Karl Swedberg wrote:
Hi Gilles,
Not sure about that bug, but wondering if these lines are
intentionally assigning the variable rather than testing for equality :
if (d = 'ui') js.push('ui.'+cw); // line 151
else if (d = 'fx') js.push('effects.'+cw); // line
152
if (d = 'ui') css.push('ui.'+cw); // line 156
seems they should have == rather than = .
--Karl
Karl Swedberg
www.englishrules.com
www.learningjquery.com
On Mar 27, 2009, at 5:06 AM, Gilles wrote:
Not sure wether it would help or not but here full plugin code.
http://codeserenity.com/jquery/scriptless/js/jquery.scriptless3.js
If anyone know how I could get rid off that Object doesn't support
property bug on IE I would really appreciate. Any advices and/or tips
on how to improve it would be welcome as well, still learning :)
On Mar 26, 12:23 pm, John Resig jere...@gmail.com wrote:
I'm not seeing an issue off-hand - could you simplify the code that
you're trying to execute? For example, does this error only occur if
getScript is used?
--John
On Thu, Mar 26, 2009 at 7:15 AM, Gilles gil...@netxtra.net wrote:
Hi,
I normally bebug my code myself, cos I believe it helps me improve
myself, but here I just can't figure it out.
basically I am writing a JQuery plugin, that JQuery plugin
generate a
bit of code that I then eval later. The code is a casacde of
getScript
with some initialization command being trigger in the middle (when
all
the getScript are finished)
To make my life easy I thought I use $.globalEval(code) to make sure
it works accross all browsers. Like expected no issue with safari 3,
safari 4, FF2 or FF3 but as soon as i tried my test page on IE7
everything broke...
And of course I get the well know and very easy to debug error
80020101.
1. It's not because of comment (none used anywhere)
2. I have tried:
eval(code)
eval(code,$)
window.eval(code)
execScript(code)
window.execScript(code)
window['code'] = code; window.eval(window['code'])
window
[jquery-dev] Re: suggestion: delayed related AJAX requests
Rather than an entire other function, what about just a {delay: ms} to .ajax
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Miloš Rašić wrote:
Here's a suggestion for a feature that I think would be useful to AJAX
developers. Sometimes, we need an AJAX feature that could allow a user
to cause a large number of consequent AJAX requests, for example in
auto-complete for searches (like Google Suggest) or filter forms that
submit whenever something is changed in them. In a case like this,
especially when the user has a slow internet connection, we have no
way of knowing if the AJAX responses will arrive in the same order as
the requests were sent. A solution to this is to wait for some time to
make sure that the user has stopped manipulating the controls that
cause AJAX requests before sending a request. At the moment, I do it
like this:
function submit_filter() {
$('#item_list').html('loading...');
$.post('some url',$('#filter').serialize(),function(data) {
$('#item_list').html(data);
});
return false;
}
$('.ajax_control').change(function() {
clearTimeout(ajaxTimeout);
ajaxTimeout = setTimeout(submit_filter,2000);
});
Basically, whenever a control is changed a timeout for ajax request is
reset to 2 seconds. A request is sent only when a user changes
something an hasn't made new changes last 2 seconds.
Since this is a frequent use case, it would be great if there would be
a $.post_delayed() function which would have additional 2 parameters:
an id, which would be used to identify related controls, and a time
interval to wait before submitting the request.
--~--~-~--~~~---~--~~
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
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: Color library
I was thinking of doing some work on the Color library today but it
looks like the code isn't accessible anymore.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Daniel Friesen wrote:
Just following up with a note. I didn't get around to setting up the
repo right away, and on Friday the UI on my laptop completely broke. I
have the entire hard drive safe but setting up the environment on the
new system will take a bit of time. I'll startup a repo once I get
back into a good dev environment.
On Mar 5, 3:15 am, Daniel Friesen nadir.seen.f...@gmail.com wrote:
Mark Gibson wrote:
Hi Daniel, thanks for your feedback, just to clear up some points:
On Mar 4, 10:10 am, Daniel Friesen nadir.seen.f...@gmail.com wrote:
I'm not really a fan of the [float, float, float] but if 'rgb(255, 255,
255)'; is supported I suppose that's ok (heck I could throw a function
rgb(r, g, b) into code).is taking time.
RGB values use the range 0..255, whereas HSV is 0..1 - even the hue
value.
I didn't see the point in using degrees asJavascriptangles are in
radians anyway, so I though 0..1 was the best compromise.
However I don't really like the explicit $.color.parse call, I think
these should already understand that if a string is passed the data
should be parsed.
This is what thecolor.object.js code is for. It provides a simple to
use object that will accept a variety of value presentations. I've
modelled it on the way jQuery.Event works. So you can choose whether
to explicitly use 'new' or not. Examples:
$.Color('rgb(255,255,255)')
new $.Color('#ff')
new $.Color([255,255,255], 'RGB')
$.Color([128,0,255])
$.Color('red')
$.Color('rgb(50%,0%,100%)', 'HSV')
The first arg is your colour: as a valid CSS string or $.Colorobject
or an array of channel values.
The second arg is the colour space you wish the new object to be in.
If the first arg is an array, then the second indicates what space
that array represents (defaults to 'RGB').
But if a string or $.Colorobject is supplied then it is converted to
the colour space requested.
Internally $.Colorbasically just extends the Array object -
containing the individual channel values, and adds some methods and a
'type' property that indicates the colour space ('RGB', 'HSV' etc.) -
these types are implemented by functions kept in the $.color.RGB/
$.color.HSV namespaces. This allows users of thelibrarya choice of
functional or OO depending on their needs.
* If you know you have a string (ie, a CSS value) and only want RGB
values then this will do: $.color.parse(str)
* If you want to convert it to a HEX representation, you have the
choice:
$.color.RGB.toHEX($.color.parse(str))
or
$.Color(str).to('HEX') - this is essentially an OO wrapper for the
above
* To get a colour as HSV regardless of it's original form (ie, could
be a string, or a $.Colorobject of either RGB or HSV):
$.Color(color, 'HSV')
Is there an actual repository yet? If you don't have one yet then at
least a small github repo for now would be good. Then I can fork (fork
in git speak, nothing to do with project forking) and commit
improvements you can pull.
It's currently in our internal SVN, was hoping to use jQuery-UI repos
eventually. I'm a bit busy on other things at present, so thelibrary
is on hold for a couple of weeks and won't be changed by me. I've not
used git for much, so if you'd like to setup a public repos for it,
feel free to grab the code in it's current state, that would be great
- same goes for the colour picker too.
Sure. It's late right now, so I'll probably do it tomorrow. I'll setup a
repo or two on GitHub. That way you can just hit fork on GitHub and the
Network tab will start tracking both of us and show the differences
between what we've committed to flag new things to pull from each other.
I'm very interested in thatcolorpicker to. Every othercolorpicker
I've run into has been a full fledged bloatedcolorpicker that defines
the entire ui, or uses some crappy theming system. However that one you
have basically just defines nothing but the standard UI pieces that are
stuck inside ofcolorpickers. That's the kind of thing minimalist
enough for me to make use of inside our project at work.
We're not using a stockcolorpicker because as part of our UI we're
also trying to improve the usability and try new things with thecolor
picker.
Yeah, this is one of the main reasons I started my own.
However at the same time while you have the hue bar and hue wheel, it
doesn't have the classic wheel with internal
triangle:http://www.qtsoftware.com/products/add-on-products/catalog/3/Widgets/...
So considering our app is aimed at designers who use photoshop, I might
still go ahead and experiment with a canvas/ basedcolorpicker and
try supporting one of photoshop's
features:http
[jquery-dev] Re: CONTEXT LOGIC
Example 1 is invalid jQuery.
Example 2's speed comparison to Example 3 is trivial. In fact Example 2
has an advantage to it. Do remember IE6's bug with getElementById,
jQuery's selectors have code to fix that bug.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
DBJ wrote:
// jq132-vsdoc.js, line # 145
return jQuery(context).find(selector);
From this one might draw following Conclusions :
C1: if context is not a dom document jQ will find things faster
because the scope of the search is narrow(er)
C2: if context above is a single dom node (aka element) jQ will
find things the fastest, please refer to: jq132-vsdoc.js, line # 107
(please everyone use this structure in a discussion :
body
span id='people'
span id='person' name='john' /span
span id='person' name='bad robot' /span
!-- and so on --
/span
/body
)
We are in the royal mess because we have no crystal clear and
unambigious terminology here. On top of that one important term is
missing:
SCOPE.
Right now we have this (by now apparently) ambiguous term: CONTEXT.
Sometimes it is (acts like, is used for) scope and sometime it does not.
1 :: $([name], #people ) // CONTEXT
(internaly: selector := #people [name], context := document )
2 :: $([name], $(#people) ) // SCOPE
(internaly: selector := [name], context := element with id 'people' )
3 :: $([name], document.getElementByID(people) ) // SCOPE
(internaly: selector := [name], context := element with id 'people' )
Do we all agree with the above? If not we have to, I think.
Furthermore. Line 3:: above is the fastest possible $() , because it
boils down to :
$( document.getElementByID(people)).find([name]) ;
This provides immediate and narrow scope for Sizzle to work in.
(reminder: jQuery.find = Sizzle )
And last but not the least :o)
Please refer to : jq132-vsdoc.js, line # 100
What am I asking for is to enforce this in jQuery. Nothing much and
nothing else. So :
$( selector:string, context:string )
Should be forbidden. should throw an exception.
The non-enforcing style of jQuery sometimes bears no fruit. The above
line is now possible, same as just saying : $() , because jQuery
authors think it is a good thing not to slap junior or senior but
lazy jQuery users, when they do these kind of coding.
But. It is a fact that companies are using jQuery. The more they use
it, the more problems they have with code that uses context in a wrong
way. And. 90% of coders actualyl use no context at all. The badly
written code mushroms and slows things down exponentially. One way out
if that (mess?) would be to enforce proper usage of context and define
the term SCOPE. Explain it to people and gently force them to use it.
2009/3/26 Daniel Friesen nadir.seen.f...@gmail.com:
I disagree. First thing to note is there are two definitions of context.
jQuery(selector).context; And jQuery(selector, context);
They are two different things which overlap just a bit.
jQuery(selector).context; Is the document context. It is the only
context that is stored in jQuery.
jQuery(selector, context); Is a node/document context for the query.
It's primary purpose is to establish document context so that jQuery
knows what document (current document, an iframe, another frameset) to
perform selectors in and use when constructing new document nodes to
insert. It does have the ability to be used to limit the scope of a
query, however that is unintuitive and makes programs confusing to read.
Your pagination example would be better handled in a different way:
$('.pagination .pagelist'); // jQuery selectors are not single-level.
Don't think everything needs to be separated into contexts. Most of the
time it doesn't
var pagination = $('.pagination');
$(pagination).find('.pagelist'); // $(selector, context); is just an
alias to $(context).find(selector); don't abuse it in ways that don't
make sense
pagination.find('.pagelist'); // Your use of another jQuery selector is
completely unnecessary anyways, you already have a jQuery object just
use .find
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
chris thatcher wrote:
I'm trying to follow this thread but it's a little loose so apologies if I'm
missing the point.
The only thing I want to disagree with is the last point. it doesnt matter
whether the context is a class or id. The context's function is to reduce
the scope of the selectors search, and the primary reason for that is simply
performance.
I know there are many signatures for $, but when providing a selector and
context the primary goal is to reduce the scope of the current selector.
There are plenty of cases where the context is a large set of nodes.
For example I might need to modify a portion of the dom that represents a
pagination interface that is provided at the top and bottom of the
interface. So I create a contect based on the class representing the
interface. Say
[jquery-dev] Re: CONTEXT LOGIC
Context is either a dom node, a document, or recently a jQuery object with the like. Context is merely used for establishing a dom node as a parent, and in the case of a document is necessary to know what document to use to create new nodes for. Thinking that $([name], #people); is the same as $(#people[name]); is wrong on multiple levels. $([name], $(#people)); actually means $(#people [name]); and the contex is not meant to be used that way. In fact trying to think that way makes things confusing and reduces code readability because you are mixing up order. If you want to build queries like this then I'd recommend you push for the inclusion of my alternate proposed format: $(#selector, [selector], .selector, ...); Which makes proper sense since you are building up selectors in order (even has potential performance benefits if someone is adventurous since I'd explicitly say to not rely on any consistent return for .end() when using it). It's even more useful when you throw widget objects into the mix. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) DBJDBJ wrote: My question/comment : What is a CONTEXT LOGIC in jQ ? I think it should be : dom node inside which is the result set to be found? The dom node inside which is jQuery to use the selector given. Default is document. If I read it right , jQ doc says that context type can be (only?) dom node or jQuery instance. So I expected that if I give context as a string it will be takens as selector for the jQuery, which will eventualy spill out a single dome node to be used as a context. And that way one can speed up her code, because querying inside the known dom element must be quicker than querying inside the whole document, each time. finding on the branch is faster that finding from the root of the tree. But it seems that if string is given as a context , the selector get's it as a prefix and context is a dom document ? So : $([name], #people)is the same as saying$(#people[name], document ) , because jQ makes it into this. While one might expect the above to be translated to : $([name], document.getElementById(people) ) , which could considerably speed up the slection ... A quick sample I have made (quickly) is here: http://jsbin.com/avowu/edit // context is correctly reported by jQ $([name], document.getElementById(people)).formula( log ) ; // this.context is reported by jQ as HTMLDocument ? // this.selector is prefixed with context $([name], #people) ; Is this by design ? Maybe jQ does this : 1 :: jQuery(#people).find([name]) 2 :: this.context = #people + [name] So that plugins can see the context which actually was used ? So the line : $([name], #people) after all IS actually making things faster ? And I am (or I was) confused with the value of this.context and this.selector, available to me inside a plugin ? But then I think I can;t be right here, because it would be much better to have the selector and context, as originaly given by the user : 1 :: this.context = #people ; this.selector = [name] ; 2 :: jQuery(context).find(selector) After this plugins will see the original selector and context. Provided my assumptions are correct. --~--~-~--~~~---~--~~ 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 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: CONTEXT LOGIC
I disagree. First thing to note is there are two definitions of context.
jQuery(selector).context; And jQuery(selector, context);
They are two different things which overlap just a bit.
jQuery(selector).context; Is the document context. It is the only
context that is stored in jQuery.
jQuery(selector, context); Is a node/document context for the query.
It's primary purpose is to establish document context so that jQuery
knows what document (current document, an iframe, another frameset) to
perform selectors in and use when constructing new document nodes to
insert. It does have the ability to be used to limit the scope of a
query, however that is unintuitive and makes programs confusing to read.
Your pagination example would be better handled in a different way:
$('.pagination .pagelist'); // jQuery selectors are not single-level.
Don't think everything needs to be separated into contexts. Most of the
time it doesn't
var pagination = $('.pagination');
$(pagination).find('.pagelist'); // $(selector, context); is just an
alias to $(context).find(selector); don't abuse it in ways that don't
make sense
pagination.find('.pagelist'); // Your use of another jQuery selector is
completely unnecessary anyways, you already have a jQuery object just
use .find
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
chris thatcher wrote:
I'm trying to follow this thread but it's a little loose so apologies if I'm
missing the point.
The only thing I want to disagree with is the last point. it doesnt matter
whether the context is a class or id. The context's function is to reduce
the scope of the selectors search, and the primary reason for that is simply
performance.
I know there are many signatures for $, but when providing a selector and
context the primary goal is to reduce the scope of the current selector.
There are plenty of cases where the context is a large set of nodes.
For example I might need to modify a portion of the dom that represents a
pagination interface that is provided at the top and bottom of the
interface. So I create a contect based on the class representing the
interface. Say
var pagination = $('.pagination');
Then to update a potion of that sub-dom I would do somthing like:
myCustomUpdate($('.pagelist', pagination));
This saves jquery from having to seach the entire document for elements
with the class 'pagelist', a big win. Instead the selector only looks under
the element array represented by the context array for my variable
'pagination'.
Does this help you? can we talk in very general examples to help illuminate
the cases you are concerned about?
Thatcher
On Wed, Mar 25, 2009 at 8:53 PM, Julian Aubourg
aubourg.jul...@gmail.comwrote:
In my mind context (as I said but I will repeat ;) should be only dom
node, or single id string. If given by user. So these will be only
three valid forms:
I so disagree with this. If we're talking efficient pages here, you HAVE to
authorise a jQuery object as context.
Say you have a list of items with elements within you wanna bind click
handlers to. A nice way (and AFAIK efficient, both in term of performance
AND memory consumption) to do so would be like this:
var items = $(itemSelector);
$(subElementSelector1,items).click(function() {...});
$(subElementSelector2,items).click(function() {...});
...
$(subElementSelectorN,items).click(function() {...});
Your idea of having only *1* dom node or to limit context expressions as id
only would forbid such a construct and would only lead to a less elegant and
less efficient solution.
I'm a great fan of contexts and use them as often as I can. They are as
good as the power of expression we have to express them. Reduce that and you
can be sure no one will ever use contexts again, at least not in a
real-world web application where ids are far less used than classes.
To me, the rational behind contexts within jQuery is crystal clear. Why
reduce it to a getElementById wrapper?
2009/3/26 DBJ dbj...@gmail.com
This is, of course, true and fine. Exactly the purpose of the context.
To define the starting node BELLOW which it will look further. Fine.
It is only that this is not what current documentation is saying :
http://docs.jquery.com/Core/jQuery#expressioncontext
At least NOT clearly and NOT unambigously...
On top of that jQuery.selector and jQuery.context in this case are not
what was originaly passed but what was processed inside jQ
So:
$([name],#people) which is equivalent to $(#people
[name]).
Results in :
selector := '#people [name] // space in the middle
context := DOMDocument
After call to $() finsihes, and plugins can start using this properties.
Above is wrong and should be :
selector := [name]
context := #people // space on the end
This might seem as some nitpicking, but it is actually extrmely important.
Because if context is always given , jQuery enabled pages will be faster.
In some
[jquery-dev] Re: replaceClass
Your original example was confusing. If you just have buttons that
change the background colors you don't even need to bother with the filter.
$(node).removeClass('color-black color-white color-blue
color-green').addClass('color-white');
I think multiple classes are supported in removeClass already. But the
regex idea is a possibility.
As for .replaceClass I still don't see a point. If
.removeClass(foo).addClass(bar); is doing bad performance things, then
those performance things should be fixed. I find the case to be trivial
in comparison to how much is already done in JS to do anything else.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Julian Aubourg wrote:
$(node).filter('.color-black').removeClass('color-black').addClass('color-white').end()
And you find that more readable than
$(node).replaceClass('color-black','color-white') ? ;)
The main issue here is that I dunno what the class will be in the first
place. I just know it will be color-XXX but I have no idea what the XXX
is. All I have are clickable elements that basically say: set backroung to
red, set background to green, etc etc. It could also be set background
to image1 and font-weight to bold or anything else, the point is I'm not
supposed to know the exact changes it is supposed to do visually to the
targeted element (that's the whole point: keeping the style info in the css
and use classes to switch the visual properties).
So clearly, the first step is to find which of the color-XXX the element is
tagged with, then replace it with color-YYY as asked by the other clickable
element. So, yes, regexp support on hasClass / removeClass would be greatly
appreciated (you don't wanna know how horrible my current code is --
basically relying on ids and a secondary structure to keep track of the
actual color class -- hence duplicating the information).
Now, onto the replaceClass. Well, node.removeClass(X).addClass(Y) is
basically:
- 1 split of X to arrayX
- 1 split of Y to arrayY
- (arrayX.length + arrayY.length) splits of the node's class attribute
- (arrayX.length + arrayY.length) times searches in the resulting split
On a side note, I don't even get why add and remove actually delegate to
jQuery.classname.has() knowing the function does a split of the class
attribute each time it is called rather then splitting the class attribute
themselves and be done with it once and for all. It sure saves some bytes in
the filesize department but it does not seem right to me from a performance
point of view.
Even if removeClass and addClass only did one split of the class attribute
each, it would still be one split too many for a replacement.
All I'm saying in the end is that a replaceClass() function would be simpler
in usage and much more efficient (depending on the performance penalty of a
regexped split) than chaining removeClass() and addClass().
I guess that, today, most people do set style properties manually but class
switching is so much more elegant, solid (since you don't have to keep track
of which style properties were set previously so that you reset them before
applying new ones) and efficient (you only change a string portion in an
attribute and you don't have to go through jQuery's style engine). I'm just
a bit puzzled jQuery makes it difficult by design in that it does not
provide regexp support for class search and forces into an efficient
solution to change a class for another.
Probably nitpicking anyway but then again, I'm just telling because I have a
real-life case on the table right now ;)
Oh well, I guess it's time to make another plugin no-one will use apart from
me ;)
Thanks for the feedback, Dan,
-- Julian
2009/3/26 Daniel Friesen nadir.seen.f...@gmail.com
Having .hasClass / .removeClass support regex has been discussed before,
there is a ticket open for one of them so it might be a possibility.
I don't see much use for replaceClass, rather I think the semantics of
reading it would be a little confusing. I can't even understand what the
code you have there is even supposed to do.
I see no reason to combine add and remove into one.
Just a quick tip, if you're trying to do boolean stuff:
$(node).filter('.color-black').removeClass('color-black').addClass('color-white').end()...
That there would replace color-black with color-white but only for nodes
with color-black, the .end() returns back to the original $(node) so
chaining can continue.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Julian Aubourg wrote:
Hey all,
I'm working on a site that offers some customizability regarding elements
colors (background font). Rather then setting the color with .css(), I
use
classes like color-red, color-green, etc (and of course, red is not the
css
red and green is not the css green). I find it much cleaner since I
need not have color values referenced within javascript or php (it's
simply
in the css
[jquery-dev] Re: Extensibility: Extending init selectors to support application objects
Yup, that is one of the possibilities I considered.
Though I was also considering the callbacks for selector rewriting.
There was an old case on the list about people passing objects to init:
$({id: 'foo'});
That can't properly be handled by the prototype trick. ^_^ It also has a
nice use case going for it since it's expressive and special character safe.
$({id: someUserSuppliedIdThatCouldContainSpecialCharactersLikeAColon});
It's perfectly possible to implement both features. A callback list
doesn't hit performance if there aren't any callbacks. Then you can use
what's suitable and get both performance and flexibility advantages.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Dave Methvin wrote:
I'm working on a patch to jQuery to make it so that initialization can
support application specific objects through extensibility.
How about if your Widget had a method like:
Widget.prototype.jQueryGet = function(){
return #widget-+this.id;
};
Then jQuery's init() could do something like this at the very top:
if ( selector jQuery.isFunction(selector.jQueryGet) )
selector = selector.jQueryGet(context);
Then you can expose whatever you want to jQuery (string selector, DOM
nodes, ready function, etc.) It's a single check in the constructor
rather than a chain of callbacks that have to be invoked on every
jQuery construction, so it certainly has performance going for it.
--~--~-~--~~~---~--~~
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
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: Enhancement suggestion: .css(['prop', 'prop', 'prop']);
Dave Methvin wrote:
I ran into a number of times where I needed to grab a
series of css values and set them all onto another,
This functionality overlaps with what you were proposing in #4295
That bug has nothing to do with the caller interpreting complex
shorthands.
I agree; I was looking at the functionality you wanted in your
original statement--grabbing a series of css values.
Really it's just mapping a 'margin' call to individual marginTop
marginRight marginBottom marginLeft calls and joining them together. The
reason being because browsers do not handle calls to the shorthands
consistently but they do handle the individuals correctly. Calling
'margin' in half the standard browsers will return an empty string
(which will unset stuff instead of setting it right) if the style is set
in the stylesheet instead of directly on the style tag.
I see no reason to require people to use
$(node).css(['marginTop', 'marginRight', 'marginBottom', 'marginLeft']);
when it's perfectly valid (and more likely) for them to try using
$(node).css('margin');
With .css(margin) (or border or padding) it seems like there is
only one thing a caller could reasonably do without parsing it--pass
it back to .css(margin, value) to be set. Are there a lot of
situations where that is needed?
I can see useful cases for .css([prop1, prop2]) but not many for
css(shorthandProperty). If you have the former, the amount of code
you need to write inside your own app will probably be less than if
you had the latter and tried to parse out the individual properties.
Passing it back to .css to reset, passing it to .css to copy styles,
saving it in a database, displaying it. Using it in an animation. Any
reason you want to use a css property get (quite frankly, a good
majority of css properties include units or whatever so I don't see many
other uses for most properties where you wouldn't parse things).
Quite frankly, my reason for wanting a fix for 'margin' and the like is
simple. Unless someone specifically wants a single edge of the margin,
they will not use marginEdge, they will use margin, and if they use that
they will run into this browser inconsistent bug. Even worse because
this is an inconsistency between browsers they will likely develop with
one output in mind and likely lead to things breaking in others. The fix
has the side effect of smoothing things over and making all browsers
give the same output so jQuery users don't have to sweat the issues with
compatibility between browsers (just like why .bind abstracts between
the different ways browsers bind events).
While some bits of these two functionalities overlap I don't believe
these overlap in code nor overall purpose enough to really be considered
overlapping. They both have their own purpose so I don't see any reason
to compare one to the other in deciding what to implement (apples vs.
oranges).
One is a browser inconsistency fix. The other is an enhancement to make
programming simpler. To be honest they are also implemented in two
different ways. The fix is a piece in jQuery.css and the enhancement is
likely a change to jQuery.fn.css or jQuery.fn.attr;
There was a performance and code size note brought up in the replies
to the bug. But I don't see how these are real concerns. The code is
only run if you are actually using these properties (if you're not then
code never gets past the conditionals and just continues like usual).
The only real point might be the movement of some of the code into a
closure or a new jQuery.rawCSS method. I recommend the use of the
.rawCSS method over the closure method, it should perform better (heck,
in some use cases it could be considered a performance enhancement for
plugins) and it has nice re-usability case. In fact that same change has
a use case in another little project, making .css extensible so that
plugins could add support for some obscure css properties like
borderRadius or transform. (That project is pending on John's .curCSS
.attr code refactor.)
Heck, if the tiny change in code for that fix is so much of a concern it
could honestly be implemented in a plugin using that .css extensibility
enhancement when complete. We could have multiple levels of
compatibility enhancement plugins people can use with jQuery; CSS
Compatibility level 1: Fixes to browser incompatibilities in standard
css properties like margin; CSS Compatibility level 2: Fixes to support
css properties in w3 draft like borderRadius and transform in as many
browsers as can handle it (^_^ Heck, we could include animation ability)
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to
jquery-dev+unsubscr
[jquery-dev] Extensibility: Extending init selectors to support application objects
I'm working on a patch to jQuery to make it so that initialization can
support application specific objects through extensibility.
The use case is in applications where you have your own meaning for
certain parts of the system. For example, a Widget system. Your app has
a class Widget and you use these Widget objects a lot. The case here
is that you want $(widgetObject) to know how to extract the node for the
Widget object so that jQuery can manipulate it.
Currently I'm using jQuery.fn.init.callbacks for the callbacks, I'd like
to have some input on what API is actually desired.
An extremely simple example use:
function Widget(id) {
this.id = id;
}
jQuery.fn.init.callbacks.push(function( selector, context ) {
if( selector instanceof Widget ) {
return #widget-+ selector.id;
}
}):
jQuery(function($) {
var myWidget = new Widget('aaa');
$(myWidget).css('backgroundColor', 'red');
});
The current defined API is about the format of the callbacks:
* Callbacks return the selector and context passed to the jQuery object.
* Callback should check the selector and see if it is a object it wants
to mutate.
* If mutation is desired the callback should give a return value.
** Callback may return an array of dom nodes to be used...
** or, callback may return a string that will be used as a selector by
jQuery to find the dom nodes.
As you can see in the code above, it checked if the selector was a
Widget object, since it was it returned a string selector which jQuery
turned into a dom node. In this example the application just organized
it's Widgets in the Widget object with a setup where each Widget had an
id of the widget's id prefixed with widget-.
So I'd like some input on what the desired API is. And any other ideas
of what other functionality people can come up with where application
objects should be handled. Currently I'm verifying that $(myWidget); and
$('div/').appendTo(myWidget); work.
Just to head off anyone suggesting workarounds. I don't post to the dev
list cause I'm interested in alternate less capable ways of doing
things, I post because there is functionality I'm interested in (and
most of the time, willing to help program the implementation for). I
already know you can hack your way around in your own Widget object to
try and create jQuery objects or whatever but that is not what I am
trying to do, I'm trying to make integration of jQuery into applications
easier.
For another note to anyone suggesting a proxy method (overriding
window.jQuery), that does not work. I can confirm that if you try that
technique this:
jQuery(function($) {
$(myWidget);
});
Will not work. And neither will this:
$('div/').appendTo(myWidget);
Because jQuery isolates itself inside of a closure to make sure that
overriding the jQuery method will not break jQuery on it's own from working.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
--~--~-~--~~~---~--~~
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
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: jQuery - Development Environments?
If anyone is interested I just tried experimenting with a little
something.
I installed a ruby file system watcher: http://paulhorman.com/filesystemwatcher/
And setup this small little script:
#!/usr/bin/env ruby
require filesystemwatcher
watcher = FileSystemWatcher.new()
watcher.addDirectory(src, *.js)
watcher.sleepTime = 5
watcher.start { |status,file|
puts Building
`make jquery`
}
watcher.join()
So I basically run it with `./livebuild.rb` inside the jQuery
directory, whenever I make a modification the script automatically
rebuilds the jquery file.
Then again, that jDevCloud idea has much more promise since you can
use trunk, your own get clone, individual jquery versions, and even
edit in-project versions.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
--~--~-~--~~~---~--~~
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
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] Enhancement suggestion: .css(['prop', 'prop', 'prop']);
At work when I was writing my own JavaScript framework (partly inspired
in API by jQuery) I ran into a number of times where I needed to grab a
series of css values and set them all onto another, as a result I ended
up coming up with another type of input to .css;
$(someNode).css(['backgroundColor', 'backgroundImage', 'width', 'height',
'position', 'top', 'left']);
Basically I made .css accept a single array of property names to grab.
The return is a object with property keys and values set on them. The
absolute beauty of this, was that you could take that same object and
set it onto another note, or even use it to revert.
var cssCache = $(node).css(['display', 'width', 'height']);
// Do a bunch of stuff to node that modifies all that kind of css.
$(node).css(cssCache); // Revert to the original values
Though I do take note now, another possibility which might fit in better
with .addClass and .bind might be something like.
$(someNode).css('backgroundColor backgroundImage width height position top
left');
Though the fact that the difference between 'width' and 'width height'
is the difference between .css returning a string or an array, so it
might be worth it to use the array input format to avoid confusion.
Any thoughts? This worth opening an enhancement ticket?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
--~--~-~--~~~---~--~~
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
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] .unbind(func);
When I wrote my framework at work with a .bind method similar to jQuery
I actually ended up adding another simple way to call it thinking jQuery
supported it.
$(node).unbind(); // everything
$(node).unbind('type'); // all events of type
$(node).unbind('type', func); // just the func event on type
$(node).unbind(func); // func on all types; not supported by jQuery
It's another useful call. I actually use it a fair bit at work since
it's about as short as helper methods:
function someClickEventFunc() { ... }
$(node).click(someClickEventFunc);
$(node).unbind(someClickEventFunc);
Worth an enhancement ticket?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
--~--~-~--~~~---~--~~
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
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: .unbind(func);
Originally the lead programmer wanted to avoid making the core of the
application dependent on any specific JavaScript framework. So I ended
up writing a small one. Now we're trying to migrate to one that can be
isolated nicely (jQuery) now that he's gone.
Right now I'm picking at small differences (The framework I wrote was
actually inspired by jQuery) and finding various parts that can improve
jQuery, and things needing extensibility that get in the way of the
ability to cleanly use jQuery inside the app.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Cloudream wrote:
+1
And I wonder why you need your own framework :P
On Sat, Mar 21, 2009 at 6:27 PM, Daniel Friesen
nadir.seen.f...@gmail.comwrote:
When I wrote my framework at work with a .bind method similar to jQuery
I actually ended up adding another simple way to call it thinking jQuery
supported it.
$(node).unbind(); // everything
$(node).unbind('type'); // all events of type
$(node).unbind('type', func); // just the func event on type
$(node).unbind(func); // func on all types; not supported by jQuery
It's another useful call. I actually use it a fair bit at work since
it's about as short as helper methods:
function someClickEventFunc() { ... }
$(node).click(someClickEventFunc);
$(node).unbind(someClickEventFunc);
Worth an enhancement ticket?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
--~--~-~--~~~---~--~~
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
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: .unbind(func);
.unbind() .unbind(type); .unbind(type, func);
Using .unbind(func); seams the most logical since the pattern looks like
you're just ommitting whatever you aren't specifying specifically.
What would *.foo do?
Though as for .bind(*, fn); I don't see how that could really be done.
There are dozens of event types, more being added, then there are custom
and namespaced events.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
John Resig wrote:
I remember someone mentioning something like:
.unbind(*, fn)
It could also apply to other things like:
.unbind(*.foo, fn)
.bind(*, fn)
--John
On Sat, Mar 21, 2009 at 6:16 PM, Daniel Friesen
nadir.seen.f...@gmail.comwrote:
Originally the lead programmer wanted to avoid making the core of the
application dependent on any specific JavaScript framework. So I ended
up writing a small one. Now we're trying to migrate to one that can be
isolated nicely (jQuery) now that he's gone.
Right now I'm picking at small differences (The framework I wrote was
actually inspired by jQuery) and finding various parts that can improve
jQuery, and things needing extensibility that get in the way of the
ability to cleanly use jQuery inside the app.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Cloudream wrote:
+1
And I wonder why you need your own framework :P
On Sat, Mar 21, 2009 at 6:27 PM, Daniel Friesen
nadir.seen.f...@gmail.comwrote:
When I wrote my framework at work with a .bind method similar to jQuery
I actually ended up adding another simple way to call it thinking jQuery
supported it.
$(node).unbind(); // everything
$(node).unbind('type'); // all events of type
$(node).unbind('type', func); // just the func event on type
$(node).unbind(func); // func on all types; not supported by jQuery
It's another useful call. I actually use it a fair bit at work since
it's about as short as helper methods:
function someClickEventFunc() { ... }
$(node).click(someClickEventFunc);
$(node).unbind(someClickEventFunc);
Worth an enhancement ticket?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
--~--~-~--~~~---~--~~
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
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: .animate({prop: 'show'}) to animate set size to natural size
The problem there is that the height there becomes the end height.
show unsets the value after animation. A little more like.
var height = $(this).height();
$(this).hide().css({height: 5})
.animate({width: show})
.animate({height: height}, {complete: function() {$(this).css(height,
);}});
But the idea of natural is that it can be used in more cases.
Basically it's a transition from any set property, to what it would be
like if it was unset.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
John Resig wrote:
We swap the value out to get the value, but don't unset the value - and
that's only for height and width.
What you're talking about can be done like this:
var height = $(this).height();
$(this).hide().css({height: 5})
.animate({width: show})
.animate({height: height});
That looks pretty simple to me!
--John
On Sat, Mar 21, 2009 at 6:18 PM, Daniel Friesen
nadir.seen.f...@gmail.comwrote:
I believe jQuery does it using swap and unsetting the value, right?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com]
-Nadir-Point Wiki-Tools (http://nadir-point.com) (http://wiki-tools.com)
-MonkeyScript (http://monkeyscript.org)
-Animepedia (http://anime.wikia.com)
-Narutopedia (http://naruto.wikia.com)
-Soul Eater Wiki (http://souleater.wikia.com)
John Resig wrote:
And how is the natural height determined if you've already explicitly
overwritten it with another value?
--John
On Fri, Mar 20, 2009 at 9:11 PM, Daniel Friesen
nadir.seen.f...@gmail.comwrote:
At work I tried to animate something to grow horizontally then grow
vertically.
.hide().css({height: 5}) // Use a small initial height so the growing
can
be seen
.animate({width: show})
.animate({height: show});
The second half of the animation of course does not work because show
only animates a non-shown value to it's natural state.
I do not believe there is a proper way (besides doing ugly manual
calculations and basically duplicating some jQuery internal tricks
outside of jQuery) to smootly animate something to it's natural state.
Perhaps we could use something like a new natural option.
.hide().css({height: 5}) // Use a small initial height so the growing
can
be seen
.animate({width: natural})
.animate({height: natural});
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---
