[jquery-dev] Adding in support for 'focus' and 'blur' events using .live and .die

2009-08-06 Thread treshug...@gmail.com

Hey guys,

I know about .livequery, but it didn't work for me. As a result, I
wrote a plugin called bond (uses .bond and .unbond) that implements
event delegation for 'focus' and 'blur' and works with *any* valid
selector. The only downside is that I have to use a plugin to achieve
this functionality. Shouldn't something like this go into the core?

Code: 
http://groups.google.com/group/jquery-dev/browse_thread/thread/3b3731308f23cbb6

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 [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---



[jquery-dev] event delegation

2008-10-24 Thread treshug...@gmail.com

I was wondering if event delegation was going to make it into the core
anytime soon? Rebinding events can get tedious and make for more code
than should be necessary. This would really put jQuery ahead of most
of the other libraries also.

If nothing is planned, I might see if I can gracefully integrate this
into the core.

Any ideas, suggestions, questions, comments?

Thanks,
Trey
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---



[jquery-dev] Re: Proposal: Attributed events

2009-01-31 Thread treshug...@gmail.com

I agree with Flesler. jQuery is designed to abstract things such as
this.

I actually do have a plugin that allows a syntax easier than this.
It's name is Keys and you can find it on the jQuery plugin site or at
http://shugartweb.com/jquery/keys.

It allows syntax such as $('input').keys('tab, space + [109]', function
() {
// do something
});

The above would fire the callback whenever 'tab', or 'space' + key 109
is pressed on any input field.

I really would like some feedback on this plugin and would love if
someone wanted to collaborate on further releases. I wrote it awhile
ago so I am intending to do a code overhaul on it.

Cheers,
Trey





On Jan 31, 11:06 pm, Ariel Flesler  wrote:
> The idea is nice, but I think is quite out of the core's scope.
> There're already +1 hotkey plugins and they work nicely.
>
> This syntax could be proposed to these plugins' owners.
>
> --
> Ariel Fleslerhttp://flesler.blogspot.com
>
> On 30 ene, 03:24, Yehuda Katz  wrote:
>
> > I brought this up a while back and I think it was well-received. I'd like to
> > get some feedback on this proposal again before putting any work into it.
> > The basic idea is:
>
> > $("p").bind("keydown[keyCode=119]", function() {})
>
> > It's basically a shortcut for:
>
> > $("p").bind("keydown", function(e) { if(e.keyCode == 119) { } })
>
> > I'd imagine it'd work with other operators (>, <, !=), and use literals
> > (true, 119, 'string'). I'm not 100% sure yet how to implement it without
> > eval, but it should be doable (would probably require a simple literal
> > parser, but that's fine with me).
>
> > --
> > Yehuda Katz
> > Developer | Engine Yard
> > (ph) 718.877.1325
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---



[jquery-dev] Re: Proposal: Attributed events

2009-02-01 Thread treshug...@gmail.com

I also want to say, sorry for the poor documentation. It is a site
that I have recently started messing around with and will hopefully
get around to finishing sometime.

In the meantime, if there are any questions, please feel free to
contact me.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---



[jquery-dev] Re: Put JS at the bottom

2009-02-08 Thread treshug...@gmail.com

Putting your js at the bottom of the page is essentially the same as
putting it in jQuery(function() {}), or .ready. The Yslow plugin
doesn't take into account that you are using jQuery and are
implementing the ready event. I have run a couple of tests for the
software company I work for and have found no noticeable impact either
way. I have however, compiled and minified the scripts into one file
and it increased performance ten-fold. Since it has a .js extension,
it can be cached by the browser.

Trey



On Feb 9, 6:13 am, bobspryn  wrote:
> I recently switched our app's javascript to include at the bottom of
> the page as we're taking many steps to increase front-end performance,
> primarily based on Steve Souders suggestions (of YUI fame).
>
> I've decided that at the moment we don't have enough javascript to
> worry about this step. By putting it all at the bottom, you see a
> flash of our web 1.0 features, which we enhance with javascript (so
> that they still work if you flip javascript off.) This means 5-star
> ratings show up as radio buttons for a split second, among a bunch of
> other similar features, before the javascript loads and does what its
> supposed to.
>
> So I'm going to move the javascript back to the top, since most of the
> features are in ready() blocks anyway.
>
> Best,
> Robert
>
> On Feb 7, 2:25 pm, Kevin Dalman  wrote:
>
> > You can accomplish *some* of the same goals of putting JS at the
> > bottom by using 'defer', like:
>
> > 
>
> > This does not defer script 'loading' in all browsers, but does defer
> > 'execution', which can noticeably improve performance in some cases.
>
> > Here is a good summary of how defer works...
>
> >http://www.websiteoptimization.com/speed/tweak/defer/
>
> > /Kevin
>
> > On Feb 7, 7:55 am, weepy  wrote:
>
> > > The Yslow plugin by Yahoo suggests putting Javascript at the bottom of
> > > the page.
>
> > > Do the jQuery devs recommend the same ?
>
> > > weepy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---



[jquery-dev] Re: Put JS at the bottom

2009-02-09 Thread treshug...@gmail.com

Good point, Mar. Users will judge a site within a fraction of a
second. If the page seems unresponsive for that long, it can't fare
well.

Pages can 'seem' to load faster if scripts are put at the bottom due
to the fact that it prevents progressive rendering (which is a good
side effect of putting CSS at the top) and parallel downloading.
Because the http 1.1 spec suggest that a browser will only download 2
components at a time, the fewer http request the better.

Cheers.


On Feb 9, 10:53 am, Már Örlygsson  wrote:
> > Putting your js at the bottom of the page is essentially the same as
> > putting it in jQuery(function() {}), or .ready. The Yslow plugin
> > doesn't take into account that you are using jQuery and are
> > implementing the ready event. I have run a couple of tests for the
>
> Actually, YUI has quite an advanced document.ready event model, and
> YUI developers use it a lot. I'd only assume YSlow not only knows
> about ready events, but *assumes* you're using them.
>
> As I understand it, "JS at the bottom" is recommended because it
> allows for faster HTML, CSS and image rendering - making pages *look*
> faster - which research purports is important for the user experience.
>
> - Combining all javascripts into as few HTTP requests as possible
> helps. (a lot!)
> - Employing a lightweight library (yay jQuery!) and slim javascript
> modules helps.
> - Using the document.ready event helps.
> - HTTP caching helps.
> - Placing javascripts at the bottom helps too.
>
> It's just one of many factors - and probably not the single biggest
> one - especially if all the others are taken care of.
>
> There are a few tricks available to suppress the "flash of web 1.0
> content and ui".
> One that I perfer, is to load a tiny 

[jquery-dev] Re: There must be a better way !

2009-02-11 Thread treshug...@gmail.com

Klaus is right.

I know older versions of IE (< 6) have had issues with this.

The W3C CSS 2.1 specifically states that quotes are optional (http://
www.w3.org/TR/CSS21/syndata.html#uri).

IE always was and always will be a leper, it's just too bad it hasn't
died yet.

-Trey
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---



[jquery-dev] Re: There must be a better way !

2009-02-13 Thread treshug...@gmail.com

As Klaus said, it isn't a bug. It is just how a browser will
'normalize' the html. And actually, we're talking about CSS. CSS 2.1
to be exact, and as I pointed out, the W3C specifically states that
quotes are optional. Therefore, a browser can normalize the quotes
however they want. That being said, it can really suck when a browser
- *cough*, IE - does that . When returning the inner html (.html
()/.innerHTML) of an element, IE won't return valid HTML in accordance
to the given doctype. It will return html with tags represented in all
caps and no quotes around attribute values.

-Trey

On Feb 13, 6:38 pm, Klaus Hartl  wrote:
> On 13 Feb., 01:03, weepy  wrote:
>
> > I would still expect that the string you get back from the dom would
> > be valid html.
>
> Where is that invalid HTML?
>
> --Klaus
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---



[jquery-dev] Re: Forcing an event handler to be the first handler

2009-02-14 Thread treshug...@gmail.com

Although I don't have a solution for you, whenever I am posed with a
situation like this, there is always a better way to approach
something. If I ever find myself about to implement a hack or
workaround, I stop and think, "Is this really necessary?" Sometimes it
is, but most of the time a better solution is reached by taking a
slightly different approach to the situation.

My two cents.

-Trey



On Feb 15, 12:59 am, Diego Perini  wrote:
> Scott,
> what I said above is incorrect, in that way it is obviously impossible
> to stop a "click" event to happen from a "mouseup" handler on the same
> element.
>
> However I looked back at how I did it and realize I removed the
> "click" event handler before it happen:
>
> 
> 
> 
> 
> window.onload = function() {
>   var element = document.getElementById('tester');
>
>   function logandstop(event) {
>     if (event.type == 'mouseup') {
>       if (element.removeEventListener) {
>         element.removeEventListener('click', logandstop, false);
>       } else {
>         element.detachEvent('onclick', logandstop);
>       }
>     }
>     top.status += ' * ' + event.type;
>   }
>
>   if (element.addEventListener) {
>     element.addEventListener('mousedown', logandstop, false);
>     element.addEventListener('mouseup', logandstop, false);
>     element.addEventListener('click', logandstop, false);
>   } else {
>     element.attachEvent('onmousedown', logandstop);
>     element.attachEvent('onmouseup', logandstop);
>     element.attachEvent('onclick', logandstop);
>   }};
>
> 
> 
> Click me !
> 
>
> For the same "order" reason I gave in my previous post (mousedown
> mouseup click) this will work cross-browser (tested FF3, IE6, Opera
> 9.6 & Safari 3.2). The "click" event is not fired and the order in
> which the three handler are registered does not change the results.
>
> I should add that in some cases I have also used an element overlay
> technique similar to the one you described, to separate events on
> different elements.
>
> Diego
>
> On 14 Feb, 03:10, Diego Perini  wrote:
>
> > Scott,
> > if I recall correctly, the solution to this maybe in the way the click
> > event works.
>
> >   click = mousedown + mouseup
>
> > if you setup three handlers, one for each of the above events you
> > should see them fire in this order:
>
> >    mousedown - mouseup - click
>
> > Don't use the alert() to show them they may appear in the wrong order,
> > use top.status...
>
> > Now (to cover different browsers) insert these lines in the "mouseup"
> > handler:
>
> >    event.stopPropagation();
> >    event.preventDefault();
>
> >    event.cancelBubble = true;
> >    event.returnValue = false;
>
> >    return false;
>
> > The "click" event shouldn't happen then.
>
> > One or more of the above lines shouldn't be necessary but while
> > testing you can leave them all, I really can't remember very well in
> > this moment...I suggest you try this first with native methods on FF
> > and see the result compared with those you can get with jQuery.
>
> > Let me know if I did understand your problem correctly. The above
> > seemed weird to me at first but there are reasons to it, so a quick
> > test will hopefully take you out of doubts...or put more on me... :-)
>
> > Diego
>
> > On 13 Feb, 22:14, Scott González  wrote:
>
> > > Not being able to guarantee the order does make this tricky.  At least
> > > for now, I'm just looking for something to improve our reliability in
> > > UI, even if we don't provide this as a guaranteed method for putting
> > > your handler at the top of the stack.
>
> > > As for why we want to do this, we're modifying the defined behavior
> > > that browsers provide.  The draggable plugin provides non-native
> > > functionality and creates non-native events.  In addition to creating
> > > new events, we believe that modifying the existing event system is
> > > beneficial.  So if you mousedown and mouseup on a draggable element
> > > without dragging, then you should get a click event and no drag
> > > events.  However, if you do drag, you should get all of the drag
> > > events (dragstart, drag, dragstop) and not get the click event, since
> > > you performed a drag not a click.
>
> > > Since we can't actually prevent the click event from being triggered,
> > > the best we can do is cancel the click event as soon as it's
> > > triggered.  While writing this last sentence I had an idea that we
> > > could throw a transparent div over the draggable as soon as dragging
> > > starts.  This would cause the mouseup to occur on a different element
> > > than the mousedown and should prevent the click event altogether.
>
> > > On Feb 13, 10:07 am, Brandon Aaron  wrote:
>
> > > > Before we can answer that, we need to answer this question:
>
> > > > Are we, as a library, guaranteeing the order of events as part of our 
> > > > API?
>
> > > > The spec and browsers do not guarantee the order of events and our 
> > > > ordering
> > > > is more a side-affect of how we currently

[jquery-dev] ajax not posting

2009-02-24 Thread treshug...@gmail.com

http://dev.jquery.com/ticket/4239

I've created a ticket for this.

Anyone else experience this?

-Trey
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---



[jquery-dev] Structure Plugin Authoring

2009-03-04 Thread treshug...@gmail.com

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 [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---