Yes a temporary wrapper is better... and useful for other things too.
Diego
On 16 Gen, 01:16, DBJDBJ wrote:
> How about a proxy (aka mediator, aka facade ) pattern ?
> Let us call that "facade" : jQLint. An facade to the real jQuery
> behind . Let's call its instance: $$
>
> // inside jQlint
> (
code. And in the documentation, it could be
> strongly urged that new developers try this at least once.
>
> Heck, let's take it a step farther... how about jquery-1.4.newb.js
> that has some sort of 'tutorial' built in when it sees bad practices?
>
> At least t
Dave,
I completely agree with Andrea Raimondi above and everything he said
make sense to me.
Why should we inflict these no sense conditionals onto everybody.
Should we then check every parameter of every method too, just to be
helpful to one people not remembering signatures or lazy to lookup a
d
, Google is
also 'deaf' so he can't hear your beautiful music, the content is king
then... ;-)
Much of the software we write will be soon obsoleted by more capable
browsers, we are just temporarily working around/overcome unusable
parts of them (hope so!)
Diego
On 10 Gen, 17:15, Dieg
Daniel,
click events can be triggered in various ways, more generally, events
should be allowed to be triggered by any means of device, a keyboard,
a mouse, a sensitive tablet/surface, a touch screen and so on and even
by voice and manyother means.
I am scary to even say that seems Microsoft has t
Karl,
it is not only "href" that has problems, seems all attributes having
an URI string as value have to be read in the way you described.
Some of them are: action, cite, codebase, data, href, longdesc,
lowsrc, src, usemap.
In IE6/7 elements have a predefined number of attributes (minimum 80,
va
Steven,
you may give this a try too, this in the spirit of reusing what we
already have available in browsers:
The "onerror" event hook should be available and usable on current
browsers and it allows you to have more complex function being called
handling the error, maybe with multiple retries.
extra "interactive" state where the BODY is available, also
possibly not completely parsed and rendered.
For the rest it is just similar to what Andrea does in his code, add a
"readyState" property to document the W3C way.
Still not a solution for what jQuery needs.
-
Di
I don't understand why you are writing code like this in a developer
group... some ongoing competition.
It is not clear if you have trade secrets or just don't want others to
see the errors in it. ;-)
Do you want to talk about them and discuss them or is this a way of
just posting a snippet, for
I don't really have any other "big" issue then this and the "few more"
other "features" only found in IE browsers ever since.
> Do not loose the site of that.
I will kindly skip that for now, many thanks for your insights anyway.
--
Diego
On 8 Ott, 17:57, DBJDBJ wrote:
> IHTMLWindow6 Interf
David,
the explanation you give of this fact make sense and is the more
plausible one. I have had others giving me that same bit of
information.
Unfortunately that's only our guess up to now, I haven't disassembled
their DLL (not yet) ! ;-)
--
Diego
On 6 Ott, 19:01, David Flanagan wrote:
> Kl
Klaus,
your statements are correct, I can confirm that...that change is
wrong.
I don't understand why for each new version of jQuery the non-strict
"==" check in the ready method is changed into the strict "===" (non
working).
There was a comment on those lines I seem to remember, stating not to
ou all for the heads-up,
Diego Perini
On Mon, Jun 22, 2009 at 8:16 PM, John Resig wrote:
> Interesting fix, Rich. I've CC'd in Diego who's been doing a lot of
> work with the ready code lately.
>
> --John
>
>
>
> On Mon, Jun 22, 2009 at 5:53 PM, Rich
Andrew,
this is a neat idea but from my knowledge it is not currently
applicable to HTML fragments to be inserted in the DOM.
"Transfer-encoding: chunked" means that "output_buffering" is enabled
on the server. Each chunk size is predefined (configurable), normally
the default in PHP is set to 4K
John,
if your doubt about Function() safety are cleared could you look back
at the "merge()" optimizations I suggested in ticket #2510.
Also the IE specific sniffing has been replaced by a better test the
speed of the function itself have not improved, and could really be
improved.
I remember "m
nks also for the readystatechange information, though I can't
> > > really put it to use because I'm using this in a bookmarklet.)
>
> > > Anyway, I'm very grateful for your working fixes, so let me know if
> > > you think I should file a ticket, okay?
ll a lot of
> current window/document assumptions in the jQuery code base.
>
> (Thanks also for the readystatechange information, though I can't
> really put it to use because I'm using this in a bookmarklet.)
>
> Anyway, I'm very grateful for your working fixes,
Jed,
forgot to say that you probably have to wrap those alert inside a
"readystatechange" for IE or similar for other browsers.
You have to wait for all the elements to be loaded in the parent
window before getting dimensions.
Here is the code I used to test:
window.parent.docume
Jed,
try these changes in current 1.3.2.
Change line 4352 from:
return this[0] == window ?
to:
return 'frameElement' in this[0] ?
and line 4358 from:
this[0] == document ?
to:
'documentElement' in this[0] ?
this will probably fix your problem (the one in the posted code), also
Ricardo,
I am highly supporting this idea even at the cost of code size (to
some extent).
Also, more independent, normally means more maintainable and less
execution calls so should be faster too.
Diego Perini
On 2 Mar, 13:18, ricardobeat wrote:
> I'm not really aware of the code prac
Dave,
I didn't meant changing anything there...maybe I optimized too much.
What I wanted to do was just adding a ".cloneNode(false)" in the
second "fragment" instance in that line so instead of:
callback.call( root(this[i], first), this.length > 1 || i > 0 ?
fragment.cloneNode(true) : fr
John,
could you have a look if this change could fit in domManip() ?
callback.call( root(this[i], first), fragment.cloneNode(this.length
> 1 || i > 0) );
it seems solving the reported errors:
uncaught exception: Node cannot be inserted at the specified point
in the hierarchy (NS_ERROR_DOM_
er:
>
> http://s3.amazonaws.com/iframeWindowTest/before.htmlhttp://s3.amazonaws.com/iframeWindowTest/after.html
>
> And submitted a bug here:
>
> http://dev.jquery.com/ticket/4268
>
> Jed Schmidt
>
> On Feb 27, 7:26 am, Diego Perini wrote:
>
> > Jed,
> > n
Andrea,
On 28 Feb, 00:42, Andrea Giammarchi
wrote:
> I bet is the classic banner, spot, or JS effect to attach to the mouse and
> somebody asked him why it is not attached since the beginning ... well,
> Marcus, if it is the case tell them that the browser is inside a window and
> if the user is
Gavin,
FYI in Firefox 3.0.6 on my Mac it seems I can get at those values
using the Java plugin with following bookmarklet:
javascript:alert(java.awt.MouseInfo.getPointerInfo().getLocation
().getX());
by typing that in the URL bar I can get current mouse X coordinates.
I cannot make it work o
tarily interrupt the testing to follow up some work but
will have a look back.
Diego
On 27 Feb, 04:20, Jed Schmidt wrote:
> Diego,
>
> My apologies, I misunderstood you.
>
> (Also, the test case is working now: resize the window to test it, and
> see that jQuery is binding one
elements which lack a nodeType, but for which
> events (resize, focus) are possible.
>
> Here's a better test case:http://s3.amazonaws.com/iframeWindowTest/index.html
>
> Jed Schmidt
>
> On Feb 26, 4:51 pm, Diego Perini wrote:
>
> > Jed,
> > I would like to
events.
>
> Windows are the only elements which lack a nodeType, but for which
> events (resize, focus) are possible.
>
> Here's a better test case:http://s3.amazonaws.com/iframeWindowTest/index.html
>
> Jed Schmidt
>
> On Feb 26, 4:51 pm, Diego Perini wrote:
>
Jed,
I would like to add that a few lines above the ones you pointed out we
also have:
if ( elem.nodeType == 3 || elem.nodeType == 8 )
return;
Can "elem" really be a window/frame reference ?
Shouldn't this give an error since windows/frames do not have a
John,
some great updates you are releasing, everything has been improved,
new functionalities and increased speed for the core methods.
Events management covers most of what I would expect. The bits about
"return false" and ".stopPropagation()" on ".live()" will be very
useful.
My compliments to
Andrea,
dropping support for IE6 will not help reduce the code in any way. The
same part of code is still needed in both IE7 and IE8.
What are the advantages in only have support for IE7 and IE8 ?
Diego
On 21 Feb, 17:24, Andrea Giammarchi
wrote:
> Ok, I tried :D
>
> On Sat, Feb 21, 2009 at 4:
big advances I see here both in code and
thinking.
jQuery is at least one year ahead the competition on these basics core
functionalities of frameworks.
Diego Perini
On 17 Feb, 00:05, "mike.helgeson" wrote:
> - The selector must be run, before the event handler is bound... this
>
John,
thank you for the nice additions and fixes, the "document order" is
really welcome :-)
Just a minor thing I noticed in the new code source is about older
Opera (probably 9.27 and older). Opera have implemented the
"sourceIndex" property too but it starts at index "0" for the
documentElement
t 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.
>
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.
>
iego, I'll try this out. However, for this specific case
> this may not be a good solution for us because we want to allow the
> mousedown event to bubble up.
>
> On Feb 13, 9:10 pm, Diego Perini wrote:
>
> > Scott,
> > if I recall correctly, the solution
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
Robert,
I have also needed this bit of help from jQuery...for extracting texts
from HTML code.
I proposed this similar solution on the Sizzle group some time ago:
http://groups.google.com/group/sizzlejs/browse_thread/thread/44d2b3fd5d532b5b
which probably solves with a simpler sort() on the
all element properties are correctly defined
> > before jQuery code begins executing. Failure to do this will cause
> > sporadic problems, especially on WebKit-based browsers such as Safari.
>
> --Karl
>
>
> Karl Swedbergwww.englishrules.comwww.learningjquery.com
>
> On Fe
"DOMContentLoaded",
> > jQuery.ready, false );
>
> > // If IE is used and is not in a frame
> > // Continually check to see if the document is ready
> > if ( jQuery.browser.msie && window == top ) (f
.
>
> > --
> > Ariel Flesler
> >http://flesler.blogspot.com
>
> > On Feb 1, 10:09 pm, John Resig wrote:
> >> Ah, ok. I suspect that some of that may be in Sizzle. Patches are welcome!
>
> >> --John
>
> >> On Sun, Feb 1, 2009 at 2:14 PM,
, 15:53, John Resig wrote:
> Is there any appreciable speed-up to caching RegExp that are that
> small? I wasn't able to find any when I looked.
>
> --John
>
> On Sun, Feb 1, 2009 at 7:58 AM, Diego Perini wrote:
>
> > I did have a quick look through the code and
I did have a quick look through the code and see that most of the
(small) regular expressions are not cached and referenced but defined
in-line in the conditionals/replacements.
For example these are repeatedly used in various place:
/\s+/
/\\/g
/\?/
I believe there are improvements in both spe
John,
I have gone through it again and looked at source code.
I now got the problem you are talking about in your message...
...parent[ doneName]... (gasp)
and I know the related problem there is in that part of selectors to
be able to do that fast enough.
But really you don't need to do th
Dimi Paun,
It could be the slowdown is due to the "in-line" RegExp in the trim().
I always keep these pre-compiled in an external variable for speed
(cached).
Since you are going to try, I would suggest that as the first try.
Next try would be also to avoid a call to trim() and just do it in-
li
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 sub
Daniel,
this is how I see these attributes on form elements:
"enabled"
the functionalities of the form element are available and interactions
by users are allowed
"disabled"
the functionalities of the form element are available and interactions
by users are disallowed
"hidden"
the form element
John,
while debugging those two .live() on few elements on my machine I have
come across another problem.
It seems that every element touched by the selector is adding a
"doneXXX" property to each parent on each iteration of the selector.
So with "mouseover/mouseout" I finished up with something
help to debug the
> problem (I suspect that this problem is largely markup dependent).
>
> --John
>
> On Thu, Jan 29, 2009 at 8:02 AM, Diego Perini wrote:
>
> > I have just gone through a problem in code that seems related to live
> > ().
>
> > A coworker ha
I have just gone through a problem in code that seems related to live
().
A coworker has just shifted from bind() to live() in a page where many
UL / LI / A (probably a hundred of them).
The anchors are just internal page jumps, there are counters for each
click on them. The user have to follow
John,
you have clearly depicted detection objectives and categorized the
type of detections, cleverly written...
couldn't do that in plain English as you did...probably even not in my
own language :-)
Diego
On 28 Gen, 16:30, John Resig wrote:
> > Feature Detection is all about checking how a f
Brandon,
here is a sample of the trick used to overcome these "form"
annoyances, I will gladly open an enhancement ticket if deemed
interesting to have in jQuery. I will first let it here for comment
reviews.
Some point:
- I used DOM0 event "onmouseup" to avoid including cross-browser code
adapt
ecause now I do support more
browsers and faster too. The size...well we have compressors (5Kb).
Diego
On 27 Gen, 23:51, kangax wrote:
> On Jan 27, 4:46 pm, Diego Perini wrote:
>
> > Juriy,
> > we agreed that if we can write something in the DOM everybody else can
> > d
ment", but "window == window.top" works.
Diego
On 27 Gen, 23:06, Diego Perini wrote:
> John,
> I could finally replicate the problem with the help of john dalton on
> IE7 (I only had IE6 to test).
>
> The problem is the use of window.frameElement, shouldn't error si
't using
jQuery window.frameElement in my own code.
Diego
On 27 Gen, 21:34, Diego Perini wrote:
> John,
>
> On 27 Gen, 20:23, John Resig wrote:
>
> > I think you misunderstood me. Simply accessing the frameElement
> > property from a frame that isn't on the same doma
27 Gen, 22:20, kangax wrote:
> On Jan 27, 1:37 pm, Diego Perini wrote:
> [...]
>
> > One "span" element with an id="length" will do much more damages to
> > every existing framework/library, and there are tons of properties
> > that can be overwri
the exact problems you detected with
the iframe check ?
Diego
> --John
>
> On Tue, Jan 27, 2009 at 11:18 AM, Diego Perini wrote:
>
> > John,
> > well the reasons are ok, but the method is wrong in fact the doScroll
> > () trick is actually short-circuited and will nev
com)
> -MonkeyScript (http://monkeyscript.nadir-point.com)
> -Animepedia (http://anime.wikia.com)
> -Narutopedia (http://naruto.wikia.com)
> -Soul Eater Wiki (http://souleater.wikia.com)
>
> Diego Perini wrote:
> > Juriy,
> > ...
> > One "span" element with an id=&q
Correct John, I also do that on my NWMatcher selector engine I should
have said "most" instead of "every".
I was aware jQuery does not suffer this problem, but the solution I
used is somehow different:
- save the element offending id="length"
- remove the offending id from element
- do the DOM c
ome alternative solution will need to be derived - especially
> since getting the exceptions was far worse (the page didn't load, at
> all).
>
> --John
>
> On Tue, Jan 27, 2009 at 11:00 AM, Diego Perini wrote:
>
> > John,
> > the report is OK and says the tru
John,
the report is OK and says the truth...Mexicans would say "ay ay
ay !!!".
This is something that should have been avoided...a too critical place
to play with.
The problem I see is that my patch and test for iframes got changed:
Line 2952 is currently:
if ( document.documentElement.doScrol
tions, we just need to
mix them with the new one in the correct way.
On 27 Gen, 18:21, kangax wrote:
> On Jan 27, 11:34 am, Matt wrote:
>
> > On Jan 27, 7:12 am, Diego Perini wrote:
>
> > > I just wrote in another thread that there are cases where I prefer to
> >
Kevin,
if that counts...I fully agree with you on the fact that browser
sniffing will never be replaced completely.
I just wrote in another thread that there are cases where I prefer to
use the following:
var IE = typeof document.fileSize !== 'undefined', // IE6, IE7 or IE8
as a general boolean
John,
you and all the jQuery team members are always at the top of
innovation.
It is not easy for a framework like jQuery and with its audience to
continuously add new features and improvements without breaking
previous code base. But you just can do it so well !!! :-)
My sincere compliments for
?
>
> IE = !!document.attachEvent;
>
>
>
> On Tue, Jan 13, 2009 at 3:00 PM, kangax wrote:
>
> > On Jan 13, 10:17 am, Diego Perini wrote:
> >> Kanagax,
> >> agree with you about "using (or not) frames" being irrelevant if the
> >> is obje
As I said, I reiterate that feature testing is the best method, nearly
in all cases, both inference and sniffing have their places in the
game.
Diego
On 13 Gen, 18:00, kangax wrote:
> On Jan 13, 10:17 am, Diego Perini wrote:
>
> > Kanagax,
> > agree with you about "usin
ly how to I create an "unknown" variable in FF /
Opera / Webkit / Konqueror or mobile web browsers ???
Diego
On 13 Gen, 15:10, kangax wrote:
> On Jan 13, 8:11 am, Diego Perini wrote:
>
> > Kangax,
> > you have convinced me about the goodness of feature testing. Now
>
o
On 13 Gen, 07:07, kangax wrote:
> On Jan 12, 10:01 pm, Diego Perini wrote:
>
> [...]
>
> > My suggestion is to start including these two constants in the process
> > of removing the others, they will never go away:
>
> > IE = typeof document.fileSize != 'u
Wrong again, that's what happen in the late nights with no sleep
// Safari 2 doesn't implement View on window
S2 = top.document.defaultView && top !== top.document.defaultView,
sorry for the spam, wrong info is worst... :-)
Diego
On 13 Gen, 04:52, Diego Perini wro
A correction in the above two lines:
// detect IE any
version
IE = typeof context.fileSize !==
'undefined',
// Safari 2 doesn't implement View on
window
S2 = top.defaultView && top !==
top.document.defaultView,
I left out part of the Safari check...
Diego
John,
even if you didn't completely removed $.browser it is great to see
most of them are gone.
Next move is to go for feature testing, plugin writers should already
start using it to speed-up the complete removal. At least they should
have a direction to follow from the team in the process of re
lse;
> >> >> > return !!(docEl.compareDocumentPosition(el) & 16);
> >> >> > };
>
> >> >> > --- PERFORMANCE RESULTS:
>
> >> >> > = inDOM1: parents("html") =
> >> >>
$.htmlEl = $('html').get(0);
> >> $.fn.inDOM = $.htmlEl.contains ?
> >> function() {
> >> var el = this[0];
> >> return $.htmlEl != el && $.htmlEl.contains(el);
> >> } :
> >>
on this specific fact.
At this point, given the messed up implementations, better being
independent from them both and go for the traversal.
It is also much shorter and really cross-browser...
--
Diego
> Diogo
>
> On Mon, Dec 1, 2008 at 10:58 AM, Diego Perini <[EMAIL PROTECTED]>
ricardo,
On 1 Dic, 05:35, ricardobeat <[EMAIL PROTECTED]> wrote:
> I always miss the obvious stuff :)
>
> I ended up with this, it's a lot faster than Diogo's code but still
> requires you to traverse the document all the way up. John Resig's
> 'contains' function is at least twice faster in FF t
ricardo,
On 30 Nov, 19:35, ricardobeat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> It seems the ownerDocument is set for the created element even if it's
> not in the DOM, it's the document where jQuery was loaded in. A simple
Correct, the "ownerDocument" will always be available, but it will
reference
Ariel,
jQuery is already doing very well in many fields, the suggestions were
to cover expressed needs not to leave out working code.
I will follow on your answers...
On 29 Nov, 16:22, "Ariel Flesler" <[EMAIL PROTECTED]> wrote:
> @Scott
>
> Ok, that's an easy change (leave it or remove it). The
Ariel,
+ 1 for me...Good you found that something needs to be reworked again
there.
A quite similar approach was firstly tested in the "event.fix()"
optimizations in 1.2.3.
At that time my proposal was an "event.create()" function returning an
object but I like your approach, it is probably bett
Mark,
maybe I am just misunderstanding you, however my tip using CSS
selector groups (comma separated) is:
for the direct descendants
descendant-or-self = "self > *, self"
for all the descendants
descendants-or-self = "self *, self"
Both will get you a collection of descendant including
h may be why it hasn't landed yet.
>
> > That said does anyone have any objections to this patch? I have to
> > admit I haven't followed the latest content ready sagas.
>
> > David
>
> > On Nov 11, 6:37 am, Diego Perini <[EMAIL PROTECTED]> wrote:
>
thenobot,
I am not happy for the problems this gives all of us, however I am
happy this comes up again so it will be fixed. These are a bit of edge
cases but are easy to cover with a bit of clean-up, and will make many
developers happy.
jQuery will highly benefit in environments like you describe
Anybody ?
--
Diego
On 8 Nov, 14:43, Diego Perini <[EMAIL PROTECTED]> wrote:
> Hi team,
> are there issues with closing that old ticket.
>
> IE is in extreme need of that patch, we get issues with iframes and
> the Back/Forward browsers button in some circumstance and I wou
Hi team,
are there issues with closing that old ticket.
IE is in extreme need of that patch, we get issues with iframes and
the Back/Forward browsers button in some circumstance and I would like
to see this fixed a.s.a.p. The problem is often visible especially
when pages only have texts in it or
I thought the "from" argument context should be used for that task.
Isn't it enough to pass the IFRAME "contentDocument" or one
of its children to limit the search inside of that specific DOM tree ?
--
Diego
On 22 Ott, 18:51, "Morgan Allen" <[EMAIL PROTECTED]> wrote:
> I had written a quick pl
You creative man...adding nice syntax and easy functionality to
animations. I will have to look to it deeper for hidden goodies.
As a side effect it will probably help users avoid leaks while coding
animations on their sites, and let them run longer on IE... :-).
Is this for 1.2.7 ?
--
Diego
ove line and the event is correctly
fired, the alert says "hello"...
Hope I did understand and explain correctly,
--
Diego Perini
On 18 Ott, 15:46, "John Teague" <[EMAIL PROTECTED]> wrote:
> sure, here is the complete test suite.
>
> thanks for hel
time.
I was just pointing out the problems that I have seen before while
writing my own code and in some other implementation of events
delegation.
Thank you for sharing your ideas, will report any finding when I have
tested it
--
Diego Perini
On 15 Ott, 16:49, "mike.helgeson" <
; nextAll
> prevAll
> siblings
> children
> contents
>
> I will include the "is" rewrite in the next plugin release, and have
> already proposed it as a patch that will hopefully get applied to the
> core.
>
> http://dev.jquery.com/attachment/ticket/3137/mult
Mike,
what I normally need is let the CSS selector specify on what elements
I want lo listen for event and not have that embedded by default
(forced) in the plugins or core.
For example I prefer to be able to fully use and specify CSS selector
like these in the delegation method:
'#nav' listenin
Tested
Fri Sep 26 13:20:21 CEST 2008
--
Diego
--~--~-~--~~~---~--~~
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 gr
n and _preventDefault properties are not defined.
--
Diego Perini
On 19 Set, 16:29, "Brandon Aaron" <[EMAIL PROTECTED]> wrote:
> Awesome. Small change with a big impact!
> --
> Brandon Aaron
>
> On Thu, Sep 18, 2008 at 10:18 PM, John Resig <[EMAIL PROTECTED]> wrot
cement, it is not that good.
>
> >> If not, you are still evaluating "whatever" inside a function and, as you
> >> know, this simply means that if you have a global scope variable, called
> >> arguments, you will never be able to use it as is, unless you specify
7;); // or just new Image();
img.setAttribute("onabort", "function () {}"); // onerror, onload also
works
alert(typeof img.onload); // yeld function instead of string...good.
I was thinking to this while thinking to Air, Caja and similars.
Evil...good...useful ?
context (document) and then append the created
element in another context (document). I can just make some
assumptions...a piece of code can get better answers for you, more
precise and specific for your exact case.
--
Diego Perini
On 17 Set, 17:39, Rainaer <[EMAIL PROTECTED]> wrote:
94 matches
Mail list logo
