That's a lot of stuff!
Seriously, I think that what is being requested here, more than anything
else, is organization.
Can we start grouping our code into "plugin packs", or something? One for
forms and friends, one for all kinds of visual effects (perhaps a package
that groups the "best of the
That's fixed in the current SVN version. The problem is that you have
elements that don't have an ID. The recent fix prevents the ^= operator
from choking in that case.
- Brian
> I tried to assign an id 'checkbox' to the checkbox in the example.
> Using not('[EMAIL PROTECTED]') result in js er
Create an empty object, pass it to the .each() block, and add each id as a
property of it as you go.
My first crack (which is probably hopelessly b0rked, but may get the point
across...):
var myInputs = {};
function sliderCallback { myInputs[this.id].rangeEl =
$(this).siblings().filter("input.ran
I'm inclined to disagree.
I believe that one should use object detection for cases in which they are
invoking that object for it's functionality. A prime example is the XHR
(although MS may be messing around with that in IE7).
But, if one is best served by simply knowing what browser we are deal
- Brian
> On 09/10/06, Brian Miller <[EMAIL PROTECTED]> wrote:
>> I'm inclined to disagree.
>>
>> I believe that one should use object detection for cases in which they
>> are
>> invoking that object for it's functionality. A prime example is the
You can't use ajax to send files. It's not supported because it's not
permitted.
The libraries that do it (e.g. Yahoo UI) create a hidden iframe on the
fly, with a form inside the iframe (that has a file upload control), which
gets submitted. It's as much of a pain as it sounds like it is.
Othe
Yes, $(document).ready() should only happen once - when the document is
first ready. What you're using for "magic" would infuriate developers on
most other projects! :)
You should have a separate function for an ajax callback to do whatever
you're doing, even if it's the same code, and you're re
see the current script.
It's big, but probably not that bad when packed (although, you might have
to lint it and pick out the little things for it to pack successfully).
- Brian
> On 09/10/06, Brian Miller <[EMAIL PROTECTED]> wrote:
>> Sam, if that's a problem with your use
This is a case where we need to "reveal sudden cleverness". I suggest
that if "return false" is the way to go (and, I do like it), then we
should make sure that if the logging plugin is used, or if the user is
using firebug or the MS deubgger at all, that there is a message in the
log clearly when
I think that there's a simpler answer to this.
If we're going to overhaul the API that much, we need to do three things.
1. Talk it out thoroughly, and make sure we get it "right" this time.
2. Publish a new full release of jQuery (2.0).
3. Put all of the "breaking changes" at the top of the READ
Keep in mind that the namespacing that I'm suggesting is solely for
readability, and should only be used where it makes things more readable.
You're right that it might put some bumps into the chaining, but I think
that making the calls non-colliding and more natural-language-y outweighs
that.
e.
Which begs the question: Why NOT generate a nightly build? It should take
all of 5 minutes to edit the crontab to make it happen. :)
> Not nightly, but updated now and then: http://jquery.com/src/jquery-svn.js
>
> -- Jörn
___
jQuery mailing list
disc
While it's not very jQuery-like, timers lend themselves to registration.
I would attach an object to window or a more permanently/easily available
object. This way, you don't have to leave closures around just to keep
references to the timers, just so you can stop them later.
Also, if you're att
Two thoughts:
$( '* > dt', context );
OR
Just put an ID on the particulat dl that you want to use as the context. :)
$( dl#foo > dt );
- Brian
> Hi jQueryians,
>
> how do I search for a children within a context?
>
> In other words, how to translate this:
> $(context).children("dt")...
> in
Perhaps you're right. But, in the mean time, you could always use
$('label').siblings().find('input,textarea').addClass('blah');
- Brian
> Hey, this is my first post to discuss@ and I'm new to jQuery though
> I'm loving it. I don't know if this is a bug or not...
>
> Shouldn't $('label').sib
Personally, I'd rather use a div or span for that sort of thing, rather
than a tag.
accordion:false,showSpeed:'slow',hideAll:true
Then, style div.accordion_init to be hidden, and you get the same effect
without "misusing" the tag.
- Brian
> Which would work on some markup like this:
>
> acco
on, was to include a script tag
that only defined an object for containing the parameters. That might be
a bit cleaner and easier.
- Brian
> Brian Miller schrieb:
>> Personally, I'd rather use a div or span for that sort of thing, rather
>> than a tag.
>>
>>
Keep in mind that there are characters allowed in classes that are not
allowed in the CSS spec for selection of classes. In other words, if you
include a paren or a bracket in a class, it can't be styled. Therefore,
you can use it for script, without worrying that someone will accidently
style ov
In the original discussion about validation, I had suggested using "label
for=" as a way to associate validation with form elements, while making
the notation semantically separate from the form element. It would be
great to do that for other elements, but I'm pretty sure that the HTML
spec calls
Darius,
$= means "attribute ends with". Check out
http://jquery.com/docs/Base/Expression/CSS/ , the "Supported, but
different" section.
Taking a close look at the selection documentation might also help you
with item #2 a bit.
You're going to have to figure out how to text-match your relative U
I second that notion! Please create a "contrib" or an "incoming" branch
in SVN, and allow anyone to drop plugins in there. A bunch of us can take
turns vetting the plugins to make sure that they're not spam or crap.
- Brian
> Rey Bango wrote:
>> Hi Dan,
>>
>>> Still, I suppose if you make enou
One thing you can do is not use "disabled" at all.
If you decorate the control like it's disabled, and leave it with an ID
(so jquery can find it) but no name, it will be an "unsuccessful control",
and won't send. If someone enters something in the field, you can use
$('myinput').attr('name', 'my
Personally, I'm noticing a lot of requests for XML namespace selection in
the parser. Can we get that into 1.1? Apperently, making $('myns:div')
would raise holy hell because it would clash with the pseudos, but
$('myns|div') might be doable.
Can we make $('myns:div') work if there's no pseudo m
I'm not suggesting bloat here, Rik. I think that, at the very least,
support for $('myns|whatever') is core stuff, and is doable without a lot
of code. Since it's about the basic functionality of selection, I think
that it's one of the few things that *shouldn't* be a plugin.
I won't have time t
>> how about if they ask for xml in ie and they don't get it..., JQ trys
>> to parse the 'xml' and then proceed normally the xml ajax
>
> Yeah... that's not happening. That'll be at least a couple extra KB of
> code for something that's relatively minor. Unless someone comes up
> with a solution t
The solution is actually relatively simple. If enough people who depend
on the software request it, they'll give it more consideration. It's easy
to rebuff one person. It's harder to to that to a larger chunk of the
user community.
What I would do to start, though, is answer his points directly
Is this patch generalized enough to add to the core? Just a thought...
- Brian
> John Resig schrieb:
>> Unfortunately, the hack to work around that is too monstrous to
>> comprehend. For now, it works fine in Safari for most cases, and
>> that's what matters.
>
> That is exactly the problem I ha
How about overriding $.end() in the grid plugin, so that it returns the
original jquery object if it's run on the grid controller?
Of course, you'd have to remember to make $.end() behave normally if run
elsewhere. Or, you could just create an $.endGrid() function for the
controller, and not worr
Heh, I should have read this first, before suggesting it myself. *blush*
- Brian
> On 01/12/06, Christof Donat <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> > Controller set of methods is returned..
>> >
>> > $('#grid').grid().data(data).drig().show()
>> > $('#grid').grid().scrollToRow(6).drig().css("
The "id" and "name" attributes must always be unique on a form. It's
breaking because you made them the same. They *must* be different, even
if they are on different forms.
- Brian
> hi,everyone
> I find use jQ, one page have two form, but the form id is diff. i find
> $(form_id).ajaxSubmit(op
Oops!
I guess I jumped the gun a little, thanks for clearing that up. I
actually knew that, but I responded without thinking it through...
- Brian
> On 04/12/06, Brian Miller <[EMAIL PROTECTED]> wrote:
>> The "id" and "name" attributes must always be
Hey, don't look at it as "us vs. them". One of the great things about
jQuery is that it plays well with others. I use them together for a bunch
of things, and there's no reason why you can't introduce it for tasks
where it's well suited.
After all, isn't "Web 2.0" all about mashups? :)
Good lu
Relax, Anrdea. :) Lots of things get lost in mailing lists.
The style is very good. There's a lot to like about it. I do have some
suggestions, though.
1. You should probably measure out the screen of the browser
(dimensions.js can help here), and expand the windows to use more of the
availab
You know, we see this request a lot.
John (or somebody), can you cron-job a nightly build?
I don't want to be pushy or anything, but I think that would make a bunch
of people very happy.
- Brian
> well, http://jquery.com/src/jquery-svn.js is not the current version
> (that's the problem).
>
>
Keep in mind that Bob Ippolito is a Python guru, and he specifically wrote
mochikit to make JS behave a bit more like Python. To him, any language
sucks if it uses C-family idioms. :)
We can choose to be more positive, using a phrase like, "Makes programming
Web 2.0 fun!" Or, something.
- Bria
I think that the reloadandbind call may be creating a closure that you're
not intending. But, that's just me looking at the code for 5 minutes, I
might not be seeing it straight.
Also, it's a bad idea to stick custom js objects onto DOM objects -
specifically "bigString". It causes conflicts bet
Thinking of a jquerish solution...
What if we used a $.ajax() call to pull out the web display of the plugins
branch from SVN, and stick it in a div on the plugins page?
If nobody does it, maybe I'll take a crack at it today or tomorrow.
- Brian
> Yep, this is in the works. Unfortunately, it's
$(':visible', this).length == 0 (Or 1, if the root of the context is
returned, which I'm not sure of.)
Note: This will be kind of inefficient if you're working with a big DOM tree.
- Brian
> Hello all,
>
> How can I check if a given element is visible or not (i.e. has
> display:block).
> I hav
> looking for an ID (which should be unique) after getting the tags is
> worthless.
Should we re-write the case of # to use elem.getElementBYId(),
and then remove the element if it's not the right tag?
- Brian
___
jQuery mailing list
discuss@jquery.co
This strikes me as a task where creating new elements may be less
gremlin-prone than cloning.
Michael Geary's "Easy DOM Creation" plugin might make it easier to write a
function that creates the appropriate DOM tree branch.
http://mg.to/2006/02/27/easy-dom-creation-for-jquery-and-prototype
- Bri
It hasn't worked since the one time that you forced it (around r1485 or so).
- Brian
> I think he means with the builds being generated. I think it's having
> problems building the right builds, again.
>
> --John
>
> On 3/29/07, Brandon Aaron <[EMAIL PROTECTED]> wrote:
>> What kind of problems a
"Gaah! My eyes!"
Classic! I'm still giggling.
- Brian
> That page with the email animations is awesome! It's like a web Chamber
> of Horrors :-)
>
> I think you won that comments debate.
>
>
> Paul Caton.
>
> ___
> jQuery mailing list
> discuss@jque
jazzle,
You're going to have to code your way out of this one. Ultimately, you
need to write an onClick or onChange event that looks at the other
checkboxes to see if they are checked, and determine what to do from
there.
Here's a thought (off the top, untested):
$('.noneorone:checkbox').bind('c
You can comma-delimit the selector, so you can package up all the td
elements you're looking for into one $ function.
Also, if you limit your context (to, say, the table in question), it'll
help speed things up.
mytable = $("#mytable");
FlexCells = $("[EMAIL PROTECTED]" + ShiftDate + "], [EMAIL P
ndColor#";
> }
>
> FlexCell = $("[EMAIL PROTECTED]" + ShiftDate + "]");
>
> FlexCell.removeClass("CalendarCellDisabled").addClass("CalendarCellEnabled").attr("state",
> "Enabled").css({background:BackgroundColo
Is it this?
http://meyerweb.com/eric/thoughts/2004/09/16/when-browsers-attack/
- Brian
>> > IE6 freezes, and I need to kill the proccess. After that, I visited
>>
>> Damn, it sure does. I'll have a look at it Juan.
>>
>
> Interesting. It's this call that causes the problem:
>
> var h = jQ
This might be a better one:
http://www.cameronmoll.com/archives/000892.html
- Brian
>> > IE6 freezes, and I need to kill the proccess. After that, I visited
>>
>> Damn, it sure does. I'll have a look at it Juan.
>>
>
> Interesting. It's this call that causes the problem:
>
> var h = jQuer
You know... The folks over at Mootools refer to theirs as "Mootorials".
Maybe we should call them "jQ-torials"? :)
- Brian
> Hello dear friends,
>
> Just a quick note to announce that Brandon Aaron -- regular
> contributor to this list, member of the jQuery development team, and
> plugin auth
Believe it or not, this isn't incredibly bad.
One thing you should do is search for things by ID using the ID only.
It's actually a bit faster. If you want to remind yourself of the tag
type, put in a comment after the line.
Another thing you can do to make this a bit cleaner is to use a comma
Thank you! Thank you! Thank you! :)
- Brian
> This is a re-post of a blog post written by Paul McLanahan:
> http://jquery.com/blog/2007/02/13/jquery-nightly-builds/
>
> Hey Everyone -
>
> After much wailing and gnashing of teeth, we now have automated
> nightly builds of jQuery ready
Here's the thing.
jQuery, along with plugins, covers a lot of what other libraries do. I
just went looking around in dojo and YUI, and while one can do most of
what they do by combining plugins, what's missing is the kind of
bullet-proofing that people Alex Russell and Eric Miraglia have gotten
i
Actually, I think that the best thing to do would be to detect what the
browser has, and use whatever's there transparently. If Canvas is there,
use it. If not, try SVG. If there's no SVG, try VML. If there's no
suitable graphics system in the browser, signal the user to download and
install a
Ideally, there should eventually be one selector base that uses the best
methods of both jQuery's selector engine and DomQuery. That way, there's
no longer an issue of which one is used.
- Brian
> Hi Rajesh,
>
> Were investigating the possibility of supporting the use of DomQuery,
> Exts sele
s. And if you value speed above all else, you might produce a
> fairly large, blazing library. We're looking at these issues to try and
> come
> to a conclusion that will benefit the jQuery community.
>
> -- Yehuda
>
> On 2/20/07, Brian Miller <[EMAIL PROTECTED]> w
I need to replace a whole lot of elements on a page
with elements. (I have limited control over how the fields are
generated.) The contents of the form fields must remain - I just want to
change the "shape" of the field to make it bigger and allow multiline
input.
What would be the best/terses
t;" + cuurentValue +
>> ";
>> this.remove
>> ();
>> });
>> So this would destroy the input and replace with textarea.
>> There might be a better way, but I "think" this should work.
>>
>> Glen
>>
>>
>>
>> On 2/2
Is all your of your main code in a ready block? Just a guess, but it
might be trying to operate on the DOM before it's loaded.
- Brian
> Hi there, I've got a really odd problem with the interface plugin. The
> thing is that when I go to the specific site that uses Interface
> theres no problem,
It's hard enough to get everything working properly for documents that are
well-formed. I don't think that it's worth the effort to force
consistency in how jQuery handles broken documents. If you do anything on
top of an invalid DOM, you can't make the results predictable. Even if
you could, th
I see what you're saying. You're worried that because there's a
difference here, there might be a differnce in a non-broken document that
we haven't found yet.
Personally, I wouldn't worry about it until/unless there's an actual use
case that's having this same problem on a non-broken DOM.
- Bri
Given that it would be Jack's call, I'd say no. Ext has a very Java-like
OO design. It would be hard work to squeeze what he's doing into jQuery
calling conventions.
That doesn't rule out Jack surprising us and doing all that work anyway.
But, that's not where I'd put my money if I were a betti
I second this suggestion. Most other meta-languages allow
backslash-escaping, I don't see why it would be a bad idea here.
- Brian
> I didn't like the idea of hacking jQuery to make selectors with these
> special chars work, but as it turned out, that is what should be
> expected! From the CSS
Plugins should still be *announced* here, though, so the people who don't
subscribe to the plugins mailing list know that they exist. :)
- Brian
> Hi everyone,
>
> It seems the new place to post plugin-related stuff is in the plugins
> mailing list ([EMAIL PROTECTED]). I didn't even know about
62 matches
Mail list logo
