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: kangax on 6 Jan 2010 00:19 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. 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). That leaves us with Firefox (~25%), Safari (~4%) and Opera (~2%). So, roughly, 30% of current browsers support fast history. I'm bringing this all up just to show that, unfortunately, fast history is not as widely supported as it might seem. > > The problem is that most "major" libraries hang unload listeners on > the body for no reason, which requires documents to reload on > navigation (otherwise they'd be crippled as all of the listeners have > been detached). As we've discussed here, the listeners aren't the > problem and the real problem (circular references involving host > objects) is easily avoided at the design stage. Sound familiar? The "problem with major libraries is somewhat bad, but not very bad. It's also kind of getting better... slowly. Latest jQuery (currently beta, IIRC) attaches "load" listener only when `window.attachEvent` is present (and `window.addEventListener` is not). It would probably be better if they used conditional comments, as Garrett does in APE: isMaybeLeak/*@cc_on=(@_jscript_version<5.7)@*/ 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. 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. The real problem is current stable jQuery, which attaches unload unconditionally and so kills those 30% of browsers, capable of fast history navigation. [...] -- kangax
From: David Mark on 6 Jan 2010 01:57 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? > > 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. > > That leaves us with Firefox (~25%), Safari (~4%) and Opera (~2%). So, > roughly, 30% of current browsers support fast history. > > I'm bringing this all up just to show that, unfortunately, fast history > is not as widely supported as it might seem. Well, it certainly should be (as Chrome would seem to have figured out). How did that Safari-clone manage to break it? > > > > > The problem is that most "major" libraries hang unload listeners on > > the body for no reason, which requires documents to reload on > > navigation (otherwise they'd be crippled as all of the listeners have > > been detached). As we've discussed here, the listeners aren't the > > problem and the real problem (circular references involving host > > objects) is easily avoided at the design stage. Sound familiar? > > The "problem with major libraries is somewhat bad, but not very bad. > It's also kind of getting better... slowly. That's ridiculous. Not one of them comes close to smoothing out IE oddities (ostensibly their most important task). It's way too late for them anyway. And look at the "progress" being made in their discussions. Are you kidding? They can't figure out problems from the decade before last, let alone deal with the future (I've seen it and it's murder). :) They threw the game away back when there was actually a shred of justification for their existence. Now they are pretty much superfluous. ;) > > Latest jQuery (currently beta, IIRC) attaches "load" listener only when > `window.attachEvent` is present (and `window.addEventListener` is not). Unload? > 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. ;) > > 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? > > 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. ;) And yes, I am going to yank that bit (or at least make it optional, defaulting to off). > > The real problem is current stable jQuery, which attaches unload > unconditionally and so kills those 30% of browsers, capable of fast > history navigation. Among many other things. It kills IE with ActiveX disabled, even though IE has supported XHR without ActiveX for years. And, as we all know, it hasn't fixed attr/removeAttr despite being handed the solution in late 2007. Futility doesn't come any clearer than that.
From: David Mark on 6 Jan 2010 02:09 On Jan 6, 1:57 am, David Mark <dmark.cins...(a)gmail.com> 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? > > > > > 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. > They did break it. My pages load fast enough that it's hard to tell sometimes. There's certainly no such ambiguity with the typical library-happy designs. :) Go here:- http://www.hartkelaw.net/ Change the theme, navigate to another page (e.g. the Spanish version), set the default theme back, click the back button and the other theme should still be applied. It is in Safari, Opera and FF, but not in Chrome. (!) Good thing they are going to fix _that_. Appears IE lost it somewhere between 2 and 8 too. Whatever. They definitely had it at one point as it's the browser I first noticed doing it (some time in the mid-90's).
From: Thomas 'PointedEars' Lahn on 6 Jan 2010 03:11 kangax wrote: > David Mark wrote: >> Jorge wrote: >>> David Mark 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. > > 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). > > That leaves us with Firefox (~25%), Safari (~4%) and Opera (~2%). So, > roughly, 30% of current browsers support fast history. > > I'm bringing this all up just to show that, unfortunately, fast history > is not as widely supported as it might seem. JFTR: A recent market study has showed that Firefox has gained a market share of 45% in Germany¹, the fourth-largest economy after the USA, Japan, and China (according to 2008 IMF/World Bank/CIA figures²). Regardless of numbers, though, fast history navigation is undoubtedly a useful feature that is going to be implemented sooner or later in the browsers that do not yet implement it. However, it also stands to reason that the more common Web applications become, the load/unload problem becomes more pressing, and solutions are going to be developed. 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. > Latest jQuery (currently beta, IIRC) attaches "load" listener only when > `window.attachEvent` is present (and `window.addEventListener` is not). > It would probably be better if they used conditional comments, Those are _not_ Conditional Comments, it is conditional _compilation_, ... > as > Garrett does in APE: > > isMaybeLeak/*@cc_on=(@_jscript_version<5.7)@*/ .... and it is utter nonsense in this context. As we had established already, the programming language has little or nothing to do with the user agent that provides the DOM API which exhibits this flaw. PointedEars ___________ ¹ [de] <http://www.heise.de/newsticker/meldung/Firefox-ueberholt-in- Deutschland-Microsofts-Internet-Explorer-873082.html> ² <http://en.wikipedia.org/wiki/List_of_countries_by_GDP_%28nominal%29> -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: David Mark on 6 Jan 2010 03:26
On Jan 6, 3:11 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > kangax wrote: > > David Mark wrote: > >> Jorge wrote: > >>> David Mark 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. > > > 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). > > > That leaves us with Firefox (~25%), Safari (~4%) and Opera (~2%). So, > > roughly, 30% of current browsers support fast history. > > > I'm bringing this all up just to show that, unfortunately, fast history > > is not as widely supported as it might seem. > > JFTR: A recent market study has showed that Firefox has gained a market > share of 45% in Germany¹, the fourth-largest economy after the USA, Japan, > and China (according to 2008 IMF/World Bank/CIA figures²). > > Regardless of numbers, though, fast history navigation is undoubtedly a > useful feature that is going to be implemented sooner or later in the > browsers that do not yet implement it. However, it also stands to reason > that the more common Web applications become, the load/unload problem > becomes more pressing, and solutions are going to be developed. But one of the most maddening misconceptions I come across is that Web apps must use a single document. Such designs fail to leverage the browsers' inherent proficiency at browsing. ;) > > 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. But it's never necessary, save for applications that paint themselves into that particular corner at the design stage. > > > Latest jQuery (currently beta, IIRC) attaches "load" listener only when > > `window.attachEvent` is present (and `window.addEventListener` is not). > > It would probably be better if they used conditional comments, > > Those are _not_ Conditional Comments, it is conditional _compilation_, .... Yes, I'm sure that was a slip of the keyboard. JFTR, Conditional Comments are useful for the _occasional_ IE-specific style (but they are frequently used as crutches). From the example site:- a.external { zoom:1 } That's it. Of course, it might seem mad to have a single rule style sheet just for IE, but I find it handy in case I have to add more later (apparently I never did for this one). > > > as > > Garrett does in APE: > > > isMaybeLeak/*@cc_on=(@_jscript_version<5.7)@*/ > > ... and it is utter nonsense in this context. As we had established > already, the programming language has little or nothing to do with the user > agent that provides the DOM API which exhibits this flaw. It's certainly a flawed strategy to detect the script engine version. I'm surprised at Kangax. :) |