Hi Marcus,
I think the reason for :text is to distinguish it from other inputs.
It's basically a shortcut for input[type=text]. There is no need to
have a filter for text areas because you can simply use the tag name
without ambiguity: $('textarea'). Of course, if you want to select all
te
The idea is for this to work for any event property. I can think of a few
examples where it could be useful in custom attributes, and obviously in key
and mouse events.
-- Yehuda
On Fri, Jan 30, 2009 at 8:55 AM, Matt wrote:
>
> On Jan 29, 8:24 pm, Yehuda Katz wrote:
> > $("p").bind("keydown[key
Hello. I was doing some form validation today and I noticed that
there's no filter for text areas. The :input filter includes it
but :text excludes it and it doesn't have a filter of it's own.
Personally I think that :text should include text areas and barring
that, there should be a filter for te
Hi folks,
I have a large HTML fragment that I load via AJAX. The fragment is big
(~660KB),
and it takes over 2s (more like 2.7s) to insert it.
I've profiled the code, and it turns out that most of the time is
spent in the .trim()
function. It is being called from .clean() (around line 835):
Hey all,
Nice meeting you guys at Kilowatt yesterday.
I seem to have run across a bug in 1.3.1:
$("abc").contents().is("[nodeType=3]")
returns true as expected, but
$("abc").contents().filter("[nodeType=3]").length == 1
returns false, due to a nodeType === 1 check in $.fn.filter but not in
$
It is now. I later found out that the .append again doesn't chain that
way as one might expect.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com]
-Nadir-Point (http://nadir-point.com)
-Wiki-Tools (http://wiki-tools.com)
-MonkeyScript (http://monkeyscript.nadir-point.com)
-A
>
> Ok, this does work:
>
> var list = ['foo', 'bar', 'baz'];
> var ul = $('#myul');
>
> list.forEach(function(data) {
> ul.append($('')).text(data);
> });
>
Surely that is:
var list = ['foo', 'bar', 'baz'];
var ul = $('#myul');
list.forEach(function(data) {
ul.append($('').text(data)
I'm not a fan of appendTo, in a case like this to me it looks like
reading code backwards, rather than nicely nesting.
Ok, this does work:
var list = ['foo', 'bar', 'baz'];
var ul = $('#myul');
list.forEach(function(data) {
ul.append($('')).text(data);
});
The extra $() call isn't bad, it'
You can't have two instances of those and elements. The
> Also this may have nothing to do with the original problem above I
> believe it is quite a big issue that must be addressed !
Well, this has to do with caching results for some selectors (with
deep selectors like "div p", for example). It's not really clear where
they should be managed - but th
Heh, that's fun - do you have a sample page?
--John
On Fri, Jan 30, 2009 at 8:20 AM, ajp wrote:
>
> ... happens with LINK elements too.
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development"
Daniel Friesen ha scritto:
>
> So for that example:
>
> var list = ['foo', 'bar', 'baz'];
> var ul = pf('#myul');
>
> list.forEach(function(data) {
> ul.append('li').text(data);
> });
>
>
> So the question is, "How does one do something like this in jQuery?"
var list = ['foo', 'bar', 'ba
>
> ul.append($('li').text(data));
>
I mean:
ul.append($('').text(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.c
Hi,
I think:
ul.append('li').text(data);
Should be written as:
ul.append($('li').text(data));
Or does that qualify as "being required to run another method"?
Hope it helps,
Kelvin :)
On Fri, 30 Jan 2009 13:44:08 -0800, Daniel Friesen
wrote:
> What is the accepted method of dom manipula
What is the accepted method of dom manipulation in jQuery (creating and
inserting new dom nodes).
I can't seam to find a reasonably intuitive method of doing this using
jQuery internals.
A good example. Given a jQuery object which contains a ul tag. How would
one insert a new li tag, and then
It appears that (testing 1.3.1) ":disabled" selects disabled form
elements, regardless of if they are hidden. As one would expect
(based on intuition and current jQuery docs).
The result is that ":disabled" is NOT the complement of enabled.
":disabled" -- select elements that are disabled
":en
'cause jQuery doesn't support that syntax. That would be $
('[class^=WasPrice]')
http://docs.jquery.com/Selectors
On Jan 29, 8:18 pm, rhasson wrote:
> you know I feel like a total idiot. I searched and searched about
> special characters and stuff and never stopped to think twice.
>
> but the
That is confusing.
The documentation currently says just "Matches all elements that are
enabled."
At the very least we should amend the documents, else this will be a
source of pain for many.
What is the behavior of ":disabled", Does it select enabled inputs
that are hidden?
Cheers
--~--~---
Done: http://dev.jquery.com/ticket/4033
Jörn
On Fri, Jan 30, 2009 at 7:17 PM, Brandon Aaron wrote:
> I'm fairly certain we normalized this in pervious versions. Definitely a
> regression. Might want to file a ticket so it doesn't get lost on the list.
> --
> Brandon Aaron
>
> On Fri, Jan 30, 20
I'm fairly certain we normalized this in pervious versions. Definitely a
regression. Might want to file a ticket so it doesn't get lost on the list.
--
Brandon Aaron
On Fri, Jan 30, 2009 at 11:51 AM, Arrix wrote:
> I'm not sure whether jQuery used to fix currentTarget for IE but I think
> it's n
Fixing currentTarget isn IE isn't really a problem at all, that isn't
limited to the onxxx-model.
Jörn
On Fri, Jan 30, 2009 at 6:51 PM, Arrix wrote:
> I'm not sure whether jQuery used to fix currentTarget for IE but I think
> it's not an easy task.
> The only way I know to get the currentTarget
I'm not sure whether jQuery used to fix currentTarget for IE but I think
it's not an easy task. The only way I know to get the currentTarget in IE is
to use this keyword, which is only available in the ele.onxxx = func model.
On Sat, Jan 31, 2009 at 12:53 AM, Jörn Zaefferer <
joern.zaeffe...@googl
Matt,
I didn't recall correctlytoo late in the night one can dream
whatever...
Thank you for reminding me and adjusting my wrong assertion.
Diego
On 30 Gen, 17:49, Matt wrote:
> On Jan 29, 3:50 pm, Diego Perini wrote:
>
> > None of them specify if the field would be submitted or not, if
On Jan 29, 8:24 pm, Yehuda Katz wrote:
> $("p").bind("keydown[keyCode=119]", function() {})
Could you also just redefine 'keydown' as a plugin?
$('p').keydown( 119, function(){} );
or
$('p').keydown( [119,120,121], function(){} );
or
$('p').keydown( 'enter', function(){} );
etc.
Matt Kruse
--
It looks like a regression to me: $.event.fix doesn't add
currentTarget to the event object, which is missing in IE. Is that a
regression? Or is there a reason it isn't added?
Jörn
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the G
On Jan 29, 3:50 pm, Diego Perini wrote:
> None of them specify if the field would be submitted or not, if I
> recall correctly all of the form elements values should be serialized
> and submitted, "enabled", "disabled" and "hidden".
Disabled form elements are not submitted.
Matt Kruse
--~--~--
... happens with LINK elements too.
--~--~-~--~~~---~--~~
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 ema
I looked at AOL's AXS library very briefly a while ago and it does
something similar to this. Might be worth glancing over for ideas:
http://dev.aol.com/axs (specifically axs.keyreg).
On Jan 29, 9:24 pm, Yehuda Katz wrote:
> I brought this up a while back and I think it was well-received. I'd
I created a local html doc to be pulled in through load(). It has a
style element - FF and IE apply the new styles, but Safari won't if
the style is in the head. So I got rid of the html, body, and head
tags so (this is still valid HTML). Now Safari applies the styles on
load.
Now if I iterate th
Oliver,
I think you misunderstood what he said.
All you need to do is include jquery in every page by putting the
tag in the html under your script tag for your gwt application. I presume
this is either in an html file somewhere or part of an html template. Just
modify the html to include jquery
I quite like the sound of the keydown[enter] style events. I wonder thought
does it have much use outside of key events? I suppose mousedown/up could
specify the button that was clicked? The reason I ask is perhaps rather than
potentially changing the syntax of the event binding calls you co
This may seem close-minded, but I tend to think the need to delete a
node from the DOM and hold onto that exact node the way it was when it
left the DOM in the event that exact node needs to be re-inserted is
kind of a specific implementation that shouldn't be handled natively
by .remove(). I've
maybe a few jquery event shortuts to specific keycodes/ranges of
keycodes, which would provide a meaningful semantic layer, as opposed
to further entrenching the spread of ranges of valid numeric keycodes
into our jquery events
$(...).bind("keydown[enter] keydown[numeric]",fn)
or maybe even simp
Jacob -
We made this change to become more standards compliant (the browsers
that supported querySelectorAll interpreted :enabled in this manner -
assuming that a hidden element was always not enabled).
--John
On Thu, Jan 29, 2009 at 10:48 AM, Jacob wrote:
>
> In a normal form POST, a form e
34 matches
Mail list logo
