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@jquery.com
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 are you
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
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
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
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,
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.
-
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,
.
There might be a better way, but I think this should work.
Glen
On 2/23/07, Brian Miller [EMAIL PROTECTED] wrote:
I need to replace a whole lot of input type=text elements on a
page
with textarea elements. (I have limited control over how the fields
are
generated.) The contents of the form
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
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] wrote:
Ideally, there should eventually be one selector base
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
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
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 for
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
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 author --
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 =
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 =
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
:#someColdFusionVar#});
}
I don't know the ShiftDates ahead of time, nor how many there will be.
Can I still apply you possible solution?
Thanks,
Chris
Brian Miller wrote:
You can comma-delimit the selector, so you can package up all the td
elements you're looking for into one $ function.
Also
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
-
looking for an ID (which should be unique) after getting the tags is
worthless.
Should we re-write the case of tag#id to use elem.getElementBYId(),
and then remove the element if it's not the right tag?
- Brian
___
jQuery mailing list
$(':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 have
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
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.
- Brian
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 luck
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 unique on a form. It's
breaking because you made
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
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(border, 1px)
A
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 have. So I
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
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
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
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',
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 enough examples
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
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 URL
Personally, I'd rather use a div or span for that sort of thing, rather
than a code tag.
div
class=accordion_initaccordion:false,showSpeed:'slow',hideAll:true/div
Then, style div.accordion_init to be hidden, and you get the same effect
without misusing the code tag.
- Brian
Which would work
, 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 code tag.
div
class=accordion_initaccordion:false,showSpeed
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
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)...
into
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
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
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 README.
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.
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
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 user base, then there are issues that
go beyond
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
, 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 XHR
(although MS may be messing around with that in IE7).
But, if one is best served
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.
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 =
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
54 matches
Mail list logo
