[Prototype-core] Re: getElementsBySelector has different behaviour in 1.5.0 and 1.5.1
On 13 Jun, 13:57, Mislav Marohnić [EMAIL PROTECTED] wrote: Can you try frames[myIframe].document.body? Thanks, I tried, but it gave the same result. One thing that is strange, is that when I try to get elements with selectors like table or .class1 it works perfectly! It is just the ids (#id) that don't work. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: getElementsBySelector has different behaviour in 1.5.0 and 1.5.1
On 6/13/07, Jostein [EMAIL PROTECTED] wrote: One thing that is strange, is that when I try to get elements with selectors like table or .class1 it works perfectly! It is just the ids (#id) that don't work. OK, so here is what you do now. Check out the latest trunk and try with it. If it still fails, figure out is the problem related to the fact you're doing cross-frame scripting. Can you make the selector fail by querying the document inside the document itself? After playing around with this, open up a new ticket for this bug. Post your minimal failing case (your 2 HTML documents with everything irrelevant stripped out) and write exact queries that fail and those that pass. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: getElementsBySelector has different behaviour in 1.5.0 and 1.5.1
On 6/13/07, Marius Feraru [EMAIL PROTECTED] wrote: [ Seeing you mentioned myIframe (+ the reference to a document property), I'm assuming you're really talking about IFRAMEs, i.e. the HTML element ]. Why would anyone expect to be able to reach other folks' documents? ;-) It's ugly enough that the child IFRAME has access to the parent, now you want it both ways? :)) Marius, cross-frame scripting is perfectly harmless. Browsers enforce the same-domain policy with frames, too, so you can't mess around with documents in other frames that don't belong to your site. But when they do, being able to mess around with them is sometimes what web apps build on. Ever used GMail? It's a frameset. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: getElementsBySelector has different behaviour in 1.5.0 and 1.5.1
On 6/13/07, Marius Feraru [EMAIL PROTECTED] wrote: Neither Gecko 1.8 nor 1.9 are able to get the content of #myIframe. $('myIframe').contentDocument.body That is W3C standard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: getElementsBySelector has different behaviour in 1.5.0 and 1.5.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mislav Marohnić wrote: $('myIframe').contentDocument.body That is W3C standard. QED: I'm obsolete. :o) Thanks (again) a million, Mislav. :) - -- Marius Feraru -BEGIN PGP SIGNATURE- iD8DBQFGcA49tZHp/AYZiNkRAm+vAJ9fK/M/toCXmX7p4zuvZgMAVCvHrQCfaSIK Sav2bCvMIeiiZI32PO7fFvU= =AvGC -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Hijack Browser Loading
[EMAIL PROTECTED] wrote: No matter what I try the images still load. Does anyone know how to hijack the browser and tell it not to load certain images? I might be wrong, but how a browser parses the HTML, decides what to download and when is all pretty browser specific. You probably can't change the way it downloads images. But you can change which images are requested. You could try having your Javascript modify the URLs of images that you want to hold off on loading. They could be changed to request a 1x1 pixel image which should come back pretty fast. And if you change them to all request the same small image then it will only make that request the first time. Then load the real images via JS when you need to. -- Michael Peters Developer Plus Three, LP --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Hijack Browser Loading
You could try having your Javascript modify the URLs of images that you want to hold off on loading. Unfortunately i've tried this out and it still loads the original images even though the swapped out image is displayed. I realize this is probably a browser specific thing, and may not be possible, but I wanted to pick everyones brains and see if anyone could come up with a creative solution. Thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Hijack Browser Loading
[EMAIL PROTECTED] wrote: Hey guys, I'm building a web app and am hoping to minimize the images loaded per page. I like the way YouTube only loads the thumbnails of the images you can see and then waits till you scroll before loading any others. They do this by placing img / tags for the initial images and then use javascript to fill out the rest. The only problem with this is someone without javascript won't see any of those additional images. So my question, and thought, was to do something like this: This looks like a question for the Rails-Spinoffs group. A simple unobtrusive approach would be to have a drawer of thumbnails with a link to view more images. For JavaScript enabled browsers, simply override the functionality of that link to load a list of image locations from memory or by AJAX. An image will be downloaded by the browser anytime 1) it parses an img with a src attribute, 2) an img node with a src attribute is added to the DOM via JavaScript, or 3) any existing img has its src changed via JavaScript. This should be standard across all browsers. As a developer, you should be able to control when images are loaded by keeping these three in mind. Note that browser image caching rules apply according to the HTTP headers sent with the image. --Ken Snyder --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Event.element() oddity
Hi Guys, I was using Event.element(event) in an image onload observer and I noticed that in IE, it would return the Image element while in FireFox it would return a [object HTMLDocument]. I used the guts of the Event.element and changed it to $ (event.currentTarget || event.srcElement) and that fixed it. This is probably an edge case. More info about event targets can be found here. http://developer.mozilla.org/en/docs/DOM:event:Comparison_of_Event_Targets --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Hijack Browser Loading
[EMAIL PROTECTED] wrote: A simple unobtrusive approach would be to have a drawer of thumbnails with a link to view more images. For JavaScript enabled browsers, simply override the functionality of that link to load a list of image locations from memory or by AJAX. The only problem with that is people without JavaScript don't see those additional images. Let me explain a little more: I have three tabs, and only one can be viewed at a time. Therefore, I'd really only like the images to only be loaded in the first viewed tab, there's no since loading images in a tab people can't see. Then when people click over to another tab those images are loaded. Make sense? No. I don't see how you can click over to another tab or load more images unless you use JavaScript and or provide a link that loads a new page with new images. You can only control the loading of images by changing the URL or JavaScripting. Maybe provide an example page? --Ken --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Hijack Browser Loading
Here's a prototype I was working on: http://code.markhuot.com/image_trick/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Event.element() oddity
Thanks for the report. This sounds serious enough to open up a ticket, can you do that? While we're at it, does anyone really know the difference between target and currentTarget? Doesn't one of them correspond to what the this keyword references when the event handler is executed? On 6/13/07, jdalton [EMAIL PROTECTED] wrote: Hi Guys, I was using Event.element(event) in an image onload observer and I noticed that in IE, it would return the Image element while in FireFox it would return a [object HTMLDocument]. I used the guts of the Event.element and changed it to $ (event.currentTarget || event.srcElement) and that fixed it. This is probably an edge case. More info about event targets can be found here. http://developer.mozilla.org/en/docs/DOM:event:Comparison_of_Event_Targets --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Event.element() oddity
event.currentTarget is the element the event was attached to (i.e. it's equivalent to this). event.target == event.srcElement is the element that triggered the event. So for example: ul id=myUl li id=myLiclick me/li /ul $('myUl').observe('click', callback); If I now click on the click me text: event.target should be (if following the specs) li#myLi and event.currentTarget should be ul#myUl. On Jun 13, 7:38 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: Thanks for the report. This sounds serious enough to open up a ticket, can you do that? While we're at it, does anyone really know the difference between target and currentTarget? Doesn't one of them correspond to what the this keyword references when the event handler is executed? On 6/13/07, jdalton [EMAIL PROTECTED] wrote: Hi Guys, I was using Event.element(event) in an image onload observer and I noticed that in IE, it would return the Image element while in FireFox it would return a [object HTMLDocument]. I used the guts of the Event.element and changed it to $ (event.currentTarget || event.srcElement) and that fixed it. This is probably an edge case. More info about event targets can be found here. http://developer.mozilla.org/en/docs/DOM:event:Comparison_of_Event_Ta... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Event.element() oddity
On 6/14/07, Tobie Langel [EMAIL PROTECTED] wrote: event.currentTarget is the element the event was attached to (i.e. it's equivalent to this). event.target == event.srcElement is the element that triggered the event. Thanks, thats what I thought. I guess MDC docs confused me by not making this clear enough :-/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---