Canceling a form submitted to an iframe target
in [JavaScript]
|
Prev: Workaround for IE6 select width cut off options' width
Next: FAQ Topic - How do I get a jsp/php variable into client-sidejavascript? (2010-01-06)
From: David Mark on 6 Jan 2010 18:40 On Jan 6, 5:47 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > kangax wrote: > > Thomas 'PointedEars' Lahn wrote: > >> So I would take the conservative approach for the time being: Avoid that > >> which leads to the necessity of adding `unload' listeners where possible, > >> and properly detect the faulty DOM implementation where it cannot be > >> avoided in order to add those listeners. > > > How would you detect faulty DOM implementation? > > IIUC, the only faulty DOM implementation is the MSHTML DOM. There must be > properties that are available in this DOM but not in other DOMs. I do not > know if (in essence) `window.attachEvent && !document.addEventListener' (I > would not try `window.addEventListener' as `window' is not supposed to refer > to a Node implementation) is the final word on the subject, but it is a > start. > Yes, if you must infer about faulty MSHTML, a multiple object inference is the best bet (as seen in My Library and copied years later by jQuery). :) The conditional compilation is not needed and the script engine version is not reliable. Furthermore, it fouls up minification, at least for the YUI compressor (deflates less). You could also look at document.expando (boolean), window.external (host object) and window.external.addFavorite (ActiveX method--typeof "unknown"). If those check out and there is attachEvent, but no addEventListener, you can be damned sure that you are in IE < 9 (and supposedly the leaks are fixed in IE8). If you want to assume IE8 fixed the problem, check document.documentMode (number). But, as always, when left with such a "solution", think of another way to deal with the problem, which is never _directly_ related to the name of the browser or version number.
From: Scott Sauyet on 6 Jan 2010 18:57 On Jan 6, 6:30 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > On Jan 6, 1:28 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: >> Indeed, I thought David would be watching the jquery-dev list like >> usual, notice yesterday's thread, and trumpet in here how the change >> is long over-due and he was the one who got them to change it! Heh. > > I certainly don't "watch" any jQuery lists. And I never trumpet > anything in here. http://groups.google.com/group/comp.lang.javascript/msg/33e110600bfaeeb7 http://groups.google.com/group/comp.lang.javascript/msg/ac02583964f3637b http://groups.google.com/group/comp.lang.javascript/msg/9c46f34a4477a812 http://groups.google.com/group/comp.lang.javascript/msg/e1d0ee645674a5a5 http://groups.google.com/group/comp.lang.javascript/msg/a3112ff1853fdd70 -- Scott
From: David Mark on 6 Jan 2010 19:06 On Jan 6, 6:57 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > On Jan 6, 6:30 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > > On Jan 6, 1:28 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > >> Indeed, I thought David would be watching the jquery-dev list like > >> usual, notice yesterday's thread, and trumpet in here how the change > >> is long over-due and he was the one who got them to change it! Heh. > > > I certainly don't "watch" any jQuery lists. And I never trumpet > > anything in here. > > http://groups.google.com/group/comp.lang.javascript/msg/33e110600bfaeeb7http://groups.google.com/group/comp.lang.javascript/msg/ac02583964f3637bhttp://groups.google.com/group/comp.lang.javascript/msg/9c46f34a4477a812http://groups.google.com/group/comp.lang.javascript/msg/e1d0ee645674a5a5http://groups.google.com/group/comp.lang.javascript/msg/a3112ff1853fdd70 > Thanks for reviving those. ;) And I hardly consider commenting on those threads to be "trumpeting".
From: David Mark on 6 Jan 2010 19:37 On Jan 6, 11:52 am, kangax <kan...(a)gmail.com> wrote: > On 1/6/10 1:57 AM, David Mark wrote: > > > > > On Jan 6, 12:19 am, kangax<kan...(a)gmail.com> wrote: > >> On 1/5/10 8:54 PM, David Mark wrote: > > >>> On Jan 5, 8:35 pm, Jorge<jo...(a)jorgechamorro.com> wrote: > >>>> On Jan 6, 2:29 am, David Mark<dmark.cins...(a)gmail.com> wrote: > > >>>>> (...) The > >>>>> typical Website today requires a reload every time the user clicks the > >>>>> back (or forward) button. (...) > > >>>> Not in current Safaris nor FireFoxes. > > >>> You are very confused, Jorge (as usual). Virtually every major > >>> browser offers fast history navigation (and has for years). You just > >>> don't see it on the Web much due to poorly designed scripts. > > >> Actually no, in reality things are not as bad as you make them sound ;) > > >> First of all, as I'm sure you know, our favorite "browser" the one > >> with ~62% market share at the moment > >> (http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0) > >> has no fast history navigation whatsoever. > > > IE? It's had it since IE2, IIRC. Did they lose it at some point? > > IE 6, 7, 8 had none, last time I checked. But we need to define fast > history navigation first. I only checked execution of scripts (i.e. that > navigating back/forward doesn't re-run them), and how unload listeners > affect it. > > I haven't checked if request is sent to a server. > > > > >> Chrome, which has just became 3rd most-popular browser, has no fast > >> history either (although they're planning to add it in a near future; > >> there's a ticket somewhere in their bugtracker). > > > Sure looks like they have it to me. I'll check though. > > http://code.google.com/p/chromium/issues/detail?id=22291 > > [...] > > > > >> Latest jQuery (currently beta, IIRC) attaches "load" listener only when > >> `window.attachEvent` is present (and `window.addEventListener` is not).. > > > Unload? > > Yes, of course :) > > > > >> It would probably be better if they used conditional comments, as > >> Garrett does in APE: > > >> isMaybeLeak/*@cc_on=(@_jscript_version<5.7)@*/ > > > No, detecting the script engine version is not a good strategy and > > never has been. Address the leak problem _directly_ by not creating > > circular references that leak. ;) > > Yeah, but then you need to stamp elements with expandos. Or use ids, but > that's a somewhat obtrusive approach. > > > > >> Prototype.js attaches "unload" when `window.attachEvent` is present and > >> `window.opera` (as an object with [[Class]] == "Opera") is not. Not a > >> bad strategy, but probably not as efficient and future-proof as CC-based > >> version. > > > Why even bring them up? Have you seen my review of that code? > > Current Prototype.js codebase? What is there to see? Everyone knows > about all of its flaws and legacy mistakes, and that a complete rewrite > is in order. Did you actually spend time reviewing it? > > > > >> I see that "My Library" adds unload when `attachEvent` is present, but > >> not `addEventListener`; pretty much what jQuery does now. But I know > >> that you would just ditch all this unload business altogether if you had > >> to update things now. > > > Yes, we've been over that many times. Back in 2007 I thought it was a > > good idea (among other things). And the difference is that mine > > doesn't _need_ to do that at all as it creates no circular references > > on attaching listeners. ;) > > I would be really interested to see "My Library" cleaned up and brought > up to speed. It has potential, but looks rather rough at the moment. > Looking it over, I can see a few things that I would change (and likely will as they are all trivial). 1. Remove unload listeners 2. Remove all signs of gBOF (deprecated method) 3. Optimize regular expressions 4. Copy simplified viewport measurement logic from:- http://www.cinsoft.net/viewport.asp 5. Copy improved attribute handling logic from:- http://www.cinsoft.net/attributes.html ....and remove the _ridiculous_ setAttributeByReplacement crutch. 5A. Include hack (no real solution yet) for IE8 bug related to maximizing elements (or maybe they will fix it in the browser). Under some circumstances, an element with offsetWidth x will create a horizontal scrollbar (1 pixel overflow) when viewport width is x. Obviously x - 1 alleviates it, but that is the wrong width (leaves one pixel wide gap). (!) The above test page has the hack. Interestingly enough, sidebars in My Library do not trigger the problem, but maximized elements do. There's a clue in there somewhere. :) 6. Server needs to filter unneeded method detection for OO layer (it knows what is going into it when building, of course). 7. Clean up add-ons (e.g. DOM ready simulation) 8. Add new keyboard monitor and a few other miscellaneous bits I've come up with recently 9. Fill in some of the unsupported CSS2 selectors (lowest priority). I'm working on a TaskSpeed demo too. Early results indicate it is the fastest at virtually everything (fairly close to "pure JS" in some cases). Ironically, this has caused me to work on #9 recently. I'm sure there are other things that could improve it without sacrificing any speed or adding much to the size. I welcome suggestions (and help from qualified applicants). :) And, of course, the documentation and Website could use some improvements (perhaps even some pretty graphics). It's just never been a concern for me to attract users for that thing. It's a loss- leader for me.
From: David Mark on 6 Jan 2010 20:16
On Jan 6, 6:30 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > On Jan 6, 1:28 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > > > On Jan 6, 10:52 am, kangax <kan...(a)gmail.com> wrote: > > > > > Among many other things. It kills IE with ActiveX disabled, even > > > > though IE has supported XHR without ActiveX for years. > > > ActiveX problem is fixed in a trunk, AFAIR. > > > Indeed, I thought David would be watching the jquery-dev list like > > usual, notice yesterday's thread, and trumpet in here how the change > > is long over-due and he was the one who got them to change it! Heh. > > I certainly don't "watch" any jQuery lists. And I never trumpet > anything in here. It's more like you start talking about "progress" > with jQuery and I _respond_ that if I hadn't beaten certain salient > points (e.g. browser sniffing, typeof xyz == 'array', etc.) into them > for years, sometimes talking directly to them, they wouldn't have > known what was wrong or what to do. The browser sniffing is but one > example, but perhaps the most important (and most obvious). Go back > to the Fall of 2007 and notice how Resig vehemently denied everything > I said in my review of jQuery (centered on sniffing). Then remember > that _you_ went over there to their list and argued my points for days > (if not weeks). That thread must have been 100 posts at least. And > remember how Resig wanted to see "my cool library" and then I > published it two months later? It was less than a year later that > Resig announced that he had figured out browser sniffing was evil and > unnecessary and had the "code to prove it" (much of which looked > suspiciously like similar code in My Library). And that pattern has > repeated itself a few times since, sometimes successful (e.g. > ActiveX), sometimes semi-successful (e.g. that ridiculous SELECT > hack), sometimes futile (e.g. attr/removeAttr). > > Now, who is following who? > Should be clear. Matt was just trying to defuse the situation by mentioning it first (he must be an aspiring lawyer). Fixed _one day ago_. Now, I haven't discussed that one in earnest in about year (when the ticket was originally filed). And, what a coincidence, I just brought it up yesterday (in this very thread). Resig is a closet CLJ fan! Either that, or the CLJ-Kruse-jQuery pipeline is still flowing, despite Resig's recent ostrich imitations. Good and all, but it won't save jQuery. :) http://dev.jquery.com/ticket/3623 And yes, Matt Kruse, it was _way_ too late (for anyone foolish enough to use jQuery any time in the last three years). You know _you_ can't even upgrade the thing due to broken compatibility (and even if you could, it's an expensive and unnecessary inconvenience). You predicting I would say such things does not change the fact that they are true. And you should have just kept your mouth shut as I didn't even notice that they fixed it. ;) |