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 20:46 On Jan 6, 12:22 pm, kangax <kan...(a)gmail.com> wrote: > On 1/6/10 9:51 AM, David Mark wrote: > > > Thomas 'PointedEars' Lahn wrote: > >> David Mark wrote: > [...] > >>>> Those are _not_ Conditional Comments, it is conditional _compilation_, > >>>> ... > >>> Yes, I'm sure that was a slip of the keyboard. > > >> IBTD :) > > > Now how would you know? I imagine Kangax knows the difference between > > the two. > > Hmm, how would I know the difference between two... :) > <http://groups.google.com/group/comp.lang.javascript/msg/9d86789cac65b2a1> > (funny that you and me already had almost exact same conversation, > although before I started testing FHN). > Oh, BTW, that's the same conversation where I explained that you need neither expandos nor an ID-requirement to create an addEvent function. How did that come up again, today? :) And you don't need handles either, but I think that's the only sane general-purpose solution. I know some will complain that it isn't exactly the same as the wrapped DOM interfaces, but how is it the goal to exactly mimic those? Seems like wrappers are a chance to improve on them. ;)
From: Thomas 'PointedEars' Lahn on 7 Jan 2010 05:59 kangax wrote: > David Mark wrote: >> Thomas 'PointedEars' Lahn wrote: >>> David Mark wrote: >>>>> Those are _not_ Conditional Comments, it is conditional _compilation_, >>>>> ... >>>> Yes, I'm sure that was a slip of the keyboard. >>> IBTD :) >> Now how would you know? I imagine Kangax knows the difference between >> the two. > > Hmm, how would I know the difference between two... :) > <http://groups.google.com/group/comp.lang.javascript/msg/9d86789cac65b2a1> > (funny that you and me already had almost exact same conversation, > although before I started testing FHN). I stand corrected. Sorry, it was too much of a "slip of the keyboard" for me to imagine. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: David Mark on 7 Jan 2010 12:34 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 offersfast historynavigation (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 nofast historynavigation 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 definefasthistorynavigation 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. > Right. That's what matters. ISTM that Chrome and IE both have it, but they preserve the _initial_ state of the DOM, rather than the last state. In such implementations, unload listeners would not need to thwart the feature. I'll test that theory when I get a chance.
From: Thomas 'PointedEars' Lahn on 7 Jan 2010 16:09 David Mark wrote: > On Jan 6, 1:28 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: >> Interestingly, it looks like "My Library" will fail on local files in >> IE7. It's commented on, but not accounted for. > > That's not true. > > API.requireMimeTypeOverride > > Set that and it won't use the non-ActiveX version. ;) That's a bit non-intuitive, don't you think? PointedEars -- 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 7 Jan 2010 16:46
On Jan 7, 4:09 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > David Mark wrote: > > On Jan 6, 1:28 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > >> Interestingly, it looks like "My Library" will fail on local files in > >> IE7. It's commented on, but not accounted for. > > > That's not true. > > > API.requireMimeTypeOverride > > > Set that and it won't use the non-ActiveX version. ;) > > That's a bit non-intuitive, don't you think? > Absolutely, but not for requiring the (hack) overrideMimeType method (which was what I had in mind at the time). :) |